Hello.
I am looking for help with the Zigbee binding. I believe that i have successfully gotten a few sensors to join my network and communicate with my radio, but i believe that there is an error in the ZigBee binding during device discovery that is preventing the device from making it’s way into openHab.
The short version:
In my openhab.log, i can see packets coming in from devices on the network. I can see devices exchanging information. During node discovery / capability enumeration, it looks like the sensor in question is replying with data, but for some reason it’s not being accepted and the ZigBee binding keeps re-running through the mesh-update procedure.
I am looking for clarification on what’s going on. I see the process move from
Discovery request IEEE_ADDRESS successfull. Advanced to NODE_DESCRIPTOR.
and then on to
Discovery request NODE_DESCRIPTOR successfull. Advanced to POWER_DESCRIPTOR.
and then i see the device reply back:
RX CMD: PowerDescriptorResponse [37493/0 → 0/0, cluster=8003, TID=NULL, status=SUCCESS, nwkAddrOfInterest=37493, powerDescriptor=RECEIVER_ON_IDLE, [DISPOSABLE_BATTERY], DISPOSABLE_BATTERY, FULL]
but then no meaningful progress seems to be made? Just multiple iterations of the
Starting mesh update
loop.
Furthermore, i see that the device is successfully reporting it’s abilities: Temperature and Humidity
2018-01-19 10:53:26.545 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Temperature measurement: 37493/1 → 0/1, cluster=0402, TID=06, reports=[Attribute Report: attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=2095]]
2018-01-19 10:53:26.563 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Relative humidity measurement: 37493/1 → 0/1, cluster=0405, TID=07, reports=[Attribute Report: attributeDataType=UNSIGNED_16_BIT_INTEGER, attributeIdentifier=0, attributeValue=5153]]
I am running openHab on an rasberryPi. I used the Habian image. apt-get reports no upgradeable packages at this time.
I am using the HUSBZB1. It is an EMBER USB stick; it has both a zWave and ZigBee radio exposed over two UARTs. I have gone through the dance needed to give the JVM access to the USBTTY that exposes the Zigbee radio and have set the baud rate appropriately.
I have turned on DEBUG level logging for both {{com.zsmartsystems.zigbee}} and {{org.openhab.binding.zigbee}}. but curiously, i never see “Power Descriptor returned” even though this source seems to imply that i should:
Attached to this post is ~ 700 lines from the log showing packets coming and going. The first line of the log is the first mention of the specific device ID. If you need more information, i am more than happy to provide it!
Other things to note:
This log line has some very weird bytes in it.
2018-01-19 10:53:05.324 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=1, commandId=10]
2018-01-19 10:53:05.327 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 37493/1 → 0/1, cluster=0000, TID=01, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=65281, attributeValue=
See:
$ hexdump -C openhab.log | grep -C 10 65281 # the string `65281` only appears once in the log file, when describing these attributes, see line `00707310` for the bytes `36 35 32 38 31`
00707270 20 52 58 20 43 4d 44 3a 20 52 65 70 6f 72 74 41 | RX CMD: ReportA|
00707280 74 74 72 69 62 75 74 65 73 43 6f 6d 6d 61 6e 64 |ttributesCommand|
00707290 20 5b 42 61 73 69 63 3a 20 33 37 34 39 33 2f 31 | [Basic: 37493/1|
007072a0 20 2d 3e 20 30 2f 31 2c 20 63 6c 75 73 74 65 72 | -> 0/1, cluster|
007072b0 3d 30 30 30 30 2c 20 54 49 44 3d 30 31 2c 20 72 |=0000, TID=01, r|
007072c0 65 70 6f 72 74 73 3d 5b 41 74 74 72 69 62 75 74 |eports=[Attribut|
007072d0 65 20 52 65 70 6f 72 74 3a 20 61 74 74 72 69 62 |e Report: attrib|
007072e0 75 74 65 44 61 74 61 54 79 70 65 3d 43 48 41 52 |uteDataType=CHAR|
007072f0 41 43 54 45 52 5f 53 54 52 49 4e 47 2c 20 61 74 |ACTER_STRING, at|
00707300 74 72 69 62 75 74 65 49 64 65 6e 74 69 66 69 65 |tributeIdentifie|
00707310 72 3d 36 35 32 38 31 2c 20 61 74 74 72 69 62 75 |r=65281, attribu|
00707320 74 65 56 61 6c 75 65 3d 01 21 c3 af 0b 04 21 c2 |teValue=.!....!.|
00707330 a8 01 05 21 07 00 06 24 01 00 00 00 00 64 29 1c |...!...$.....d).|
00707340 08 65 21 c3 a6 1e 66 2b 4d c2 8d 01 00 0a 21 00 |.e!...f+M.....!.|
00707350 00 5d 5d 0a 32 30 31 38 2d 30 31 2d 31 39 20 31 |.]].2018-01-19 1|
00707360 30 3a 35 33 3a 30 35 2e 33 32 39 20 5b 44 45 42 |0:53:05.329 [DEB|
00707370 55 47 5d 20 5b 62 65 65 2e 64 6f 6e 67 6c 65 2e |UG] [bee.dongle.|
00707380 65 6d 62 65 72 2e 61 73 68 2e 41 73 68 46 72 61 |ember.ash.AshFra|
00707390 6d 65 48 61 6e 64 6c 65 72 5d 20 2d 20 2d 2d 3e |meHandler] - -->|
007073a0 20 54 58 20 41 53 48 20 66 72 61 6d 65 3a 20 41 | TX ASH frame: A|
007073b0 73 68 46 72 61 6d 65 41 63 6b 20 5b 61 63 6b 4e |shFrameAck [ackN|
short version is these weird bytes
01 21 c3 af 0b 04 21 c2 a8 01 05 21 07 00 06 24 01 00 00 00 00 64 29 1c 08 65 21 c3 a6 1e 66 2b 4d c2 8d 01 00 0a 21 00 00 5d 5d 0a
edit just kidding about the log file! Apparently i’m too new. I’ll attach in a later post.
. Also, if you use a