Closed eiaro closed 6 years ago
I understand your idea and it is exactly doing what is needed. I already have done the queuing in CCZnp, but because of the syncronous Response which is coming from serialport_datareceived event there is already a kind of async, but realised with events. Thats not very comfortable for the caller, especially not if he want's to combine requests like it is necessary on EndDeviceAnncdInd when you have to read device infos.
A very tricky Situation is to deal with sync requests, that not only hae a sync Response with status, but also are waiting for an async response. Because of that i already implemented a mapping in zdo_ReqRspMap.json
and handle it in ZpiObject
class with property public ZpiObject IndObject
.
An example is in ZclBridge.cs
on which i am currently working. Here i implemented the sending of ZclPackets (Zigbee Packets). It can be do by AF_DataRequest which is an SRSP, but it have to await a AREQ, too. (it's an ARSP but it does not have an own message type, because it is defined by direction property)
I still think events must be used, but hidden from the end user. When you send a packet that you expect a response to, the controller will wire it up so it only returns from wait when the response is in. That way it becomes easier for the user to keep his code clean and responsive.
I found 2 Errors:
I have added it and now it will compile. Please check it in your next commit
This is currently in a broken state. There are still work to be done to run able code, but I have to get some shut-eye.
The interesting stuff is the queues in CCZnp and the threads dealing with them. I think it gives you some breadcrumbs to show how I'm thinking to make this async. Main point is when the end user makes a Zigbee command and sends it to ZigbeeController, it will pass it on to CCZnp that will translate it to a Z-Stack message, put it into a SerialPacket and send it off. It will capture the response (if any) and relay it back to the awaiting end user. At least that's the idea... :)