I’ve recently started on the whole HA journey. Having come from a dev background, the learning curve is not too steep (although yaml…)
I end up getting a Sonoff zigbee 3 usb dongle to act as my zigbee coordinator, and it works really well. All my devices are connected via ZHA, as that seemed the way to go.
I’ve noticed many times in forum posts, and by looking at the blakadder list, that MQTT seems to have better coverages of devices generally, and often exposes more entities as compared to ZHA.
Hi,
In home automation, as with software engineering, language matters as it helps you get a mental model of how stuff works.
<pedant mode engage>
Comparing the MQTT protocol with the Zigbee is like comparing HTTP with 4G - they are different as explained here:
The Sonoff 3 Zigbee coordinator is excellent, but being a mesh radio device (IEEE 802.15.4), distance coverage depends on the number of mains powered devices you have to act as routers.
MQTT has no coverage itself - but typical devices using the protocol use Ethernet or Wi-Fi as a transport. If you have good Wi-Fi coverage or wired Ethernet, MQTT is useful (e.g. the ESPhome, Tasmota, WLED firmware for ESP devices all use it). Just don’t add lots of WLAN kit, as ISP routers may not segment IoT from gaming creating issues.
Implementations of the MQTT protocol tend to expose more device attributes as they usually are open source, written by the community, and not limited by arbitrary marketing droid decisions . The downside is you may need to tinker more, but you can also create your own kit (e.g. I wrote a garden watering controller in Python which has full automatic discovery in HASS via MQTT - down to attribute icons).
As you’ve seen, folks like https://blakadder.com/ do great work taking cheap kit with crap firmware and reverse engineering it to get FOSS firmware working giving the best of both worlds. Sonoff owe Theo Arendst a lot, as does Shelly!
Commercial structures of licensing, patents, and standards are also surprisingly important.
Zigbee devices tend to be cheap and single purpose (e.g. a motion sensor) whereas more expensive Z-Wave devices might add features (e.g. multi-sensor PIR/ temperature/ light level/ air quality/ air pressure/ wind direction…). Why? A Z-Wave multisensor has high per-device licensing fees so extras get chucked in to “add value faster than cost” .
Zigbee devices don’t have a strong standards body, so can have issues (although that didn’t help Z-Wave…) with compatibility. Thread is designed to fix that, mixing the same mesh radio device (IEEE 802.15.4) with mandatory compatibility testing. The downside is that Matter / Thread testing and licensing costs big bucks, so until volume production gets the price down and manufacturers can test the savings of not needing a private IoT cloud anymore, we’re using FOSS to fix stuff.
. The downside is you may need to tinker more, but you can also create your own kit (e.g. I wrote a garden watering controller in Python which has full automatic discovery in HASS via MQTT - down to attribute icons).
.
this post!