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 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.
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.
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.
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!
It should be possible to create extendable apps that can add devices without recompiling the app.
First the app needs to know about what kind of functionality the Zigbee device supports. It can be a door sensor, a thermometer, a thermostat, or almost anything else. This device profile needs to be supported by the app, otherwise it’s quite meaningless to try to pair with the device.
If it knows the device profile, however, there might still be issues. I don’t know how the pairing process of a Zigbee device works, but I imagine it might be something like this:
The device is put in pairing mode by pressing some button.
The device broadcasts it’s unique device id.
The zigbee gateway notices the device in pairing mode, and sends the unique id to the app.
The app sends some authentication response to the gateway. Here might be the problem I assume. Maybe there is some secret key hidden in the device that each app that should be able to pair with it needs to know? If so this secret key needs to be made public in some way.
The device validates the authentication response and off we go.
So, does each app need to know some secret to be able to pair with a device? Or where does the problem lie?
The problems lies in the way the Homey SDK implements support for Zigbee devices, where apps need to declare up front (in their “manifest”) which Zigbee devices they support.
So basically how it works:
Device is put into pairing mode
Homey starts the pairing process (which, for Zigbee, is generic, so not specific for an app)
Homey receives the model identifiers for the device (“manufacturer name” and “product id”)
With those identifiers, Homey looks up if there’s an app installed that supports the device:
If there isn’t one, then it will assign the generic Zigbee driver to the device
If there is one, then it will assign the specific app’s driver to the device
Because apps need to declare up front which devices they support, apps cannot implement a generic Zigbee driver (or a driver for all devices from a specific manufacturer).
And because Homey’s generic Zigbee driver is very limited, for all but the most simple devices (lights and sockets/switches) you need a specific driver, and thus a specific app.
So, if the Homey implementation of Zigbee pairing process is not ideal, are there other Zigbee gateways / apps that allow us to be more flexible in the driver selection?
Yes, implementations like Home Assistant’s ZHA, and zigbee2mqtt, are much more flexible, support many more devices, and have much better generic device support.
