Home Assistant and Sonoff Zbbridge

Hello,

from what I read on this thread, Sonoff Zbbridge appears to be unstable with ZHA and Zigbee2mqtt.

However, I could use Home Assistant interfaced to Tasmota WITHOUT ZHA (by using mqtt, instead) as an alternative, but I don’t understand if the same problem happens for Tasmota on Zbbridge too.

Do you have experience of dropping, and re-pair needed, for devices connected to Zbbridge through Tasmota with MQTT integration?

Do you know if the requirement discussed in the above link (very stable wifi connection) is necessary for Tasmota too? In particular: do you know if with a not so much stable wifi network it can happen that devices MUST frequently (or occasionally) be re-paired?

Thanks

That problem does not exist if using Zigbee2Tasmota.
Why ?
if you use ZHA or Zigbee2MQTT with a flashed ZbBridge, Tasmota acts as a serial relay. Communication is more like this :
Zigbee chip → Serial relay (Tasmota) ) → ‘Zigbee’ signal over Wifi → ZHA (or Zigbee2mqtt) → HA

if you use Zigbee2Tasmota, it is like this :
Zigbee chip → Tasmota → mqtt messages over Wifi → HA

Thanks, that is the answer I was searching for.
However, I experienced some devices dropping with zigbee2tasmota too,and I was forced to re-pair the devices.
This is very frustrating and I wonder what could be the cause ( and a fix for it…)

Good learning thanks, there was one downside of zigbee2tasmota as you had to manually configure devices on home assistant end, is this still valid?

yes, devices still need to be configured in .yaml

If devices keep dropping, try improving your mesh. Add a power plug/outlet or a bulb to act as routers.

You meant mesh, right? :slight_smile:

Yes. Autocorrect is not always correct.

It would be very nice to have a zigbee2tasmota integration on home assistant side to manage the configuration, it looks like too much manual work.

I see.
But I would like to know/understand why if devices drop they need to be paired again.
Let’s consider for example a battery powered door sensor. If it drops, why then its messages are not caught anymore by the zbbridge?
To be more specific: what does “drop” mean in terms of the zbbridge configuration/data?
Are some data deleted in the eeprom of the zbbridge? Are some data deleted in the sensor’s memory ad well?

Note that in my zb network I don’t use routers. But I experienced drops of devices as well.

Thanks

When people say ‘drop’ they usually mean the devices stop responding and communicating completely, and that is usually caused by interference or a weak signal.

I know this, but I wonder what it means in terms of the zbbridge’s configuration/data and why it needs that a device has to be re-paired

FYI, the communications between ZHA and the Zbbridge is a TCP serial protocol, not MQTT. I believe both ZHA and zigbee2mqtt expect this link to be very robust as I do not believe they implement any handshaking or error recovery on this communication.

I’ve had a Tasmota Sonoff Zbbridge Zigbee running for amount 2 years with no noticable communications problems. Yes, ZHA has had some glitches, but I do not attribute any of my issues with ZHA to wifi TCP communications problems between my Mac mini and the Zbbridge. They are located in the same room about 20 feet apart. That said, I do see error messages like shown in the example below appear in my HA log, maybe at most one per day over the two year period. My wifi is three Mikrotik access points, each is set in a different 1/3 of the 2.4 Ghz spectrum.

I’ve had 3 or 4 devices ‘fall off’ the ZHA network, they were all Aqara battery end devices however. But never had to ‘re-pair’ any of what I would call more ‘main stream’ zigbee battery and mains devices.

The ZHA developers seem to recommend against using wifi for connections between a remote zigbee coordinator and the HA server. That said, the zigbee2mqtt developers seem to be working on their implementation of Zbbridge remotely to zigbee2mqtt.

On a different ‘opinion’, I just restarted experimenting with a zigbee2mqtt docker instance with a USB attached Tube ZB adapter. And wow, zigbee2mqtt has really made great improvements since I move from it to ZHA two years ago. Yes I have both ZHA and zigbee2mqtt running on zigbee channel 11, which is pretty near in the lower 1/3 of the frequency envelop of one my wifi routers on wifi channel 1. I’m not seeing any issues. And have 15 Bluetooth LE temperature sensors around the house advertising all the time. Guess I am lucky, but it does seem possible to have a fairly full 2.4 GHz spectrum and still have stable environment.

To your point about manually adding devices to Home Assistant verses having them auto discover. I thought zigbee2mqtt does have HA autodiscovery, but I turn these off for every integration I can. Yes, I am still a YAML-guy, but IHMO, when sensors do auto discover and add via integrations, I more often than not find a need to ‘customize’ them. So, for me, I prefer to start from my own device config: from naming to unique ids, to units of measure, then all seem to be things you want to define as your system grows.

2022-01-31 07:15:14 ERROR (bellows.thread_0) [bellows.uart] CRC error in frame b'667ea1a960b9154881ab61d2446ba027de3a9f49489f2738917e' (b'3891' != b'55ba')

Thanks for your feedback. I don’t understand exactly what you mean in the quoted text: did you have to re-pair the Aqara battery end devs that you saw fall-off?

The Xiaomi and Sonoff/eWeLink devices, especially the temp/humidity sensors: WSDCGQ11LM & TH01 (see my rant at the bottom of this post) have been so weird and unreliable with my ZHA (w/ Sonoff Tasmota ZbBridge), all my other devices have been far more stable, functional and reliable. Examples, I have a Xiaomi WSDCGQ11LM that fell off my ZHA and despite hours of trying to reset and re-add it, it would never connect again to ZHA. So, I added it back to the Aqara hub I had and it has been reliably reporting temperature and humidity readings for over a year (of course, I have found no way to get these readings out of the Aqara system). Other Xiaomi WSDCGQ11LM’s dropped off over time, a few I tried to re-add, some with success for a while. But I gave up on these units, and quit futzing with them. Then there is the Sonoff/eWeLink TH01 I have attached to my ZHA two years ago. I added it and according to the ZHA info and map, it is there but is not connected to any neighbor, this for two years. And all the while, this device had been reliably reporting temperature and humidity values (albeit at a slower rate than I or others (google posts on this devices)). But, the whole time ZHA has never thought it had a connection to either the coordinator or any router!

Bottom line, if I want a zigbee device to ‘work’, first I look to a Hue or Friends of Hue device and add it to my Hue hub, second based on price and other functions I look to Ikea products and add them to my Ikea hub. If I was more of a masochist, I guess I would third buy more Aqara and Sonoff devices and attach them to their native hubs (but no!). I have reinstalled a zigbee2mqtt docker container with the Tube ZB hub as I said, and so far I am impressed, but time is a tough teacher.

Rant on:
So about 2 years ago, I said, gee it would be great to have at minimum a temperature and humidity sensor in every room, refrigerator/freezer/wine cooler and outside the house. Looking at the fairly large selection of wireless sensors at reasonable price at that time, it seemed ‘doable’ … what an adventure!

To this end, which is not your question, but bare with me…

I have bluetooth low energy temperature and humidity sensors in all locations, combined with a Raspberry Pi 2 centrally located that listens for the BLE advertisements from these 20 sensors. I get about 800 readings per hour from all the sensors. I just happened to reboot the Raspberry Pi today to add a CO2 sensor. It had been running 144 days and I had not touched it during that period. That is basically 165 million temperature readings, nonstop, I just changed my first battery last week, most of the BLE devices are still over 65% battery charged. For more info:

https://github.com/deepcoder/bluetooth-temperature-sensors

Thanks for all these infos