Improved external integrations

Feature requests
2

Hi @Will_71,

Thanks for this feedback, it’s very concrete and it’s great to see your pellets integration taking shape!

I clarify that Claude helped me write this message but it’s me who thought about each point :joy:

1. Choosing a house from a list

Yes, that’s a good idea. Today, dynamic lists (source) only know how to propose devices from the integration. We will add "source": "houses": the list will display the names of the houses and record their selector, i.e. the identifier that GET /house already returns to you. You will therefore be able to make the correspondence directly.

It will work everywhere this field format is used: configuration, actions, widget settings and scenes. I’m preparing a PR.

Only constraint: you will need to increase the minimum gladys_version of your manifest, as older versions of Gladys refuse a source they don’t know.

2. Decimal value in the configuration

It’s actually a bug. The server already accepts decimals, but the numeric field of the form has no step attribute: the browser only accepts integers and blocks the recording. Even the example in the documentation (a latitude at 48.85) didn’t pass :sweat_smile:

I opened a ticket: Issue · GitHub

The fix is one line and will apply to all integration forms (configuration, actions, widgets, scenes).

3. Entering a value from the widget

The need is real, your current path (go to the integration, change the price, return to the dashboard) is not practical.

However, I don’t want input fields displayed permanently in the widgets. We have chosen that widgets remain read-only + press: this is what allows Gladys to guarantee a clean rendering everywhere (mobile, wall tablet, light or dark theme).

My proposal: a widget button can declare fields. When you press it, a small form opens in the card, pre-filled by your integration, and Gladys validates the values before sending them to you.

On your widget, it would look like this (mockup):

2-formulaire-ouvert
2-formulaire-ouvert912×1720 86.7 KB

If a value is outside the limits you have declared, the error is displayed under the field:

3-erreur-de-saisie
3-erreur-de-saisie912×1720 89.1 KB

And once saved, your return message is displayed and the card is updated:

4-livraison-enregistree
4-livraison-enregistree912×1416 72.4 KB

On the integration side, the button gains a fields table, in the same format as the action fields of the manifest. Since the content of the widget is built with each request, the default value can be the last price you recorded:

{
  "type": "button",
  "label": { "en": "Pallet delivered", "fr": "Palette livrée" },
  "icon": "truck",
  "action": {
    "key": "delivery",
    "fields": [
      { "key": "bags", "type": "number", "required": true, "min": 1, "max": 200, "default": 72,
        "label": { "en": "Bags delivered", "fr": "Sacs livrés" } },
      { "key": "price_per_bag", "type": "number", "required": true, "min": 0, "max": 50, "default": 7.3,
        "label": { "en": "Price per bag", "fr": "Prix par sac" } }
    ]
  }
}

And you receive the entered values, already validated, in values:

gladys.onWidgetAction('pellets', async (actionKey, params, { settings, values }) => {
  if (actionKey === 'delivery') {
    await stock.addDelivery(values.bags, values.price_per_bag);
    return { message: { fr: `+${values.bags} sacs enregistrés` } };
  }
});

A few rules planned:

  • 4 fields maximum, of type number, text, checkbox or list;
  • the form only appears after the press, the card at rest does not change;
  • like the current widget buttons, it is usable by any connected user: these values are therefore to be treated as an event (a delivery), not as a modification of the integration configuration.

This is not yet specified or developed. What do you think? Would this cover your case?

4. Declaring devices in weather integrations

For use in scenes, there is no need for devices: since Gladys 5.1, any integration, including a weather integration, can declare its own scene triggers and actions (scene_triggers and scene_actions in the manifest). For example:

  • an action « Get current weather » that returns temperature, pressure, wind… in outputs. The following actions of the scene can use these values, and a « Continue only if » condition allows filtering on them;
  • a trigger triggered by your integration when something happens (« rain expected in the hour », for example).

For graphs, a weather integration can also declare a widget with a chart component fed by its own data.

However, I am not very favorable to mixing the concepts of device and weather. In Gladys, a device is something physical: equipment that you control or a sensor that measures at your place. The weather is data provided by a service, with its own format (current conditions, hourly and daily forecasts, alerts) and its own widget. If we transform the forecasts into devices, we end up with fake sensors mixed with the real ones (in the rooms, the graphs, the scenes…), and each weather provider would create theirs in their own way.

If you need a real measured outdoor temperature, a physical sensor remains the good solution, and it will be a real device.

Thanks again for this feedback!