Q: Would it be possible to create a generic Zigbee app supporting custom drivers?

Just theoretically: would it be possible to create a community app that supports having some kind of generic Zigbee app that supports adding custom drivers? I mean in such a way that end users can easily add/modify new devices of different brands, independently of an App itself (e.g. uploadable from the App config (or in user storage or Homey).

I am currently using Deconz but would like to switch back to native Homey when the 2023 version is released. Currently getting support for new devices in Homey is a hot topic because it depends on the the developer to add it and release an updated version of the entire App, even if it’s just a new version of a device that already exists (e.g. Tuya).

In Deconz there is a concept of standalone “DDF” files, which is basically a json defining the capabilities and handling for a device.
https://dresden-elektronik.github.io/deconz-dev-doc/modules/ddf/#goals

IMO a similar setup for Homey would make it much easier for non-programmers to add new devices, taking away some pressure on the devs.

In short, no, if it was possible for example the tuya zigbee app would have been a lot easier then how it is now, that every single unique device ID needs to be added to the app, and there is a lot of them.

Yes, that was my point. And many of those Tuya devices with different ManufacturerId’s are actually 100% identical apart from that.

So I would expect a Generic Zigbee App to be able to configure/setup the device it manages based on an external config. Since you can also add any Zigbee device as Homey/Generic, and from what I understood the app is supposed to provide additional device specific functionality?

And that’s why I said “no” as it just isn’t possible with Homey, an app needs all ID’s hardcoded into its code to be bound to a device, if the ID isn’t in an app the generic zigbee device will be used, which is really generic (only onoff, dim and Color).

As the zigbee standard wasn’t strict until Zigbee 3.0, devices have a lot of their own implementations.
But even now manufacturers have a lot of freedom on how and what they implement into a device. (There is even a specific cluster by Tuya, which some devices use for full functionality)

But even then, as example zwave is pretty strict, but even then it isn’t possible to create a generic app, because of the same limitations created by Athom. (They want an app for every brand)
The generic Z-Wave device even only has on/off, not even dim nor Color.

So do you mean the hardcoded bit can never be incuded in a separate file that the App reads and then uses to pair/configure a given device? But instead by design, Homey always requires a predefined file containing per-device driver settings? I’m not a dev, but does not sound very extensible. :frowning:

I read about the Zigbee 3.0 “standard” and all kinds of standard and specific clusters etc., but that’s where the extensible part comes into play (mapping/parsing/transforming). Not saying it would be easy, but at least having the option to control that part outside of the app itself would make it so much more flexible.

Right now 95% of Tuya/Aqare app thread is about adding new devices, even though the basics may already be present in the respective Apps. IMO many of those users would be very willing to test an early exernal “driver” if they could easily add it (as a file for example), and the dev doesn’t have to be bothered by the same question over and over again. :slight_smile:

The pairing is happening without the app ever knowing, that is all done by the zigbee core of Homey.
During pairing (one of the later steps) it will check if an app has the device’s ID so it can bind clusters of the device to an app, in some cases this binding is mandatory or no messages are send by the device for that capability, and without that the messages will never get into an app either and everything will stay in the core go to waste.

Maybe I’m missing the point here, but if what would prevent a generic App X from managing these deviceid’s (+ correct cluster bindings etc.) for several different brands? The App could load device specific config files realtime?

I think the brand separation bij Athome is artificial, correct? I think the Tuya app for example also supports some other whitelabel brands.

No, Homey apps cannot load Zigbee configuration realtime. The specific devices an app can handle cannot be changed other than with an app update.

Just because Homey can’t be extended in the way you envisage doesn’t mean it’s not extensible. Anyone is allowed to write an app and run it on their Homey so the provision is there.
As you seem to have a clear vision of how this should work, maybe you can write the app to see for yourself what can and can’t be done rather than just disregarding the comments of some very experienced developers.
If you can achieve what you propose then I would be very happy to use it.

Sorry, that’s not what I meant. I was just trying to understand how a zigbee device and an app work together under the hood. I was referring specifically to the Zigbee “driver” pairing & handling part, definitely not Homey in general. Plenty of essential community apps out there that build on the Homey framework! :slight_smile:

1 Like