[BitCloud] Binding to a group

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I'm testing the group binding stuff.
Then using indirect addressing with unicast bindings there dstAddrMode == 0x03 (MAC address + endpoint) all works fine.

But then using a binding to a group dstAddrMode == 0x01 (group address) it doesn't work.

For info, I'm sending a simple ZCL HA onOff command with
following destination addressing:

req->dstAddressing.profileId = HA_PROFILE_ID;
req->dstAddressing.clusterId = ONOFF_CLUSTER_ID;
req->dstAddressing.clusterSide = ZCL_SIDE_SERVER;
req->dstAddressing.addrMode = APS_NO_ADDRESS; // use binding
req->dstAddressing.endpoint = 0x01; // target endpoint
...
... default response disabled

the binding is created successful so here is no problem, but sending only works with unicast bindings.

In the ZCL_Response using the group binding, the status is 0xA6 (APS_INVALID_PARAMETER_STATUS). What does that mean, shouldn't sending work the same for unicast and group bindings? Also tried to set the req->dstAddressing.endpoint = APS_BROADCAST_ENDPOINT; but still same behavior.

Last Edited: Fri. Oct 16, 2015 - 02:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It should work. Just to be sure, show the parameters of your bind request.

You need to fill only source endpoint, target endpoint is taken from the binding table:

req->endpointId = xxx;

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

because of the group addressing the target endpoint should become broadcast i think.

here are the ZDP bind request parameters

bindReq.srcAddr = remoteAddr;
bindReq.srcEndpoint = remoteEndpoint;
bindReq.clusterId = ONOFF_CLUSTER_ID;
bindReq.dstAddrMode = APS_GROUP_ADDRESS;
bindReq.dstGroupAddr = testGroup; // does exist on some other nodes

The binding is created successful (verified by response status, and I could also do a unbind once and the entry is found).

I tried it with BitCloud 1.10 maybe something changed in the APS binding refactoring in 1.11.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manuelp wrote:
I tried it with BitCloud 1.10 maybe something changed in the APS binding refactoring in 1.11.
It is very likely that this functionality was broken, I don't remember, really. And now this code is completely rewritten, I think there was a reason for that.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok good to know, I give it a try.
thank you very much :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm this is weird, I ported 1.10 application to BitCloud 1.11.
The app is using STANDARD_SECURITY_MODE. and all ZCL_Requests are unicast. In 1.11 clusters from Components/ZCL/include like the OnOff cluster wich has cluster .security set to ZCL_APPLICATION_LINK_KEY_CLUSTER_SECURITY, stopped working.
I changed cluster .security to ZCL_NETWORK_KEY_CLUSTER_SECURITY but this doesn't help. The ZCL_Response() returns ZCL_SENDING_ERROR_STATUS after a while.

In contrast clusters wich has ZCL_NETWORK_KEY_CLUSTER_SECURITY like identify and self created clusters are working very well!

I don't understand why this is happening, there is no real technical difference between a OnOff and a Identify both with the same security settings. In BitCloud 1.10 the same code is working. Any idea?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

manuelp wrote:
I don't understand why this is happening, there is no real technical difference between a OnOff and a Identify both with the same security settings.
This is kind of normal. in BC 1.11 clusters were updated to use security defined by the specification for them, but what kind of security will be used depends on internal table record, but not on the cluster description. This will be fixed in BC 1.12.

But using incorrect security for a cluster means that you will be compatible only with yourself.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok thanks for the info.

Quote:
But using incorrect security for a cluster means that you will be compatible only with yourself.

Thats right but OnOff cluster should work with standard security since Home Automation for example is allowed to use either Standard or high security.

I guess some clusters can't be hard wired to a security mode since this sometimes is profile dependend.