Je viens d’essayer mais les widgets ne fonctionnent pas.
Dans les logs rien de spécial on voit qu’il récupère bien les stations et les prix
Tu as bien configuré les widgets ?
Tu peux mettre une capture d’écran de ta config stp en masquant eventuellement les éléments sensibles ?
Tu es bien en 2.0.5 sur l’intégration ?
Gladys est bien en 5.1.1 ?
De mon côté je n’ai pas de problème avec les widgets
Pour les versions oui c’est bon.
Pour la capture de la config tu veux quoi l’intégration ou le widget?
Après pour la config y’a rien de particulier donc je te dirais oui j’ai bien configuré.
Tout 
Afin que que je puisse reproduire sur mon instance de dev 
Edit : Si informations sensibles, envoi en privée
Ca fonctionne mais il a fallu désinstaller et réinstaller l’intégration.
Ok c’est noté je soumets à Claude dans l’après midi pour voir s’il trouve un bug
Merci
j’ai créé trois maisons et trouve ‹ Ma maison dans Gladys ›, je devrais trouver les trois …
Prévisualiser les stations proches échoue …
J’ai supprimé puis recréé vu le niveau de version…
Voici le retour de Claude :
- « Les données du widget sont indisponibles »
Cause (vérifiée dans le code de Gladys) : le cœur attend l’ack de widget.get en 15 s (WIDGET_GET_TIMEOUT_MS). Au-delà, le front (ExternalWidgetBox.jsx) :
efface le contenu déjà affiché, affiche « données indisponibles » sans détail, ne planifie aucun réessai → la carte reste morte jusqu'à un rechargement du dashboard (d'où la réinstallation).Sur un conteneur froid on dépasse facilement 15 s : 2 cartes qui tirent en même temps, la recherche en cercles concentriques (1 requête par anneau, timeout 15 s chacune), le géocodage du code postal, les noms de stations (2 jeux de données de plus).
Correctif :
getWidgetContent a sa propre échéance de 9 s ; au-delà il renvoie une carte « Lecture du flux open data… » avec un TTL de 15 s, pendant que le vrai pull continue et remplit le cache → la carte se remplit toute seule au pull suivant. Une vraie erreur reste une erreur (le cœur l'affiche à l'utilisateur) : seul l'ack manqué était muet. stationStore.search partage sa promesse en vol : 2 cartes = 1 recherche au lieu de 2.
- Les arrondis
C’est Gladys, pas l’intégration, et à deux endroits :
tuile avec un nombre → formatNumber avec maximumFractionDigits: 2 tuile liée à un appareil → DeviceFeatureValueText → Math.round(v * 10) / 10 → 1 décimaleC’est le second cas sur ta capture : 1,699 devient 1,7 dans le widget, 1,699 sur la page de l’appareil.
Correctif : toutes les tuiles de prix envoient désormais du texte formaté par nous (1,699), dans la langue envoyée par le cœur. Contrepartie assumée : la carte « Ma station » perd la liaison live à l’appareil — mais notifyWidgetsChanged pousse déjà le cœur à retirer la carte après chaque passe qui bouge un prix.
À signaler en amont si tu veux : DeviceFeatureValueText qui arrondit à 1 décimale est discutable pour n’importe quel capteur précis.
3. Plusieurs maisonsLe cœur ne sait résoudre les options dynamiques d’un select que sur les appareils (SELECT_SOURCES = [‹ devices ›]) — aucun manifeste ne peut lister les maisons.
Correctif :
house.js garde maintenant toutes les maisons localisées (il n'en gardait qu'une). Nouveau champ de config « Quelle maison » (texte libre, optionnel) : nom comparé sans casse ni accents, vide = la première localisée. Le bouton « Aperçu des stations » affiche la maison utilisée + la liste des maisons connues de Gladys, pour savoir quoi écrire. Les noms seulement, jamais les coordonnées.
Tout devrait être corrigé dans la version 2.0.6 qui vient de sortir
Ce soir tout semble correct maison par maison.
Simplement elles sont accessibles dans paramètres et il n’y aurait pas moyen de constituer une zone de liste ?.. OK c’est du confort.
Pour moi en principe c’est tout bon …bravo.
Bien après cette période de tests je recadre avec les seuls carburants que j’utilise.
Habituellement je vais à cette station mais ils vendent du SP98 :
• TotalEnergies - 104/106 AV MEDERIC - Noisy-le-Grand (1.6 km) — Gazole : 2.250 EUR/L, SP98 : non vendu, E10 (SP95-E10) : en rupture…
Merci
C’est corrigé dans la prochaine version (2.0.7) :
Tu avais raison : ta station vend du SP98. Elle affichait « non vendu » à cause d’un trou dans les données, que l’intégration lisait mal. C’est corrigé et poussé sur
claude/quirky-hypatia-59syh1.Ce qui se passait
- Hier, le fichier national disait « SP98 en rupture temporaire depuis le 21/09 ».
- Aujourd’hui, le flux ne donne plus rien pour le SP98 : ni prix, ni rupture. La station a sans doute levé sa rupture sans remettre son prix.
- L’intégration lisait ce « rien » comme « non vendu ».
Correctif
- Quand le flux ne dit rien sur un carburant, l’intégration regarde maintenant l’historique des prix des 30 derniers jours (jeu public
prix-des-carburants-j-1).- Si la station a affiché un prix pour ce carburant sur cette période, il passe en « en rupture » au lieu de « non vendu ».
- Une rupture « définitive » déclarée par la station n’est jamais remise en cause.
- Si l’historique ne répond pas, rien ne casse : on garde ce que dit le flux.
- La réponse est gardée en mémoire 6 h, donc pas de requête en plus à chaque rafraîchissement.
- Code dans src/countries/franceRecent.js, branché dans src/countries/france.js.
Vérifié sur ta station (93160009)
- Avant : SP98 non vendu.
- Après : SP98 en rupture. Même chose pour l’E10, qui est vraiment en rupture en ce moment.
- Tous les tests passent (4 nouveaux), ainsi que le lint et le format. La doc FR/EN et
CLAUDE.mdsont à jour.À savoir
- Sur l’appareil, le texte sera « En rupture », sans date, parce que le flux n’en donne pas dans ce cas.
- Dès que la station remettra son prix SP98, il s’affichera normalement.
Merci pour cette nouvelle version avec widgets/déclencheurs : le widget « les moins chères » et le déclencheur « la station la moins chère a changé » sont vraiment très utiles en ce moment
Question : au niveau de l’affichage du nom des stations, pourrait on l’ajuster en fonction de la place disponible sur l’écran qu’on utilise ?
Sur Ordi
Sur Mobile :
Ok, alors je pense que la meilleure solution serait que Gladys envoie la largeur de l’écran en cours et que le texte s’adapterait selon l’option n°3, mais je comprends que c’est une demande au niveau du core.
Concernant l’option 1, si je comprends bien, ce serait de créer un dashboard PC et un autre dashboard pour mobile ? Pour moi c’est trop « lourd » et ça ne me convient pas !
Donc ce que je proposerais en attendant serait d’apporter un paramètre sur l’option 3 : pouvoir régler le nombre de caractères à afficher car ça permettrait à chacun de l’adapter à ses écrans (de mon côté j’ai encore de la place sur mes écrans PC/Tablette/Mobile) ?