And do you keep the API information if you switch from one service to another?
A small note on your second paragraph:
I think we can remove France to have just Weather as generic for the widget choice.
Yes, the API keys are saved in the database, so you can switch from one source to another without re-entering the key. And given the size of the Meteo France key, it’s better that way. But still, Meteo France is optional, only for displaying the map.
Yes, it’s planned for the text, but as I haven’t yet replaced the old weather widget, for now, it’s still called Meteo France. I’ll change it once the cleanup is done.
I prefer this approach! A single weather widget, with two separate integrations.
In fact, this is how all of Gladys works: there is only one widget per type of functionality, and each brand or technology has its own integration to manage communication with the outside of Gladys.
The image is up to date for those who want to try it out:
docker pull willde71/gladys-test:meteofrance_integration
So we have an OpenWeather integration that hasn’t changed and a new Meteo France integration that allows you to retrieve weather data for France only without an API key. An optional API key allows you to obtain Meteo France vigilance maps.
The weather widget is fully switched to the new design. During the update, the dashboard will be updated.
The widget configuration changes a bit as you can now choose the weather data source:
- OpenWeather
- Meteo France
Here are the details of the possible configurations depending on the source. OpenWeather in the free version does not offer the same data as Meteo France. Hence the differences.
Here are some images
I also added a trigger and actions in the scenes:
A trigger on alert level
An action to retrieve Meteo France vigilance
Variables exposed for use in messages.
An action to send the Meteo France vigilance map
Example in Telegram
I was able to test it and it’s perfect 
I didn’t find any bugs on my side 
Hi @Will_71,
I’ve launched Fable 5 on the external integration project of the “Weather” type to unblock you. 
The goal is to allow you to migrate your integration to an external integration, so you can evolve it independently.
Regarding the widget, we’re definitely going to evolve the existing one, taking inspiration from your excellent proposal. Thanks for all the work you’ve put in, it’s really a great foundation!
@Will_71 :
For your information, I’ve invited you to the Gladys repo so you can be invited to review PRs
@Will_71 The SDK PR:
Can you check if the API contract looks good to you?
I’ll check and let you know
Great! Claude tells me that the approach taken is normally sufficient and fully compatible with the approach you took with Météo France.
So normally, you’ll be able to propose the new widget and an external Météo France integration based on this foundation
we can also adjust if needed later
Yes, the only limitation is that now that we provide an API, everything must remain backward-compatible and versioned in case of breaking changes.
So no right to change the API format every other day!
But I’m rather confident.
I’m going to do an external integration gladys-openweather on my side.
I looked at your PR on the SDK.
Here are the points I noted
-
Vigilance map — WeatherPayload has no image field. No channel. Won’t work.
-
Alert descriptions capped at 2000 characters. Not sure that will work with the full Météo France bulletin, though it also provides a short summary. On my side, I have:
- text — the official summary, one sentence (« Severe and lasting heatwave in progress. »), capped at 1000 characters
- bulletin — the full multi-paragraph bulletin, capped at 4000 characters
-
Scene triggers based on vigilance status
In my Météo France PR, every 15 minutes, checkVigilance() queries the API for each house. The current color is compared to the previous one.
If it rises and reaches at least 2 (yellow), the service emits EVENTS.METEO_FRANCE.NEW_VIGILANCE. scene.triggers.js:105 retrieves the event and starts the relevant scenesThis is the integration that pushes the information to Gladys, spontaneously.
However, onWeatherGet does the opposite: Gladys calls the integration, the integration responds. The integration has no way to say « something is happening now ». The SDK does not expose a push channel for this.
Consequence: scenes triggered by vigilance no longer work. Unless the core itself starts querying weather integrations at regular intervals and detecting transitions
I’ll check and get back to you!
Hi @Will_71!
Thanks for your detailed feedback, it was very accurate, the three issues you pointed out were real. We just addressed them in the PR for the generic weather API (#2738), keeping the most generic version possible each time:
1. The length of alert texts 
The description field goes from 2000 to 5000 characters: your summary + the full bulletin fit in it (NWS CAP bulletins also regularly exceed 2000 characters, it wasn’t specific to Météo France). On the widget side, the bulletin is displayed folded into 3 lines and unfolds on click, as in your original PR.
2. Scene triggers on alerts 
This was the most important point. We did two things:
- Two new generic scene triggers in the core: « Weather alert triggered » and « Weather alert ended », configurable by house, type of phenomenon (wind, rain-flood, thunderstorms, heatwave… the 9 phenomena of MF alert are in the enum) and minimum severity. The core checks the weather every 30 minutes and diffs the alerts: an alert that appears or worsens triggers, an alert that ends triggers. It works with all providers, without implementing anything on the integration side.
- A « nudge » for freshness: your integration, which knows when the alert changes, can send
external-integration.weather.refresh(viarequestWeatherRefresh()in the SDK). The core then immediately restarts its verification cycle: the scene goes out in a few seconds instead of waiting for the next poll. It’s intentionally a signal without data (the « trigger, not data » doctrine we already apply to webhooks): the data always goes through the standardized path.
3. Alert maps 
The pivot format gains an images field: your integration declares up to 3 images (key + multilingual label), and the core fetches the bytes on demand via weather.get-image (onWeatherGetImage(cb) in the SDK). The core validates (PNG/JPEG only, ≤ 500 Ko), caches for 10 minutes and serves the image from the Gladys origin: the browser never loads a third-party URL. In the widget, a « Provider Images » box displays your J and J+1 cards with their label. And it’s generic: a provider can also put a rain radar or a satellite image there.
The SDK is up to date with onWeatherGetImage and requestWeatherRefresh. With the finer conditions added just before (partly-cloudy, pouring, hail + the is_day flag for night variants) and typed alerts, everything your front displayed should now go through the generic API.
Don’t hesitate if you still see a gap in carrying your integration, it’s the pilot of the weather type, your feedback calibrates the contract for all subsequent providers. 