Process AREQ SerialPacket as Response

Mr-Markus commented 6 years ago

https://github.com/Mr-Markus/ZigbeeNet/blob/0d06cf9d5b402de25a95c8ea38ce89e1ff84090e/ZigbeeNet/CC/CCZnp.cs#L403

At this Point it can happen that a packet with type AREQ can be read from InputStream. This is defined by TI in UNPI

Asynchronous Request transfer initiated by Host Asynchronous Indication – transfer initiated by NP. Both types of asynchronous messages use the same message type bit field (0x02). The type of message (request/indication) depends on which processor initiated the transaction.

Two Scenarios:

You send an SREQ and will return a SRSP with Status. But as second Response you receive an AREQ packet, too. Example: nodeDescReq which is send as SREQ but awaits a SRSP with Status if it was sent correct and a second AREQ that contains device info This is an AREQ packet that is send from client-to-server (Server = end device)
An end device in yout Network (e.g. Thermostat) is sending you new Information because Temperatur changed. This is also an AREQ packet. But is is send from server-to-client (Server = end device)

For Scenario 1 i already created a JSON mapping file zdo_ReqRspMap.json that defines which SREQ awaits which AREQ packet, too. In class file ZpiObject the property public ZpiObject IndObject holds the Information if there is an AREQ Response awaited

I think this Information have to be used here

eiaro commented 6 years ago

Yes, the code is kind of scaffold here due to it being 1am and I don't have a full knowledge of the protocol. So a SynchronousResponse would be similar to a ACK, and then you would wait for the corresponding AsynchronousRequest, right?

For the request you indicated... NP sends Cmd0 = 0x25, Cmd1=0x02 ED responds Cmd0=0x65, Cmd1 = 0x02 -> Just an ACK... ED responds Cmd0 = 0x45, Cmd1 = 0x82 -> Hey we get a response, put it in response queue.

How would one find what messages the ED can send without it being requested? How can we identify this as early as possible to put it in the right queue?

Mr-Markus commented 6 years ago

No problem, because of that i described the situation.

Not really as a kind of ACK. Mostyl it returns a status SUCCESS = 0x00 or FAILED = 0x01, but not all TI Requests Returns it. And sometimes it returns more than one param or even nothing.

Take a look:

"bindDevice": {
        "type": 1,
        "cmdId": 1,
        "params": {
          "req": [
            {
              "action": 0
            },
            {
              "commandid": 1
            },
            {
              "destination": 3
            }
          ],
          "rsp": []
        }
      }

or here

"getDeviceInfo": {
        "type": 1,
        "cmdId": 0,
        "params": {
          "req": [],
          "rsp": [
            {
              "status": 0
            },
            {
              "ieeeaddr": 3
            },
            {
              "shortaddr": 1
            },
            {
              "devicetype": 0
            },
            {
              "devicestate": 0
            },
            {
              "numassocdevices": 9
            },
            {
              "assocdeviceslist": 11
            }
          ]
        }
      }

As i understood some SREQ have an SRSP and then wait for a response by the device. Maybe it is an AREQ because the direction is server-to-client (enddevice to coordinator). And for that we have to put it into the response queue if it before a request with that awaited response was send.

I think that this few AREQ responses can only be send by device if they were reqested by coordinator. And if there is no request in request queue that awaits it is a normal device AREQ. So it should be possible to identify them.

Mr-Markus commented 6 years ago

@eiaro Are you working at this point? I would like to avoid conflicts because of working at the same Code at the same time. But It is fundamental for further work. If so I will try another issue #17 T4 template with @nicolaiw within the next days

eiaro commented 6 years ago

At the moment not working. I have no clue on how to read the files, and their names doesn't match the spec document so I am at a loss. See #19 for status.

Mr-Markus commented 6 years ago

Yeah names are different, becaue i got this file from another project and i don't know why they changed it, but because of the huge amount of commands etc. i haven't changed them and search by id or parts of Name by it... That is the reason of the Meta classes and the generic ZpiObject. But I will work on them and also try if it is possible to enhance that files or convert it to another format. Locally I already have created some toolt that do parsing it. With this Tools i created the Meta classes. It should be possible to convert them.

Mr-Markus / ZigbeeNet

Process AREQ SerialPacket as Response #18