Hi Mattia,

It seems you are doing everything alright. I need to test that I will come back to you shortly.

Regards,

    Badiss.

Hi John,

When you publish using "gecko_cmd_mesh_generic_client_publish" you get back the server unicast address via the "mesh_generic_client_server_status" event. This is a status report by a server model basically.

In there, the server address is present.

Hi Francois,

This is available if you implement the Health model server on the node but only after provisioning. The event "gecko_evt_mesh_health_server_attention_id" contains that information.

I haven't tested that myself as of yet, but you should get the event when being provisioned and if a health client calls cmd_mesh_health_client_get_attention.

Does that make sense ?

Regards.

Hi,

That is the unicast address. If the node is provisioned, you can get it through the "node initialized" event (gecko_evt_mesh_node_initialized_id).

If your node isn't provisioned, you get the unicast address assigned from the provisioner when the provisioning process is successful, through the "node provisioned" event (gecko_evt_mesh_node_provisioned_id).

If your node isn't provisioned, just ignore the unicast address you get from the "node initialized" event.

Secondary elements have their addresses assigned sequentially following unicast addresses of the primary element.

Regards.

Hi John,

The proper way would be to use subscription an publication group addresses.

One switch on the switch node may control a group of light nodes and the other switch another one.

You can have on the switch node element 0 and element 1 corresponding to switch 0 and switch 1. Each switch may implement the same model but publish to independent group addresses.

Does that make sense ?

Regards.

Hi John,

The proper way would be to use subscription an publication group addresses.

One switch on the switch node may control a group of light nodes and the other switch another one.

You can have one the switch node element 0 and element 1 corresponding to switch 0 and switch 1. Each switch may implement the same model but publish to independent group addresses.

Does that make sense ?

Regards.

Hi John,

The proper way would be to use subscription an publication group addresses.

One switch on the switch node may control a group of light nodes and the other switch another one.

You can have on the switch node element 0 and element 1 corresponding to switch 0 and switch 1. Each switch may implement the same model but publish to independent group addresses.

Does that make sense ?

Regards.

Hi John,

The proper way would be to use subscription an publication group addresses.

One switch on the switch node may control a group of light nodes and the other switch another on.

You can have on the switch node element 0 and element 1 corresponding to switch 0 and switch 1. Each switch may implement the same model but publish to independent group addresses.

Does that make sense ?

Regards.

Hi John,

The proper way would be to use subscription an publication group addresses.

One switch on the switch node may control a group of light nodes and the other switch another on.

You can have on the switch node element 0 and element 1 corresponding to switch 0 and switch 1. Each switch may implement the same model but publish to independent group address.

Does that make sense ?

Regards.

Hi John,

The proper way would be to use subscription an publication group addresses.

One switch on the switch node may control a group of light node and the other switch another light node group.

You can have on the switch node element 0 and element 1 corresponding to switch 0 and switch 1. Each switch may implement the same model but publish to independent group address.

Does that make sense ?

Regards.