Issue #276 has been updated by Stefano Lenzi.
Philipp Buluschek wrote: > I currently use the dirty 2nd byte version :-) > > I think we should keep the ZigBee/Profile separation clean. But as we call > invoke with a "Cluster", it is already specific to ZCL messages. Also the > response AF_INCOMING_MESSAGE has a "clusterID" field which hints at the use > of the ZCL. Thus my question whether all AF_INCOMING_MSG are in fact ZCL > frames. > I agree! We can expected that 99.0% of the AF_INCOMING_MSG are ZCL Frames but is not guarantee, so fare the ZCL frames are the payload of AF_* API so anything can be transmitted. For example: vendor specific application can use their own data, or a user can send ZDP frame for ZDO cluster that are not supported by the dongle > How is a profile which does not use the ZCL supposed to be handled? Maybe not > through the AF layer? As I said the AF Layer is general purpose and it is the reason for keeping it clean from ZCL layer, the application sending data is the only aware of the meaning of the byte[] content of the it.cnr.isti.zigbee.api.Cluster > If the AF layer is purely ZCL specific, we can use the 2nd byte solution > without breaking separation (ie. all profiles using the ZCL will be handled > correctly, not just HA) > > Else, I'm in favor of the ClusterFilter version. It's really the cleanest. > (the one where we use only send() and then register the listener is too low > level for the caller. This should be abstracted.) > AF is not pure ZCL specific so I will go for ClusterFilter, moreover the 2-nd byte solution must check the ZCL frame Header because if sending Manufacturer enabled ZCL frame then the transaction field will be the 4-th byte > So for me the decisive question is: are all AF_INCOMING_MSG ZCL frames? As I said the correct answer is NO even if most of the time we will expect ZCL frames ---------------------------------------- Improvement #276: Correct usage of ZCL transaction IDs http://zb4o.aaloa.org/redmine/issues/276#change-724 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
