Hallo,
Ich werde mir heute Abend die Erstellung einer Integration zur Auslesung der Verbrauchsdaten von Gaz auf der Website des Lieferanten ansehen.
Ich denke, ich werde von dem ausgehen, was hier gemacht wurde: GitHub - ssenart/home-assistant-gazpar: GrDF Gazpar meter integration for Home Assistant · GitHub
Es gibt eine andere Lösung, die nicht mehr zu funktionieren scheint: GitHub - vingerha/gazpar_2_mqtt: Revamp of the abandoned gazpar2mqtt · GitHub
Ich bin offen für weitere Vorschläge.
Mein Vorschlag, das Einfachste ist, ein leeres Repo zu erstellen und dann das Folgende in Claude einzugeben:
In diesem Repo möchte ich, dass du eine externe Integration « GRDF Gazpar » für das Lesen der Gasverbrauchsdaten erstellst.
Beginne mit dem offiziellen Integrationstemplate: GitHub - GladysAssistant/integration-template-js: Gladys Assistant Integration template for a JS external integration · GitHub
Dann lass ihn dich überraschen 
Ich glaube nicht, dass es eine gute Idee ist, ihm eine technische Lösung vorzugeben, normalerweise ist er besser als wir darin, und ihm eine Lösung aufzuzwingen, « beschneidet » ihn in seiner Denkweise 
Viel Spaß!
Hallo,
Die Integration kommt in den Store. Sie ermöglicht es, folgende Werte zu verfolgen:
| Funktion | Kategorie | Einheit |
|---|---|---|
| Täglicher Verbrauch | Energiesensor | kWh |
| Tägliches Volumen | Volumensensor | m³ |
| Zählerstand | Energiesensor | m³ |
| Durchschnittliche Außentemperatur | Temperatursensor | °C |
Nur ein Problem, das Claude als spezifisch für meinen Zähler angibt. Die Außentemperatur wird nie aktualisiert. Im schlimmsten Fall entferne ich diese Daten; mir scheint, dass viele von uns Außentemperatursensoren haben (meiner Meinung nach relevanter).
Ich bin ganz Ohr 
Eine Idee wäre, aber wenn die Person keinen Außensensor hat, kann man dann die Wettertemperatur abrufen?
Das ist nicht 100% genau, aber es kann helfen, wenn sie benötigt wird.
Übrigens, nur so aus Interesse (ich habe kein Gas), wofür wird sie verwendet?
Ist das zur Berechnung des DJU?
Meines Wissens ist die Temperatur nur ein Indikator, der hilft, den Gasverbrauch beim Heizen deiner Wohnung besser zu verstehen. Im Winter ist das besonders offensichtlich: Wenn die Temperaturen sinken, steigt der Gasverbrauch.
Außerdem, soweit ich weiß, ist es in Gladys derzeit nicht möglich, ein Diagramm mit zwei verschiedenen Darstellungsarten zu erstellen (z. B. ein Histogramm für den Gasverbrauch und eine Kurve für die Temperatur). @pierre-gilles, liege ich falsch? Falls nicht, kann ich einen Feature-Request erstellen, falls er noch nicht existiert
@PhilippeMA, vergiss nicht, deinem App ein Cover hinzuzufügen!
Ich habe extra eine Version dafür veröffentlicht, aber es hat nicht geklappt… Ich habe gerade gesehen, dass die Bildgröße nicht richtig war (>800x534). Ich habe gerade den ganzen Prozess wiederholt, ich hoffe, es wird jetzt gut sein
Bearbeitung 13:50: Jetzt ist alles in Ordnung!
@PhilippeMA: Danke für diese Integration, die mir sehr nützlich ist
Ich habe einen Verbrauchsfehler in einigen Monaten festgestellt: z. B. zeigt der Mai 2026 je nach Anzeigezeitraum einen anderen Verbrauch an
et ich habe auch keine Zählerstandsanzeige, noch die Temperatur (aber ich weiß nicht, ob ich einen Sensor habe)
Hallo @Chris75,
Du kannst in die Einstellungen der Integration gehen und auf « Daten jetzt aktualisieren » klicken; normalerweise sollte dein Index dann im Dashboard angezeigt werden. Das passiert nur nach der Installation der Integration; und da GRDF die Informationen nur einmal täglich aktualisiert, aktualisiert sich die Integration standardmäßig nur alle 6 Stunden.
Was die durchschnittliche Temperatur betrifft, habe ich das gleiche Problem… Ich werde mal schauen, ob sich das korrigieren lässt, sonst werde ich es entfernen. Wie oben erwähnt, ist dies eine informative Angabe, um den Gasverbrauch zu erklären; ich denke, wir haben diese Information bereits anderswo in Gladys und wahrscheinlich relevanter als die von GRDF.
Ich beobachte bei mir zu Hause das gleiche, was du im Diagramm feststellst. Mir kommt es so vor, als würden die angezeigten Daten für den ersten angezeigten Monat nicht dem gesamten Monat entsprechen.
Wenn du das gleiche Diagramm mit einer täglichen Granularität erstellst, wirst du sehen, dass der Mai am 14.05 beginnt, daher denke ich, dass Gladys, wenn sie eine monatliche Aggregation durchführt, nur die Daten zwischen dem 14.05 und dem 31.05 summiert, was den Unterschied erklärt, den du feststellst.
Kann das jemand bestätigen? (@pierre-gilles)
Autsch, das ist hässlich. Wie viele Tage hast du in der Konfiguration angegeben? (Historische Daten zum Importieren (Tage))
Falls es eine dreistellige Zahl ist, versuche, sie auf 10 zu setzen; da du die Daten bereits importiert hast, ist die Tiefe nicht mehr relevant.
Ich werde versuchen, das zu korrigieren. Danke für dein Feedback
Es ist nicht nötig zu suchen, denn tatsächlich hatte die Konfiguration die ursprüngliche Anzahl (1000 Tage) beibehalten, die ich beim ersten Mal eingegeben hatte: Ich habe 10 eingegeben und jetzt funktioniert es!
Vielleicht könnte man eine Warnung einfügen, die Anzahl zu verringern, sobald der gesamte Verlauf geladen wurde?
warum können wir das Widget „Energieverbrauch“ nicht so nutzen, wie wir es bei Strom tun?
Denn das wurde nicht während der Entwicklung vorgesehen.
Wie immer gibt es nur eine Sache zu tun: eine Funktionsanfrage zu stellen.
ok, aber betrifft diese Funktion die externe Integration oder Gladys?
Hallo @cicoub13,
Ich habe deinen Kommentar an Claude weitergeleitet. Ich bin mir nicht sicher, ob seine Antwort relevant ist…
Hier ist seine Antwort:
Die laufende Korrektur:
Das Manifest und die beiden Dokumentationsdateien. Die neue Bezeichnung des Feldes:
Wird nie an Ihren Browser gesendet, sobald es gespeichert ist, und wird nur an GRDF übertragen. Wie jede andere Gladys-Einstellung wird es unverändert in der Datenbank Ihres Servers gespeichert.
Und der Abschnitt „Datenschutz“ der EN/FR-Dokumentation beschreibt nun die Konsequenz: Jede Person, die Zugriff auf den Server oder ein Backup hat, kann das Passwort lesen, wie bei jeder anderen in Gladys eingegebenen Kennung. Ich weise auch darauf hin, dass GRDF Privatpersonen weder API-Schlüssel, noch Token, noch Anwendungs-Passwörter anbietet — das Passwort des Kontos ist der einzige Zugang, was die Information umso nützlicher macht, zu kennen.
Was sich nicht ändert, und warum:
Es gibt nichts zu verbessern auf der Integrationsseite: Das SDK überträgt uns den Wert im Klartext, und GRDF verlangt ihn im Klartext für die Anmeldung. Eine Verschlüsselung auf unserer Seite würde das Problem nur verlagern — wir müssten den Schlüssel im gleichen Container speichern. Der einzige echte Fortschritt käme vom Kern (Verschlüsselung der Variablen im Ruhezustand) oder von GRDF (ein Authentifizierungsmodus per Token); weder das eine noch das andere liegt in unserem Verantwortungsbereich.
Er hat es geändert, um zu sagen, dass das Passwort nicht verschlüsselt ist (das ist das normale Verhalten). Danke, zumindest wird der Benutzer nicht getäuscht
