Ein Diagramm, mit dem HP HC-Indizes gestapelt werden können. (Ich präzisiere, weil man das heute nicht kann)
In den Diagrammen eine Live-Datenauswahl ermöglichen.
Ich mag den Mockup
In einem weiteren Gedanken: Wäre es nicht besser, die Zähler von den Integrationen zu trennen? Das würde jedem ermöglichen, seine Datenquelle auszuwählen.
Alles, was ich an der Enedis-API mache, ist « generisch », wie üblich, ich verwende eine Kategorie und einen Typ, die bereits in Gladys existieren (ENERGY_SENSOR).
Wir sollten uns abstimmen, damit diese Arbeit auf die Arbeit anbringbar ist, die du am Lixee TIC gemacht hast, und auf die MQTT-Integration, damit sie für alle externen Dateneingänge offen ist.
Welche Kategorie/Typ verwendest du bereits beim Lixee TIC?
Ok, und wir sind uns einig, was die Daten von Lixee TIC angeht, und wenn ich auf der Seite von Gladys grob Folgendes mache:
SELECT SUM(value)
FROM device_feature_state
WHERE device_feature_id = 'xx'
AND created_at >= '2022-12-01 00:00:00'
AND created_at <= '2022-12-01 23:59:59'
Okay, also sind das nicht genau die gleichen Daten wie bei Enedis!
Wir müssen die beiden mit einem unterschiedlichen Typ unterscheiden.
Bei Enedis habe ich Zugang zu 2 APIs:
Lastgangkurve: Diese Teilressource gibt die Werte zurück, die den Messungen des Lastgangs des Verbrauchs eines Kunden für jeden Tag des angeforderten Zeitraums entsprechen. Die zurückgegebenen Werte sind durchschnittliche Verbrauchswerte im Messintervall des Zählers (standardmäßig 30 Minuten). Jeder Wert ist zeitlich markiert. Die Lastgangkurve wird über vollständige Tage von Mitternacht bis Mitternacht des folgenden Tages in lokaler Zeit erhalten. Ein Aufruf kann maximal 7 aufeinanderfolgende Tage umfassen. Ein Aufruf kann Daten umfassen, die maximal 24 Monate und 15 Tage vor dem Aufruftag liegen.
Tagesverbrauch: Diese Teilressource gibt die Werte zurück, die dem täglichen Verbrauch (in Wh) an jedem Tag des angeforderten Zeitraums entsprechen. Jeder Wert ist datiert. Ein Aufruf kann Daten umfassen, die maximal 36 Monate und 15 Tage vor dem Aufruftag liegen.
Auf deiner Seite hast du im Grunde eine Variable, die immer die Summe der vorherigen Variable und des seit dem vergangenen Verbrauchs ist?
Das ist der Zählerstand, er inkrementiert sich immer, ja, das scheint das zu sein, was du beschreibst (es gibt keine Operation, der Zähler liefert den Wert).
Ok, in diesem Fall ist es wirklich ein ganz anderer Job, den Verbrauch und den Preis zu berechnen ^^
Die Arbeit, die ich bei Enedis mache, wird nicht auf Linxee TIC anwendbar sein. Es wird eine spezielle Arbeit erforderlich sein, um in der Lage zu sein, die Verbrauchsdaten stündlich/täglich aus dem Index abzuleiten.
Kleiner Hinweis, einige haben mehrere HC-Zeiten (in meinem Fall von 1:32 bis 8:32 Uhr und von 12:31 bis 14:31 Uhr)
Ich kann es kaum erwarten, das Ergebnis zu sehen, umso mehr, als es wirklich ein aktuelles Thema ist
Hallo,
hier eine kleine Frage: Diese Enedis-Integration, ist das wie Lixee? Nur gültig, wenn man einen Linky-Zähler hat? Nichts für diejenigen, die nicht mit Linky ausgestattet sind?
Damit Enedis die Verbrauchsinformationen täglich (und auch stündlich, glaube ich) zur Verfügung stellen kann, muss man einen kommunikationsfähigen Zähler haben.
Der Unterschied zum Lixee TIC ist, dass es nicht in Echtzeit ist.
Ich unterstütze nur Spenceurs Kommentar, denn bei mir ist es genauso: zwei HC-Zeiten
Ich kann es kaum erwarten, zu sehen, wie diese Integration funktioniert, denn ich habe bereits meine Solaredge-Integration (Solarpanels) und möchte genau sehen, was bei Enedis passiert.
Ich bin mir nicht sicher, ob ich die Verwaltung der Produktion bereits in der ersten Iteration dieser Funktion umsetze, es ist eine separate API auf Seiten von Enedis, das ist wirklich eine zusätzliche Arbeit
Zuerst konzentriere ich mich in der ersten Iteration auf den Verbrauch