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 ![]()