Check the readme for the binding for an (incomplete) list of devices supported.
I believe that this is solved - I’ve had no reports of this for a long time.
We have prepared a User Guide on how to work with Elelabs ZigBee USB with OpenHAB.
Does the USB version work on a RPi based openHab ?
Yes. It does.
Does it work with all zigbee profiles ?
The adapter itself can work with ZHA, ZLL, Energy measurement profiles, but to my understanding ZigBee OpenHAB binding supports only ZHA profile right now. Though it can still work with the ZLL devices, just doesn’t support all the features, ZLL offers.
Does it work with HUE ?
Yes. It does. At least tested with the bulbs. More devices are on the test list.
Does it work with IKEA lamp motion and switches devices ?
Lamp yes, motion and switches to be tested.
I read posts that are indicating (for other zibee USB devices) the commutation stops after x hours and openhab has to be restarted to get it working again. Its this device not having this issue ?
Have not seen yet. Would appreciate a link to the problem description to get a deep look.
what version of openhab did you use ?
The required support for Elelabs USB Adapter was added since 2.3.0 ZigBee binding version. So 2.3.0+
Check the issues list - there are a couple of open issues. One I think is resolved through a thread blocking issue in the ASH layer, and I think is closed. The other is possibly still there for large networks. I will take a look at closing some of these as there have been no reports on this for many months.
I guess the answer to this question is that as this is simply a standard Ember NCP, IF the problem is still there, then this device will also suffer the problem.
Both my Xiaomi sensors and Philips Hue dimmer are discovered and then drop out the network within a few hours. I don’t have any other devices to test but, at least in my experience, I would say it’s still an issue.
If you have an issue, then please comment on it, and PLEASE provide logs so we can see if it’s the same issue and try and resolve it.
It’s very common for people to say “I have the same issue”, but without real information (ie logs!) it’s often very difficult to confirm this.
I doubt this is related to the issue that is reported on the issues list at the moment where the whole binding locks up due to too much traffic. Of course it could be, in which case this is a known issue, but if you only have a small number of devices, this is probably not the problem.
I should also add that the Xiaomi devices are well known for dropping off the network - there are also comments about this on other forums (eg SmartThings). These are not ZigBee compliant and I think don’t support routing properly, and I think will only connect to the coordinator directly…
I’m having issues with the Philips Hue dimmer too which as I understand is certified as ZigBee compliant.
I’ve raised https://github.com/openhab/org.openhab.binding.zigbee/issues/215 which has a log attached
1 Like
The hue dimmer is not supported by the binding, so this won’t work.
I’m confused as it looks like support was added here:
You’re right - this was added it seems. I’d forgotten since most remotes are not supported at the moment. I had a look at your log, but it doesn’t really show any problem - the devices all appear to be working from what I can tell and it would be useful if you can provide some information about what the log shows from the user perspective.
i’m using telegesis etrx357 usb lrs.
it works with baud rate of 19200. after changing the coordinator to 57600 i get errors.
on 19200 there are delays on dimmer synchronisations. (osram bulb)
2018-06-12 13:26:58.602 [me.event.ThingUpdatedEvent] - Thing ‘zigbee:coordinator_telegesis:08a2a421’ has been updated.
2018-06-12 13:26:58.988 [hingStatusInfoChangedEvent] - ‘zigbee:coordinator_telegesis:08a2a421’ changed from ONLINE to OFFLINE: Failed to startup ZigBee transport layer
2018-06-12 13:26:59.072 [hingStatusInfoChangedEvent] - ‘zigbee:coordinator_telegesis:08a2a421’ changed from OFFLINE: Failed to startup ZigBee transport layer to UNKNOWN
2018-06-12 13:27:01.271 [hingStatusInfoChangedEvent] - ‘zigbee:coordinator_telegesis:08a2a421’ changed from UNKNOWN to OFFLINE: Failed to initialize ZigBee transport layer
How did you change the dongle speed? Maybe it didn’t get set correctly as it looks like the dongle is no longer responding.
im using paper ui
Configuration --> Things --> Edit --> Telegesis Coordinator
how can i do it on another way?
Sorry - I’m a bit confused. The setting in PaperUI is to configure the binding to the configuration that is set in the dongle. If the dongle is set for 19200 (which is the default), then you need to set the binding to 19200, or it won’t work. If you set the binding to 57600, and have not somehow reconfigured the dongle, the binding will not be able to communicate.
It seems that you have not changed the dongle speed? I’d suggest to read the Telegesis manual to see how to configure this.
hups…sorry… my fault.
changing the baud rate directly on the stick -->. it works.
but short question. how can i manage the dimmer-delay on visualisation?
setting the dimmer will be executeted immediately, but the visualisation “jumps”
update: i have seen that it is a general problem.
btw thanks for the hard work!
I’m not 100% sure I understand what you mean…
Do you mean that you click on the slider to move from 0 to 100%, the slider shows 100%, then maybe 50%, then 100%?
If that’s what you mean, then this is an issue with the way OH works. There should be a setting that stops the UI updating from the command, and only updates from the state. This should (mostly) fix your issue I think, but I can’t find this in the ESH docs at the moment and as it’s not something I personally use I can’t look it up.
Maybe someone else will be able to comment on this.
yes that is exactly what i mean!
thank you
why does the baud rate resets after reboot of the OS. (from 57600 to standard 19200 in paper ui)
also it resets after scan of zigbee binding.
is this a bug?
It shouldn’t do this. I know others (using Ember dongle for example) can change the baud rate without problem (there are two different Ember versions, and they use different baud rate and different flow control), so I don’t see why the Telegesis dongle should be any different as it’s literally exactly the same code (ie it uses a common class for all dongle types).
I just did a quick test using the Ember dongle, and it definitely saves the baud rate…