Zigbee binding

Hi Kim,
seems you had some fun with

a while ago :wink:

I’ve now rediscovered one of my HUE motion sensors and I’m now getting some more channels discovered.
I do remember that Chris said one day, that not all discovered channels are supported necessarily by the particular device…

Anyway: Now I’ve noticed a “switch” channel (in addition to “occupancy”,“temperature”, “battery level/voltage/alarm”), which is new compared to my former tries (up to now I had just “motion”, “temperature”, “illuminance”, “battery level”).

Do you know, what the “switch”-channel is meant for and if it is working (and how)?
Is it probably the LED indication switch as I asked here:

Can you provide the full information on the channel?

I think it is simply a switch that these devices report - if I remember correctly, it’s a client side switch to allow switching of lights directly.

Hi Chris,
thanks for the quick reply :wink:

I’ve started the discovery of another HUE motion sensor:

2018-12-29 14:00:51.114 [DEBUG] [p.discovery.ZigBeeDiscoveryExtension] - DISCOVERY Extension: Starting mesh update for 0017880103285C97
2018-12-29 14:00:51.114 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 0017880103285C97: Node SVC Discovery: Update mesh
2018-12-29 14:00:51.114 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 0017880103285C97: Node SVC Discovery: has no tasks to perform
2018-12-29 14:00:51.115 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: NetworkAddressRequest [0/0 -> 65533/0, cluster=0000, TID=B6, ieeeAddr=0017880103285C97, requestType=0, startIndex=0]
2018-12-29 14:00:53.298 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ManagementLqiResponse [0/0 -> 0/0, cluster=8031, TID=NULL, status=SUCCESS, neighborTableEntries=4, startIndex=3, neighborTableList=[NeighborTable [extendedPanId=0B6209FECDE3B482, extendedAddress=0017880103285C97, networkAddress=33413, deviceType=END_DEVICE, rxOnWhenIdle=RX_OFF, relationship=CHILD, permitJoining=UNKNOWN, depth=1, lqi=1]]]
2018-12-29 14:00:53.299 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ManagementLqiResponse [0/0 -> 0/0, cluster=8031, TID=NULL, status=SUCCESS, neighborTableEntries=4, startIndex=3, neighborTableList=[NeighborTable [extendedPanId=0B6209FECDE3B482, extendedAddress=0017880103285C97, networkAddress=33413, deviceType=END_DEVICE, rxOnWhenIdle=RX_OFF, relationship=CHILD, permitJoining=UNKNOWN, depth=1, lqi=1]]]
2018-12-29 14:00:57.046 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: NetworkAddressRequest [0/0 -> 65533/0, cluster=0000, TID=C4, ieeeAddr=0017880103285C97, requestType=0, startIndex=0]
2018-12-29 14:00:57.046 [DEBUG] [pp.discovery.ZigBeeNetworkDiscoverer] - 0017880103285C97: NWK Discovery node rediscovery request failed. Wait before retry.
2018-12-29 14:00:58.423 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: BindRequest [0/0 -> 33413/1, cluster=0021, TID=C6, srcAddress=0017880103285C97, srcEndpoint=1, bindCluster=6, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:00:58.424 [ERROR] [converter.ZigBeeConverterSwitchOnoff] - 0017880103285C97: Error 0xffff setting client binding
2018-12-29 14:00:58.424 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Initializing channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_batterylevel with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterBatteryPercent@3bb8ea8c
2018-12-29 14:00:58.424 [DEBUG] [verter.ZigBeeConverterBatteryPercent] - 0017880103285C97: Initialising device battery percent converter
2018-12-29 14:00:58.424 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: BindRequest [0/0 -> 33413/2, cluster=0021, TID=CD, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:00:58.546 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: NetworkAddressRequest [0/0 -> 65533/0, cluster=0000, TID=CE, ieeeAddr=0017880103285C97, requestType=0, startIndex=0]
2018-12-29 14:01:06.424 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: BindRequest [0/0 -> 33413/2, cluster=0021, TID=CD, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:06.546 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: NetworkAddressRequest [0/0 -> 65533/0, cluster=0000, TID=CE, ieeeAddr=0017880103285C97, requestType=0, startIndex=0]
2018-12-29 14:01:06.547 [DEBUG] [pp.discovery.ZigBeeNetworkDiscoverer] - 0017880103285C97: NWK Discovery node rediscovery request failed. Wait before retry.
2018-12-29 14:01:06.855 [DEBUG] [verter.ZigBeeConverterBatteryPercent] - 0017880103285C97: ZigBee attribute reports ZclAttribute [cluster=POWER_CONFIGURATION, id=33, name=BatteryPercentageRemaining, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=200, lastReportTime=Sat Dec 29 14:01:06 CET 2018]
2018-12-29 14:01:06.855 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103285C97: Channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_batterylevel updated to 100
2018-12-29 14:01:06.855 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Updating ZigBee channel state zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_batterylevel to 100
2018-12-29 14:01:06.856 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Initializing channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_temperature with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterTemperature@180a7a72
2018-12-29 14:01:06.857 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: BindRequest [0/0 -> 33413/2, cluster=0021, TID=D2, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1026, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:08.047 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: NetworkAddressRequest [0/0 -> 65533/0, cluster=0000, TID=D3, ieeeAddr=0017880103285C97, requestType=0, startIndex=0]
2018-12-29 14:01:08.364 [DEBUG] [converter.ZigBeeConverterSwitchOnoff] - 0017880103285C97: ZigBee command receiveds OnWithTimedOffCommand [On/Off: 33413/1 -> 0/1, cluster=0006, TID=00, onOffControl=0, onTime=3000, offWaitTime=0]
2018-12-29 14:01:14.857 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: BindRequest [0/0 -> 33413/2, cluster=0021, TID=D2, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1026, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:14.857 [DEBUG] [converter.ZigBeeConverterTemperature] - 0017880103285C97: Failed to bind temperature measurement cluster
2018-12-29 14:01:15.088 [DEBUG] [converter.ZigBeeConverterTemperature] - 0017880103285C97: ZigBee attribute reports ZclAttribute [cluster=TEMPERATURE_MEASUREMENT, id=0, name=MeasuredValue, dataType=SIGNED_16_BIT_INTEGER, lastValue=2091, lastReportTime=Sat Dec 29 14:01:15 CET 2018]
2018-12-29 14:01:15.089 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103285C97: Channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_temperature updated to 20.91 °C
2018-12-29 14:01:15.089 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Updating ZigBee channel state zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_temperature to 20.91 °C
2018-12-29 14:01:15.089 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Initializing channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterOccupancy@2ae90dd
2018-12-29 14:01:15.089 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 0017880103285C97: Initialising device occupancy cluster
2018-12-29 14:01:15.089 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: BindRequest [0/0 -> 33413/2, cluster=0021, TID=D6, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1030, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:16.047 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: NetworkAddressRequest [0/0 -> 65533/0, cluster=0000, TID=D3, ieeeAddr=0017880103285C97, requestType=0, startIndex=0]
2018-12-29 14:01:16.047 [DEBUG] [pp.discovery.ZigBeeNetworkDiscoverer] - 0017880103285C97: NWK Discovery node rediscovery request failed. Wait before retry.
2018-12-29 14:01:16.489 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 0017880103285C97: ZigBee attribute reports ZclAttribute [cluster=OCCUPANCY_SENSING, id=0, name=Occupancy, dataType=BITMAP_8_BIT, lastValue=1, lastReportTime=Sat Dec 29 14:01:16 CET 2018]
2018-12-29 14:01:16.489 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103285C97: Channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy updated to ON
2018-12-29 14:01:16.489 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Updating ZigBee channel state zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy to ON
2018-12-29 14:01:16.609 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 0017880103285C97: ZigBee attribute reports ZclAttribute [cluster=OCCUPANCY_SENSING, id=0, name=Occupancy, dataType=BITMAP_8_BIT, lastValue=1, lastReportTime=Sat Dec 29 14:01:16 CET 2018]
2018-12-29 14:01:16.609 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Initializing channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_batteryalarm with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterBatteryAlarm@20ef307b
2018-12-29 14:01:16.609 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103285C97: Channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy updated to ON
2018-12-29 14:01:16.609 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Updating ZigBee channel state zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy to ON
2018-12-29 14:01:16.609 [DEBUG] [onverter.ZigBeeConverterBatteryAlarm] - 0017880103285C97: Initialising device battery alarm converter
2018-12-29 14:01:16.610 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: BindRequest [0/0 -> 33413/2, cluster=0021, TID=D9, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:17.548 [DEBUG] [pp.discovery.ZigBeeNetworkDiscoverer] - 0017880103285C97: NWK Discovery finishing node rediscovery
2018-12-29 14:01:18.086 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 0017880103285C97: ZigBee attribute reports ZclAttribute [cluster=OCCUPANCY_SENSING, id=0, name=Occupancy, dataType=BITMAP_8_BIT, lastValue=1, lastReportTime=Sat Dec 29 14:01:18 CET 2018]
2018-12-29 14:01:18.086 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103285C97: Channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy updated to ON
2018-12-29 14:01:18.086 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Updating ZigBee channel state zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy to ON
2018-12-29 14:01:23.090 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: BindRequest [0/0 -> 33413/2, cluster=0021, TID=D6, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1030, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:24.610 [DEBUG] [zigbee.transaction.ZigBeeTransaction] - Transaction timeout: BindRequest [0/0 -> 33413/2, cluster=0021, TID=D9, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:24.857 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Initializing channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_batteryvoltage with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterBatteryVoltage@59bd2496
2018-12-29 14:01:24.857 [DEBUG] [verter.ZigBeeConverterBatteryVoltage] - 0017880103285C97: Initialising device battery voltage converter
2018-12-29 14:01:24.857 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: BindRequest [0/0 -> 33413/2, cluster=0021, TID=DC, srcAddress=0017880103285C97, srcEndpoint=2, bindCluster=1, dstAddrMode=3, dstAddress=00124B0009EB11FC, dstEndpoint=1]
2018-12-29 14:01:26.308 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 0017880103285C97: ZigBee attribute reports ZclAttribute [cluster=OCCUPANCY_SENSING, id=0, name=Occupancy, dataType=BITMAP_8_BIT, lastValue=0, lastReportTime=Sat Dec 29 14:01:26 CET 2018]
2018-12-29 14:01:26.308 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 0017880103285C97: Channel zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy updated to OFF
2018-12-29 14:01:26.308 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 0017880103285C97: Updating ZigBee channel state zigbee:device:fdc78d39:0017880103285c97:0017880103285C97_2_occupancy to OFF
2018-12-29 14:01:27.298 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: DeviceAnnounce [33413/0 -> 0/0, cluster=0013, TID=NULL, nwkAddrOfInterest=33413, ieeeAddr=0017880103285C97, capability=128]

This is discovered as “Unknown Zigbee device …” with the seven channels as described above.
After adding this thing to the configurred things, a second thing is discovered as “Philips SML001 - Hue motion sensor”

If I accept the second one too, then this thing will have just the former four channels :wink:
Both seem to work (one with “motion” and the other with “occupancy”)

Seems if the device is announcing itself in two different flavours…

The log doesn’t really show anything relating to the discovery - all the requests are timing out. This is probably also why you see different flavours of the device being detected - the binding looks for the services that the device reports - if these requests don’t get a response, then the binding doesn’t know the service exists. Maybe sometimes the device responds, and other times it doesn’t - this results in different services being reported.

I think the switch channel is what I said earlier, although there’s no information in this log, but I seem to recall that it is what these devices report. So, it’s probably not a useful channel as it can only be used to report movement in a similar way to the other channels…

1 Like

This device is acting pretty strange in discovery mode.
I have mine discovered fine and added. But even though, when I start discovery again, the coordinator finds the same device again, add it and aprox 1 sec after, remove it. It IS the same device adresse as the one I have already included…

I havn´t paied enough attention to this matter, as the “original” device seems to be running just fine, even though the coordinator seems to find it everytime it perform an discovery.

Amt. though none of my zigbee devices is repporting due to the problem from yesterday. I have not restartet the server yet (or the binding), which I think is needed this time to get it running…

THe Philips SML001 (Hue motion sensor) will add 4 channels when beeing discovered allright.
Occupancy
Illuimiance
Temperature
Battery Level

Thats it.

1 Like

O.k. clear to me :wink:
I’m fine with the four channels.
Was just hoping to get rid of the annoying LED blink if motion is detected.

I have still stickers on the devices to cover the LED front :wink:

Thanks a lot for the replies Chris, Kim,

You cant, so keep the sticker :slight_smile: I dont even think you can, if you use the Philips Hue gateway. But I have never tried. I have been focusing on getting the Zigbee binding to work with my Hue and Zigbee devices…

With the latest 2.5 binding and 1.1.8 lib, it seems to run pretty good. Just got my devices up running again, after restarting the binding. So I have the Philips Hue motion sensor running, a Philips Hue Dimmer Switch, a Osram Lightify plug, and a Trust Motion sensor. All running Zigbee binding.
(My problem/crash yesterday is/was caused by something else, still struggling trying to find the reason and cure).

Actually, this is possible with the HUE bridge :wink:
When the HUE motion sensors are paired with it, the LED is just used as “low battery warning”:

Exactly, that’s my intention too. Thanks a lot to Chris for the good work!

Hmm, I did try when I first got the motion sensor. It has been almost two years ago. I could be wrong, but I think I recall that the led behaviour was the same back then. Perhaps things has changed since.

This is probably not the device - it’s probably the binding. The binding adds a temporary thing initially to indicate that a new device has been found - it may then update that later once it knows the device information. This used to work ok, and it might still work ok, but in the past few weeks ESH removed some of the functionality that bindings use to do this, so it’s also possible it’s not working as well any more.

I seem to recall we looked at this in the past, and it did not work with all devices (or it didn’t work with mine at least). If I remember correctly, my device didn’t support this attribute.

Yes :wink:
As I said, I can really live with it. The are more urgent things to look after for sure :wink:

@chris
What determines which channels a device supports?

I use to have a batterylevel for the Trust motion sensor. But now it´s a switch for Battery Alarm, and it seems to work in opposite way, when the switch is ON, the value is OFF.

It’s as I said a few posts above -:

the binding looks for the services that the device reports - if these requests don’t get a response, then the binding doesn’t know the service exists. Maybe sometimes the device responds, and other times it doesn’t - this results in different services being reported.

A new channel was recently added for the battery alarm - we didn’t remove the old channels so these can still be available.

But these will only be discovered during the very first discovery, or??

No - there are checks done at the moment each time the binding starts. I’m in the process of changing this -:

In theory if the XML file is still available this shouldn’t matter as the information for detecting the channel types is in the XML.

I was just wondering how to get the batterylevel channel back… Also the Tampering channel as well as the Motion Intrusion doesn´t really make sense cause they dont seem to work. So I wonder how/why they appear.

I have not removed and re-added the sensor, after I updated the binding the other day. I dont know if this is needed. But the binding has been restartet quite a few times since, (due to other issues I have on my system atm).

I believe its been stated a number of times that the binding simple adds the channels the device itself reports and that some of them might not work. Not sure if its something that can be easily changed in the bindings so my method has been to ignore them and also don’t link any items to them

The only way to change this is to add static definitions for every device. This isn’t something I want to do unless it’s really necessary as it’s quite a bind to have to maintain these every time anything changes - especially as the number grows (in ZWave for instance, we have around 850 devices and I had to write a large management system to maintain that, and it still takes me hours every week to look after!).

Sorry Chris, I almost added a note in my post that it probably wasn’t necessary and does not seem to me to be necessary. I was actually trying to save you the trouble of having to reply to yet another post asking why there are channels that don’t seem to do anything because thru 1779 posts and counting, you have worked so hard to support your binding.
Again… Thank you so much for you hard and tireless work

1 Like

I know. But…
The device report two channels which it isn´t using (or they´re not working… How am I suppose to tell the difference). And the battery level channel seems to be missing…

I would assume a device reports the same channels each time, and not depending on the binding. Thats why i asked!