Et tu gardes les infos des API si on passe d’un service à l’autre ?
Petite remarque sur ton second paragraphe :
Je pense que l’on peut supprimer France pour avoir juste Météo en générique pour le choix du widget.
Oui, les clés d’API restent sauvegardées en base donc tu peux passer d’une source à l’autre sans remettre la clé. Et vu la taille de la clé Meteo France, il vaut mieux. Mais bon, Meteo France ça reste optionnel uniquement pour afficher la carte.
Oui, c’est prévu pour le texte mais comme je n’ai pas encore remplacé l’ancien widget météo, alors pour l’instant il s’appelle toujours Meteo France. Je modifierai une fois que le ménage sera fait
Je préfère cette approche ! Un seul widget météo, avec deux intégrations séparées.
En fait, c’est le fonctionnement de tout Gladys : il n’y a qu’un seul widget par type de fonctionnalité, puis chaque marque ou technologie dispose de sa propre intégration pour gérer la communication avec l’extérieur de Gladys.
L’image est à jour pour ceux qui veulent essayer:
docker pull willde71/gladys-test:meteofrance_integration
Donc on a une intégration OpenWeather qui n’a pas changé et une nouvelle intégration Meteo France qui permet de récupérer les données météo uniquement pour la France sans clé API.
Une clé API optionnelle permet d’obtenir les cartes de vigilance Meteo France.
Le widget météo est entièrement basculé avec le nouveau design. Lors de la mise à jour, le dashboard sera mis à jour.
La configuration du widget change un peu car on retrouve maintenant le choix de la source de données météo:
- OpenWeather
- Meteo France
Voilà les détails des configurations possibles en fonction de la source. OpenWeather en version gratuite n’offre pas les mêmes données que Meteo France. D’où les différences.
Voilà des images
J’ai également ajouté un déclencheur et des actions dans les scènes:
Un déclencheur sur niveau d’alerte
Une action Récupérer la vigilance Meteo France
Les variables exposées pour utilisation dans les messages.
Une action Envoyer la carte de vigilance Meteo France
Exemple dans Telegram
J’ai pu tester et c’est parfait 
Je n’ai pas trouvé de bug de mon côté 
Salut @Will_71,
J’ai lancé Fable 5 sur le chantier des intégrations externes de type “Météo” pour te débloquer. 
L’objectif est de te permettre de migrer ton intégration vers une intégration externe, afin que tu puisses la faire évoluer en toute autonomie.
Concernant le widget, on va clairement faire évoluer l’existant en s’inspirant de ton excellente proposition. Merci pour tout le travail que tu as fourni, c’est vraiment une très bonne base !
@Will_71 :
Pour info je t’ai invité au repo Gladys pour que tu puisses être invité à review des PRs
@Will_71 La PR du SDK :
Tu peux regarder si le contrat d’API te parait bien ?
Je regarde et je te tient au courant
Top ! Claude me dit que l’approche prise est le format est normalement suffisant et totalement compatible avec l’approche que tu as prise avec Météo France.
Donc normalement, tu pourras proposer le nouveau widget et une intégration externe Météo France en te basant sur cette base
après on pourra aussi ajuster si besoin
Oui, la seule limite c’est que maintenant qu’on fournit une API, tout doit rester rétrocompatible et versionné en cas de changement breaking.
Donc pas le droit de changer de format d’API tous les 4 matins !
Mais là je suis plutôt confiant.
Je vais faire une intégration externe gladys-openweather de mon côté
J’ai regardé ta PR sur le sdk.
Voilà les points que j’ai relevé
-
Carte de vigilance — WeatherPayload n’a aucun champ image. Aucun canal. Ne fonctionnera pas.
-
La description des alertes plafonnée à 2000 caractères. Pas sur que cela passe avec le bulletin complet meteo france, après il donne aussi un résumé court.
De mon côté j’ai:- text — le résumé officiel, une phrase (« Épisode caniculaire sévère et durable en cours. »), plafonné à 1000 caractères
- bulletin — le bulletin complet multi-paragraphes, plafonné à 4000 caractères
-
Les déclencheurs de scène en fonction de l’état de vigilance
Dans ma PR meteo france toutes les 15 min, checkVigilance() interroge l’API pour chaque maison. La couleur du moment est comparée à celle du tour précédent.
Si elle monte et atteint au moins 2 (jaune), le service émet EVENTS.METEO_FRANCE.NEW_VIGILANCE. scene.triggers.js:105 récupère l’événement et démarre les scènes concernéesC’est l’intégration qui pousse l’information vers Gladys, spontanément.
Or onWeatherGet fait l’inverse : Gladys appelle l’intégration, l’intégration répond. L’intégration n’a aucun moyen de dire « il se passe quelque chose maintenant ». Le SDK n’expose pas de canal push pour ça.
Conséquence : les scènes déclenchées par la vigilance ne fonctionnent plus. Sauf si le core se met lui-même à interroger les intégrations météo à intervalle régulier et à détecter les transitions
Je regarde et je reviens vers toi !
Salut @Will_71 !
Merci pour ton retour détaillé, il était très juste, les trois manques que tu as pointés étaient réels. On vient de les traiter sur la PR de l’API météo générique (#2738), en gardant à chaque fois la version la plus générique possible :
1. La longueur des textes d’alerte 
Le champ description passe de 2000 à 5000 caractères : ton résumé + le bulletin complet y tiennent (les bulletins CAP de la NWS dépassent aussi régulièrement les 2000 caractères, ce n’était pas spécifique à Météo France). Côté widget, le bulletin s’affiche replié sur 3 lignes et se déplie au clic, comme dans ta PR d’origine.
2. Les triggers de scène sur la vigilance 
C’était le point le plus important. On a fait deux choses :
- Deux nouveaux triggers de scène génériques dans le core : « Alerte météo déclenchée » et « Alerte météo terminée », configurables par maison, type de phénomène (vent, pluie-inondation, orages, canicule… les 9 phénomènes de la vigilance MF sont dans l’enum) et sévérité minimale. Le core interroge la météo toutes les 30 minutes et diffe les alertes : une alerte qui apparaît ou s’aggrave déclenche, une alerte qui se termine déclenche. Ça marche avec tous les fournisseurs, sans rien implémenter côté intégration.
- Un « nudge » pour la fraîcheur : ton intégration, qui sait quand la vigilance change, peut envoyer
external-integration.weather.refresh(viarequestWeatherRefresh()dans le SDK). Le core relance alors immédiatement son cycle de vérification : la scène part en quelques secondes au lieu d’attendre le prochain poll. C’est volontairement un signal sans données (la doctrine « trigger, not data » qu’on applique déjà aux webhooks) : les données repassent toujours par le chemin normalisé.
3. Les cartes de vigilance 
Le format pivot gagne un champ images : ton intégration déclare jusqu’à 3 images (clé + libellé multilingue), et le core va chercher les octets à la demande via weather.get-image (onWeatherGetImage(cb) dans le SDK). Le core valide (PNG/JPEG uniquement, ≤ 500 Ko), met en cache 10 minutes et sert l’image depuis l’origine Gladys : le navigateur ne charge jamais d’URL tierce. Dans le widget, une case « Images du fournisseur » affiche tes cartes J et J+1 avec leur libellé. Et c’est générique : un fournisseur peut aussi y mettre un radar de pluie ou une image satellite.
Le SDK est à jour avec onWeatherGetImage et requestWeatherRefresh. Avec les conditions plus fines ajoutées juste avant (partly-cloudy, pouring, hail + le flag is_day pour les variantes nuit) et les alertes typées, tout ce que ton front affichait devrait maintenant passer par l’API générique.
N’hésite pas si tu vois encore un manque en portant ton intégration, c’est le pilote du type météo, tes retours calibrent le contrat pour tous les fournisseurs suivants. 