Pour le bouton « Forcer la mise à jour », tu es sûr que tu as installé l’intégration avec le bon manifest ?
Tu as bien copié le manifest venant du build ?
Oui, là pour le coup, sûr à 100%.
La seul fois où le manifest à changer, pour le coup j’ai trouvé ça logique et d’instinct j’ai supprimé puis recréé. Si c’est possible d’ailleurs en dev, pouvoir modifier le manifest directement depuis l’intégration ou mieux qu’il le vérifie/recharge seul serait encore mieux (notamment pour les testeurs), mais là je pose seulement la question de la faisabilité ^^
Et pour le coup :
-
Si aucune image prod (Tuya), la mise à jour du dev crée une erreur :
-
Si une image prod est active (Zendure), la mise à jour du container charge l’image prod et ecrase le dev (ennuyeux ^^) => Voir la version de l’image docker ci-dessous après clic sur mise à jour vs l’adresse
http://10.5.0.227:1444/dashboard/integration/device/external/ext-dev-zendure-2/configqui indique que j’étais sur l’image dev
=> l’adresse prod esthttp://10.5.0.227:1444/dashboard/integration/device/external/ext-terdious-gladys-zendure/config
Ouch ^^ 
Concrètement, tous les fabricants de batteries grand public (Anker, Zendure, EcoFlow, Marstek, Bluetti…) proposent :
- des batteries solaires (avec entrées PV),
- des batteries simples (sans entrée PV).
Donc la catégorie n’est pas spécifique à Zendure (le nom dans le titre, c’est juste l’intégration à l’origine du besoin) — au contraire, on la rend réutilisable pour toutes les batteries de stockage. La PR se concentrait sur les batteries solaires, mais on peut tout à fait couvrir les deux cas.
Et en effet les remarques de GPT5.6.
Je mets à jour la PR dans ce sens.
Pour info :
Noms génériques (aucun terme Zendure), alignés VE/Gladys.
État de charge
| Type | Sens | Unité |
|---|---|---|
battery-level |
État de charge | percent |
Puissances (instantanées, ≥ 0)
| Type | Sens | Unité |
|---|---|---|
charge-power |
Puissance entrant dans la batterie | watt / kilowatt |
discharge-power |
Puissance sortant de la batterie | watt / kilowatt |
solar-input-power |
Entrée PV | watt / kilowatt |
output-power |
Total vers la maison (PV direct + décharge) | watt / kilowatt |
grid-power |
Import réseau | watt / kilowatt |
off-grid-power |
Sortie hors-réseau (secours) | watt / kilowatt |
Énergies (compteurs cumulés) + état
| Type | Sens | Unité |
|---|---|---|
charge-energy |
Énergie totale chargée | kilowatt-hour |
discharge-energy |
Énergie totale déchargée | kilowatt-hour |
solar-energy |
Énergie solaire totale | kilowatt-hour |
output-energy |
Énergie totale fournie à la maison | kilowatt-hour |
grid-energy |
Énergie totale importée | kilowatt-hour |
off-grid-energy |
Énergie totale sortie hors-réseau | kilowatt-hour |
available-energy |
Énergie disponible actuelle (instantané) | kilowatt-hour |
→ UNITS_BY_CATEGORY['battery-storage'] = [PERCENT, WATT, KILOWATT, WATT_HOUR, KILOWATT_HOUR], défaut par type : percent (level), watt (puissances), kilowatt-hour (énergies) — ce qui règle le point fallback du reviewer. Et catégorie ajoutée à isSensorCategory.
- Store d’intégration mis à jour avec le nouveau format de manifest, donc tu peux y aller @Terdious si tu veux publier Tuya ou Zendure
- SDK mis à jour en v0.5.0 ( changelogs )
- Template JS mis à jour avec le SDK v0.5.0
- Gladys mis à jour dans #2665 avec toutes les dernières nouveautés, et un correctif pour le bouton « Forcer la mise à jour »
N’hésite pas si tu as des questions
Petite nouveauté pour éviter d’avoir à attendre 1h entre chaque passage du store d’intégration, j’ai créé un petit tool npx pour valider en local (ou laisser son agent IA valider) qu’une intégration passe bien les règles de validation :
npx github:GladysAssistant/integration-store
A lire sur le README du store.
Je mets à jour le template JS
@Terdious, est-ce qu’il te manque encore quelque chose pour Zendure, Tuya, Netatmo, Shelly ou d’autres intégrations ?
Mon objectif est de sortir une première V1 la semaine prochaine. L’idée n’est évidemment pas de couvrir tous les cas dès le départ, mais d’avoir une base solide sur laquelle on pourra itérer. Si on peut déjà proposer quelques intégrations à ce moment-là, ce serait vraiment génial ! 
« Nous » pensons que oui !! En tout cas pour des v1 sans nul doute ^^ Merci beaucoup !!
Evidemment j’en suis conscient, ce serait de toute façon impossible de déterminer tous les besoins actuels et futurs sans itérer dessus ^^
Je pense que pour une V1 tout ce qui est déjà proposé est suffisant ! La preuve, je fais pratiquement tout fonctionner !!
Ecoute, je suis en SDK 0.5.0, et ça fonctionne !!^^
Bon il a fait pas mal de modification entre temps, donc je pars du principe que c’était de notre côté. L’UDP fonctionne sur 6 appareils / 10 et les autres il faudra les ajouter en manu. Et c’était déjà le cas sur l’intégration Tuya Core, donc c’est qu’on est bon !!
Edit : Bon ça c’était moi, maintenant je laisse la parole à Claude 
C’est malin ça redonne du boulot 
:
OUI, j’ai lu le SDK 0.5.0 en entier (via ton fork, dans mon périmètre) — et c’est énorme : PG a industrialisé quasiment tout ce qu’on s’était dit. Trois game-changers qui touchent directement notre roadmap :
| Nouveauté SDK 0.5.0 | Ce que ça fait | Résout |
|---|---|---|
publishTransports() + DEVICE_TRANSPORTS + manifest transports:["local","cloud"] |
Badge local/cloud/injoignable par appareil (macaron) rendu par le core ; et quand les 2 canaux sont déclarés, le core affiche un toggle standard « Préférer le local » livré comme clé réservée GLADYS_PREFER_LOCAL |
#8 + notre point 3 (notre local_mode custom devient standard !) — c’est exactement ce qu’on a argumenté à PG |
publishDiscoveredDevices fait désormais un UPSERT des params d’un appareil déjà créé (IP DHCP qui change, cloud→local…) sans toucher nom/features ; un changement de structure affiche le bouton « Mettre à jour » |
Plus besoin de supprimer/recréer | C (le manque « update params ») + le churn DHCP |
Manifest actions + onAction(key, cb) avec l’exemple detect_protocol (IP saisie à la main → détection de protocole, timeout_seconds jusqu’à 120 s) |
Bouton d’action avec résultat affiché | #7 (appareils non vus par l’UDP : IP manuelle + détection) |
Bonus dispo aussi : onGetImage/publishCameraImage (caméras/sonnettes), OAuth2 (onOAuthAuthorizeUrl/onOAuthCallback, Netatmo-style), sous-containers (getContainers/startContainer + onHardwareUpdated), setConnectionStatus (état de connexion appli).
Ce que ça implique pour nous (gros mais dans le bon sens)
On devrait migrer sur le modèle standard :
- remplacer notre config
local_modecustom partransports:["local","cloud"]+ lecture deGLADYS_PREFER_LOCAL(mon modèle « toggle live » de tout à l’heure se branche dessus tel quel) ; - appeler
publishTransportsà chaque poll pour afficher le badge local/cloud/injoignable (et notre circuit-breaker →unreachable) ; - ajouter l’action
detect_protocolpour les appareils non scannés ; - profiter de l’upsert des params : notre re-scan au toggle met maintenant vraiment à jour les appareils existants (IP incluse) → on pourra retirer le contournement
resolveDevice/mergeParams à terme.
MAIS ça dépend de ce que la branche core que tu tournes implémente réellement (transports, GLADYS_PREFER_LOCAL, onAction, upsert). Avant de migrer, je veux lire ton core.
Excellent !! 
Je serais très curieux d’avoir tes retours sur Netatmo et Frigate ensuite
Netatmo est normalement couvert, il y a tout une gestion de l’oauth.
Frigate est géré aussi avec une gestion des sous-containers.
@ProtZ je penses que l’intégration Nuki pourrait devenir une intégration externe
@cicoub13 Idem pour TP-Link !
@bertrandda à voir ce qu’on fait pour Airplay et Google Cast
Si certains veulent tester les intégrations externes, voilà un build Docker (amd64 only) :
ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2
L’image est mise à jour automatiquement avec tous les développements que je fais
La documentation est à jour !
En français :
En anglais:
Bravo pour tout le travail effectué sur cette architecture qui va débloquer plein de mondes
Il y a juste un détail qui m’embête 
Avant, une intégration développée par qqun était intégrée dans Gladys et d’autres développeurs ou toi @pierre-gilles pouvait venir faire un fix ou une évolution si le développeur principal n’avait pas le temps ou ne répondait plus.
Dans le futur, avec ces intégrations externes, que se passe-t-il si une intégration n’est plus maintenue ? Elle devient inutilisable ? Il faut faire un fork et demander aux gens de migrer à la main ?
Et question bonus ? Comment décide-t-on si une intégration doit être externe ou interne ?
Oui, on peut tout à fait imaginer un fork dans ce cas. Et si une intégration devient très utilisée avec une vraie demande de migration simplifiée, on pourra envisager un processus de migration pour accompagner les utilisateurs.
L’idée est aussi que la communauté puisse reprendre facilement une intégration abandonnée : comme tout est ouvert et découplé du core, la maintenance ne repose plus uniquement sur moi.
À part les intégrations vraiment “universelles” (Matter, Zigbee, MQTT…), pour moi, quasiment tout ce qui peut être externe devrait l’être.
Ce qui me surprend le plus avec ce nouveau système, c’est à quel point l’expérience utilisateur est identique à une intégration native. Avec Fable 5, on a réussi à créer une expérience où, côté utilisateur, il n’y a quasiment aucune différence entre une intégration interne et une intégration externe.
En revanche, pour le projet, la différence est énorme : les contributions peuvent être faites en parallèle sans demander de mon temps, et l’expérience est standardisée entre les intégrations.
Honnêtement, je ne serais pas surpris qu’on arrive à plusieurs centaines d’intégrations dans les prochains mois grâce à cette approche.
OK, merci pour les réponses.
J’ai un peu peur de la qualité des intégrations externes et du coup du ressenti utilisateur vis-à-vis de Gladys. Une des forces de Gladys, c’est sa stabilité.
Même si l’installation se fait en pointant vers un repos externe (et que les docker sont blindés pour ne pas affecter l’instance Gladys), les utilisateurs vont arriver ici en disant Gladys ne fonctionne pas.
HA a mis en place un système de scoring des intégrations pour guider les utilisateurs sur leur qualité. On va vers ça aussi ?
C’est une crainte légitime, et il faudra effectivement être vigilant là-dessus. Mais aujourd’hui on a plutôt le problème inverse : le manque d’intégrations 
Depuis le début de la v4, c’est probablement le reproche n°1 qui revient : beaucoup d’utilisateurs aimeraient utiliser Gladys, mais leurs appareils ne sont tout simplement pas supportés.
À terme, si on arrive à avoir des centaines d’intégrations externes, je pense qu’il faudra effectivement mettre en place des mécanismes pour aider les utilisateurs à faire leur choix : notes, commentaires, indicateur de maintenance, nombre d’utilisateurs, dernière version publiée, etc.
Mais ne mettons pas la charrue avant les bœufs 
La priorité aujourd’hui est d’avoir un écosystème d’intégrations beaucoup plus large. On pourra ensuite construire les outils nécessaires pour garder une bonne qualité globale.
Ok, j’ai avancé sur les intégrations de type « Communication » (ex: Telegram), et c’est disponible dans le SDK v0.6.0.
Je viens de porter avec Fable l’intégration Telegram en one-shot, et ça marche parfaitement.
Je trouve même que l’expérience est meilleure qu’avec l’intégration qu’on a dans Gladys
Le repo Github:
Possible d’avoir un build arm v8 ?