4 ms·

One thing I found a bit unsettling about some products is how manufacturers can say they support a standard when they’re really using it as a basis for a propri

One thing I found a bit unsettling about some products is how manufacturers can say they support a standard when they’re really using it as a basis for a proprietary lock-in strategy. I didn’t realize the standards were so loose until I started researching some newer devices to support Home Assistant, namely the Aqara U100 which seems to require the Aqara hub to be able to support standard Zigbee when it’s advertised as supporting Zigbee https://community.home-assistant.io/t/aqara-u100-smart-lock/579805 https://community.home-assistant.io/t/aqara-u100-smart-lock/...

yurishimo 3y ago
Is this true of Zwave? From what I understood, one of the reasons that zwave devices are substantially more expensive, is that the licensing and certification requirements are much more strict. There also isn't a "first party" zwave hub that I can find. The Zwave alliance seems to only deal with the protocol and licensing, thus, any hub that claims to support zwave, will work with any zwave device.
- organsnyder 3y ago
  That's been my experience so far. I have ~20 Z-wave devices from a variety of manufacturers. They all work very well with Home Assistant, and many of them now support firmware updating directly through HA as well.
- gh02t 3y ago
  No. Loosely speaking, Zwave pretty strictly defines a list of device types (lightbulb, thermometer, etc) and supported formats for read/writes to it by device type (turn on/off, reports temperature,...). The API to handle those is then standardized, and the device manufacturer just fills in the code to implement the calls appropriate to the device. Devices are more-or-less "self-describing." Baseline Zigbee is a bit more freeform (it's not solely a home automation protocol) and is a transport for whatever data format manufacturers want to send, with devices implementing their own details on top. Later on there was an attempt to standardize the communication format for home automation similar to how Zwave works and it was somewhat successful, but manufacturers still have a bad habit of having deviations and quirks. The standard is also not as rigidly enforced like it is with Zwave. Again this is all simplified and there's more nuance but that's generally the breakdown. Practically speaking you'll have more consistency with Zwave devices, but nowadays Zigbee devices have a lot more variety. Support for (and quality of support for) new devices in Zigbee can be a bit more hit-or-miss, but it's usually pretty good nowadays with Zigbee having more marketshare/momentum. I use both, I have more problems with Zigbee, but I also have more devices for it by virtue of their being more choices.
vineyardmike 3y ago
This seems like an edge case. It’s pretty rare to see a product advertise a protocol that isn’t freely used like this one. It even explicitly says in the product description it requires a hub. Aqara has always played fast and loose with support of various open specs. Ecobee remote thermometers use Zigbee, but they can’t be generally paired to non ecobee products, and as such they don’t advertise Zigbee support.

yurishimo 3y ago

Is this true of Zwave? From what I understood, one of the reasons that zwave devices are substantially more expensive, is that the licensing and certification requirements are much more strict. There also isn't a "first party" zwave hub that I can find. The Zwave alliance seems to only deal with the protocol and licensing, thus, any hub that claims to support zwave, will work with any zwave device.

organsnyder 3y ago
That's been my experience so far. I have ~20 Z-wave devices from a variety of manufacturers. They all work very well with Home Assistant, and many of them now support firmware updating directly through HA as well.
gh02t 3y ago
No. Loosely speaking, Zwave pretty strictly defines a list of device types (lightbulb, thermometer, etc) and supported formats for read/writes to it by device type (turn on/off, reports temperature,...). The API to handle those is then standardized, and the device manufacturer just fills in the code to implement the calls appropriate to the device. Devices are more-or-less "self-describing." Baseline Zigbee is a bit more freeform (it's not solely a home automation protocol) and is a transport for whatever data format manufacturers want to send, with devices implementing their own details on top. Later on there was an attempt to standardize the communication format for home automation similar to how Zwave works and it was somewhat successful, but manufacturers still have a bad habit of having deviations and quirks. The standard is also not as rigidly enforced like it is with Zwave. Again this is all simplified and there's more nuance but that's generally the breakdown. Practically speaking you'll have more consistency with Zwave devices, but nowadays Zigbee devices have a lot more variety. Support for (and quality of support for) new devices in Zigbee can be a bit more hit-or-miss, but it's usually pretty good nowadays with Zigbee having more marketshare/momentum. I use both, I have more problems with Zigbee, but I also have more devices for it by virtue of their being more choices.

vineyardmike 3y ago

This seems like an edge case. It’s pretty rare to see a product advertise a protocol that isn’t freely used like this one. It even explicitly says in the product description it requires a hub. Aqara has always played fast and loose with support of various open specs. Ecobee remote thermometers use Zigbee, but they can’t be generally paired to non ecobee products, and as such they don’t advertise Zigbee support.