Process AREQ SerialPacket as Response about zigbeenet HOT 5 CLOSED

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.

from zigbeenet.

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?

from zigbeenet.

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.

from zigbeenet.

@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

from zigbeenet.

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.

from zigbeenet.