Enedis-Linky-Integration

Zur Info gibt es in die gleiche Richtung GRDF, das etwas Ähnliches macht

https://sites.grdf.fr/web/portail-api-grdf-adict/faq-grdf-adict

Der Enedis-Sandbox funktioniert heute, also konnte ich die Entwicklung wieder aufnehmen :smiling_face:

Ich konnte erste historische Daten abrufen!

Die grafische Ansicht ist zwar nett, aber nicht unbedingt anpassbar genug, um Verbrauchsdaten dieser Art zu visualisieren.

Der nächste Schritt ist, eine Anzeige dieser Art zu erstellen:

Etwas, das ich nicht verstehe, ist, ob man mit dieser API aktuelle Daten erhalten kann oder nicht, weil ihre Dokumentation nicht klar ist. Sie sagt:

Ein Aufruf kann Daten umfassen, die maximal 36 Monate und 15 Tage vor dem Aufrufdatum stammen.

Und an anderen Stellen:

Also, da ich im Sandkasten bin, sind das nur gefälschte Daten, also schwer zu sagen, ob das der Realität entspricht…

Zur Info: In Domoticz habe ich ein Modul, das die Enedis-API nutzt und die Aktualisierung erfolgt täglich um 8:00 Uhr (ca.).

image

Ich hole mir maximal die Daten vom Vortag. Keine Echtzeitverbrauchsdaten

Möchtest du, dass ich dir meine Enedis-Zugangsdaten sende, um den echten Wert zu testen?

Kann nicht, ich habe noch keinen Zugriff auf die Produktion! Solange die App nicht fertig ist, ist es Sandkasten :slight_smile:

Die Integration entwickelt sich weiter!

Heute arbeite ich an der Konfiguration der Integration und der Anzeige des Konfigurationsbildschirms pro Zähler:

Nur eine kleine Frage aus Neugier: Wer von euch hat einen Grundtarif und wer hat einen Tarif mit Hoch- und Niedertarifzeiten?

  • Grundtarif
  • Tarif mit Hoch- und Niedertarifzeiten
0 votant

Nur um zu wissen, wie ich die Entwicklung priorisiere, da die Kostenverwaltung zwischen den beiden stark unterschiedlich ist:

  • Beim Grundtarif ist es super einfach, ich habe den « täglichen Verbrauch » in einer Enedis-API-Route und multipliziere die Anzahl der kWh mit dem Preis pro kWh.

  • Beim Tarif mit Hoch- und Niedertarifzeiten muss ich alle 30 Minuten auf die Route zugreifen und jeden Verbrauchsabschnitt mit dem entsprechenden Preis multiplizieren. Nicht kompliziert, aber ganz anders als die tägliche Route, die nicht verwendet werden kann :slight_smile:

Hallo,
Zur Information gibt es Städte, für die all dies nicht nutzbar sein wird … nämlich diejenigen, bei denen Strom und/oder Gas von einem kommunalen Versorger und nicht von Enedis oder GrDF verteilt wird.
Siehe: Entreprise locale de distribution d'électricité et de gaz (France) — Wikipédia

Ja, gleichzeitig ist es für diejenigen, die keine Smart Meter haben, schwierig, die Daten remote abzurufen ^^

Es geht voran mit dem Vertrag :sunglasses:

Ich bin heute auch mit dem Code weitergekommen, aber das ist Arbeit und ich möchte das gut machen :slight_smile:

Ich halte euch auf dem Laufenden, sobald ich mehr zu zeigen habe!

Hallo zusammen,

bei mir ist das nicht der Fall, aber ich weiß, dass es bei einigen Anbietern… oder zumindest bei Total Energie! super-günstige Tarifzeiten gibt!

Ich glaube nicht, dass du die Info von Enedis hast.

@pierre-gilles @VonOx
Sollte ich ein anderes Thema erstellen?
Ihr sprecht regelmäßig über die Datenwiederherstellung von Linky über 2 verschiedene Methoden (Cloud-Seite von Enedis von pg und Modul- und App-Seite von VonOx).
Mehrere Male habe ich euch nach den nicht-Linky-Zählern gefragt, die es noch massenhaft gibt (ich spreche nicht von den antiken Scheiben). Diese Vor-Linky-Zähler verfügen über einen Ausgang mit 2 Drähten (für den Abonnenten und EDF), die an ein Teleinfo-Tool von EDF angeschlossen werden können.
Beim Surfen im Netz habe ich herausgefunden, dass man einen PC (drahtlos über ein Modul mit ESP oder kabelgebunden über USB) im seriellen Modus anschließen kann und dass diese Verbindung die gleichen „historischen“ Informationen direkt vom Zähler (und nicht aus der Cloud) liefert, die auch Linky liefert (wobei Linky andererseits zusätzliche „Standard“-Informationen liefert).
Und als ich noch tiefer auf GitHub gegraben habe, habe ich herausgefunden, dass es eine MQTT-Schnittstelle (sogar auf Docker) für Teleinfo (teleinfo2mqtt) gibt.
Wäre es nicht möglich, das Gladys-Angebot mit diesem Modul zu erweitern? Nicht jeder hat Linky, weit davon entfernt…
https://github.com/fmartinou/teleinfo2mqtt

https://canaletto.fr/post/home-assistant-esp-and-teleinfo
Falls die Frage im YT-Live von morgen angesprochen werden könnte (denn man wird wahrscheinlich über die EDF-Entwicklungen um die Daten sprechen)

Das Modul lixee tic verbindet sich mit den Teleinfo-Säulen, nicht sicher, ob es nur für Linky gilt.

Hallo VonOx,
kannst du die Info haben? Bei den Zählern vor Linky besteht die Teleinfo-Schnittstelle aus 2 Drähten, und soweit ich gesehen habe, hat Linky Teleinfo 2 Drähte, aber einen zusätzlichen Draht.
Die Daten, die du mit Lixee TIC abrufst, sind « historische » oder « Standard » Daten, anscheinend beide möglich bei Linky, und wie werden sie gesammelt? Bei den Zählern vor Linky sind es nur « historische » Daten und lokal (der Teleinfo-Port bei Pre-Linky ist nicht bidirektional).
Hast du schon mal von Teleinfo2mqtt gehört und/oder es dir angesehen, das ich erwähnt habe?

Man muss nur ein bisschen suchen :wink:, ich verkaufe nichts.

Das ist für den Linky (in Zigbee)

Das ist für alle modernen Zähler (nicht mit Scheibe) per USB

Ich habe das vorher mit einem Pi gemacht, bevor es den Linky gab.

Als Enedis die API, die ich gerade integriert habe, abwertet :sweat_smile:

Zum Glück ist die API v5 bereits verfügbar! Na wenigstens springe ich direkt zur v5 ^^

Wütend! Aber vielleicht weniger als eine Release zu machen, die nach einigen Tagen veraltet ist :sweat_smile:

Hallo zusammen :slight_smile:

Kurzer Zwischenstand, weil dieses Thema gut vorangekommen ist:

  • Ich hatte Ende des Jahres einige blockierende Fehler mit der neuen Enedis v5 API, die vom technischen Team von Enedis nach den Sommerferien behoben wurden, was mich für diese Entwicklung freigeschaltet hat
  • Die Synchronisation Gladys Plus ↔ Enedis funktioniert gut im Sandkasten. Es ist stabil und ich bin sehr zufrieden mit der Architektur, die ich implementiert habe.
  • Die Synchronisation Gladys lokal ↔ Gladys Plus funktioniert gut, ehrlich gesagt ist das wirklich solide, ich bin zufrieden :sunglasses: Meine Philosophie dazu ist, dass Gladys Plus die gesamte Instabilität des Enedis-API-Teils absorbiert (API-Aufrufe, tägliche Synchronisation, Rate-Limit, Retry, usw…)
  • Ich habe Enedis gebeten, die Verträge neu zu unterzeichnen, da ich meine Rechtsstruktur ändere, willkommen « Gladys Assistant SAS » :partying_face: Das ist der Punkt, der für den Zeitplan der Veröffentlichung einer ersten Alpha entscheidend sein wird, ich hoffe, die neuen Verträge schnellstmöglich unterzeichnet zu bekommen.
  • Sobald die Verträge unterzeichnet sind, muss ich die von mir entwickelte UI Enedis vorstellen. Wenn der Wortlaut in Ordnung ist, kann ich in die Produktion gehen und eine client_id/client_secret für die Produktion abrufen, und dann können wir mit einer Alpha starten.

Wie sieht das aus?

Bei der UI habe ich mich bisher auf den Synchronisationsteil konzentriert, um eine minimale Alpha zu haben, die im Synchronisationsteil sehr stabil ist.

Die schöne Anzeige, die Verwaltung der Kosten (Nacht- und Tagtarif, Basistarif), all das kommt später, sobald die v0.1 in Bezug auf Synchronisation/Stabilität validiert ist!

Die aktuellen Bildschirme:

Ich versuche, das so schnell wie möglich mit dem Zeitplan von Enedis herauszubringen, ich würde es gerne so schnell wie möglich in die Hände echter Benutzer geben.

Der Anzeigeteil, die Berechnungen für volle/halbe Stunden usw. wird eine echte Plage sein, also teile ich die Entwicklung lieber in zwei Teile, um den Tunneleffekt auf meiner Seite zu vermeiden (weil es nicht sehr motivierend ist, im Dunkeln zu entwickeln :stuck_out_tongue: )

Toll !! Gute Arbeit !