Issue #276 has been updated by Stefano Lenzi. Tracker changed from Bug to Improvement Category set to zigbee.ha.driver Status changed from New to In Progress Assignee set to Stefano Lenzi Priority changed from Normal to Low Target version set to org.aaloa.zb4osgi.zigbee.ha.driver-0.7.0
I have assigned this issue to the _zigbee.ha.driver_ because it is the one that uses the ZigBeeDevice service, but the issue can affect also the following modules: * _zigbee.zcl.library_ * _zigbee.basedriver_ ---------------------------------------- Improvement #276: Correct usage of ZCL transaction IDs http://zb4o.aaloa.org/redmine/issues/276#change-709 Author: Philipp Buluschek Status: In Progress Priority: Low Assignee: Stefano Lenzi Category: zigbee.ha.driver Target version: org.aaloa.zb4osgi.zigbee.ha.driver-0.7.0 Has a patch: No 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 [email protected] 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
_______________________________________________ Dev mailing list [email protected] http://zb4osgi.aaloa.org/mailman/listinfo/dev
