Got it. thank you.
At least in The UK, they are easily available at places like Farnell, and eBay…
Farnell/Element14 seems to cover most countries I tried - Spain, Germany, Hong Kong, Singapore… It’s not too hard I think 
.
The HUSBZB-1 is a combo zwave and zigbee controller. The ETRX3 does not have zwave and looks to cost about 2x as much. Chris also gave me a warning about the quickstick, but it’s been working well for me so far!
Sure - I know this doesn’t have the ZWave function, but I figured in this thread we were talking about ZigBee. I just want people to be aware of the limitations as it might not be a quick fix if someone comes across the issue (as we have already seen here!).
Your work on this project is so greatly appreciated.
I was able to get the HUSBZB-1 to work, openhab is getting the on/of events, but when i try to toggle the switch from openhab it does not work, and getting the following in the log.
[WARN ] [ing.zigbee.handler.ZigBeeThingHandler] - No handler found for zigbee:device:09a6fe9e:00124b000880c3d4:00124B000880C3D4_1_switch_onoff
Would you say it’s related to the bug or it will be fixed in your next update?
No - I don’t think it’s related to the bug. Probably it’s something else as this likely indicates that the dongle is working and the network is initialised.
What device is this and does Habmin show it as offline? After a restart, my Centralite outlet comes right up… every time. But my GE Link bulbs need encouragement! Some will come up online and some will be offline. Power cycling one of the bulbs (not necessarily one of the offline ones) and waiting a minute will get most of them back online. I just repeat until they are all online. If OH has been down for a long time, they all need a power cycle, after which they will flash. When there is a really stubborn one, I power the bulb off, start discovery, and then power it back on and the bulb will flash. If it is still offline, a power cycle will bring it back online. For really really stubborn ones, I reset the bulb and then do a discovery.
When my bulbs are marked offline, I see the error that you are getting and they cannot be controlled until back online.
Its a ORVIBO in-wall switch it shows online, and as said OH is being updated every time the switch is pressed, its simply missing the abllity to toggle the switch from OH.
Can I confirm what this means? When you click the physical switch on the device, OH updates, but if you click the switch in the OH UI, nothing happens?
If so, can you provide a debug log - for starters let’s look at exactly what happens when you click the switch - later we might want to look at the initialisation… So, if you can provide a few seconds of logging either side of you pressing the button on the UI that would be a good start…
SUPER newbie here, read as much i could before posting this and i was able to get zigbee and zwave bindings “online” using a HUSBZB-1 but unable to discover any of my devices (GE switch, sengled lights).
any help would be appreciated
I tried to get debug info but couldn’t seem to get it to show in \openhab2-userdata\log (like i said SUPER noob)
Have you reset your devices, if they had been previously paired? Sometimes they need a reset straight out of the box. And followed the manufacturers instructions for putting them into pairing mode before starting discovery? Sorry for asking the basics, but you did say SUPER noob .
Did you try this?
You got it exactly right, so here is a bit of logging.
Switch on → off
18:48:29.145 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - ← RX ASH frame: AshFrameData [frmNum=5, ackNum=7, reTx=false, data=37 90 45 00 04 01 06 00 01 0A 40 01 00 00 78 FF BF B9 FA FF FF 07 18 00 0A 00 00 10 00]
18:48:29.154 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - RX EZSP: EzspIncomingMessageHandler [type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=10, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=120], lastHopLqi=255, lastHopRssi=-65, sender=64185, bindingIndex=255, addressIndex=255, messageContents=18 00 0A 00 00 10 00]
18:48:29.163 [DEBUG] [.zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingMessageHandler [type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=10, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=120], lastHopLqi=255, lastHopRssi=-65, sender=64185, bindingIndex=255, addressIndex=255, messageContents=18 00 0A 00 00 10 00]
18:48:29.173 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 64185/1 → 0/10, cluster=0006, TID=00, reports=[Attribute Report: attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=false]]
18:48:29.190 [DEBUG] [.converter.ZigBeeConverterSwitchOnoff] - 00124B000880C3D4: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=false]
18:48:29.198 [DEBUG] [.converter.ZigBeeConverterSwitchOnoff] - 00124B000880C3D4: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=false]
18:48:29.216 [INFO ] [smarthome.event.ItemStateChangedEvent] - zigbee_device_09a6fe9e_00124b000880c3d4_00124B000880C3D4_1_switch_onoff changed from ON to OFF
18:48:29.232 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=6]
Switch off → on
18:51:26.017 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - ← RX ASH frame: AshFrameData [frmNum=3, ackNum=7, reTx=false, data=37 90 45 00 04 01 06 00 01 0A 40 01 00 00 7E FF BF B9 FA FF FF 07 18 00 0A 00 00 10 01]
18:51:26.049 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - RX EZSP: EzspIncomingMessageHandler [type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=10, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=126], lastHopLqi=255, lastHopRssi=-65, sender=64185, bindingIndex=255, addressIndex=255, messageContents=18 00 0A 00 00 10 01]
18:51:26.104 [DEBUG] [.zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspIncomingMessageHandler [type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=10, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=126], lastHopLqi=255, lastHopRssi=-65, sender=64185, bindingIndex=255, addressIndex=255, messageContents=18 00 0A 00 00 10 01]
18:51:26.132 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 64185/1 → 0/10, cluster=0006, TID=00, reports=[Attribute Report: attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]
18:51:26.157 [DEBUG] [.converter.ZigBeeConverterSwitchOnoff] - 00124B000880C3D4: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=true]
18:51:26.167 [DEBUG] [gbee.dongle.ember.ash.AshFrameHandler] - → TX ASH frame: AshFrameAck [ackNum=4]
18:51:26.157 [DEBUG] [.converter.ZigBeeConverterSwitchOnoff] - 00124B000880C3D4: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=true]
18:51:26.181 [INFO ] [smarthome.event.ItemStateChangedEvent] - zigbee_device_09a6fe9e_00124b000880c3d4_00124B000880C3D4_1_switch_onoff changed from OFF to ON
OH UI
19:08:09.736 [DEBUG] [ing.zigbee.handler.ZigBeeThingHandler] - 00124B000880C3D4: Command for channel zigbee:device:09a6fe9e:00124b000880c3d4:00124B000880C3D4_1_switch_onoff → OFF
19:08:09.795 [WARN ] [ing.zigbee.handler.ZigBeeThingHandler] - No handler found for zigbee:device:09a6fe9e:00124b000880c3d4:00124B000880C3D4_1_switch_onoff
19:08:09.847 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘zigbee_device_09a6fe9e_00124b000880c3d4_00124B000880C3D4_1_switch_onoff’ received command OFF
19:08:09.854 [INFO ] [smarthome.event.ItemStateChangedEvent] - zigbee_device_09a6fe9e_00124b000880c3d4_00124B000880C3D4_1_switch_onoff changed from ON to OFF
And here is what happens when I stop and then start the binding
I have switched now from Ubuntu to Windows 10 Pro on my Atom based hardware. I am on the latest nightly build of everything. I have used the serial driver from the “CP210x_Windows_Drivers” from Silicon Labs. From that package I have used the “Silicon Labs CP210x USB to UART Bridge” driver. It exposed the Zigbee functionality on COM3.
So in OH, I added the Ember thing with the port set to COM3 and baud rate to 57600. OH still shows the “Bad packet” log entry, but it seems to work nevertheless. My Ember coordinator shows as “online”. I can now control my hue lamps.
Despite seemingly working coordinator (HUSBZB-1), I still can’t discover following devices:
-Hue motion sensor
-Osram Smart+ switchable socket
I am on the latest nightly version of OH 2.2 and the binding. Is this to be expected, or do I need to troubleshoot?
I think you also need to enable debug logging for the main binding as well as the ZigBee library. I guess there is an issue during startup and for some reason it’s not configuring the channel.
The following command should enable logging on the binding.
log:set DEBUG org.openhab.binding.zigbee
Or maybe there’s some other filter on the log, but somehow I’d like to see the binding initialisation if possible.
I would not expect the motion sensor to work at the moment, but the socket probably should - I’ve tested both Bitron and SmartThings sockets along with a number of other switches.
here is another log, with the main binding in debug mode, I don’t think i have any filters on the log
The only obvious line I can see in the log is
14:34:24.565 [ERROR] [gbee.dongle.ember.ash.AshFrameHandler] - <-- RX ASH frame: BAD PACKET 11 11 34 7B A1 9C 54 26 C1 01
maybe an unhandled exception is being raised by this packet which cancels out the initialization.
I got it working, the caveat was that I needed to start the device scan before I plugged the socket in. That made it show up.
The Osram socket is produced by Ledvance, marketed as Sylvania in the U.S. and uses the Zigbee Lightlink protocol.
Thanks - I’ll take a look.
I don’t think so - the device is working, and the “ASH” messages are low level device message issues. The problem is more likely to be in the higher level parts of the binding. Anyway, I will take a look at the logs and see what I can see…