Hallo,
Zur Information und um Doppelarbeit zu vermeiden, werde ich morgen Claude auf eine Daikin-Integration starten 
Das Video zur Entwicklung einer externen Integration hat mir stark Lust gemacht, selbst anzufangen 
Ich werde vielleicht auch Tester brauchen 
Ich halte euch auf dem Laufenden 
Das ist entwickelt und nur für Tests verfügbar, momentan:
Ich werde jedoch auf die nächste Version warten, um die Authentifizierung mit diesem PR zu testen:
@pierre-gilles Hast du eine Idee, wann die nächste Version mit der Umleitungsseite veröffentlicht wird?
Danke
Ich versuche, das heute Abend zu machen 
Es ist live in der 4.84.4:
Danke
OAuth2 funktioniert gut und ich konnte Tests durchführen
Es gibt noch einige Fehler, die gerade behoben werden, aber ich warte auf den nächsten Reset von Claude, um weiterzumachen Ich habe alle meine Tokens aufgebraucht 
Ich sollte morgen eine stabile Version veröffentlichen können
Die Integration ist fertig
Sie sollte in etwa einer Stunde für alle verfügbar sein
Für meine persönliche Information, welche Daikin-Geräte wären mit dieser Integration kompatibel?
Die Klimaanlagen werden kompatibel sein
Welches Daikin-Gerät hast du?
Du kannst das README hier einsehen:
derzeit kein ahah
aber bestimmt bald ^^
Achtung, hier behandeln wir nur Klimaanlagen, die mit dem Daikin-Cloud verbunden sind und die Onecta-App verwenden
Das ist verfügbar
Kleines Fix, da die Werte nach der ersten Cloud-Verbindung nicht aktualisiert wurden:
Bei einer Erstinstallation ist die Reihenfolge: Der Container verbindet sich mit Gladys bevor das Daikin-Konto existiert. Der Handler connected (index.js:241) erkennt !api.isConnected, zeigt „kein verknüpftes Konto“ an und kehrt zurück — er erreicht nie Schritt 4, startPolling().
Dann führt der Benutzer OAuth aus: onOAuthCallback las einmalig (refreshAndPublish) für die Entdeckungsoberfläche… und nichts weiter. Der Timer wurde daher nie aktiviert. Die einzigen Möglichkeiten, ihn zu starten, waren ein Neustart des Containers oder eine Änderung des Intervalls in der Konfiguration (einziger Fall, in dem onConfigUpdated startPolling() aufrief).
Daher das genaue Symptom: erste Werte korrekt, dann keine Aktualisierung alle 900 s mehr.
Version 1.0.7 verfügbar
Super Integration und danke. Ich habe einen Vorschlag. Ich finde dein Logo/Ikon viel zu generisch. Ich werde die Marke oder das Protokoll darauf hinzufügen. Das wird aussagekräftiger.
Sollte in der nächsten Version verfügbar sein, die in etwa einer Stunde verfügbar sein sollte:
https://github.com/prohand/gladys-daikin-cloud/blob/main/cover.png
Achtet darauf, euren Cache zu leeren, falls ihr das richtige Bild nach dem Update nicht seht.
Ich wollte deine Meinung zu einer Funktion hören, die ich Claude entwickeln lassen habe, aber die eine Gegenleistung bei der Energieverfolgung beinhaltet.
Also, ich habe gesehen, dass im Energieverfolgungsbereich Folgendes aufgetaucht ist:
Das war ursprünglich auch auf Ebene 0, aber du wirst später besser verstehen 
Ich dachte mir, wir könnten den Energieverfolgungsbereich von Gladys mit diesen Informationen nutzen, die in Gladys hochgeladen werden:
Ich habe ihn also gebeten, mir zwei Funktionen zu erstellen, nämlich „Verbrauch 30 Minuten“ und „Kosten 30 Minuten“
Und nachdem ich es am 08.08. getestet habe, entspricht der Verbrauchswert genau dem, was ich in der Daikin-App habe (ebenso am 09.09):
Der kleine Haken ist, dass im Energieverfolgungsbereich „Energie dieses Monat“ und „Energie dieses Jahr“ auf 0 bleibt, wie in der Dokumentation hier angegeben:
Also, es sieht so aus:
Für dich kann ich diese Version mit dem Verbrauch und den Kosten von 30 Minuten in die Produktion schieben oder gibt es noch etwas zu überarbeiten?
Danke
Hallo @prohand, super Arbeit, ich habe den Code des Branches überprüft und das Ergebnis ist konsistent mit dem, was der Core macht. Du kannst pushen, die Mechanik ist gut. Drei Punkte gibt es trotzdem, von denen zwei eine Korrektur vor oder direkt nach dem Produktionsstart erfordern.
1. Der Parent ist ein Zähler, der auf null zurückgesetzt wird, kein Index
Du veröffentlichst „Energie heute“ unter energy-sensor / energy, was Gladys als „kumulierter Energieverbrauch“ dokumentiert und als Index behandelt. Der Job calculateConsumptionFromIndex macht index(t) − index(t−1) und wirft negative Deltas weg („counter reset detected“). Also wird nichts doppelt gezählt — das ist gut, warum dein Tagesgesamtwert genau ist — aber alles, was zwischen der letzten Abfrage vor Mitternacht und der ersten Abfrage nach Mitternacht verbraucht wird, geht verloren, jede Nacht. Bei 900 Sekunden Abfrageintervall ist das das letzte Viertel der Stunde; und wenn Daikin seinen Bucket 22h–24h erst nach Mitternacht füllt, sind es zwei Stunden, die verschwinden.
Der saubere Fix: Die Integration hält ihren eigenen kumulierten Wert (in ihrem Store, total += max(0, today − today_vorgänger)) und veröffentlicht einen echten energy-sensor / index, der monoton ist. Der Core leitet dann genau ab, und das Mitternachtsproblem verschwindet.
2. Die 2-Stunden-Buckets verfälschen die Kosten in HP/HC und Tempo
Daikin bietet nur 12 Intervalle von 2 Stunden. Deine 30-Minuten-Serie wird also so aussehen: 0, 0, 0, 1.8 kWh, 0, 0, 0, …. Der Tagesgesamtwert ist korrekt (deshalb die Übereinstimmung mit der Onecta-App), aber die Verteilung über den Tag ist es nicht. Denn calculateCostFrom berechnet jede 30-Minuten-Fenster mit dem Preis dieses Fensters: Bei einem Basisvertrag ist das ohne Konsequenzen, bei Spitzen-/Nebenspitzen- oder Tempo-Tarifen kann der Preis jedoch deutlich falsch sein, je nachdem, wann die Abfrage stattfand.
Zwei Optionen: Das klar dokumentieren („Kosten zuverlässig im Basisvertrag, indikativ in HP/HC“), oder besser — saveStates akzeptiert ein created_at, du kannst also die Zustände des Index zeitlich auf die Grenzen der Daikin-Buckets veröffentlichen, statt zur Abfragezeit. Der Verbrauch fällt dann in die richtigen Halbstunden.
3. UUIDs selbst ableiten, ist mein Problem, nicht deins
Die ids der Features auszuwählen, um energy_parent_id verweisen zu können, bevor die Zeilen existieren, funktioniert (das device.create fügt die Features ein und löst die Links in einem zweiten Durchgang), und dein Schutzmechanismus — nur Features zu benennen, die Gladys noch nicht kennt — ist der richtige. Aber das Veröffentlichen einer id im Discovery-Payload entspricht nicht der Spezifikation externer Integrationen: Das funktioniert heute, weil nichts es validiert, und ich will nicht, dass es zu einem impliziten Vertrag wird.
Ich werde also addEnergyFeatures() (das von Zigbee2mqtt/Tasmota) auf externe Integrationen in getDiscoveredDevices anwenden: Jede Integration, die einen Index veröffentlicht, erhält automatisch das 30-Minuten-Paar, IDs und Links werden vom Core verwaltet. Halte deinen Code gut isoliert (featureUuid.js + der Block in buildDevice), damit du ihn entfernen kannst, wenn es verfügbar ist.
Der Link:
Und zwei Details:
energy deiner Fähigkeits-Skala ist nutzlos: energy_parent_id kam im August 2025 in Gladys, lange vor den externen Integrationen. Jede Instanz, die deinen Container ausführen kann, hat bereits die Energieverfolgung.energy typisiert, daher erscheinen sie als mögliche Eltern in Einstellungen → Energieverfolgung, und ein Benutzer, der sie verkabelt, würde die gleichen kWh mehrmals zählen. Eine Zeile in der Dokumentation mit „Verknüpfen Sie nur den Tagesverbrauch“ würde die Frage vermeiden.Kurz gesagt: Go für die Produktion, und ich kümmere mich um Punkt 3 auf der Core-Seite.
Ok, danke für das super detaillierte Feedback und für Punkt 3, um das du dich kümmerst
Ich erinnere Claude am Mittwochabend nochmal an das Thema
Ich schau mal, ob ich vorher noch eine Produktion mache
Veröffentlichung von 1.0.10 mit Berücksichtigung der Energieverfolgung von Gladys
Ich lade dich ein, die Dokumentation direkt für die Implementierung zu sehen
Ich habe gerade diese Fake-Website entdeckt:
Sie verspricht eine 100% lokale Daikin-Steuerung
Noch lustiger ist, dass sie Gladys als kompatibel auflistet (logisch, da sie MQTT nutzen)
