Then it was plugged into a microPC already happily running Ubuntu and openHAB5 in a Docker container.
I followed the bits and pieces of information found about this in other discussion topics and articles:
lsusb finds it as “Silicon Labs CP210x UART Bridge”
ls -l /dev/serial/by-id finds it as /dev/ttyUSB0 which belongs to dialout group
the existing openhab user (mapped to userid 9001 in container) was added to dialout and tty groups
the container was redeployed in Portainer to attach the /dev/ttyUSB0 device on the host to the same path in container, and to add as extra environment options for Java -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0
within the container the /dev/ttyUSB0 was chmodded to o+rw
in openHAB I added the official ZigBee binding, then added a new Thing for ZigBee Coordinator with Ember Coordinator type, /dev/ttyUSB0 , software flow control and the rest are default (115200 8N1, boost power mode, normal transmit power, medium network size with 25 objects)
I ticked the Advanced box and enabled Reinitialize Controller.
With all the above, I do see in the Thing some new details being populated (PAN ID and others), which would suggest that the serial interface is working.
But the Thing is stuck in Initializing status, and I don’t have any other Zigbee devices to test connectivity.
Am I doing something wrong? Did I miss some steps? Is this a bug? What can I check (binding logs, permissions, anything)?
Thanks for the quick reply! I saw that post but, as Sonoff has already published the firmware version 8.0.2, the 7.4.4 released half a year ago on some random github repo did not appeal to me Sonoff boldly claims that the E model works with openHAB, so I’m still not finding any errors in judgment, decisions and the steps so far. Then why doesn’t it work?
Hi,
From what I recall and what I personally use the only firmware version that I saw and still see in the OpenHab zigbee documentation as verified for use in OpenHab is
6.10.3 which is the default firmware version that came with the dongle.
Other versions work with zigbee2mqtt and standalone solutions but unless the binding developer has changed it and the OpenHab docs require update It still only say 6.10.3 is what OH requires.
You might want to give reflashing with that version a try and see if it behaves differently.
Thanks - I did some more reading in various github issues, which were discussing the poor documentation of chip manufacturer’s releases and the “recent” complete swap of the SDK and code, the slowness of implementation in java libraries, and the slow adoption in various large or small projects. Home Assistant is among the leaders in speed, openHab is trailing among the last. The latest firmware version, 8.0.2, is for v14 of the code; and the one supported is v9 or so.
I have just downgraded the dongle back to the delivered firmware 6.10.3 and I’ll test it in the morning.
I’m slowly starting to see the discrepancy between a consumer’s understanding of technology based on marketing fanfare, vs. the reality of code, dependencies and standards adherence. I don’t actually have hundreds of products available that I can just pick from, based on various criteria, under the assumption that the Zigbee logo means they’ll all be compatible. It’s back to checking the Hardware Compatibility Lists like decades ago, to confirm that some specific product will work.
What I would appreciate is that openHAB’s own documentation for the Zigbee binding doesn’t only list the hardware dongles supported, but also the firmware versions supported, in no ambiguous terms. That’ll save the next guy some hours or days of research, and possibly some money.
I think what you will eventually find like many other ZigBee users do that if you truly want flexibility to use any kind of device that “brands” itself as ZigBee you will end up using the zigbee2mqtt solution.
This goes back to how many device manufacturers do not follow the ZigBee standard and as the binding creator has stated many times is the reason they do not work with the official OH ZigBee binding. The zigbee2mqtt approach tends to be more forgiving and tolerant to the “1 off’s” then the official OH binding is out of the box.
With that being said you will likely hit more challenges if you purchase devices off of places like Ali express or even amazon Tuya as one example is notorious for that problem as a fyi because they want you to use the cloud solution they market.
Now I remember that, back then, I included my learnings in the respective section in the binding documentation, to save others the time I invested, and now I‘d encourage you to do the same by suggesting an edit.
I tried both (the binding and zigbee2mqtt) and I have to say that the latter appeared by an order of magnitude more complicated to maintain, and I am really happy with the binding.
I actually use both in my prod setup I try it first on the OH zigbee binding and if it works great that is where it stays if it does not then it gets unjoined and added to the mqtt solution I agree the mqtt solution is more effort than OH zigbee binding but if I bought a one off or off brand device and it did not work for me in OH binding I am not going to just toss it or send it back because odds are I made the purchase for a use case that it was specific for that kind of device. Not based on a cost limit but a unique need that major brands did not seem to offer or have available.
I’d be more interested in which of the two ways to interface devices is more stable over time. I intend to use smoke detectors and water leak sensors, and this use case should not accept sensors that just drop offline randomly or require periodic resets.
I can live with being picky on which sensors I buy (and buying one first for testing). Most of the sensors are anyway for smoke detection - following legal requirements I need like 12 in the house, and they also need to be tested and DIN certified otherwise they’ll invalidate the house insurance in case of an event. That pretty much excludes cheap knock-offs from AliExpress, and forces me towards national distribution channels whose products would meet the legal compliance requirements.
Zigbee2MQTT is to me a complete black box at this time, so I can’t even make a comparison. However at a superficial view it does seem to introduce more dependencies / more links in the chain which can fail. Maybe I’m wrong and uninformed, and I’d happily stand corrected.
Ideally the water leak sensors should be able to communicate directly with a water valve motor and shut off the water, without having to pass messages through a third party that processes the information and makes decisions. For that reason I opted for HomematicIP for heating, because the thermostats bind directly to the actuators; the “hub” can join that wireless network to allow status monitoring and remote control, but is entirely optional, so if it fails for whatever reason (ie PoE injector bursts a capacitor) the heating in house doesn’t go down completely. But HomematicIP is a closed, proprietary ecosystem and the options for water leak and smoke totally suck, so here I am trying out Zigbee…
Interesting discovery just now, not sure how relevant it is for development/initial configuration. Seems to be related only to retaining existing configuration on zigbee2mqtt after flashing.
The dongle came with firmware 6.something and I upgraded it directly to 8.0.2 with Sonoff’s online firmware updater. Then I discovered that I can’t get it to work fully, and downgraded back to 6.10.3. Then you mentioned that 7.x should work. Sonoff offers a couple subversions in 7.4.x but not 7.3.x, so I attempted to flash 7.4.4, which popped up this warning (which didn’t appear for 8.x):
There are pro’s and con’s to both solutions. You may want to read about mqtt and then even set up a broker and play around with it. mqtt can used for more than just ZigBee devices. Is it somewhat more complex to set up initially? Yea is it more reliable? depends on where you install the broker. Is it better than a straight ZigBee solution within OH or HA or any other approach? That is a point of perspective. Does MQTT have a steep learning curve? That really depends on your technical abilities mostly.Is it more complex to setup and maintain? Yes it does have a different way of doing things so there is new terminology’s that you will need to learn but what is does allow for is adding any device that has mqtt capability and allows for many different solutions to subscribe to events. So, you can have a redundant solution getting input from a device at same time your primary solution is subscribed and receiving events from the device. This means you are not locked into just 1 monitoring solution for any published topic change. As I said before I use both in OH and find the intial setup of MQTT topics to be a bit tedious but once done they are rock solid as long as my Broker is running. I also use the OH zigbee binding and have very few issues with devices that are attached to OH via it as well. But I also use other devices that are just MQTT only and that work fine, and I use a zigbee2mqtt instance as well and subscribe to topics from the devices. It all depends on what you needs are and what you want It can be either a locked in approach or a flexible approach that allows more independence to handle the events from your device using different orchestrator solutions.
Using the Zigbee-Binding for two years straight now without a single hiccup and new devices being added in a matter of two minutes. Can highly recommend this.
