Lists like this have been requested many times in the past so I’m certain there is interest.
The list of devices is short mainly because it requires someone to go through the effort of creating a PR to confirm the device works. The general advice from the developer is if it implements ZHA or ZLL it will work out of the box. It’s only those companies that add extra stuff (e.g. Xiaomi) that encounter problems since those require special case handling so the device list is mostly focused on those devices.
For Zwave we have a quite extensive database of supported devices and it’s well maintained because of the way the Zwave binding works the device has to be in the database to be supported. Zigbee doesn’t have that requirement though so it might be harder to force users to report compatibility. But I know I would and I would encourage others to do so as well.
That is simply because people don’t update the list when they test a new device - not because the system doesn’t support a lot more devices. In general, the system should support “any” ZigBee compliant device that uses the listed clusters in the docs.
Ultimately the binding, and the underlying libraries are used in a number of commercial products and a couple of these products have been through Zigbee certification.
I would say in general it is useful - so long as people take the time to update it. I’d be a little concerned that people don’t tend to bother since we do have such a list at the moment, but generally users do not go to the effort of producing a PR to report a confirmed working device right now.
Isn’t that exactly the same as the database that is being discussed here? The “database” I think is managed on GitHub, so still requires people to create a PR to report compatibility? (or maybe I’m wrong? - I’ve not looked at this in detail).
This is exactly what we see now - people do not take the time to update the list of compatible devices. Most users do not care to much about this - they mostly tend to try a device, and if it works, they use it and don’t bother to update the compatibility list.
That’s true, but the database being discussed here is really “just” a database of devices - it’s not providing detailed thing definitions like we have in ZWave as the ZigBee binding automatically detects the different clusters/features of devices.
I was referring to creating a PR to update the binding docs to add to the list of known working devices (similar to what you asked me to do a couple years ago when I was happy to report that Peanut Plugs worked without a hitch).
Sure - I understand that. My point was that at the moment you have to create a PR to update the binding docs. People don’t bother. We are discussing a new database where instead people have to create a similar PR to update THAT database. I’m just saying that if people don’t both creating a PR now, do we think they will do it with a different system?
Also - don’t get me wrong - I’m not against adding an openhab category to the other database. The problem is though that if people think it is a definitive list, then we end up with people thinking that the binding only supports a small number of devices - which is exactly what @blakadder stated above -:
It’s interesting to understand why you think people will create PRs to this new repository, when they don’t currently do so with the openHAB documentation? Is it an issue that people don’t know to do this or something?
ZHA integration in Home Assistant has solved this problem by simply not listing any devices in its docs. Instead they try to explain in docs how zigbee compatibility works in simplified layman’s terms like this:
There is no official compatibility list of supported devices for the simple reason that practically all devices Zigbee Home Automation that are fully compliant with the standards and specifications as set by the Zigbee Alliance should technically be compatible with this ZHA integration. The fact remains, however, that some hardware manufacturers do not always fully comply with each set specification, which can cause a few devices to only partially work or not work at all with ZHA, but developers can create workarounds for such issues via a solution for ‘ZHA exception and deviation handling’ that this implementation features. See that section for more information.
Tip to new users is that, while there is no official list of supported devices, some ZHA users take comfort that blakadder maintains an unofficial Zigbee Device Compatibility Repository which anyone can submit compatibility reports to, it can be found at zigbee.blakadder.com and currently contains independent compatibility lists and device pairing tips for several home automation gateway/bridge/hub softwares, including but not limited to open source Zigbee implementations such as; ZHA, Tasmota, Zigbee2MQTT, and ZiGate.
ZHA exception and deviation handling
The ZHA implementation in Home Assistant relies on a library called “ZHA Device Handlers” to resolve issues with Zigbee devices that do not fully conform with the Zigbee standards. The few devices that deviate from the Zigbee specifications set by the Zigbee Alliance may therefore require proper bug reports with debug logs from users to assistant the developers in writing custom ZHA Device Handlers for all of a device functions to work properly with the ZHA integration.
Such a custom “ZHA Device Handler” are Python scripts that internally are also referred to as a “quirk” because they fix “quirks”, like deviations from the standard specifications. ZHA Device Handles do this by transparently, acting as a translator, translating and converting non-compliant device messages and instead present them to the application as coming from a virtual compliant device. These ZHA Device Handlers for Home Assistant can thus be used to parse custom messages to and from Zigbee devices. The ZHA Device Handlers that are made can then be reused by all users in future versions of Home Assistant.
So you’re saying that we shouldn’t really worry about any lists or databases?
I actually think this is a better idea. The whole concept is that standard devices should work. The binding docs lists the type of support (ie the channels, and the clusters linked to these channels) - in general any device that supports this should work in the binding.
I do not think that openHAB own official end-user documentation should have list of supported Zigbee devices, as then it will probably better only lists the type of devices supported and explain in layman’s term that all standard devices of those types should work and maybe just refer to a third-party database like @blackadder has if end-users want are looking for general ideas on on what devices one can buy.
However, I believe that it is probably a good idea to if possible keep some kind of (dynamic) list in the development documentation of non-standard devices that openHAB Zigbee Binding have had to implement custom device handlers. This is also one area where Home Assistant’s ZHA docs is somewhat lacking as well, but it is relatively simple to find a listing of the devices that deviate from standard Zigbee and already have custom device handlers (a.k.a. “quirk”) in HA’s ZHA implementation that by looking in zha-device-handlers/zhaquirks at dev · zigpy/zha-device-handlers · GitHub
There is currently support for the following device types within Home Assistant:
Alarm Control Panel
Number (i.e. analog output)
There is also support for grouping of lights, switches, and fans (i.e. support for commanding device groups as entities). At least two entities must be added to a group before the group entity is created.
One of the differences is that the blakadder database has built up a community of its own around it.
Not only it is updated by enthusiasts and evangelists who sometimes test all the devices that they buy with several different Zigbee implementations, but I also believe that it is also updated by some manufacturers and resellers who see it as a way to promote devices by showing their compatibility.
True, and that’s great - but the question I thought that was posed right at the beginning is if the openHAB community would support it. I guess your point is that it wouldn’t?
I’m not sure what “argument” you mean? In theory, the ZA list is meant to be all certified products. I know that the product I certified is there and this was done via the certification process - it doesn’t require a community etc to update the list if that’s what you mean?
Is Zigbee “light group” groups not part of the the standard Zigbee Light Link (ZLL) specifications?
I do not use Zigbee groups myself but know that it is used heavily by fans of Zigbee lightbulbs. I understand it is esessial to get multiple Zigbee lightbulbs to be absolutly perfectly syncronized to be controlled by one remote, like a wireless wall switch, using Zigbee binding, (which I believbe is especially usefull for grouping of Zigbee spotlight type lightbulbs in recessed lighting installations).
I would think there is definitely be an interest in that and it might even be a showstopper for new users.
It’s part of the zigbee specification, yes. ZLL doesn’t really exist now, but it’s included in all profiles.
That wasn’t my point though - my point was that openHAB doesn’t have a groups concept that the binding is aware of. This means that it’s not possible to use groups with bindings.
Again, this is correct, but OH doesn’t have this support so it’s not so easy to provide it in the binding. I might look to add something as a console command, but then it’s a bit unclear how to allow the user to operate this.
The Z-Smart Systems library supports this, but there’s no obvious way to manage/operate this within openHAB unfortunately. Anyway, I think this is well off topic now
Another problem I see is that whereas z-wave is backwards compatible, zigbee isn’t (AFAIK).
For instance, I bought a bitronvideo stick, running an old ember stack. It doesn’t work with my zigbee sockets. AFAIK there is currently no firmware upgrade possible for this stick so my sockets are ‘not supported’ - yet they probably are with newer stack / other sticks (I’m just not prepared to throw any more money at zigbee due to things like this)
So what I’m trying to get at is the supported list would have to be very very detailed