Success with Sonoff zigbee bridge and zigbee binding

I didn’t manage without socat, but your errors seems different then mine.

Serial Error: Device cannot be opened on Port rfc2217://

Did you tried to telnet to Maybe the port is closed.


Yes, I’m able to telnet. There other threads here saying that zwave binding works with rfc2217 but not zigbee. And the issue in githut (by the way, a 8 month old one) says RFC2217 ports cannot be used because there is no discovery logic for these ports

To whom it may apply: I tried to get my zigbee bridge online with OH zigbee binding. Due to not supporting rfc2217 at the moment I configured socat accordingly as a service. Worked fine so far, I was able to open the serial port with a terminal emulator. But within the zigbee binding I received an error message that the port could not be found. Unfortunately no more messages in the OH logs. But I found the problem in syslog. Karaf wasn’t able to write a lock file in /var/lock. /var/lock is owned by root:uucp, so I added uucp group to user openhab and restartet OH: binding online :slightly_smiling_face:
It is because java/karaf opens a lock file when opening a serial port.
My system: ubuntu 20.04 LTS in a linux-container on a qnap nas, OH 3.1.0.M1


I am testing this on OH3. Does anyone know difference between Tasmota ZHAbridge and ZbBridge modules? Only ZHAbridge can be connected by socat at 8888 port. Neither other commands mentioned below (like ZbPermitJoin 1) are supported when ZHA current module or Zigbee map otherwise available when ZbBridge current module. Also wonder whether socat --dd command is blocking ‘by-design’ behaviour (it never returns when issued at terminal).

FYI, latest recommendation is to not use WiFi-based gateways like Sonoff ZBBridge as a EZSP bridge.

The reason for this is that EZSP protocol serial interface that OpenHAB (and Zigbee2MQTT as well as HA ZHA) uses does not have good fault tolerance methods for handling packet loss and latency delays.

I posted a deeper technical explanation and more detailed arguments here:


Tip! If still need a network-attached remote EZSP adapter then recommend instead use a (wired) Ethernet-based solution. Examples:

Tasmota ZHA bridge is basically just a Serial-to-IP proxy-server which the OpenHAB Zigbee Bindings can connect to via socket as a direct serial communication to the EFR32 (EFR32MG21) Zigbee SoC chip/module inside ITead Sonoff ZBBridge as a remote Zigbee serial port adapter. This method is however not recommended to be used with WiFi-based bridges /gateways like ITead Sonoff ZBBridge because the Silicon Labs EZSP (EmberZNet Serial Protocol) interface does not have enough fault tolerance built-in to handle packet loss and latency delays that can be common on WiFi networks but not usually known of as other applications normally handle such faults better.

Tasmota ZBBridge on the other hand also contains a full blown Zigbee to MQTT gateway/hub solution so as long as do not use it with OpenHAB Zigbee Bindings via socat and instead use Tasmota ZBBridge’s native Zigbee to MQTT gateway/hub functionality that is perfectly stable as the MQTT protocol used is fault tolerant. See full ZBBridge solution docs here → Zigbee - Tasmota

1 Like

Thanks for this howto. I’m running OH2 on my own Ubuntu 18.04 server. I’m stuck at socat -dd pty,link=/dev/ttyzbbridge,raw tcp:192.168.x.y:8888 command. It says ‘Permission denied’. When I do ls /dev/ I do not see the ttyzbbridge directory.

Steps I followed so far:

  • Flash Sonoff zbbridge with tasmota and be sure to be able to telnet to port 8888.

  • Installed the serial biding in OH

  • I added EXTRA_JAVA_OPTS="" under JAVA in /etc/default/openhab2 like described in Serial Port Configuration | openHAB

  • I added the openhab user to the dialout group.

  • I tried adding the owner to the socat command, like socat -dd pty,link=/dev/ttyzbbridge,raw,user-late=openhab,group-late=dialout tcp:192.168.x.y:8888, but it still says ‘Permission denied’.

What steps can I take to troubleshoot this?


Install socat, and bind your serial port to the zbbridge radio:
socat -dd pty,link=/dev/ttyzbbridge,raw tcp:192.168.x.y:8888
Of course, adjust the IP address to point the zbbridge one.

This is where I think I cannot pass, my zigbee is not responding well to serial binding.

1, terminal
sudo socat -dd pty,link=/dev/ttyzbbridge,raw tcp:


2021/05/10 22:11:23 socat[69618] N PTY is /dev/ttys007

2021/05/10 22:11:23 socat[69618] N opening connection to LEN=16 AF=2

2021/05/10 22:11:23 socat[69618] N successfully connected from local address LEN=16 AF=2

2021/05/10 22:11:23 socat[69618] N starting data transfer loop with FDs [5,5] and [7,7]

2021/05/10 22:41:19 socat[69618] N socket 2 (fd 7) is at EOF

2021/05/10 22:41:20 socat[69618] N exiting with status 0

myhome@myhome ~ % sudo socat -dd pty,link=/dev/ttyzbbridge,raw tcp:


2021/05/10 22:47:47 socat[72894] N PTY is /dev/ttys006

2021/05/10 22:47:47 socat[72894] N opening connection to LEN=16 AF=2

2021/05/10 22:47:47 socat[72894] N successfully connected from local address LEN=16 AF=2

2021/05/10 22:47:47 socat[72894] N starting data transfer loop with FDs [5,5] and [7,7]

2021/05/10 22:52:47 socat[72894] N socket 2 (fd 7) is at EOF

2021/05/10 22:52:47 socat[72894] N exiting with status 0

2, zigbee logs

22:09:22.375 TCP: to MCU/2: 8430FC7E

22:09:23.283 RSL: STATE = {“Time”:“2021-05-10T22:09:23”,“Uptime”:“0T00:25:11”,“UptimeSec”:1511,“Vcc”:3.481,“Heap”:28,“SleepMode”:“Dynamic”,“Sleep”:50,“LoadAvg”:19,“MqttCount”:0,“Wifi”:{“AP”:1,“SSId”:“MyHome”,“BSSId”:“50:C7:BF:C3:A4:DB”,“Channel”:2,“RSSI”:100,“Signal”:-25,“LinkCount”:1,“Downtime”:“0T00:00:05”}}

22:09:32.482 TCP: to MCU/1: 64CF21A9512ADBB97E

22:09:32.485 TCP: from MCU: 47CFA1A9512AFD69

22:09:32.488 TCP: from MCU: 7E

22:09:32.536 TCP: to MCU/1: 8520DD7E

22:09:32.537 TCP: to MCU/2: 8520DD7E

22:09:42.607 TCP: to MCU/1: 75CC21A9512A6A4F7E

22:09:42.611 TCP: from MCU: 50CCA1A9512AC17D5E

22:09:42.613 TCP: from MCU: 7E

22:09:42.660 TCP: to MCU/1: 8610BE7E

22:09:42.662 TCP: to MCU/2: 8610BE7E

22:09:52.741 TCP: to MCU/1: 06CD21A9512A4B627E

22:09:52.745 TCP: from MCU: 61CDA1A9512A01037E

22:09:52.795 TCP: to MCU/1: 87009F7E

22:09:52.796 TCP: to MCU/2: 87009F7E

I use zigbee2Tasmota and everything works fine overall, but sonoff sensors do not give full information on mqtt.
Is there a setting that allows all data to be published to mqtt?
In the web interface I can see all the parameters, e.g. battery status, unfortunately this data is not in the mqtt message.

new to zigbee here and searching a more stable and better range solution from my ember chipset POPP ZB-Stick using with openhab zigbee binding.
so i can use Tasmota ZHA bridge and add my zb contacts and sensors and then “see” them as mqtt things with my Openhab?Is there a how to?Is this solution more stable than my current one?

You don’t need ZHA, just flash Tasmota on the Sonoff ZBBridge and pair your devices. In OH you create your things with the necessary channels. Works very well! For me the range is much better then the standard sticks I had in my Pi. I also bought 2 routers of Ikea to extend the range.

thnx for ur answer,i got a sonoff zbBridge,flash it and bind some devices,shown at tasmota’s webui and controling them with console commands. So far so good.Now i am trying to mqtt those devices to my openhab but i dont know where to start…i am trying to find some examples to get an idea.

edit. i paired a aqara plug,sending its states with separated mqtt topics for example power state :


giving this to thing’s MQTT State Topic and 1/0 at custom on/off value ,i can see the plug’s power state.
I cant figure out how to send a power command to the plug.I use


at MQTT Command Topic and { “device”:“zbPlug1”, “send”:{“Power”:“On”} } at custom ON value and { “device”:“zbPlug1”, “send”:{“Power”:“Off”} } at custom OFF value and now i can command the plug but i cant see its state…Any ideas?Is there another way to do this?


Here is a quick howto:

  • [already done] Flash your bridge with tasmota zbbridge firmware following Sonoff Zigbee Bridge (ZBBridge) Zigbee compatibility (ignore the ZHA part)

  • Install and configure a MQTT server somewhere on your network, reachable by your bridge and openHAB. Mosquitto is a good choice, and is included on openHABian.

  • Declare your MQTT server in tasmota. In the tasmota console, you should see MQTT messages sent.

  • Configure Tasmota MQTT formatting for zigbee (in tasmota console) :

    • SetOption89 1
    • SetOption83 1
    • SetOption112 1
  • Check the information is correctly published on MQTT server. MQTT Explorer for Windows is very useful.

  • Declare your MQTT server in OpenHAB (see my setup below)

  • In OpenHAB, declare your MQTT bridge, things and channels.

  • In OpenHAB, declare your items

  • Done !

Some useful links :

Hope this helps.

Thanx mate,i can read now all sensors value in separate topics alright,i am now looking the way to send command to a switch and read its status at the same time.
i can send command and control switch but for incoming i get :

2021-10-05 10:09:57.418 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '1' not supported by type 'OnOffValue': No enum constant org.openhab.core.library.types.OnOffType.1

Sonoff ZBBridge is not stable because it uses WiFi, but you can get Elelabs/POPP Zigbee EFR32MG12 based sticks very stable if upgrade firmware as well as always use a long USB extension cable for it.

I also collected these generic tips to set up the best general condition for a stable Zigbee network mesh:

Improving Zigbee network range

Both poor signal quality or signal interference can lead to transmission errors and related issues. This section contains fundamental troubleshooting tips on how to improve signal quality plus optimize range and coverage. Improving signal quality and removing sources of signal interference can in most cases maximize range and resolves problems related to transmission errors. Please try to follow at least some of these recommendations before posting on the community forums or reporting issues to developers.

  1. Adding more Zigbee routers between devices far away and the next closest router or your Zigbee coordinator. Zigbee network topology uses a “mesh network” design which means that each device that acts as a Zigbee router will extend the total range and coverage of your Zigbee network as a whole. The solution is to distribute more Zigbee routers in areas with poor reception. Note that while there are exceptions, understand that almost all permanently powered devices will serve as a Zigbee router. Thus adding more permanently powered Zigbee devices will allow greater range better coverage. There are also dedicated Zigbee routers which you can find by doing a community search for “Zigbee signal repeater” or “Zigbee range extender”) (an example being IKEA Tradfri Signal Repeater). Devices that can not act as routers are typically battery-operated and known as “end devices”. There are some exceptions as some end devices (e.g. Xiaomi/Aqara devices) have issues connecting through routers that are not from the same manufacturer.
  2. Use a long USB extension cable with your Zigbee coordinator adapter. This not only enables you to position the Zigbee coordinator adapter for better signal quality, but it also allows you to locate the Zigbee coordinator further away from Wi-Fi access-points/routers or other sources of 2.4GHz signals to avoid signal interference. Optimally in the best area in your home depending on your building’s floorplan. Ideally, you want to place the Zigbee coordinator somewhere in the middle of your house/apartment. Building materials influence signal quality, for example, dense/thick concrete, bricks, masonry, etc. dampen all wireless signals. Place the Zigbee coordinator with some distance from walls, ceilings and floors. Also, try different orientations of your Zigbee antenna (or your whole Zigbee coordinator adapter if it has an internal antenna). Some Antennas have a stronger signal in a certain direction. Simply changing orientation can improve signal quality already. Note: A bad USB extension cable may lead to connection issues between the system and the Zigbee coordinator adapter, symptoms of this are disconnection messages.
  3. Zigbee and Wi-Fi can operate on various channels in the 2.4GHz spectrum. A busy Wi-Fi access-points/routers that are operating in the same frequency range (overlapping channels) as your Zigbee coordinator will drown out the Zigbee traffic, especially if they are located close to each other. To avoid interference between Zigbee and Wi-Fi try to choose channels without overlap. Check the channel your Wi-Fi access-points/routers are using (either by checking on the router’s web interface or using a Wi-Fi analyzer app). The Zigbee channel is currently not shown in the Home Assistant front-end but you can find the channel in the logs (watch out for Network parameters log entry with the channel number, e.g., radioChannel=15). Changing the channel of the Zigbee network needs recreating it and re-join/re-pair all of your Zigbee devices. Typically it’s a lot easier to change the channel used by your Wi-Fi. See this article for Wi-Fi and Zigbee channels coexistance to avoid using overlapping frequency ranges.
  4. Check if updating the firmware on your Zigbee coordinator adapter and your Zigbee end devices is possible. Note that depending on your hardware the latest Zigbee coordinator firmware might not always be the one recommended by the community so it is advised to ask before upgrading.
  5. If your Zigbee coordinator adapter has a removable antenna (e.g., with an SMA-connector) then you have the option of replacing it with a high-gain antenna. Note that antennas with higher gain usually have directionality: You might have better reception on the same floor, but reception across floors might suffer. In addition, you also have the option to use an antenna extension cable if needed (usually using just a USB extension cable for your Zigbee coordinator adapter is the better alternative). This should really only be needed if you are trying to cover a long distance, like to another building or very dense/thick walls, ceilings and floors.
  6. Buy more powerful Zigbee radio hardware with a better radio range, preferably with an external antenna and based on a newer chip that offers up-to-date firmware. If you are not only experimenting with Zigbee but want a permanently stable and healthy Zigbee mesh network with potentially many devices then you should consider upgrading to a more powerful and newer Zigbee coordinator USB adapter or Ethernet to serial gateway/bridge. Generally, Zigbee adapters with an external antenna will have a better range and offer you more flexibility, therefore you will also want to avoid buying an internal Zigbee adapter unless it has a port for an external antenna.

Note that some Zigbee devices are not fully compatible with all brands of Zigbee router devices. Xiaomi/Aqara devices are for example known not to work with Zigbee router devices from Centralite, General Electrics, Iris, Ledvance/OSRAM/ LIGHTIFY/Sylvania, Orvibo, PEQ, Securifi, and SmartThings/Samsung. Better results can usually be achieved by using mains-powered devices IKEA and Nue/3A Home or dedicated DIY routing devices based on Texas Instruments CC253x/CC26x2 and XBee Series 2/3 Zigbee radios.

If possible always aim to start out with many mains-powered devices before adding any battery-operated devices as a “weak” Zigbee network mesh (e.g., the device is too far from the Zigbee coordinator or a Zigbee router) may prevent some devices from being paired or experience dropped connections and unstable operations. Adding Zigbee router devices are also needed to increase the maximum of devices that can be connected to your Zigbee mesh network.

PS: Alternative to ITead ZBBridge is [ZB-GW03 eWeLink Ethernet Zigbee Gateway with Tasmota FW:

thnx mate,i went with the sonoff zigbee bridge flashed with tasmota and zigbee2tasmota firmware.It is very stable just need figure out some mqtt/openhab issues.My goal is to set up a stand alone zigbee network with zigbee2tasmota.

you proably need to modify the config in your channel. A switch can only accept on/off/open/closed, so you need to set a custom value, in your case 0 and 1


- id: switch
    channelTypeUID: mqtt:switch
    label: tst
      stateTopic: stat/zbBridge/zbPlug1/switch
      off: "0"
      on: "1"

thnx,i solved this one,i can receive the plug’s state alright now.I now straggling to send the right mqtt command to control the plug, made a new thread here

FYI, ITead has released Silabs EmberZNet 6.10 (v6.10.3) firmware for their EFR32MG21 USB dongle:

Not tested but will probably work on ZB-GW02, ZB-GW03, ZB-GW04, and Sonoff ZBBridge as well?

I understand they all use same radio board design based on “SM-011 V1.0” radio module by CoolKit:

xsp1989 also announced the good news is that a router firmware “will be released soon” here:

FYI, Zigbee Router firmware for EFR32MG21 adapters has now been released by xsp1989 on GitHub.

From readme sounds as tested with ITead Zigbee 3.0 USB Dongle and SM-011 based USB adapters.

The same “SM-011 V1.0” Zigbee radio modules by CoolKit Technologies is also used inside some Zigbee gateways/hubs like this popular ITead Sonoff ZBBridge and ZB-GW03 eWeLink Ethernet Zigbee Gateway sold by EACHEN and SmartWise, so could perhaps be that the same Zigbee Router firmware could maybe also be used on the SM-011 Zigbee module in all or some of those products as well?

It might be that ITead Sonoff ZBBridge requires signed firmware image to work, see related discussion: