[development] Support multiple AVRs?

[andig]

I've just hit a similar problem in https://github.com/andig/pimatic-fritz/tree/multi-box and thought I'd look around for similar use cases.

How would could I use yamaha-avr with multiple receivers?

[andig]

@mwittig in my case I have tried passing the context (here: the actual AVR instance) to the device on discovery but that requires another device configuration parameter which doesn't seem to make sense (as it would also be exposed in the UI).

Do you think it would be feasible to add an additional parameter for "private" properties in devices.coffee here:

discoveredDevice: (pluginName, deviceName, config) ->
  env.logger.info("Device discovered: #{pluginName}: #{deviceName}")
  @emit 'deviceDiscovered', {pluginName, deviceName, config}

[andig]

Another approach might be to create new device types per AVR instance but that doesn't seem very elegant either. Any thoughts how to solve this? Would be great using this and other plugins for multiple platform instances.

[mwittig]

Strategy 1: Have a look at pimatic-johnny-five where I implemented support for multiple endpoints. Johnny Five can manage multiple boards (e.g. Arduinos, ESPs, virtual boards like Port Extenders) which are defined as part of the plugin configuration. Each device configuration is associated to a board by referencing it by boardId. There is no device discovery for Johnny Five, however.

Strategy 2: Another example is https://github.com/mwittig/pimatic-milight-reloaded where each device configuration has a property "ip" with the address of the milight gateway. As the connection to the milight gateway is handled by the underlying library (presumably a similar case to what you have with "fritz") the device implementation is pretty much straightforward. I have also implemented device discovery for milight, but it is a pretty dumb animal as it is not possible to query which milight devices have been paired with the gateway. So basically, I use the base library to detect milight gateways on the network and then I create candidate devices for each bulb type for each gateway.

Regarding the multi-box use case you are looking at, the device discovery can be a lot smarter as you can query the devices and you possibly can detect whether a given box is just a "slave" router within a mesh setup. Do all meshed router boxes share the same credentials? If yes, I can imagine a third strategy, where you have the configuration for the mesh master as part of the plugin configuration and you can override the address as part of the device configuration (e.g., an option address attribute) to let the device access the state information from the mesh slave. I am not sure this make sense - it is just my rough understanding of #53.

NB: It is possible to automatically upgrade the plugin and device configuration if a new plugin version requires changes of the configuration schema. If you have not done this yet I am happy to assist.

[andig]

Thank you! Strategy 1+2 combined sounds like the way to go for time being:

"plugins": [
    {
        "plugin": "fritz",
        "boxes": {
            "main": {
                "url": ...,
                "user": ...,
                "password": ...,
            }
        }
    }
],
"devices": [
    {
        "id": "home-switch",
        "box": "main",
        "name": "Fritz outlet",
        "class": "FritzOutlet",
        "ain": "xxxxxxxxx"
    },
]

This isn't horribly elegant. The devices box property should really be an enum which means I need to dynamically modify the device-config-schema.

As this needs to be done on each plugin I still feel it might be nicer to allow this on the framework level. Might be possible to do this by adding an internal instance attribute for plugins that is used as prefix to plugin and device names? This would obviously take longer to implement but fix the same case for any plugin (like the AVR ones).

NB: It is possible to automatically upgrade the plugin and device configuration if a new plugin version requires changes of the configuration schema. If you have not done this yet I am happy to assist.

Nice- would appreciate a pointer. I'd need to upgrade both plugin and devices config.

[andig]

Ok, found one more issue (and really sorry- this is of-topic for this repo). If I define boxes in the example above as object I cannot declare its properties as I won't know the property name upfront (only its type). I can go for array but find adding a name attribute a little less obvious and it might invite for declaring duplicates.