Add-On config.json with optional structure

Development
,
1

Hello folks,

i’m struggling with an add-on for which I want to allow the optional configuration of MQTT discovery templates, similar to this:

templates:
  - name: tpl_blind
    payload:
      device_class: blind
      payload_open: longup
      payload_close: longdown
      payload_stop: stop
      optimistic: true
      tilt_min: 0
      tilt_max: 1
      tilt_closed_value: 0
      tilt_opened_value: 1
      tilt_command_template: >-
        {% set tilt = state_attr(entity_id, "current_tilt_position") %}{{ tilt
        }}

But I don’t get past the schema definition. I defined an empty list within the options, similar to the buttons. When I leave out a schema for templates, I can configure the block in YAML mode, but it does not show up in the final config[].

When I try to configure a schema entry for templates I found no way to define an “arbitary list of key/value pairs”, as I do not know in advance what names/values will have to be configured for this template. I want to allow “any”.

How would I have to write that? Currently it’s

    "options": {
      "mediola": {
        "host": "",
        "password": ""
      },
      "mqtt": {
        "host": "",
        "port": 1803,
        "username": "",
        "password": "",
        "discovery_prefix": "homeassistant",
        "topic": "mediola",
        "debug": false
      },
      "blinds": [ ],
      "switches": [ ],
      "buttons": [ ],
      "templates": [ ]
    },
    "schema": {
      "mediola": {
        "host": "str",
        "password": "str"
      },
      "mqtt": {
        "host": "str",
        "port": "int(0,65535)",
        "username": "str",
        "password": "password",
        "discovery_prefix": "str",
        "topic": "str",
        "debug": "bool"
      },
      "blinds": [
        {
        "type": "match(ER|RT)?",
        "adr": "str?",
        "name": "str?",
        "template": "str?"
        }
      ],
      "switches": [
        {
        "type": "match(IT|IR)?",
        "adr": "str?",
        "name": "str?",
        "on_value": "str?",
        "off_value": "str?"
        }
      ],
      "buttons": [
        {
        "type": "match(IT)?",
        "adr": "str?"
        }
      ]
    }

I tried

      "templates": [
        {
        "name": "str",
        "payload": [ ]
        }
      ]

but this rejects my intended configuration. So the question is: How do I “schema” the “payload” to accept the structure show on top?

2

Not possible. Addon schemas are expected to be strongly typed so users know what is and isn’t supported by the addon. There’s really only two options here:

  1. Add a list of key value pairs like this:
[{
  "field": "str",
  "value": "str"
}]

of course it will require every value be a string if you do this. So if some things are supposed to be numbers or booleans then that won’t really work.
2) ask for a path to a yaml/json file in /share with these templates. Users that want to use this option put this config ina file there and reference it then you pull it in during the setup of your addon.

Although I have to say I’m a bit confused. Why are you asking users to configure Mqtt discovery themselves? What is the addon doing if not publishing those messages for users? And how will users know what topics and values to put in the config?

3

It’s complicated. I try to pimp up a currently small Add-On “mediola2mqtt” that allows access to the Mediola Gateways. It would be fine to have a full fledged integration, but there is none and I’m incapable to write one. The “Mediola” is the only solution to get access to the “Elero” shades, which are quite popular here. The Add-On mediates between HA (via MQTT) and the Mediola-API.

The current configuration is quite easy, just naming the types and IDs of the devices controlled by the Mediola Gateway. These devices get placed into auto-discover and can easily be used by HA. The corresponding auto-discover settings are burried within the sourcecode.

Unfortunately there are a couple of similar devices that support different attributes and require different contol codes for the same operation. My idea was to include a method to tweak the device-templates in case one needs a different set of parameters - which I cannot forsee as strongly typed values. After all, this can be dozens of differnt shades, switches, buttons, … whatever. Generic 433MHz devices, Homematic, … all sorts of wireless devices. The Mediola does the wireless stuff quite right. It just does not talk to HA. But it’s the only authorized solution to talk to the encrypted Elero-devices.

The “Mediola” is similar to the CCU3 in function, so a complete integration would be quite challenging. Especially since it is almost impossible to get access to their API docs… These guys are not interested to have their eco system remotely controlled by third party tools, but to sell their own software where they can charge for every so small integration…

Instead of defining optional overrides for each and every variant that have to be configured on every instance of a shade, I’d like to offer the possibility to define a “named template” where the common differences are defined just once and the template is referenced for each device. Which DOES work, as soon as I get the template definition recognized.

Seems I have to do it in a less general way by just offering a couple of distinct “currently known possible different” settings.

4

Somfy blinds are working now! I will I get Type IT into this?