Hello,
Pour information et pour éviter les doublons je devrai lancer demain Claude sur une intégration Daikin 
La vidéo sur le développement d’une intégration externe m’a fortement donné envie de me lancer 
J’aurai également peut être besoin de testeur 
Je vous tiens au courant 
C’est developpé et dispo uniquement pour les tests pour le moment :
Par contre je vais attendre la prochaine version pour la sortie de cette PR afin de tester l’authentification:
@pierre-gilles Une idée de quand sort la prochaine version avec le redirect page ?
Merci
J’essaie de faire ça ce soir 
C’est live dans la 4.84.4 :
Merci
L’Oauth2 fonctionne bien et j’ai pu effectuer des tests
Il reste quelques bugs en cours de correction mais j’attends le prochain reset de claude pour continuer J’ai usé tout mes tokens 
Je devrais pouvoir sortir une version stable demain
L’intégration est prête
Elle devrait être dispo d’ici 1h environ pour tous le monde
Pour mon. information perso, quel sont les appareil daikin qui serait compatible avec cette intégration ?
Les climatiseurs seront compatible
Tu as quoi comme appareil daikin ?
Tu peux voir le readme ici :
actuellement aucun ahah
mais surement bientôt ^^
Attention ici on traite que les climatiseurs qui sont connectés sur le cloud daikin et qui utilise l’application onecta
C’est dispo
Petite fix car les valeurs n’étaient pas raffraichit après la 1er connexion au cloud :
Sur une première installation, l’ordre est : le conteneur se connecte à Gladys avant que le compte Daikin n’existe. Le handler connected (index.js:241) détecte !api.isConnected, affiche « aucun compte lié » et retourne — il n’atteint jamais l’étape 4, startPolling().
Ensuite l’utilisateur fait l’OAuth : onOAuthCallback faisait une lecture unique (refreshAndPublish) pour peupler l’écran Découverte… et rien de plus. Le timer n’était donc jamais armé. Les seules façons de le démarrer étaient un redémarrage du conteneur, ou un changement de l’intervalle dans la config (seul cas où onConfigUpdated appelait startPolling()).
D’où le symptôme exact : premières valeurs correctes, puis plus aucun rafraîchissement toutes les 900 s.
Version 1.0.7 dispo
Super ton intégration et merci. J’ai une remarque. Je trouve ton logo/icône beaucoup trop générique. Je rajouterai la marque ou le protocole dessus. Ce sera plus explicite.
Dispo dans la prochaine version qui devrait être dispo dans l’heure :
Attention à bien vider vos cache si jamais vous voyez pas la bonne image après la mise à jour
Je voulais avoir votre avis concernant une fonctionnalité que j’ai commencé à faire développer par claude mais qui implique une contre-partie dans le suivi de l’energie.
En gros j’ai vu que dans la partie suivi de l’energie ceci était apparu :
Ceci était également au niveau 0 à la base mais vous comprendre mieux un peu plus tard 
Je me suis dis qu’on allais exploiter la partie Suivi de l’energie de Gladys avec ces informations qui remontent dans Gladys :
Je lui ai demandé donc de me créer 2 fonctionnalités qui sont « Consommations 30 minutes » et Coût 30 minutes"
Et après l’avoir testé sur la journée du 08/08 la valeur de consommation correspond exactement à ce que j’ai dans l’application Daikin (Idem pour le 09/09) :
Le petit hic c’est que dans le suivi de l’energie on a « Énergie ce mois-ci » et « Énergie cette année » qui reste au niveau 0 de l’intégration comme l’indique la doc ici :
En gros cela ressemble à ceci :
Pour vous je peux pousser en prod cette version avec la conso et le coût 30 minutes ou bien il y a des choses à revoir ?
Merci
Salut @prohand, super boulot, j’ai regardé le code de la branche et le résultat est cohérent avec ce que fait le core. Tu peux pousser, la mécanique est bonne. Trois points quand même, dont deux qui méritent une correction avant ou juste après la mise en prod.
1. Le parent est un compteur qui se remet à zéro, pas un index
Tu publies « Énergie aujourd’hui » en energy-sensor / energy, que Gladys documente comme « la consommation d’énergie cumulée » et traite comme un index. Le job calculateConsumptionFromIndex fait index(t) − index(t−1) et jette les deltas négatifs (« counter reset detected »). Donc rien n’est compté deux fois — c’est bien pour ça que ton total journalier tombe juste — mais tout ce qui est consommé entre le dernier poll avant minuit et le premier poll après est perdu, chaque nuit. Avec 900 s de polling ça fait le dernier quart d’heure de la journée ; et si Daikin ne remplit son bucket 22h–24h qu’après minuit, c’est deux heures qui disparaissent.
Le correctif propre : que l’intégration tienne son propre cumul (dans son store, total += max(0, today − today_précédent)) et publie un vrai energy-sensor / index monotone. Le core dérive alors exactement, et le cas minuit disparaît.
2. Les buckets de 2 h faussent le coût en HP/HC et Tempo
Daikin n’expose que 12 tranches de 2 h. Ta série 30 minutes va donc ressembler à 0, 0, 0, 1.8 kWh, 0, 0, 0, …. Le total du jour est juste (d’où la correspondance avec l’app Onecta), mais la répartition dans la journée ne l’est pas. Or calculateCostFrom tarifie chaque fenêtre de 30 min au prix de cette fenêtre-là : sur un contrat Base c’est sans conséquence, sur heures pleines/creuses ou Tempo le coût peut être franchement faux, selon l’heure à laquelle le poll est tombé.
Deux options : le documenter clairement (« coût fiable en Base, indicatif en HP/HC »), ou mieux — saveStates accepte un created_at, tu peux donc publier les états de l’index horodatés aux bornes des buckets Daikin plutôt qu’à l’heure du poll. La conso retombe alors dans les bonnes demi-heures.
3. Dériver toi-même les UUID, c’est mon problème, pas le tien
Choisir les id des features pour pouvoir pointer energy_parent_id avant que les lignes existent, ça marche (le device.create insère les features puis résout les liens dans une seconde passe), et ton garde-fou — ne nommer que les features que Gladys ne connaît pas encore — est le bon. Mais publier un id dans le payload de découverte n’est pas dans la spec des intégrations externes : ça passe aujourd’hui parce que rien ne le valide, et je ne veux pas que ça devienne un contrat implicite.
Je vais donc câbler addEnergyFeatures() (celui de Zigbee2mqtt/Tasmota) sur les intégrations externes, dans getDiscoveredDevices : toute intégration qui publie un index aura la paire 30 min automatiquement, ids et liens gérés par le core. Garde ton code bien isolé (featureUuid.js + le bloc dans buildDevice) pour pouvoir le retirer d’un bloc quand ce sera dispo.
La demande :
Et deux détails :
energy de ton échelle de capacités ne sert à rien : energy_parent_id est arrivé dans Gladys en août 2025, bien avant les intégrations externes. Toute instance capable de faire tourner ton conteneur a déjà le suivi d’énergie.energy elles aussi, donc elles apparaissent comme parents possibles dans Réglages → Suivi de l’énergie, et un utilisateur qui les câble compterait les mêmes kWh plusieurs fois. Une ligne dans la doc pour dire « ne rattachez que la conso du jour » évitera la question.Bref : go pour la prod, et je m’occupe du point 3 côté core.
Ok merci pour la review super détaillé et pour le point 3 dont tu t’occupes
Je relance Claude sur le sujet mercredi soir
Je vois si je fais une mise en prod avant
Sortie de la 1.0.10 avec la prise en compte dans le suivi de l’energie Gladys
Je vois invite à voir la doc directement pour l’implémentation
Je viens de decouvrir ce site faikin :
Il promette un contrôle daikin 100% en local
Chose encore plus drole il cite gladys en compatibles (logique vu qu’ils passe par mqtt)
