# Improved external integrations

**URL:** <https://community.gladysassistant.com/t/amelioration-integration-externes/10952>\
**Category:** Demandes livrées\
**Created:** [October 3, 2026, 8:39pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952 "2026-10-03T20:39:25Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [October 3, 2026, 8:39pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/1 "2026-10-03T20:39:25Z")

</div>

Following external integration developments, here are some missing features that would improve the use of external integrations.

1. Retrieve and select the list of houses with a selector.  
Today, if I want to target a house in the installation, I cannot get a list.  
For example, in this integration, I have to manually enter the name of my house. With a list, it would be more practical.  

2. Add a decimal value in the configuration.  
I wanted to be able to specify a price with a decimal to calculate the amount of my pellet stock. This is not possible today.  
 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/5/1/51e645ad064f143714b55afc53108d9ad8b6131c.png)

3. Still with my prices, I would like to have a text/numeric field in the integration widgets.  
For example, still in my pellet stock, the price changes quite often and when I enter a new pallet into stock, the price has changed. To change the price, go to the integration, change the price, return to the dashboard to press a button to validate the delivery is quite a tedious process, I find.  

4. Be able to declare devices in weather integrations.  
The goal would be to have, for example, a Weather device with different features such as temperature, atmospheric pressure, etc., to be able to use it in scenes, make graphs, etc.

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [October 5, 2026, 12:32pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/2 "2026-10-05T12:32:06Z")

</div>

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 😂

### 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 😅

I opened a ticket: [Issue · GitHub](https://github.com/GladysAssistant/Gladys/issues/3166)

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](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/a/9/a9689d211a623cde2fc143e5f20334b2ad4a2fa6.png)

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

 ![3-erreur-de-saisie](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/2/6/2692d9e3345843a0e3946ea5078b047f1b5fa82f.png)

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

 ![4-livraison-enregistree](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/f/7/f707f3ba510fbece5a03897af0dc6549c9b721bd.png)

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:

```json
{
  "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`:

```js
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 «&nbsp;Get current weather&nbsp;» that returns temperature, pressure, wind… in `outputs`. The following actions of the scene can use these values, and a «&nbsp;Continue only if&nbsp;» condition allows filtering on them;
- a trigger triggered by your integration when something happens («&nbsp;rain expected in the hour&nbsp;», 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!

---

<div class="post-metadata">

**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\
**Post date:** [October 5, 2026, 12:42pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/3 "2026-10-05T12:42:52Z")

</div>

Hi everyone!

This topic is now **in development**.

A PR has been opened to accept decimals in the number fields of external integrations:

> <https://github.com/GladysAssistant/Gladys/pull/3167>
>
> \### Description
> 
> A \`config\_schema\` field of type \`number\` could not hold a decim…al value. Typing \`12.5\` made the form impossible to submit, and the browser showed \*"Please enter a valid value. The two nearest valid values are 12 and 13."\*
> 
> The bug was in the front only. The server already accepts decimals: \`validateConfigValue\` only checks that the value is finite and within \`min\`/\`max\`. The \`\<input type="number"\>\` rendered by \`ConfigSchemaForm.jsx\` had no \`step\` attribute. The HTML default step is \`1\`, so the browser's own validation treated any decimal as a step mismatch and blocked the form submission.
> 
> \*\*Changes\*\*
> 
> \- \`front/src/components/integration/ConfigSchemaForm.jsx\`: add \`step="any"\` to the number input. Every surface that renders the \`config\_schema\` grammar uses this shared component, so the fix covers all of them:
> - the integration Configuration screen
> - manifest action \`fields\`
> - the per-user \`contact\_schema\`
> - external widget \`settings\`
> - external-integration scene triggers and actions
> \- \`front/cypress/e2e/routes/integration/external-integration/ExternalIntegrationConfigNumber.cy.js\`: a new Cypress spec. It types \`12.5\` in a \`number\` field with \`min: 0\`, keeps the spec's own \`latitude\` example (\`default: 48.85\`, \`min: -90\`, \`max: 90\`), saves, and checks that both inputs pass native validation and that the request sends \`{ price\_per\_bag: 12.5, latitude: 48.85 }\`.
> \- \`docs/specs/external-integrations/contracts/manifest.md\` (C.1): the list of renderings now says that a \`number\` field accepts integers and decimals alike, limited only by \`min\`/\`max\`. The contract itself does not change.
> 
> \*\*Verification\*\*
> 
> \- The new spec passes with the fix. Without the fix it fails in two ways: \`stepMismatch\` is \`true\`, and with the validity assertions removed the save request is never sent (\`cy.wait('@saveConfig')\` times out). This matches the bug as users saw it.
> \- The existing external-integration specs still pass: \`ExternalIntegrationOAuth\`, \`DashboardExternalWidgetBox\` and \`SceneExternalIntegration\` (17/17 tests in total, together with the new one).
> \- \`prettier-check\`, \`eslint\` (no new warnings on the changed files) and \`npm run build\` pass in \`front/\`.
> 
> \### Related request
> 
> Forum: https://community.gladysassistant.com/t/amelioration-integration-externes/10952
> 
> Closes #3166
> 
> \### Checklist
> 
> \- \[x\] If a forum topic or GitHub issue exists, the description links it (\`Forum: https://community.gladysassistant.com/t/...\` or \`Closes #...\`)
> \- \[x\] Tests pass: no server change in this PR. Cypress was run on the external-integration specs.
> \- \[x\] Linter and prettier pass on the front (no server change)
> \- \[x\] No undocumented breaking change
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> https://claude.ai/code/session\_01NSSfNjHFyMm47GK4kqcR6Q
> 
> \---
> \_Generated by \[Claude Code\](https://claude.ai/code/session\_01NSSfNjHFyMm47GK4kqcR6Q)\_
> 
> 
> 
> \## Summary by CodeRabbit
> 
> \* \*\*Bug Fixes\*\*
> \* Number fields in external integration settings now accept decimal values, while still enforcing their minimum and maximum limits.
> \* Decimal values are accepted when validating and saving integration settings.

Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.

---

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [October 5, 2026, 12:48pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/4 "2026-10-05T12:48:31Z")

</div>

Thanks for your feedback @pierre-gilles.  
All your suggestions meet my needs.

For the Weather part, personally, it’s already what I do, through scenes, but it was a request from a user who simply wanted to retrieve this through devices to avoid creating scenes.

---

<div class="post-metadata">

**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\
**Post date:** [October 5, 2026, 2:16pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/5 "2026-10-05T14:16:52Z")

</div>

Hi everyone!

This topic is now **in development**.

A PR has been opened to allow a widget action button to open a form:

> <https://github.com/GladysAssistant/Gladys/pull/3168>
>
> \### Description
> 
> An external integration widget can now ask the user for a few v…alues when a button is tapped. The motivating case comes from a pellet-stock integration: when a pallet is delivered, the user needs to enter the price paid. Today that means going to the integration's Configuration screen to change the price, then back to the dashboard to tap "Pallet delivered".
> 
> The spec now lets a widget action declare \`fields\`. A tap opens a short form inside the card, pre-filled by the integration, and the values go to the integration with the action. The card itself is unchanged and still shows no input controls: the form only appears after a tap.
> 
> The proposal was shared on the forum with mockups and approved by the integration author.
> 
> \*\*Spec\*\* (\`docs/specs/external-integrations/capabilities/dashboard-widgets.md\`, updated in this diff):
> \- \*\*Section 7\*\*: new "Action fields: a form behind the button" paragraph.
> \- \*\*Sections 10 and 11\*\*: \`values\` added to \`widget.action\` and to \`onWidgetAction\`.
> \- \*\*Sections 12, 13 and 14\*\*: frontend rendering, accepted risks and tests.
> \- \*\*Out of scope\*\*: reworded. Input controls are still excluded from the card at rest.
> 
> \*\*What an integration declares\*\*: \`action.fields\` in the button content.
> \- At most 4 fields.
> \- Same field format as \`config\_schema\`, limited to \`string\`, \`number\`, \`boolean\` and \`select\`.
> \- No \`section\` and no \`source\`. The content is built at runtime, so the integration lists the options and defaults directly. For example, the price defaults to the last one paid.
> \- The declaration is checked with the manifest's own field validator (\`validateConfigField\`, now exported). An invalid declaration drops the button and logs a warning that names the action.
> 
> \*\*Server\*\*:
> \- The widget action route accepts \`{ settings, values }\`.
> \- \`values\` are checked against the fields of the action found in the integration's own content, with the shared \`validateConfigValue\`. A refused value returns a 422 naming \`values.\<key\>\`. Defaults are applied and missing required fields are refused. Nothing reaches the integration before this check passes.
> \- The validated values are sent as \`values\` in \`widget.action\`, next to the \`params\` the author declared. They are never merged into \`params\`.
> \- \`values\` is left out of the payload for actions without \`fields\`, so existing integrations see no change.
> 
> \*\*Frontend\*\*:
> \- A button with \`fields\` opens and closes its form under the button row. The button gets \`aria-expanded\` and an accent ring while its form is open.
> \- The form reuses \`ConfigField\`, which gains an optional \`idPrefix\` so input ids stay unique when several widgets sit on one dashboard.
> \- On success the form closes and the integration's message is shown. A 422 is shown inside the form.
> \- The light, Horizon glass and dark themes are handled.
> \- \`actionFormSend\` and \`actionFormInvalid\` are added in all four languages.
> \- Decimal values already work in this form, because number inputs accept them since #3167.
> 
> \*\*Compatibility\*\*: additive. An older Gladys drops the unknown \`fields\` key when it normalizes the content, so the button still runs, without \`values\`. The spec says an integration that relies on \`values\` should raise its \`gladys\_version\` or refuse an action that arrives without \`values\`. The SDK still has to expose \`values\` in the ecosystem repo.
> 
> \### Related request
> 
> Forum: https://community.gladysassistant.com/t/amelioration-integration-externes/10952
> 
> \### Checklist
> 
> \- \[x\] If a forum topic or GitHub issue exists, the description links it (\`Forum: https://community.gladysassistant.com/t/...\` or \`Closes #...\`)
> \- \[x\] Tests pass: \`cd server && npm run coverage\` passes (exit 0) and the changed server files are at 100% line coverage. Cypress: \`DashboardExternalWidgetBox.cy.js\` passes 5/5, including a new journey covering the pre-filled form, a 422 shown in the form, a decimal value posted and the form closing on success.
> \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`). \`compare-translations\` and the front \`npm run build\` pass too.
> \- \[x\] No undocumented breaking change
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> https://claude.ai/code/session\_01PyKtrWXekCb7FwCbKLtgSX
> 
> \---
> \_Generated by \[Claude Code\](https://claude.ai/code/session\_01PyKtrWXekCb7FwCbKLtgSX)\_

Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.

---

<div class="post-metadata">

**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\
**Post date:** [October 5, 2026, 2:18pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/6 "2026-10-05T14:18:39Z")

</div>

Hi everyone!

This topic is now **in development**.

A PR has been opened to allow external integrations to choose a house from a list (`source: "houses"`):

> <https://github.com/GladysAssistant/Gladys/pull/3169>
>
> \### Description
> 
> Dynamic select lists (\`source\`) in an external integration mani…fest could only offer the integration's own devices. This PR adds a second core-defined source, \*\*\`"source": "houses"\`\*\*. The list shows the names of the houses of Gladys and stores their \*\*selector\*\*, the identifier \`GET /house\` already returns, so the integration can match the stored value directly.
> 
> \`\`\`json
> { "key": "house", "type": "select", "source": "houses", "label": { "en": "House", "fr": "Maison" }, "required": true }
> \`\`\`
> 
> It works everywhere this field format is rendered: the integration configuration, actions, widget settings and scene triggers/actions. \`select\` and \`multi\_select\` are both supported.
> 
> \*\*Server\*\*
> \- New shared \`DYNAMIC\_SOURCES\` enum (\`devices\`, \`houses\`) in \`lib/external-integration/constants.js\`. Manifest validation and value validation both use it, so the two lists can't drift. The vendored \`manifest.schema.json\` enum follows.
> \- \`getDynamicOptions\` only resolves the sources a schema declares, with one query per source. It still makes no query when no field declares a source.
> \- \*\*Privacy:\*\* the error for a refused \`houses\` value never lists the houses (\`must be one of the selectors of the houses of Gladys\`). The integration posts config values itself (\`POST /config\`), so a refused value must not hand it the house list. Reading that list stays behind the \`location: true\` contract of \`GET /house\`. Picking a house in a form needs no \`location\`: the core renders the list, and the integration only receives the house the user chose.
> 
> \*\*Front\*\*
> \- New shared helper, \`components/integration/dynamicOptions.js\`. The config page, the widget settings editor and the scene trigger/action editors each had their own copy of the device-loading code; they now all use this helper. Each declared source is loaded once: devices from \`GET /api/v1/service/:selector/device\`, houses from \`GET /api/v1/house\`. Both routes are authenticated and not admin-only.
> 
> \*\*Spec (same diff, per AGENTS.md)\*\*
> \- \`contracts/manifest.md\` C.1: the \`source\` enum, the \`houses\` semantics, the no-\`location\` rule, the non-enumerating error and the stale-value behavior.
> \- \`contracts/host-api-endpoints.md\`: \`GET /house\`, the selector ↔ \`source: "houses"\` link.
> \- \`capabilities/scene-triggers-and-actions.md\`, \`capabilities/dashboard-widgets.md\`, \`core/tests.md\`.
> 
> \*\*Compatibility:\*\* an integration that declares \`source: "houses"\` must raise its manifest's minimum \`gladys\_version\` to the first release that ships this change. Older cores reject a source they don't know.
> 
> \*\*Follow-up needed in \`GladysAssistant/integration-store\`:\*\* the canonical schema of the store indexer (\`schemas/manifest.schema.json\`) still has \`"enum": \["devices"\]\`. Until it gets \`"houses"\`, the indexer will reject a published manifest that uses the new source. That repo needs its own PR.
> 
> \### Related request
> 
> Forum: https://community.gladysassistant.com/t/amelioration-integration-externes/10952
> 
> \### Checklist
> 
> \- \[x\] If a forum topic or GitHub issue exists, the description links it (\`Forum: https://community.gladysassistant.com/t/...\` or \`Closes #...\`)
> \- \[x\] Tests pass: \`cd server && npm run coverage\` (Codecov requires 100% coverage on changed lines) and Cypress (\`npm run cypress:run\`) if the UI changed
> - New server tests: manifest validation (config, actions, widget settings), front and integration config, actions, the non-enumerating error, and resolving each source once in a mixed schema. Every changed server line is covered locally.
> - The scene Cypress spec now picks a real house through a \`source: "houses"\` action field and checks that the saved selector is right. The scene, widget and external-integration config Cypress specs all pass locally.
> - In the local sandbox, 19 gateway / Gladys Plus tests fail because the outbound proxy answers 405. The exact same 19 fail on \`master\`; everything else passes.
> \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`)
> \- \[x\] No undocumented breaking change
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> https://claude.ai/code/session\_01MB15SJK3JwLVNaCzKmsiy5
> 
> \---
> \_Generated by \[Claude Code\](https://claude.ai/code/session\_01MB15SJK3JwLVNaCzKmsiy5)\_

Don’t hesitate to follow the PR, to test (optional, especially for small requests) and to give your feedback here if needed.

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [October 5, 2026, 3:51pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/7 "2026-10-05T15:51:56Z")

</div>

@Will_71 What do you think about this PR: [External integration widgets: let an action button open a form by Pierre-Gilles · Pull Request #3168 · GladysAssistant/Gladys · GitHub](https://github.com/GladysAssistant/Gladys/pull/3168) ? 🙂

---

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [October 5, 2026, 4:04pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/8 "2026-10-05T16:04:03Z")

</div>

I’ll watch it tonight and let you know.

---

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [October 5, 2026, 8:54pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/9 "2026-10-05T20:54:28Z")

</div>

@pierre-gilles, it’s fine for me. 🤩 👏

I modified my external integration and validated on your image.

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/b/4/b454aec2fa17ca571a10f73f3d1c265697d99066.png).

---

<div class="post-metadata">

**Author:** ![Chris75](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/c/6a8cbe/32.png) [@Chris75](https://community.gladysassistant.com/u/Chris75)\
**Post date:** [October 6, 2026, 8:18am UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/10 "2026-10-06T08:18:07Z")

</div>

> [@pierre-gilles](#):
>
> However, I am not very in favor of mixing the concepts of device and weather. In Gladys, a device is something physical: equipment that you control or a sensor that measures in your home. Weather is data provided by a service, with its own format (current conditions, hourly and daily forecasts, alerts) and its own widget. If we turn forecasts into devices, we end up with fake sensors mixed with real ones (in rooms, graphs, scenes…), and each weather provider would create their own in their own way.

@pierre-gilles I don’t understand why we couldn’t create «&nbsp;weather&nbsp;» devices since in the integrations «&nbsp;air quality&nbsp;», «&nbsp;vigieau&nbsp;», «&nbsp;UV index&nbsp;», «&nbsp;speed test&nbsp;», «&nbsp;fuel prices&nbsp;», «&nbsp;TV guides&nbsp;», etc. do create devices that can be used in scenes?

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [October 9, 2026, 8:33am UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/11 "2026-10-09T08:33:46Z")

</div>

> [@Will\_71](#):
>
> @pierre-gilles, for me it’s OK. 🤩 👏

Great, I’ll include that in the next version of Gladys 🙂

> [@Chris75](#):
>
> @pierre-gilles I don’t understand why we couldn’t create “weather” devices

I answered here 🙂

> [@Improved external integrations](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/2?u=pierre-gilles):
>
> 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 joy1. 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 /hou…

---

<div class="post-metadata">

**Author:** ![Chris75](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/c/6a8cbe/32.png) [@Chris75](https://community.gladysassistant.com/u/Chris75)\
**Post date:** [October 9, 2026, 9:10am UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/12 "2026-10-09T09:10:42Z")

</div>

> [@pierre-gilles](#):
>
> I answered here 🙂

@pierre-gilles: my question was much more specific:  
I don’t understand why we couldn’t create «&nbsp;weather&nbsp;» devices since in the «&nbsp;air quality&nbsp;», «&nbsp;vigieau&nbsp;», «&nbsp;UV index&nbsp;», «&nbsp;speed test&nbsp;», «&nbsp;fuel prices&nbsp;», «&nbsp;TV guides&nbsp;», etc. integrations, devices are created that we can use in scenes?

The devices from these external integrations do not correspond to physical devices but to providers: so why couldn’t the external «&nbsp;Météo France&nbsp;» integration do the same?

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [October 9, 2026, 11:43am UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/13 "2026-10-09T11:43:01Z")

</div>

What is the use case you are currently unable to do?

---

<div class="post-metadata">

**Author:** ![Chris75](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/c/6a8cbe/32.png) [@Chris75](https://community.gladysassistant.com/u/Chris75)\
**Post date:** [October 9, 2026, 2:47pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/14 "2026-10-09T14:47:37Z")

</div>

Oops, I just realized I’m in the wrong topic: this doesn’t concern changes at the core level.

---

<div class="post-metadata">

**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\
**Post date:** [October 12, 2026, 5:08pm UTC](https://community.gladysassistant.com/t/amelioration-integration-externes/10952/15 "2026-10-12T17:08:28Z")

</div>