zigbee-herdsman: Packet decoding bug in deconz driver?
Related to https://github.com/Koenkk/zigbee2mqtt/issues/12611#issuecomment-1240692790.
None of my IKEA remotes work in Z2M (they can pair just fine, but button presses are not recognized). I’m using Z2M with a ConBee (original, not model II). The exact same hardware combination works with deCONZ.
I dug a bit deeper and found out these in the logs:
2022-09-08T11:35:30.125Z zigbee-herdsman:deconz:frameParser DATA_INDICATION RESPONSE - seqNr. 59 srcAddr: 0xeaf8 destAddr: 0x0 profile id: 0x104 cluster id: 0x5 lqi: 255
2022-09-08T11:35:30.133Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":1,"manufacturerSpecific":true,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":31,"manufacturerCode":4476,"commandIdentifier":7},"Payload":{"value":257,"value2":13},"Command":{"ID":7,"parameters":[{"name":"value","type":33},{"name":"value2","type":33}],"name":"tradfriArrowSingle"}},"address":60152,"endpoint":1,"linkquality":255,"groupID":0,"wasBroadcast":true,"destinationEndpoint":53}'
2022-09-08T11:35:30.133Z zigbee-herdsman:controller:log 'zcl' data is from unknown device with address '60152', skipping...
So Z2M is seeing the zcl
data but cannot find the source device, and skips it. But note that the source address is supposed to be the NWK, and what is being logged is definitely not the NWK. I re-paired the remote forcing a change of NWK but the address being logged is always the same. The address is 60152
, or 0xEAF8
. which will be significant later.
I then used Zshark to sniff into the network and confirmed that the address being logged is not the address in the packets:
Note that the source address is always fixed as 0xEAF8
. It matches specific bytes of the IEEE address. I am assuming that there’s a bug in the decoding logic here: https://github.com/Koenkk/zigbee-herdsman/blob/b4cdf8ba6935ca20aa6967e1a0afed32f320e64b/src/adapter/deconz/driver/frameParser.ts#L241 and it is extracting the wrong bytes from the packet.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 32 (7 by maintainers)
@ChrisHae is this something you could check?