Zigbee binding

No - not yet. These sensors (or at least the version I have) requires special treatment or they will remove themselves from the network. I’ve coded this up, but haven’t tested it as I found the Telegesis dongle didn’t pass through the message I needed :frowning: . I’ve now worked out how to solve it there as well and I’ll try and get this into the binding shortly.

I don’t think I’ve looked at this. If you have a log of this trying to join then please send it over and I’ll take a look.

Never mind, I’ve got them back now. The way was as follows:
-Delete all zigbee items and things, including the dongle
-shut down OH
-paste zigbee things back into jsondb from backup
-start OH
-use hue dimmer to reset bulbs
-when bulbs show as online, recreate items.

I was never succesful in setting the panid from PaperUI. However, it worked in the jsondb eventually.

Out of curiosity, if a device would remove itself, would I see something like this in the log?

14:21:44.969 [DEBUG] [egesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisDeviceLeftNetworkEvent [networkAddress=14695, ieeeAddress=D85DEF11A1002A12]
14:21:44.979 [DEBUG] [ongle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisDeviceLeftNetworkEvent [networkAddress=14695, ieeeAddress=D85DEF11A1002A12]

I’ve noticed it with the Busch-Jaeger switch and didn’t really know what to think of it. It seems to rejoin as soon as I press the switch though.

OH snapshot 2.2.0 build 1099
Zigbee binding
HUSBZB-1 (Ember)

@chris, I saw a new unknown device show up, with nearly the same Attributes as the controller. I’m not sure what to do with this device. You’d stated that Things would not need to be deleted with the latest binding updates, but maybe the old controller needs to be removed?

Unknown Device


I’ll take a look at the discovery to see how it’s differentiating this. The address is 0, so this is the controller and it therefore shouldn’t be detected as a thing…

Is your ember still working ok? No more logs with the communication stopping issue?

Thank you for confirming! I’ll leave it alone for now.

I’m still trying to troubleshoot, but something is not quite right. At this point, I haven’t been able to determine if it is the Zigbee binding or OH. Occasionally, I am seeing random bulbs not responding to rules or UI commands, even though the Thing is online. They come back after a restart. Upgrading to build 1099, I am no longer seeing the error I’d reported earlier (copied below), but I also saw this error turn up once for a zwave device which was unresponsive, so it does not look binding specific. Even though the error is not coming up, I am still getting unresponsive devices. That is why I restarted last night. Unfortunately, after going for a few days without issues, I thought all was well and had turned off debugging.

2017-11-21 04:23:47.310 [WARN ] [e.core.thing.internal.profiles.ProfileCallbackImpl] - Cannot delegate command 'OFF' for item 'DS_FurnaceRoom_Bulb' to handler for channel 'zigbee:device:9b51c72d:7ce524000012cc42:7CE524000012CC42_1_switch_level', because no handler is assigned. Maybe the binding is not installed or not propertly initialized.

Thinking it may be related, I tried this a week ago, but it was obviously not a cure and will remove it before my next restart.

Here’s a random oddity… I had a few bulbs that I had swapped out with dimmers and decided to put them in our stove hoods. They were still paired and showed online when turned on. I added items and saved the file, but the links weren’t created. Even after a restart of OH, the links were still missing. I had to manually create the links to control the lights. I didn’t see any errors, but I do have debug logs, if you’d like them. This is another one that could be either the binding or OH.

submitted: http://www.cd-jackson.com/index.php/tickets/zwave-log-ticket/viewticket/ticketid-306

With this binding, is there a way I can see (in a rule) which colormode my hue bulb is in?

The item connected to the bulb should show the colour if that’s what you mean? Or does colour mode mean something else (I’m not super familiar with all the features these bulbs support!).

I’d like to know whether the bulb is showing a certain hue/brightness/saturation or a brightness/color temperature. It comes down to whether the bulb is showing whites or colors. Whenever I touch the HSB controls, the bulb switches to color mode, when I touch the color temperature slider, the bulb is in color temperature mode. The mode doesn’t reflect in either of the sliders though. The hue hub API seems to be able to tell what mode the bulb is in, so the information is most likely transmitted somewhere.

The reason I would like to distinguish, is that I have a mix of color bulbs and switched conventional lights. Whenever I use color, I would like to turn plain white lights off automatically.

If it isn’t in the binding, I will probably solve it by a virtual switch: Touch a color parameter, switch one way, touch a CT parameter, switch goes the other way.

It’s not in the binding at this point. Please add an issue to the issue tracker and I will take a look at adding a channel - it’s not too hard to do.

1 Like

I just took a few moments to test the latest update and I can confirm my problem has not been resolved, I looked through the logs and i found the following line maybe it will shed some light.

16:52:50.875 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=3, reTx=false, data=F8 90 45 00 04 01 06 00 01 01 40 01 00 00 EC FE B4 67 B1 FF FF 08 18 F8 01 00 00 00 20 00]
16:52:50.890 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - RX EZSP: EzspIncomingMessageHandler [type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=236], lastHopLqi=254, lastHopRssi=-76, sender=45415, bindingIndex=255, addressIndex=255, messageContents=18 F8 01 00 00 00 20 00]
16:52:50.917 [DEBUG] [.zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingMessageHandler [type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=236], lastHopLqi=254, lastHopRssi=-76, sender=45415, bindingIndex=255, addressIndex=255, messageContents=18 F8 01 00 00 00 20 00]
16:52:50.945 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=45415/1, destinationAddress=0/1, profile=260, cluster=6, addressMode=null, radius=0, sequence=248, payload=18 F8 01 00 00 00 20 00]
16:52:50.962 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=248, commandId=1]
16:52:50.981 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [On/Off: 45415/1 -> 0/1, cluster=0006, TID=F8, records=[Read Attribute Status Record: attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, status=0, attributeValue=0]]
16:52:51.002 [DEBUG] [.converter.ZigBeeConverterSwitchOnoff] - 00124B000880C3D4: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=0]
16:52:51.005 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6]
16:52:51.002 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Boolean
16:52:51.041 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - Sent queue larger than window [1 > 1].
16:52:51.053 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00124B000880C3D4: Initializing ZigBee thing handler
16:52:51.063 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameNak [ackNum=3]
16:52:51.077 [DEBUG] [org.openhab.binding.zigbee           ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.firmware.FirmwareUpdateHandler}={service.id=447, service.bundleid=242, service.scope=singleton} - org.openhab.binding.zigbee
16:52:51.082 [DEBUG] [iscovery.ZigBeeNodePropertyDiscoverer] - 00124B000880C3D4: ZigBee node property discovery start

Is there an exception being printed somewhere with a stacktrace? There’s an exception in the log here, but no stack trace so I don’t know where it has come from.

Can you also say exactly what you did to cause this? Is it changing the state of the device somehow?

correct no stacktrace


here is another full log, it happens when i do bundle:stop, then bundle:start.

please search for “ClassCastException”

Exactly what you said before there there is probably an exception when the device is initializing before the handler is being created.

Thanks - I have an idea what may cause this. It’s an issue with the binding I spotted a while ago, but thought it wouldn’t be an issue for a while - I might be wrong there… ;(

I can now confirm the Busch-Jaeger 6711 U flush-mounted relay insert as working.
It has two channels, switch and dimmer. However, the dimmer channel just switches the light but doesn’t seem to change the light level. Maybe dimming only works with the 6715 U insert.

@chris you can add the BJ 6710 U to your list of supported items, I think it’s called 6711 U-500 for the international market.
Loving it, thanks for developing this awesome binding!

Looking forward to the XML export to get the battery powered switches working too :wink:

1 Like

Thanks. I’ve added the XML so this should be in the build in the next day or so.

1 Like

Thanks for adding this!