EDIT (Pierre-Gilles): Die Integration von Enedis-Linky ist verfügbar!
Die Dokumentation:
Hallo @bertrandda! Super Entwicklung 
Was die Geschichte des Gateways angeht, bin ich etwas skeptisch, eine Drittanbieter-Firma für diese Art von Entwicklung zu nutzen:
- Was sagt uns, dass diese Plattform langfristig bestehen bleibt? Bei Ausfall/Update der API, was sagt uns, dass der Entwickler Zeit investieren wird, um diese Plattform zu warten?
- In Bezug auf die Datensicherheit, ja, die Website sagt, dass nichts gespeichert wird, aber wir müssen ihr einfach vertrauen!
- Die Enedis-API hat ein Rate-Limit pro Unternehmen, das ziemlich niedrig ist. Da nichts über den Server läuft (und der Client tun kann, was er will, was mir übrigens auch fragwürdig erscheint), können wir keine Warteschlange für die Anfragen implementieren. Ich denke, dass wir ziemlich schnell Probleme mit Synchronisationen und Fehlern 429 bekommen werden…
- Ich finde es aus Sicherheitsgründen etwas seltsam, dass die Tokens an den Client gegeben werden. Bei anderen Gateways, die ich gesehen habe (https://enedisgateway.tech zum Beispiel), fungiert das Gateway als Durchgang und gibt die Enedis-Tokens nicht an den Client weiter. Dadurch kann man Rate-Limiting durchführen und Anfragen bei hohem Traffic in eine Warteschlange stellen.
Idealerweise wäre ich dafür, die rechtliche Struktur des Projekts zu nutzen und das über Gladys Plus laufen zu lassen, das würde mehr Sinn machen und wäre nachhaltiger ^^
Davon hatten wir schon mal gesprochen:
Allerdings wird das dann über Gladys Plus verfügbar sein, also gegen Bezahlung… Ich will nicht, dass das wie ein Putsch rüberkommt aha ^^ Aber diese kostenlosen Plattformen machen mir etwas Angst, wir haben keine Garantie und wir wollen, dass dieser Service für die nächsten 10 Jahre verfügbar ist.
Was denkt ihr dazu?
In Bezug auf die Wahl dieses npm-Moduls und dieses Gateways habe ich mich für diese Vorgehensweise entschieden, weil sie mir praktisch erschien. Es handelt sich tatsächlich um die Implementierung der Enedis-API. Klar, wenn Enedis seine API ändert, müssen diese Änderungen auch im JavaScript-Modul umgesetzt werden. Aber selbst wenn wir unser eigenes Gateway entwickeln, das dieses Modul verwendet oder nicht, müssen wir irgendwo Änderungen vornehmen, und die Modifikation auf Seiten des Moduls ist nicht besonders kompliziert. Die Tatsache, dass die Geheimnisse an den Benutzer weitergegeben werden, vermeidet gerade den Umweg über ein Drittanbieter-Gateway bei jedem API-Aufruf von Enedis (und somit das Weiterleiten der Benutzerdaten über einen Drittanbieter-Dienst). Sobald du deine Tokens hast, fragt Gladys direkt bei Enedis an. Selbst wenn das Gateway gelöscht wird oder nicht mehr funktioniert, wird die Integration bei denen, die sie bereits konfiguriert haben, weiterhin funktionieren.
Aber ich verstehe durchaus den Nutzen eines Pufferservers, um Fehler zu reduzieren. Ich glaube nicht, dass dies heute ein echtes Problem ist (ich habe nachgeschaut, die Grenze liegt bei 5 Anfragen/Sekunde), und auf unserer Seite, wenn wir einen Fehler haben, versuchen wir 30 Minuten später erneut, die Daten abzurufen (schon jetzt haben wir einen halben Tag Verzögerung bei den Daten aufgrund der Enedis-API, es sollte also nicht zu problematisch sein, ein paar Minuten länger zu warten). Wenn das also das einzige Problem ist, kann ich über enedisgateway.tech gehen.
Allgemeiner zu dieser Enedis-Linky-Integration und Gladys Plus: Ich bin absolut dafür, Dienstleistungen hinzuzufügen, die das G±Angebot ergänzen können. Das ist es, was das Projekt langfristig am Leben erhält. Aber während Alexa, Google, Owntracks… der Umweg über G+ notwendig ist, weil eine öffentliche URL benötigt wird, weil die Verbindung von außen initiiert wird, funktioniert dies hier bei jedem Benutzer. Ich bin sogar bereit, etwas zusätzliches auf Seiten von G+ mit einem speziellen Enedis-Vertrag für die Gladys-Struktur zu entwickeln, um mehr Stabilität für die G±Benutzer zu bieten. Aber es stimmt, dass ich diese Integration als neue Motivation sah, um grundlegende Benutzer zu haben (die zwangsläufig einen Teil zu Gladys-Plus-Benutzern führen wird). Es ist die Art von Modul, das du ohne zusätzliche Kosten konfigurieren kannst, wie das Wetter, der Kalender, Telegram… für jemanden, der Gladys einige Wochen testen möchte, kann es nur vorteilhaft sein.
Darüber können wir noch einmal diskutieren. Ich glaube nicht, dass es eine sehr dringende Integration ist, die veröffentlicht werden muss. Auch die Meinung der anderen ist zu sehen.
Gerade bin ich mir nicht sicher, ob das eine gute Praxis ist! Diese Tokens sind dafür gedacht, von dem Partnerunternehmen verwendet zu werden, nicht vom Endbenutzer, oder?
Für den kommerziellen Teil bin ich offen! Das kann außerhalb von Gladys Plus sein, das kann eine separate Option sein, alles ist möglich
Ich erlaube mir, zu diesem Thema zu antworten, nehmt es mir nicht übel 
In diesem Fall (wenn ich deiner Argumentation folge), warum gehört dann die Wetter-Integration nicht zum Gladys-Angebot? Wäre eine Installation ohne Token nicht einfacher?
Eigentlich denke ich, dass es eher in Richtung „Nutzungsbedingungen“ der Enedis-API geht, die nur für Unternehmen bestimmt ist.
Ja ja, hab ich verstanden
ich geh xD
@bertrandda wenn ich mich nicht irre, sind die Tokens 1 Jahr gültig. Hast du eine API-Rückmeldung mit dem Ablaufdatum?
Ich stimme @VonOx zu, der Nutzer erstellt sein Konto selbst und steht in direkter Beziehung zu OpenWeather
Im Fall der Enedis-API benötigt man einen Unternehmensdienstleister, der einen Vertrag mit Enedis unterzeichnet (das ist eine Anforderung von Enedis, in diesem Fall wäre es einfacher, wenn es wie bei OpenWeather wäre!)
Ich bin mir nicht sicher (muss überprüft werden), ob die Tokens für den Endnutzer bestimmt sind, aus Gründen der 1) IT-Sicherheit 2) vertraglichen Bestimmungen
Um einen Vergleich zu ziehen, die Integration mit Enedis ist meiner Meinung nach viel näher an der Integration von Alexa/Google Home als an der Integration von OpenWeather, und bei Google Home/Alexa hat der Endnutzer keinen Zugriff auf die Tokens, das wäre schlimm
Tatsächlich hätte ich die Enedis-API wohl etwas genauer studieren sollen, wir sollen nicht direkt auf die Daten zugreifen.
Ich denke, ich werde zunächst versuchen, über das Gateway enedisgateway.tech zu gehen, da es bereits eingerichtet ist. Ich werde versuchen, das auf „modulare“ Weise zu tun, sodass wir das Gateway dynamisch ändern können, wenn der Nutzer G+ abonniert hat oder nicht. Vielleicht können wir sogar nur das G±Gateway nutzen, wenn wir das Gefühl haben, dass das enedisgateway.tech nicht hält. Was denkst du, wann wäre das besser?
Grundsätzlich wäre ich eher dafür, über Gladys Plus zu gehen, das ein vertrauenswürdiger Vermittler für Gladys-Nutzer ist. Und ich habe ein bisschen Angst vor dem Rate-Limit, das vom Partner auf 5 Anfragen/Sekunde global für eine Anwendung (alle Clients zusammen) festgelegt ist.
Kommerziell gesehen möchte ich einerseits keine Funktion anbieten, die nur „kostenpflichtig“ ist, aber andererseits, wenn wir den Enedis-Gateway enedisgateway.tech „kostenlos“ zusätzlich zu Gladys Plus anbieten (ich setze Anführungszeichen, weil enedisgateway.tech letztlich auch Spenden für die Infrastrukturkosten benötigt), wäre das nicht ein Schuss ins eigene Knie für die Adoption von Gladys Plus, zumal ich bereits große Schwierigkeiten habe, rentabel zu sein 
Ich kann dir auf meiner Seite relativ schnell Enedis-API-Routen auf Gladys Plus bereitstellen, wenn du möchtest. Es ist Oauth, keine riesige Integration
Gut, das geht sehr schnell, ich habe bereits eine Antwort von Enedis erhalten, sie benötigen zusätzliche Informationen, aber ich habe bereits eine erste Version des API-Vertrags
Ich habe die API auf dem Sandkasten getestet und begonnen, Routen auf der Gladys-Plus-Seite zu implementieren, um die Authentifizierung zu verwalten (das ging schnell) + Durchgangsrouten mit Warteschlangen, um die Rate-Limitierung einzuhalten!
Ok gute Nachrichten, ich lasse dir Bescheid geben, wenn du eine erste Version der betreffenden Routen auf der Seite von Gladys Plus hast, damit ich die Datenabfrage auf der Integrationsseite ändern kann.
Gibt es eine Testumgebung für Gladys Plus? Eine Pre-Production oder so, oder starte ich auch G+ lokal?
Ja! Ich werde heute damit weitermachen, das sollte recht schnell gehen, denke ich
Nein, da ich allein an Gladys Plus arbeite, mache ich alles lokal
Sobald die Funktion fertig und gut getestet ist, werde ich sie in die Produktionsumgebung deployen und dir alle Informationen geben, um darauf zuzugreifen.
Ich kann dir bereits das Format der API-Antworten geben, da es dem Enedis-Format entspricht (ich bin nur ein Vermittler, ich ändere nichts)
Hier sind die verfügbaren Routen auf der Enedis-Seite, die ich bereitstellen werde:
Beispiel für Parameter/Antworten auf der Route /v4/metering_data/consumption_load_curve:
Query:
{
usage_point_id: 16401220101758,
start: '2022-08-01',
end: '2022-08-03',
}
Antwort:
{
"meter_reading": {
"usage_point_id": "16401220101758",
"start": "2019-05-06",
"end": "2019-05-12",
"quality": "BRUT",
"reading_type": {
"measurement_kind": "power",
"unit": "W",
"aggregate": "average"
},
"interval_reading": [
{
"value": "540",
"date": "2019-05-06 03:00:00",
"interval_length": "PT30M",
"measure_type": "B"
}
]
}
}
Aber ich nehme an, du hast das bereits mit der aktuellen Integration gemacht, also wirst du hier nicht viel ändern müssen?
Ich habe heute gut gearbeitet, ich habe die meisten Backend-Routen auf der Gladys Plus-Seite fertiggestellt.
Die Authentifizierung auf der Gladys Plus-Seite funktioniert gut:
(Das ist ein erster Proof of Concept, ich werde es verbessern)
Auf der Gladys-Seite wird deine Enedis-Integration super einfach sein, du wirst Zugriff auf JS-Funktionen haben, die dir die Daten zurückgeben. Bisher habe ich drei Funktionen codiert:
const data = await gladys.gateway.enedisGetConsumptionLoadCurve({
usage_point_id: '22516914714270',
start: '2021-09-01',
end: '2021-09-05',
});
const data = await gladys.gateway.enedisGetDailyConsumptionMaxPower({
usage_point_id: '22516914714270',
start: '2021-09-01',
end: '2021-09-05',
});
const data = await gladys.gateway.enedisGetDailyConsumption({
usage_point_id: '22516914714270',
start: '2021-09-01',
end: '2021-09-05',
});
Diese Funktionen geben die gleichen Daten zurück wie die Enedis-API.
@bertrandda Ich habe eine erste Version der API für dich fertig!
Ich habe dir alle Informationen zur Nutzung der API per Nachricht geschickt
Zögere nicht, mir dort zu antworten, falls du Fragen hast!
Du warst schnell!
Danke, ich schau mal rein.
Hallo zusammen! Am Ende bin ich es, der hier vorankommt, und ich möchte euch meine verschiedenen Überlegungen vorstellen.
Der Teil mit der Verbindung/Datenerfassung in Gladys ist fast funktionsfähig, und ich möchte parallel dazu die Überlegungen zur Anzeige dieser Daten in der Benutzeroberfläche starten.
Hier sind einige Entwürfe dazu.
Verbindung mit der Enedis-API
Anzeige der verschiedenen erkannten Zähler und Vertrags-/Tarifdeklaration
Anzeige auf der Dashboard-Seite
Ich denke, es ist interessant, auf dem Dashboard Boxen zu haben, die speziell für den Stromverbrauch gedacht sind, damit man hier super-kustomisieren kann.
Ich denke dabei insbesondere an die Berechnung der Kosten des verbrauchten Stroms, die mit den Daten der Zähler berechnet wird:
Was haltet ihr von diesen Überlegungen?
Fehlen noch Informationen?