Issue with ZigBee binding. Discovery request POWER_DESCRIPTOR failed but i see device replying w/ it's power profile!

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.

The log file that i have is too big to post here and i’m too new to the form to post logs… so if you want to see the log, i guess i can email it to you?

You didn’t mention which version of the binding you are using. If you are not using the latest, you will probably want to… lots changed/got fixed. Check this recent post (and the rest of the thread!)…

The code for electrical stuff was only recently included, and I’m not sure if it is all there yet (my Centralite outlet doesn’t show a channel for it yet).

Please post the log somewhere on the net and I’ll take a look. In general it’s not possible to post logs here - only very short ones anyway so you need to use something like Dropbox.

Alternatively you can email them to me at chris at cd-Jackson.com.

I’ve just merged it and will do a rebuild at some point today…

Good point. I was under the assumption that the latest stable/master is automatically installed w/ the openhab-addons package.

It appears that i am using version 2.2.0. I do not know how to get the specific build/git hash, though.

210 │ Active │ 80 │ 2.2.0 │ ZigBee Binding

The software powering these forums is, to put it charitably, hostile to quickly surfacing the most current information. a sticky thread w/ pinned posts for every new development / testing release would be appreciated. kudos for also putting the “how to install” instructions in one centralized place.

Nowhere in the top most posts (or bottom most) posts of the ZigBee binging thread is a clear statement that the binding is still under active development and there’s good reason to not use whatever ships with the distro.

It’s not clear to me where this updated binding lives? Chris has his own fork that’s several commits behind the “official?” repo. The official documentation:

https://docs.openhab.org/tutorials/advanced/installing.html

has a broken URL:
https://github.com/openhab/org.openhab.ui.habmin/tree/master/output

As does the other probable location:
https://github.com/cdjackson/org.openhab.binding.zigbee/tree/master/output

After a very careful scouring, it seems that this is the latest JAR:
https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/ws/bindings/org.openhab.binding.zigbee/target/

(version 2.3.0-snapshot)

It looks like

./var/lib/openhab2/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.2.0/org.openhab.binding.zigbee-2.2.0.jar

is a sym list to

./srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.2.0/org.openhab.binding.zigbee-2.2.0.jar

but after installing the 2.3.0 JAR and removing the 2.2.0 jar, but i still see version 2.2.0 in start up!

[10:21:09] root@openhab:/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.3.0# pwd
/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.3.0
[10:21:11] root@openhab:/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.3.0# ll ..
total 12K
drwxrwxr-x+ 3 openhab openhab 4.0K Jan 20 10:17 ./
drwxrwxr-x+ 4 openhab openhab 4.0K Jan 17 17:06 ../
drwxrwxr-x+ 2 openhab openhab 4.0K Jan 20 10:15 2.3.0/
[10:21:13] root@openhab:/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.3.0# ls -l
total 1144
-rw-rw-r-- 1 openhab openhab 1166777 Jan 20 10:08 org.openhab.binding.zigbee-2.3.0-SNAPSHOT.jar
-rw-rw-r-- 1 openhab openhab      41 Jan 20 10:15 org.openhab.binding.zigbee-2.3.0-SNAPSHOT.jar.sha1
[10:21:18] root@openhab:/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.3.0# sha1sum org.openhab.binding.zigbee-2.3.0-SNAPSHOT.jar
407c2f2e55ba8c787dcb07c136e798c7d0bc75fd  org.openhab.binding.zigbee-2.3.0-SNAPSHOT.jar
[10:21:26] root@openhab:/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zigbee/2.3.0# cat org.openhab.binding.zigbee-2.3.0-SNAPSHOT.jar.sha1
407c2f2e55ba8c787dcb07c136e798c7d0bc75fd

but it looks like i’m able to get the jar loaded when i put it in my

/srv/openhab2-addons

dir. and then a

bundle:uninstall

and then a

service openhab2 stop/start

and now i’m golden:

211 │ Active │ 80 │ 2.3.0.201801200902 │ ZigBee Binding

Cool! The documentation in this area is definitely lacking… maybe with your recent experience fresh in your mind you could update it? Once you do it once, it’s pretty straight forward and less tedious when the jar file name doesn’t change.

BTW, the location of the latest jar was included in the post I linked to in my first reply :wink:. Also, if you use a repository installation of the OH 2.3.0 snapshot, the bindings are much easier to update. IIRC, they update themselves on restart.

You should simply use the snapshot version of OH - that’s where the binding lives. If you use the snapshot runtime, then you can simply install the latest binding. Otherwise unfortunately it’s a little more difficult to manually include the snapshot bindings into a release runtime (as you are finding).

I don’t think so. I use standard development practices - I develop in my own repo, then create a PR and merge into the OH repo. So normally my repo is ahead of the OH repo as it has the newer stuff that’s not yet merged into the master binding.