This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Trying to send from a switch to a coordinator

This is probably a very easy question to answer and I apologise for not fining the solution myself but I have been trolling through the documentation for several hours now with no light in sight.

All the examples provided for Zigbee devices are set up to communicate directly from one device to another, eg. switch to light bulb. However, in the real world of home automation this is not the way it appears to work. Home automation networks have a coordinator that not only establishes the network and handles security but also manages all the interactions between devices. Switches do not talk to light bulbs directly but simply send their commands tot he coordinator or hub which is then responsible for deciding what to do in response to the command.

My problem is that there does not appear to be any documentation, at least not that I have found so far, that explains how to address the command correctly to send it to the coordinator. The coordinator is always address 0 but what about the endpoint? In my situation, using a SmartThings hub, the endpoint does not seem to matter as long as the address is set to 0. Is this correct? Is this the best practice or am I missing something here?

Parents
  • Hello,

    I am not sure if I understand your question correctly, but I'll give it a go.

    Not all messages go through the coordinator, but the coordinator is the first node in the network, the node that created the network, and the current coordinator will always have address 0.

    The ZigBee network is dynamic, so when the network is operative, the nodes will, based on the distance and signal strength of the messages between the nodes, and store this in the routing table. Hence, you can't decide which path a specific message should go. You can only control the destination address. So if the distance between two nodes has a shorter and/or more reliable path than the path through the coordinator, then this route will always be used between these nodes.

    Now, if you want to send a message to node 0, you can do this by addressing it to node 0. What sort of message do you intend to send? Does the coordinator have any endpoints that you want to use?

    Best regards,

    Edvin

  • Attribute reporting is what I was expecting here but the default setting for the nRF52840 library is to allow a minimum reporting interval of 1 second or more whilst the SmartThings hub asks for 0 seconds to get immediate reports when the attribute changes. I found the definition for ZB_ZCL_MIN_REPORTING_INTERVAL in the file zb_zcl_reporting.h and changed its value to 0. Now the hub is able to subscribe to attribute changes. Before this the subscription was rejected because the minimum requested time was too low but the hub did not report the rejection so I had no ides what was going on until I got a sniffer to watch the traffic.

    Next I had to ensure that whenever the light is turned on or off the attribute is reported correctly. If this is done locally by pressing a button one must use the ZB_ZCL_SET_ATTRIBUTE macro to change the attribute value accordingly. The nRF52840 will then report the change to anyone who is subscribed to that attribute.There can be a delay of up to 5 seconds for some reason but it does send the report and the hub is updated.

    It would be a HUGE benefit to have a debug setting for the stack that would allow it to trace the incoming and outgoing messages, like a locally limited sniffer. Without it, the developer really has to set up  network sniffer to find out what is happening since the information from the stack seems to be virtually non existent and there is almost no usable documentation on how it is supposed to be functioning.

Reply
  • Attribute reporting is what I was expecting here but the default setting for the nRF52840 library is to allow a minimum reporting interval of 1 second or more whilst the SmartThings hub asks for 0 seconds to get immediate reports when the attribute changes. I found the definition for ZB_ZCL_MIN_REPORTING_INTERVAL in the file zb_zcl_reporting.h and changed its value to 0. Now the hub is able to subscribe to attribute changes. Before this the subscription was rejected because the minimum requested time was too low but the hub did not report the rejection so I had no ides what was going on until I got a sniffer to watch the traffic.

    Next I had to ensure that whenever the light is turned on or off the attribute is reported correctly. If this is done locally by pressing a button one must use the ZB_ZCL_SET_ATTRIBUTE macro to change the attribute value accordingly. The nRF52840 will then report the change to anyone who is subscribed to that attribute.There can be a delay of up to 5 seconds for some reason but it does send the report and the hub is updated.

    It would be a HUGE benefit to have a debug setting for the stack that would allow it to trace the incoming and outgoing messages, like a locally limited sniffer. Without it, the developer really has to set up  network sniffer to find out what is happening since the information from the stack seems to be virtually non existent and there is almost no usable documentation on how it is supposed to be functioning.

Children
No Data
Related