WTH is it so hard to find out which devices are 100% compatible with home assistent

WTH is it so hard to find out which devices are 100% compatible with home assistent.
My cabinets are full of smartstuff which aren’t completely working as they should.

  • bulbs which are not supporting all features
  • smart plugs with failing power measurement
  • zigbee / zwave things not behaiving as should…

You can find almost everything in the fora, but in most cases, I dont find the shole solution

This would be great.

Maybe there should be some way to rate each device we have in HA within the device pages of HA and have this fed back into a database that is available online.

You can search integrations by brand now to see what is compatible.

1 Like

I agree that improved a lot, but I think there are still space for improvement…

I will give an example, I have a few iTag devices from Apple. If I type Apple on the integration search, it will find it. Then, going deeper, there is iBeacon in the list. I believe half of the people seen that will understand iTags would be covered, while the other half will be unsure, b7t nonone will be 100% sure with that.

When I type Aqara, it shows Xiomi. Some people knows that Aqara is pet of Xiomi, but most of consumers don’t know that.

I recently bought a cheap power strip UseeLink. I couldn’t find anywhere if it was compatible or not… And it is working fine.

I know this is not easy to solve and I think we should ask.more the device vendors than HA team, but I fully agree this is a WTH.

It would be an impossible job to keep up to date.
The vendors makes new firmware nad hardware versions all the time and hardly ever tell the developers of the HA integrations about it.
The developers usually find out when an user complains about their device not working and the the task of reserve engineering the device through the user starts.

I remember before the integrations were rated like bronze, silver, gold…
I requested to filter integration depending on the rating on GitHub, but nothing happened.
I guess the next best thing now is to have the ability to filter how the integration gets the information (cloud polling, local push…)

Ideally this responsibility should lay at the device vendor side, but they are not gonna do this before consumers starts asking for this, and this will require Home Assistant to be a relevant consumer focused product…

The information handling does not really say much.
You can have cloud polling, which many consider the worst form, but the vendor can provide an API for it, so the support is well integrated.
On the other hand you can have a local push integration, which many sees as the best solution, but it can be based on a reverse engineered closed vendor specific protocol, where not all features have been found yet and the ones that have been found might be guesses wrongly.
On top of that the vendor might change the protocol without notice.

You should research your products and make sure that the vendor has an open API for a local solution.

1 Like

As others have noted, it would be an uphill battle with the manufacturers.

That said, what about a test feature? Although it is not a complete solution prior to purchase, it might help with returns quickly.

I imagine it as:

  1. go into an add-on or integration for Compatibility tester
  2. identify what method of comms supposed to happen
  3. power on device
  4. start connectivity
  5. start capability tests
  6. generate report

Obviously I am spitballing here, but the test could be done the day the device arrives, and not mess up network, and allow for real quick return.

Long, long time ago, we used to have this feature in modems. We could run first a hardware level test, then if passed that, we could try what AT commands it could do, and finally, it would return a list of capabilities.

1 Like

Your old modems adhered to the standard of AT commands.
The smart devices with vendor specific protocols adhere to no standard, which means you can not identify anything for second step.

They’re working on it.

True, So does Wi-Fi, Zigbee, Z-Wave, Bluetooth are with published standards.

If you are referring to the data formats and exchange, then I agree.

+1 Zigbee2MQTT website for example is a great reference as it does an awesome job at not only listing compatible products as ”Supported Devices” but also listing and sorting each of exactly which features that they expose (e.g. entities or Zigbee clusters and their attributes, such as different power monitoring functions, etc.) as well as documenting device specific tips on how to put that device into pairing mode for joining → https://www.zigbee2mqtt.io/supported-devices/


1 Like

The z2m compatibility list is marvelous. Z2M docs in general are a step above most OSS projects, as are HA’s docs in most respects.

But I don’t know how HA could manage a similar device list in a meaningful way. Z2M has the “advantage” that support for any new device is always a manual process, so the device docs are a pre-req of the device support merge.

So many integrations are open enough that tracking supported devices is virtually impossible. For instance a majority of Homekit devices have worked with HA for a long time, and now even more with the addition of BT and Thread support to the HK integration. How could HA staff maintain a list of all that?

Even though I’m a skeptic, I hope Matter will make a lot of these concerns moot.

Actually, ZigBee has a quite a lot of standards, but vendors can still be somewhat creative with extra features.
Z-wave is very strict with its standards and there are required certification needed in order to call it Z-wave, so the devices can interoperate fluently.

Yes, and I understand that the ZHA documentation can be very confusing about explaining that, so that could and should probably be explained better, see these sections in the existing ZHA docs today.

First, the initial header list at the top mentions that there is support for a set of specific “device types”:


Secondly, there is a section under troubleshooting which tried to explain that support is today device specific in ZHA (as instead developers have chosen to expose specific Zigbee clusters and attributes):


Thirdly, there is another section under there that tries to explain that devices that use non-standard Zigbee clusters and attributes will need custom ZHA Device Handlers (a.k.a. “quirks”) coded for them which parse/convert/translate non-standard Zigbee clusters and attributes to the default standards:


Please help contribute if you think that ZHA can be improved, especially for new users and beginners.


FYI, Blakadder also hosts separate device compatibility lists for Zigbee and Tasmota templates which are meant to be community maintained (only through GitHub), though those are not as structured or well-updated as the official Zigbee2MQTT device support database:



Even if devices are „fully compatible“ (like for ZigBee devices when checking if my integration is listed on the Blackadder list), there are funny surprises once they are integrated like

  • reporting power usage only every 5 minutes
  • reporting zero W as power usage every 5 minutes
  • etc.

I use deCONZ and am quite sure ZHA and ZB2MQTT struggle with same or similar things - same same but different, choose your problems. Well, plenty of hardware lying around after frustrating experiences and and a lot of wasted time, finally be sold at some point.

The fact is: the user experience of HA relies on good hardware. And that is a bit out of control of HA.

Especially for ZigBee a „Works with HA“ list would - in addition to basic hardware details - need more information like

  • protocol
  • coordinator
  • integration

Would love to see such approaches and contribute manually. Maybe HA could ask if all devices are working properly and build that list automatically. Just activate sharing statistics (new option „Works with HA“ list contribution), could be a way.

That seems the way to go. If it could be more elaborate, to build some kind of rating or review system so we can find what other users did to integrate and troubleshoot their devices would be great. Or just to know if there is some kind of drawback, partial compatibility or general opinions.