I would suggest to check your configuration for starters since you have at least 3 coordinators running -:
My zwave came up on ttyUSB0 and zigbee on ttyUSB1, but I have udev rules to give them static names in case they ever changed.
Not sure what you mean here… try /dev/ttyUSB1. Exactly what version of the binding do you have (bundle:list in Karaf)? What OS/version? Driver issue? Does the zwave side come up? Logs would probably help too.
Glad there are others with this device! Zwave has been working great but zigbee has some issues that Chris is looking into.
Sorry, by that I mean I try both /dev/ttyUSB0 and /dev/ttyUSB1 since I can’t tell which is Zwave and which is Zigbee.
Zwave does not come up either, but again, not sure what I’m doing.
The version is the latest version link you had, so here it is:
184 | Active | 80 | 2.2.0.201707272205 | ZigBee Binding
It’s a Raspberry Pi Zero W, Raspian, fully up to date.
And now that I know where to find logs, I see errors:
10:22:46.496 [ERROR] [andler.ZigBeeCoordinatorEmberHandler] - Serial Error: Port /dev/ttyUSB1 does not exist
10:22:46.508 [ERROR] [andler.ZigBeeCoordinatorEmberHandler] - Serial Error: Port /dev/ttyUSB0 does not exist
I found the tutorial about teaching OpenHAB to see serial port symlinks, but first I have to figure that out.
In the meantime, this is the info I can get about the ports. The only difference is a couple of 1-0 flips. How do I tell which one is Zwave and which is Zigbee?
Edit: I have followed the tutorial by modifying the karaf startup script and adding the line
-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB1 \ to the java start. Unfortunately, no change to the error in the logs.
Are there any steps I might not have done, or information that would help figure out why it’s not working?
Just FYI I had a response back from Dresden which has now got things moving. Their docs are a little light on information and have a lot of errors so it’s a little slow but I’ve now got the basic comms working with the ConBee.
Yeah! Those are great news. Step by Step. As soon as the stick is supported I will get one! Can’t wait to get rid of the hue bridge.
Does your zigbee binding work like zwave and needs some kind of database? I would like use zigbee devices beside bulbs. e.g. the Ubisys Lineup
I really would like to help support more things. I don’t know much about Java (but coding in general isn’t a problem), but ordering those Items and debug and make some ordinary copy paste and adjusting from existing devices may help 
No - it’s totally database free. At the moment it’s only really supporting a limited number of clusters (mainly associated with lights - dimmers/switches/colour). This can be added to though.
Zigbee is a bit more descriptive than Zwave so it doesn’t need the database. That said, I also plan to remove a large chunk of the dependancy on the database in ZWave as well when I get the chance.
These should work. I did some work with Ubisys a while back so I have a few of their devices and used them for some early testing on the binding. Note that the metering functions aren’t yet supported, but the switches/dimmers work fine (last time I checked anyway).
That would be great - there’s only so many dongles I can run myself 
. Once ConBee is (hopefully) supported, we’ll have 3 different dongles which is quite nice. Thankfully most of the system is common and it’s “just” the low level interfaces that change…
Are Zigbee green power devices supported? Specifically is there support for the Hue Tap?
No - not at the moment.
Do you know if adding support for it is a matter of adding code to the
binding or whether it’s lower down in stack (ex. Zigbee firmware layer)?
I’m not (yet) familiar with openHAB development but I’m pretty comfortable
with Java, so if it’s at the binding later I’d be interested in attempting
to add support.
It definitely requires specific versions of firmware, but at least some versions do support this. The latest Silabs firmware supports GP proxy (5.8 or 5.9 has it) and I think the very latest TI firmware also supports it.
I bought a Hue Tap a while back with a view to adding this, but I’m suspicious that it’s not working (since my professional protocol sniffer doesn’t see it, and it should).
If you want to look at adding support for GP, then you should in the first instance look at adding support to the framework.
Thanks! I have the TI CC2531 and the debugger so I can flash different firmware on. My Hue Taps are definitely functional (currently talking to a Hue bridge). If you know specifically which firmware I need to flash that’d be really appreciated - in the past I’ve found hunting down TI firmware to be a real pain.
I don’t know the specifics of TI - I normally develop with Silabs, but I did see an announcement that their latest stack for ZB3 included GP, but I don’t have a pointer. I guess if you just go to their ZStack homepage you should be able to download the link.
One issue though is normally TI provide their stuff in a Windows installer package - not so nice if you don’t use Windoze.
Hi Chris,
As told before i have some Xiaomi temperature devices, but they don’t work with the zigbee binding and the TI CC2531 USB.
Today after ordering it , my Xiaomi Gateway 2 arrives and with the Xiaomi binding de temperature sensor works great as expected.
I have also a cc2531 debug USB stick.
If i start a debug with the USB device and log all action when i learn the temperature sensor on the xiaomi gateway and aslo the normal operation can you take a look at it?
Maybe you can see what the problem with the zigbee binding?
It would be great if also the Xiaomi Devices will work with te binding,
Let me know, thanks in advance.
Mickel
I do have some Xiaomi devices here and will take a look at these when I get a chance. It’s worth noting though that the Xiaomi devices are not Zigbee compliant - they use Zigbee like communications, and 802.15.4, but that doesn’t make them compliant. I’ve seen other notes on the net that they don’t work with other Zigbee gateways such as SmartThings.
That’s not to say it’s not possible, and I do intend to see if it’s possible to make it work, but please be aware it may not be possible if the Xiaomi sensors don’t fully implement Zigbee protocols.
I’m not sure that logging USB traffic will help too much though - I’d probably need to see a sniffer log.
When changing the coordinator’s (Ember) channel in both Habmin and PaperUI, I get the following errors. Also, what is the purpose of the Reset Controller field?
2017-07-31 05:40:54.170 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Configuration received (Coordinator).
2017-07-31 05:40:54.171 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_port.
2017-07-31 05:40:54.172 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_channel.
2017-07-31 05:40:54.173 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_initialise.
2017-07-31 05:40:54.174 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_panid.
2017-07-31 05:40:54.174 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_macaddress.
2017-07-31 05:40:54.175 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_extendedpanid.
2017-07-31 05:40:54.176 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_networkkey.Configuration isn’t handled at that point - it only gets handled when the handler restarts. I’ll remove the log entry - but it won’t change anything.
It will reinitialise the coordinator - this makes changes to the coordinator configuration such as the PAN Id, EPAN Id, channel, etc. Otherwise the startup will just use the existing parameters.
Correction… when I make changes in PaperUI, I get the errors above. When I do it in Habmin, I get the following whether I set Reset Controller to true or not
2017-08-01 04:03:14.596 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Configuration received (Coordinator).
2017-08-01 04:03:14.596 [ZigBeeCoordinatorHandler ] - 000D6F000B29A0CB: Unhandled configuration parameter zigbee_channel.
I’m not sure I have this yet. If Reset Controller is false, will changes to the coordinator be saved and applied after the next startup… and if it is true, then the coordinator will restart immediately and apply the changes?
That’s just because PaperUI always updates every parameter, and HABmin only sends updates to parameters that have changed. This is one reason I don’t suggest to use PaperUI for this on ZWave - you can easily end up with 50 to 100 configuration updates being sent to the device when you change the device name (ie nothing actually changed, but now you have a LOT of configuration to send).
The configuration is only applied at the startup of the thing handler. What I can’t remember is if I restart the thing handler at this point in which case it would be immediate. It should restart immediately - I just have a feeling it might not…
If you can see the ports in the system but OH can’t, then my guess would be permissions. This may help:
That is a very handy thing to know, thank you!
When Reset Controller was false, none of the configuration changes were being saved in Habmin or PaperUI. When Reset Controller was true, PaperUI did not save the changes and did not restart the controller (or thing handler). Habmin did try to restart it, but then the binding was stuck in a loop of errors. I’m packing up the logs for you. Looks like the same errors I was seeing when restarting the binding. After I restarted OH, the changes to the settings I’d made were not applied. So, configuration changes did not save when Reset Controller was true or false.
I don’t think Reset is the best word to use here. And it’s a little scary too. Maybe changing Reset to Restart would work better?