ZigBee binding and obtaining destination endpoint information

[Glenn Ivar Klausen]

I'm implementing the door lock cluster on the server side (the door lock device), and needs to send event commands to the client (door lock controller/gateway) . According to the cluster definition, information like the client address and destination endpoint from the binding information. The problem is that the ZB_BDB_SIGNAL_FINDING_AND_BINDING_TARGET_FINISHED signal does not contain any parameters about the binding client, hence no information about the address or destination endpoint. 

You can only use reporting attributes on the door locked/unlocked status, no e.g. on event commands as responses to adding a new user on the door lock. The zb_zcl_door_lock.h defines e.g. this API/macro to send and event command:

#define ZB_ZCL_DOOR_LOCK_SEND_LOCK_DOOR_RES(buffer, \
addr, \
dst_addr_mode, \
dst_ep, \
ep, \
prfl_id, \
seq_num, \
status)

As you can see the destination ep and address is needed, but how does the server obtain that. 

I've gone through every single one of the Zboss examples, and none of them shows how to do this. 

From ZigBee Cluster Library Specification chapter 7.3.2.1 Alarms, Reports, and Events 

A door lock implementing all of the optional features provided in this cluster has the ability to push data to a controller in three different forms, Alarms, Reports and Events. Alarms are used to report critical states on the door lock. Reports are used to inform a subscribed device of changes of state in specific attributes on the lock. Events are used to inform a bound device about changes in state related to the operation and programming of the door lock. Event commands are sent to a binding. Examples of events are locking and unlocking the lock and adding or deleting a user on the lock.

 

[Edvin]

NB: We are really short staffed due to Summer Holidays in Norway. You must expect some extra delay in technical questions these days, I am afraid. I am sorry for the inconvenience.

I will get back to you as soon as I can, hopefully tomorrow.

[Edvin]

Hello Glenn,

All devices that are bound to an endpoint will receive a report when the endpoint changes state. You can test this similar to the test description of the multi_sensor example.

To test this, I compiled the unmodified ble_zigbee_dynamic_door_lock_nus example, and I used the cli_agent_router as the coordinator, and used the following commands (I simplified the address to simplify the reading):

> bdb role zc
Coordinator set
Done

> bdb channel 16 (change this if you are using another channel)
Setting channel to 16
Done

> bdb start
Started coordinator
Done

> zdo match_desc 0xffff 0xffff 0x0104 1 0x0101 0
Sending broadcast request.
src_addr=ABCD ep=8
Done

> zdo ieee_addr 0xABCD
1234567812345678

> zdo eui64
8765432187654321

> zcl bind on 1234567812345678 8 8765432187654321 64 0x0101 0xABCD
Done

> zcl subscribe on 1234567812345678 0x0101 0x0104 0x0000 48
Done

> log enable info zigbee.report

After this I connect to the doorlock with my phone (BLE). Then you can use the following commands to the NUS RX characteristic to lock/unlock the door:

"sesame" - will open the door.

"hodor" - will close the door.

When I open or close the door, I will see the reports in the log:

<info> zigbee.report: Received value updates from the remote node 0xABCD
<info> zigbee.report:     Profile: 0x0104 Cluster: 0x0101 Attribute: 0x0000 Type: 48 Value: 2
<info> zigbee.report: Received value updates from the remote node 0xABCD
<info> zigbee.report:     Profile: 0x0104 Cluster: 0x0101 Attribute: 0x0000 Type: 48 Value: 1

So I also subscribe to the cluster, but all data that is needed is present in the callbacks from the coordinator. 

Read through the multi_sensor test description, and test the short guide that I have here and see if you get the reports from the door lock cluster.

Best regards,

Edvin