How to add converter for unsupported zigbee device?

[Chvalov (Andrii)]

I faced that some devices from tuya ecosystem don’t work “No supported clusters found”, also noticed that there are unresolved issues with some devices from xiaomi/aqara.

Is there an possibility or a template for adding devices that don’t follow zigbee standards ? Maybe there’s a boilerplate for writing Java converters, and from the openHAB side loading them by SPI or JPMS?

I have a sniffer based on CC2531, besides most of the devices are supported in z2m, which can be helpful in developing a converter for openHAB

Unfortunately, I haven’t found a tutorial or example of how to add a converter for unsupported devices

Please don’t recommend using z2m or migrating to HA, I would like to contribute to openHAB, specifically native support for zigbee devices, but I don’t know where to start yet

[Pedro_Liberal]

The issue is, as I understood ot, that those devices simply do not follow the standard. And as such, require a “per device” assessment/work in order to make them compatible. xiaomi, Bosch , aqara and some others are guilty of this.
Think about how many different temperature sensors from different companies are out there, now multiply that by however many different kinds of other sensors and devices that aren’t compatible, and now you’re saying “let’s make them work natively with OpenHAB” - someone has to work on each device individually, and afterwards, provide support.
I think that is the basis for the decision to only support the standard zigbee devices - which makes total sense.
On the other hand, I don’t think anyone would reject a PR to add compatibility with other devices if you make one….
But that’s me assuming. I could be wrong, and that would be it

[obones]

Well, at least for Tuya, there is a documentation for the specific profiles it is providing to implementors.
Making openHAB support this would go a long way in supporting all those “el cheapo” sensors that are so easy to come by.

[Chvalov (Andrii)]

@Pedro_Liberal

The issue is, as I understood ot, that those devices simply do not follow the standard. And as such, require a “per device” assessment/work in order to make them compatible. xiaomi, Bosch , aqara and some others are guilty of this.

They want to keep users on their products, so they don’t follow (deviate) the zigbee standard

@Pedro_Liberal

Think about how many different temperature sensors from different companies are out there, now multiply that by however many different kinds of other sensors and devices that aren’t compatible, and now you’re saying “let’s make them work natively with OpenHAB” - someone has to work on each device individually, and afterwards, provide support.
I think that is the basis for the decision to only support the standard zigbee devices - which makes total sense.

Being able to add your own converters by extending the core library methods makes sense, as we already have zigbee support.
Providing such a feature (at the level of modules, scripts, etc…) is sufficient for the community to support third-party devices.

[Chvalov (Andrii)]

Chris once wrote about refactoring code to easily add non-standard devices, but unfortunately I don’t see a boilerplate code to use

@chris

I have now done a lot of this refactoring, and once complete it should make it easier to add non-standard devices - at least to cover the application layer. If they don’t adhere to the lower level standards which are handled by the coordinator then that’s much more difficult (ie probably impossible) to resolve.

[Chvalov (Andrii)]

@chris can you tell me how to add Zigbee support for devices that do not follow Zigbee Alliance standards ?

As I understand it adding an *.XML file to the “/OH-INF/thing/” resources does not add support, only visually adds channels in the OpenHab panel and most likely adding an *.XML file to the resources “com.zsmartsystems.zigbee.autocode” will not change anything either or not ?

[JimT (jimtng)]

Just like z2m, we could support individual devices. If not in the main addon, as a third party repository / database, although I think it would be better to just include it into the main addon, just like how z2m does it.

[chris (Chris Jackson)]

@Chvalov

As I understand it adding an *.XML file to the “/OH-INF/thing/” resources does not add support, only visually adds channels in the OpenHab panel and most likely adding an *.XML file to the resources “com.zsmartsystems.zigbee.autocode” will not change anything either or not ?

This does add support - it can add channels - not just visually, but in practice.

However, it only allows adding channels connected to ZCL attributes. This allows adding non-standard attributes, or manufacturer specific clusters etc. If a device doesn’t following the ZCL standards at all, then it will not be possible to add support without code changes.