Apologies if a dumb question, but I’ve just been given one of these to add some Zigbee devices to an existing, mostly Z-Wave, OpenHAB install, and I just can’t understand what is the point of this device.
It appears to require some additional software called deCONZ (an unfortunate choice of name from the point of view of French speakers) running on a host computer to actually do anything.
My own OpenHAB uses ZigBee with an Elelabs ELU013 which is plug and play, with no poorly supported additional software to install, and it works like a charm. Oh, and it’s cheaper too.
I have sent back the Phoscon gadget and will get an ELU013 once they’re in stock once again, so that’s my installation issues solved in Alexandrian fashion. I am just baffled at why would anyone bother to produce such an uncompetitive device?
As described on that page the software offers an UI for configuring the device and your zigbee devices and it offers a REST API so that it indeed does something in a way that you even can use it standalone on a linux system ( I assume on other platforms as well ).
So in addition to the €40.- radio gadget you have an RPi (€60‒€80 before chip shortage, saw one for €240 the other day ) with some specific software installed to make the thing talk to the OpenHAB Deconz binding, all this just to communicate with a Zigbee device?
What is the advantage over getting a proper Zigbee coordinator that works out of the box, doesn’t require additional hardware or software and talks directly to the OpenHAB Zigbee binding?
Just curious. Maybe the device has some other application that I’m not aware of, but it seemed so pointless to me that I had to ask.
Price isn’t everything, and you’re very wrong calling it a poorly supported software. It’s right the opposite.
They support even many of the cheapish Ch*nese sensors such that don’t work well with the OH ZigBee binding because they ignore the ZigBee standards whereas the binding is pretty strict.
I used both, ELU013 and Conbee and would ever again choose the latter.
You wouldn’t have needed to bother installing additional software if you had used openHABian instead, it accomplishes that for you.
Haven’t tested but I guess it would work, too, to run that if you install standard openHABian (plus deCONZ via menu option) on that RPi. Like you said the difference is only shield vs USB. Shields/HATs use serial connectors, Conbee has an additional USB2serial bridge chip. Same for ELElabs, they also offer both variants.
No. Normally you would be running your main openHAB on the RPi, too. So price is €40 hence not so uncompetitive. I guess Jan’s exotic split setup is for other reasons unrelated to ZigBee.
Yes, that may work. The reason it is split is that my openHAB runs not on openHABian but on a PC Engines APU (along with some other software) and this system is mounted in the basement in a rack. This configuration is much older than the ZigBee setup.
The Raspberry Pi with the RaspBee (which is a Phoscon gateway, but that was not available as complete system when I ordered it) is located in the center of the house for better connectivity.
Rule of thumb: keep it simple - in your case: use the Zigbee Binding. But: sometimes reality gets into the way and a particular device isn’t supported by the Zigbee Binding. In this case there are three options:
replace the unsupported device with a supported one or
use additional software to integrate the unsupported device into openHAB (Zigbee2MQTT, deCONZ, …).
Just to give a - somewhat different - example:
Right now I’m evaluating how to make my dumb 50+ GU5.3 bulbs smart. Basically, there are two options (leaving aside some exotic technologies like DALI and DMX):
use Zigbee GU5.3 bulbs (Gledopto, …)
use Milight GU5.3 bulbs (FUT104)
I could integrate the Zigbee bulbs into one of my existing Zigbee networks (Zigbee Binding and Zigbee2MQTT) - no additional hardware/software would be required. But: I can get the Milight bulbs for half the price of the Zigbee bulbs … I even built a Milight gateway based on a NodeMCU and NRF24L01+ for evaluation purposes - it works, but I tend to prefer option 1 to keep the whole setup as simple as possible - even though it will cost me a lot more money.
I’ve been using zigbee2mqtt instead of the ZigBee binding because it supports the devices that I have. Quite liking it and so far have had no reason to change.
The dongle costs $20 (sonoff) and the software is free.
I have used deConz since I lost all settings using the Ikea Hub.
Never tried the OH Zigbee binding.
I list a few deConz pros/cons I have found.
Please fill me in on what OH Zigbee matches or even does better.
Deconz pros:
device Firmware OTA update & Conbee Firmware update over USB.
direct switch/device associations setup through the Old WEB App. (Switches work on groups with Hub down, good for WAF). No need for clumsy button pairing.
native groups, making large groups turn on/off/dim in perfect sync
new SW version every month or so with devices added every time
support large networks, now up to 512 devices
good network map with live status/connection routes. Debug and device config access through clusters.
supports database backup/restore making transfer to new host easy
Given that @chris does not get paid for doing this and already seems to have plenty in his hands I tend to opt for option two, either scanning the web for reports of the device operating correctly with OpenHAB or trying it out and returning it if it doesn’t work satisfactorily. If I was conversant with Java and could contribute more effectively, I would certainly try collaborating with Chris when I come across a new device with incomplete support.
Option three (Zigbee2MQTT) did cross my mind a few times, especially since I already use and am familiar with MQTT, but so far it hasn’t justified the added complexity and the more links in the chain the higher the potential for anything to go wrong.
) with some specific software installed to make the thing talk to the 
