[zb4osgi Dev] [ZB4O - Improvement #276] Correct usage of ZCL transaction IDs
redmine at zb4osgi.aaloa.org
redmine at zb4osgi.aaloa.org
Thu Dec 4 14:12:40 CET 2014
Issue #276 has been updated by Philipp Buluschek.
In @WaitForClusterResponse.consume()@, why do we still check the transaction ID (which is always 0), and more importantly, why do we check the cluster ID. I think it woould make more sense to use the Filter for all the checks.
Basically a request sender must fully identify which messages he accepts as answer.
This makes the Filter mandatory in the call (not null), but this is a good thing in my opinion - having code with null objects increases the number of possible states (and thus the bugs) and also puts us at risk to have NPE.
Maybe we need a more general Filter interface like
public boolean accept(ZToolPacket);
which also support non ZCL messages.
Improvement #276: Correct usage of ZCL transaction IDs
Author: Philipp Buluschek
Assignee: Stefano Lenzi
Target version: org.aaloa.zb4osgi.zigbee.ha.driver-0.7.0
Has a patch: Yes
Has license agreement signed: No
In @ZigBeeDeviceImpl.invoke()@ the transaction ID is put to 0, with a comment that it is a bug in the Z-Stack, that the transaction ID of the incoming message is always 0.
In fact, this is intended behavior (see http://e2e.ti.com/support/wireless_connectivity/w/design_notes/transaction-sequence-number-z-stack-zigbee.aspx). There is no transaction ID which is valid for all incoming messages. But instead, each application must define its own transaction IDs.
In our case, we handle ZCL messages which have defined a transaction ID in the ZCL header. This is the value which must be checked to be sure that the incoming message corresponds to the sent query. (note that the transaction ID which is passed into AF_DATA_REQUEST is a different one (!). It is only used to match the AF_DATA_REQUEST to the corresponding AF_DATA_CONFIRM).
To correctly consume incoming messages, we should
- Allow the "Cluster" which is passed into invoke() to also provide its ZCL transaction ID (from the ZCL header).
- Add the ZCL transaction ID to the waiter (instead of the current transaction ID which is used only in the AF_DATA_REQUEST/AF_DATA_CONFIRM exchange)
- Allow the AF_INCOMING_MSG to return the ZCL transaction ID from the data (it's the 2nd byte in the data). In particular, it should not return the TransID value from the serial frame as it is always 0.
Currently the comparison of ZCL transaction IDs is done, for example, in @AttributeImpl.doClusterWideRead()@, but at this point it is already too late (the message was already consumed, we can just log an error).
One unresolved problem is how to identify if the incoming AF_INCOMING_MSG is actually a ZCL frame. Is it always so?
DO NOT ANSWER TO THIS E-MAIL ADDRESS, NO ONE WILL READ IT. PLEASE WRITE TO dev at zb4osgi.aaloa.org
ZigBee 4 OSGi - Redmine E-Mail Notificatioon
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://zb4o.aaloa.org/redmine
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev