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

ZigBee: Accessing local binding table on end device

I have an end device acting as a server, and I need to send data to a bound client. This is custom data, so I cannot use a reporting attribute. Basically I need to access the binding table on end device/server, and obtain the bindings for a specific endpoint and cluster in order to address the packet to the client and send it. 

No one of the examples show this, and it really hard to figure this one out from the documentation. I also see there are several questions regarding the same topic here on dev zone, but these has not been answered or its just referred to the multisensor example and reporting attributes, which really doesn't help as that is not what is queried.

  • Hello,

    What kind of data do you intend to send, and how do you plan to send it? Is it only the short or long address you need in order to send the data?

    BR,

    Edvin

  • And why exactly is it not possible for you to use the attribute reporting that is used in the mutlisensor example? Is your data not stored in a cluster? If not, then how is it stored?

    I think we need some more background before I can give an answer on this question.

  • It would be both events that arises on the end device/server and responses to commands received by the server. Typically the first byte of the data would be the op code (event/response identifier) then payload data (everything from 0 - n bytes). 

    Events should be sent to the device which is bound on the endpoint and cluster (the client), command responses would normally be to the device that sent the command (the/a client). In a normal case these two devices will be the same. 

    When the server receive a command, alle the necessary data is present in the received command to send a response, so then there is not issue, the problem however, are the events. For the server to be able to notify the client of an event, client must be bound on the server. An event may arise on the server at any point in time, event before it has ever received a command from the client, so no information about a client is available. Therefore the client shall bind on the server when the server joins the network or powers up, and then the server uses the binding information to send the events/responses.  

    Using an API as ZB_ZCL_SEND_COMMAND_SHORT for both events and responses I believe would the correct way to do it.

     ZB_ZCL_SEND_COMMAND_SHORT( \
    buffer, addr, dst_addr_mode, dst_ep, ep, prof_id, cluster_id, cb) \
    (zb_addr_u *)(&(addr)), dst_addr_mode, dst_ep, ep, prof_id, cluster_id, cb)

  • Hello,

    So you want to be able to send a message to the devices based on events on the server node, if I understand correctly, a bit similar to notifications in BLE (based on your case history, it looks like you have had some questions on the nRF51 back in 2015). 

    I don't see why you can't do this using a cluster and attribute reporting. Although there are parameters called minimum and maximum reporting interval, it is possible to disable this. please see the ZCL specification, section 2.5.7.1.5 and 2.5.7.1.6.

    If you set the maximum interval to 0x0000, and minimum != 0xfffff, then change-based reporting should be used. This means you are able to report whenever you want to, in your custom cluster. This is not mentioned in the online version (v6, which I linked to), but it is introduced in v7, which we use. The v7 spec is not publically available, but it says:

    "If this value [maximum reporting interval field] is set to 0x0000, and the minimum reporting interval field does not equal 0xffff there SHALL be no periodic reporting, but change based reporting SHALL still be operational".

    Is this something you can use? In that case, you can use zb_zcl_set_attr_val() (which is used in the multi sensor example). 

    If that is not suitable for your application, can you please explain why it isn't. I am sorry if I missed something important in your description, but I don't see why that wouldn't work.

    BR,

    Edvin

Related