Zigbee2mqtt: Generic support for all ZLL devices - is it possible?

[james-fry]

Did you read the FAQ?
https://koenkk.github.io/zigbee2mqtt/information/FAQ.md

Yes :)

Unsupported device?
https://koenkk.github.io/zigbee2mqtt/how_tos/how_to_support_new_devices.html

Indeed I do.

A question?
Read the documentation: https://koenkk.github.io/zigbee2mqtt/

Yes - its a new question I hope - I searched the issues and wiki.

Is it possible that zigbee2mqtt can be enhanced to provide generic support for any/all ZLL devices? i.e. its not necessary to update and add code to specifically support each and every one?
Currently Hue hub, Ikea tradfri hub, amazon echo, smarthings etc can all pair devices that are ZLL compliant without needing per-device type specific support to be added in their firmware.

I just purchased a zigbee ZLL dimmer that is compatible with the above hubs, but I will need to code support in Z2M. (Device with modelID 'HOMA1031' is not supported.)
I will attempt to add support for this device...

[Koenkk]

No, in practice they almost all require a different configuration (as can be seen in https://github.com/Koenkk/zigbee-shepherd-converters/blob/master/devices.js). (this could perhaps be done for bulbs)

[james-fry]

Thanks for quick response. I guessed this might be the answer :)
Although I assume ZLL (zigbee light link) does target bulbs (or bulb-like devices such as dimmers) only.

[khzd]

Hi
With the succès of zigbee and Z2M, what will be the code with 1000 différents devices
I think we may think to an alternative to ModelId strategy construction
Cheers

[ryanbeaton]

How are the hubs doing it then?

[Chrischi-]

Basically, each device submits an identify with available / supported clusters and Zigbee2MQTT writes them to the database.db. If the devices fulfill the implementation via ZCL, then you should have the entire cluster (according to ZCL) available in toZigbee.js and fromZigbee.js. With this you could then create / supplement the devices.js. But this is only one approach. Of course there are more things to think about.

On the other hand Zigbee2MQTT is only a bridge and does not need this logic at all.

Maybe someone could build an extra device wizard!?!

Only my thoughts.

[james-fry]

I started looking to support the ZLL dimmer I have via customer devices.js in hassio addon.
(which btw might happen more slowly now I see it works perfectly on my hue hub)

There are a number of archetypes for ZLL bulbs:

• on/off+brightness
• on/off+brightness + colour temp
• on/off+brightness + colour temp + rgb

I can see that these result in standardised approach in devices.js:

• on/off+brightness --> extend: generic.light_onoff_brightness
• on/off+brightness + colour temp --> extend: generic.light_onoff_brightness_colortemp
• on/off+brightness + colour temp + rgb --> extend: generic.light_onoff_brightness_colortemp_colorxy

I'm guessing that these three archetypes are determined from some pretty specific and common zigbee zll clusters, so is it not possible for there to be analysis when a devices is paired to identify ZLL clusters and automatically determine correct extension?

[Koenkk]

@james-fry yes this can be done, but note that zigbee-shepherd-converters also serves as a central point where working devices are gathered (also the zigbee2mqtt supported devices documentation is based on this). What we could do is to auto generate the converter so that pull requests can be created more easily.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bohtho]

With a check for generic archetypes in zigbee2mqtt an automatic and generic HomeKit/Homebridge converter would be easy to make on top of this (for example for the very stable and dynamic Homebridge-MQTT plugin, which in turn easily could be supported in line with the Home-assistant support).