Issue #276 has been updated by Stefano Lenzi. File bugfix_276.patch added
I have implemented the ClusterFilter solution but before applying to the trunk I want to release the current codebase. ---------------------------------------- Improvement #276: Correct usage of ZCL transaction IDs http://zb4o.aaloa.org/redmine/issues/276#change-725 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
