search

dresden-elektronik / deconz-serial-protocol

deCONZ Serial Protocol
7 stars 2 forks source link

No response from the conbee 2 #10

Closed pwielders closed 2 years ago

pwielders commented 2 years ago

Version information from the stick: 2.11.02 / 14/03/2021 266B0700

According to the documentation after sending: APS_DATA_INDICATION command (17 : 24: 00: 07:00: 00:00: 3A:FF:C0)

APS_DATA_INDICATION 0x17 - Sequence 0x24 - Reserved 0x00 - Frame length 0x0007 - Payload length 0x0000 - Checksum 0xFF3A

I should receive the data, but nothing happens. Anything I am missing here ? Also the Device State (0x0E) report 0xA6. This is 1010:0110. What does this highest bit mean ? Documentation does not describe the two highest bits, but the highest bit (0x80) is on ???

Full log: Receiving: 0E:20:00:07:00:A6:00 Sending: 04:22:00:07:00:00:00 Checksum 4F:FF Receiving: 0E:21:00:07:00:AE:00 Sending: 17:24:00:07:00:00:00 Checksum 3A:FF Receiving: 0E:22:00:07:00:AE:00 Sending: 17:26:00:07:00:00:00 Checksum 38:FF

pwielders commented 2 years ago

More experimenting with this show that this stick "hangs". I need to close the Serial port an open it again to get it operational. Hereby the full exchange logs:

[ Extracting information from the stick, works fine !] Sending: 07:12:00:08:00:00:00:00:DF:FF:C0 Receiving: 07:12:00:08:00:A2:00:0A

[Trying to get a ZDO information, the 64 bit address (profile/ZDP, cluster 1 -> Request 64 bits address of remote device)] Sending: 12:18:00:1B:00:14:00:01:00:02:42:3F:00:00:00:01:00:00:05:00:01:42:3F:00:01:04:00:96:FE:C0 Receiving: 12:18:00:09:00:02:00:22:01 [ indicates success, 0x00 and device state => 0x22]

Receiving: 0E:19:00:07:00:AE:00 [ State update 0xAE, highest bit 8 [0x80] ??? and there seems to be data and a send confirm]

Sending: 17:1B:00:07:00:00:00:43:FF:C0 [ requesting the data that is available but no response !!!! Why ??? ]

[Waiting for several seconds, than trying to read the config, which prior to the send was working]

Sending: 07:1C:00:08:00:00:00:00:52:FF:C0 [ Also no response, however it was working prior to the first Send...]

pwielders commented 2 years ago

More testing shows that the beacon information continues to operator properly, also removed the receiver of the message (turned it off) and it is observed that after some time the APS_DATA_CONFIRM is send as an unsollicited message but if the status is requested, there is also no response. See logs below:

Sending: 12:14:00:1B:00:14:00:01:00:02:42:3F:00:00:00:01:00:00:05:00:01:42:3F:00:01:04:00:9A:FE:C0 Receiving: 12:14:00:09:00:02:00:22:01 [after approximatly 10 seconds] Receiving: 0E:15:00:07:00:A6:00 [ Still puzzled what the highest bit 0xA6 -> 0x80 means. Not documented in the spec here!!] Sending: 04:15:00:07:00:00:00:5C:FF:C0 [ No response on this request for the information]

Receiving: 1C:16:00:0C:00:05:00:02:D2:F8:87:B3 Beacon: 0xF8D2 Quality: 135 RSSI: -77 Lifetime: 0 TimeOut: 0

Receiving: 1C:17:00:0C:00:05:00:02:D2:F8:8F:B4 Beacon: 0xF8D2 Quality: 143 RSSI: -76 Lifetime: 0 TimeOut: 0

pwielders commented 2 years ago

Found the bug, there was an unitialized variable, that casued havoc on the CRC claculation. Problem solved ! Sorry for any inconvenience! Although I am still eager to learn what the highest bit means as it is not documenetd :-) Does it maybe mean received invalid CRC ? and if so how can I clear it ?