Best Way to implement a Hub-Proxy / Generic Device Driver

Developers
,
1

Hi there,

i am writing an integration for an old SmartHome which went offline a while ago. It has only a local api now, which i am connecting to Homey.

Now i have all this data in the api, which would allow me to basically generate all the device drivers and devices automatically.
Yet homey seems to require to have them declared in the compose.json.

I wonder if there is a better way, that allows me to make a generic driver and just set up some mappings for certain capability types, and generate the devices without creating all the files for them manually.

Is it possible to declare devices and drivers in code?

This is currently all i have to do in code to set up a new device:

module.exports = class RstDevice extends LivisiDevice {
    async onInit() {
        super.onInit();
        this.mapRoCapabilitiesAsync("measure_humidity", "HumiditySensor", "humidity");
        this.mapRoCapabilitiesAsync("measure_temperature", "TemperatureSensor", "temperature");
        this.mapRwCapabilitiesAsync("target_temperature", "ThermostatActuator", "pointTemperature");
    }
};


module.exports = class RstDriver extends LivisiDeviceDriver {
    async onInit() {
        this.initializeLivisiDeviceDriver('RST');
    }
};

but then i have to add all that stuff in the compose file :-/

2

Not quite sure what you mean, but there’s a method called Driver#onMapDeviceClass that you might be able to use.

Driver classes still need to be declared up front (they need to exist when the app starts), not sure about device classes though.

As an alternative, you could consider writing a Driver/Device class generator that will create the required driver/device classes from the API declaration. I can’t give any examples for that though.

3

Ive tried poking chatgpt yesterday, and it pointed me to a method called addCapability on the device class.
This sounded good at first, as i can then dynamically set up the capabilities on a generic device class in the moment it is instantiated.
Only point here was, that the documentation says this method is expensive, and should only be used when needed.

I am wondering now if this means i should alos avaoid it on the first pair, or whether it just means that i should not constantly turn on and off capabilities on already initialized devices.

but using this function, i can just dynamically set up capability mappings on instances of a single device class, and thus avoid to create this and that many drivers for all the different devices.

everything i need to do, is create a mapping between the legacy smarthome capabilities and the homey capabilities. Every device that can be found can then be searched for ‘compatible’ capabilities and these can be automagically assigned and then mapped on the device

4

You don’t have to declare capabilities up front, you can set them programmatically in the “device object” that you use during pairing. See this example (so in app.json you can have "capabilities":[]" and then dynamically add the relevant capabilities per device during pairing).

1 Like
5

Thx, that i what i was looking for!

6

In addition you can also add capabilityOptions if you want to add custom titles for standard capabilities or custom settings for numeric capabilities like min/max/steps etc.

Example: Here I collect capabilities and set capabilityOptions as needed. io.home-assistant.community/lib/Client.js at main · RonnyWinkler/io.home-assistant.community · GitHub