Gladys Assistant 4.66: Energieverbrauch und Zigbee2mqtt 2.7.1!

Danke @pierre-gilles für die Entwicklung dieser Funktion und @Terdious für die Finanzierung :ok_hand:

Das ist sehr vielversprechend, aber ich muss geduldig sein, bevor ich meine Informationen im Dashboard anzeigen kann: Die Berechnung des Verbrauchs und der Kosten für meinen historischen Verbrauch liegt bei 3% in 30 Minuten, also werde ich etwa 15 Stunden brauchen! Mit einem Zlinky und etwa zwanzig intelligenten Steckdosen nehme ich an, dass das normal ist :wink:

Ich wollte jedoch zwei Aspekte meiner Benutzererfahrung bei der Einrichtung dieser Integration teilen, falls das hilft:

Die Dokumentation erklärt, dass man « die Hierarchie seines Stromnetzes sehen kann » und dass man « sicherstellen muss, dass jedes Gerät richtig mit seinem Elternteil verknüpft ist ». Ich glaube, ich verstehe in etwa, worum es geht, aber eigentlich bin ich mir nicht so sicher, und ich denke, es könnte eine Erklärung in diesem Schritt der Dokumentation geben, die erklärt, warum es eine Hierarchie gibt, was sie bringt und welche typischen Hierarchien es gibt. Das gegebene Beispiel mit der Steckdose Nous ist dafür etwas ‹ leicht ›.
Zum Beispiel habe ich bei mir eine Enedis-Integration, einen Zlinky-Zähler, eine Messsteckdose für Verbrauch, die tatsächlich die Erzeugung von Energie meiner Solarpaneele verfolgt, und etwa zwanzig intelligente Steckdosen, die den Verbrauch messen, von denen einige ‹ gestapelt › sind. Zum Beispiel habe ich eine Verbrauchssteckdose ‹ Multimedia › am Eingang eines Mehrfachsteckers und mehrere andere Verbrauchssteckdosen für Geräte an diesem Mehrfachstecker (der Bildschirm, der Verstärker,…). Und ich bin mir nicht sicher, welche Hierarchie ich einrichten soll :wink:
Okay, ich gebe zu, dass ich vielleicht ein bisschen zu weit gehe…

Und außerdem, als ich das Zlinky in der Zigbee-Integration aktualisiert habe und dann in die Energieverfolgungs-Integration gegangen bin, hatten die 6 EASFxx-Indizes (ich bin im Tempo-Tarif) keine klaren Namen (HC Blau, HP Blau, HC Weiß,…). Vielleicht liegt das daran, dass ich zuerst auf 4.66 migriert habe und dann auf 4.66.2 (weil ich glaube, dass du einige Verbesserungen daran vorgenommen hast, Pierre-Gilles, aber vielleicht haben die beiden aufeinanderfolgenden Updates mir nicht davon profitieren lassen…). Ich weiß nicht, ob es möglich ist, die klaren Namen automatisch zu vergeben?

Danke für dein Feedback!

Halte uns auf dem Laufenden, sobald es berechnet ist, ich bin gespannt auf das Ergebnis :slight_smile:

Die Idee ist, eine Hierarchie basierend darauf zu erstellen, wer an was angeschlossen ist.

Wenn eine Steckdose an einer anderen angeschlossen ist, muss die „Eltern“-Steckdose in der Hierarchie oben platziert werden und die „Kind“-Steckdose unten.

Langfristig wird das ermöglichen, den tatsächlichen Verbrauch korrekt zu rekonstruieren, ohne doppelt zu zählen, besonders wenn mehrere Geräte „gestapelt“ sind.

Bisher wird diese Möglichkeit noch nicht genutzt, aber es wird später nützlich sein :slight_smile:

Also, es gibt zwei Dinge :grinning_face_with_smiling_eyes:

  • Bisher habe ich die Geschichte der EASFxx nicht ganz verstanden (du musst im Standardmodus sein). Bei mir bin ich im historischen Modus, und mein Lixee TIC gibt eher BBRHPJB usw. zurück. Wenn du mir die Bedeutung jedes EASFxx geben kannst, kann ich sie ordnungsgemäß in Gladys integrieren!
  • Diese neuen, klareren Namen werden jedoch nur für neue Geräte verwendet, die mit Gladys gekoppelt werden. Ich kann es mir nicht leisten, die Namen bereits bestehender Funktionen zu überschreiben: Wenn ein Benutzer seine Daten umbenannt hat, wie er es möchte, wäre es etwas hart, alles zu ersetzen…

Jetzt könnten wir auch einen kleinen Helper in der Zigbee2MQTT-Schnittstelle hinzufügen, um spezifische Erklärungen für dieses Gerät anzuzeigen, das, ehrlich gesagt, für alle ein bisschen komplex ist (mich eingeschlossen :grinning_face_with_smiling_eyes:).

Zum Beispiel könnte man das machen:

Wenn du mir die Bedeutung jeder Funktion (EASFxx + external_id in Gladys) gibst, kann ich das alles in die Schnittstelle integrieren!

Soweit ich in Gladys gesehen habe, existieren alle Indizes/Namen des Standard-TIC bereits in einem MQTT-Gerät namens „Téléinformation“ (inklusive der EASFxx), aber nicht im historischen TIC (was eine Verbesserung sein könnte, denke ich).

Die EASF können je nach Energieanbieter variieren:

  • EDF Tempo, dann verwendet man EASF01 bis EASF06 für HCJB, HPJR usw.
  • Super-Spitzenzeiten von Total Energies: HP, HC und HSC, dann verwendet man nur EASF01, 02 und 03
  • EDF Basis: EASF01
  • EDF HP/HC: EASF01 und EASF02
  • usw.

Ich denke, es ist schwierig, spezifische Namen für den Standard-TIC zu haben, da, wenn man den Anbieter wechselt, EASF01 vom alten zum neuen Abonnement wechselt (aber was ist mit dem Index …).

Hallo zusammen,

Ich habe heute Morgen an der Weiterentwicklung des Widgets „Verbrauch“ gearbeitet:

  • Möglichkeit, zwischen einer „Kosten“- und einer „Verbrauch“-Ansicht in kWh umzuschalten
  • Dynamische Währungsverwaltung (Euro vs. Dollar für unsere US-Nutzer!)

Hinzufügen eines „Lade“-Status, wenn sich das Widget aktualisiert:

Der Pull Request:

Hallo!

Als ich heute Morgen versucht habe, all das in Betrieb zu nehmen, habe ich festgestellt, dass es eine MQTT-Funktion „Energieerzeugung“ gibt. Wird diese im Energiebereich, über den wir hier sprechen, verwaltet?

Falls ja, ist es möglich, die beiden „30-Minuten“-Intervalle automatisch zu erstellen, ähnlich wie bei den anderen Indizes?

Nein, das wird nicht verwaltet :slight_smile: Die Funktionen existieren zwar und du kannst sie mit Daten füllen, aber dieser Bereich existiert derzeit nicht in Gladys.

Ich beobachte diese Entwicklung zunächst aus der Ferne, weil ich Solarpaneele besitze, deren API ich nutze, um meinen Verbrauch/Ertrag abzurufen.

Aber die Berechnung der Kosten mit den Hoch- und Niedertarifzeiten ist wirklich super interessant!!

Ich weiß nicht, was am Ende mehr Sinn machen würde: einen Lixee für meinen Linky kaufen oder versuchen, die Werte der aktuellen API mit diesen Energiemanagement-Funktionen zu integrieren?

Derzeit kommuniziert die API mit NodeRed, und ich habe Fake-MQTT-Geräte erstellt, um das Ganze auf Gladys-Seite abzurufen.

@pierre-gilles, was meinst du dazu?

Die Berechnung der Verbräuche hat tatsächlich 15 Stunden gedauert, und jetzt warte ich auf die Berechnung der Kosten: 18% sind in etwa 6 Stunden erledigt… :wink:

ok, das ist klar und ich verstehe die Logik, um Doppelzählungen mit Messwerten des Verbrauchs zu vermeiden.
Aber kannst du mir bestätigen, was ich mit den ‹ Bausteinen › Enedis, Zlinky und der Messung der Solarpanel-Produktion machen soll: Die drei sollten auf der gleichen Ebene 0 sein, und dann sollten alle meine Verbrauchsmessungen unter Enedis liegen? Standardmäßig hat Gladys das gemacht: alles (Zlinky, Solarpanels und jede Verbrauchsmessung) ist ein Kind von Enedis.

Bei mir habe ich das:
EASF01 = HC Blau (externe ID = zigbee2mqtt:Compteur Zlinky:teleinformation:easf01:current_tier1_summ_delivered)
EASF02 = HP Blau (zigbee2mqtt:Compteur Zlinky:teleinformation:easf02:current_tier2_summ_delivered)
EASF03 = HC Weiß (zigbee2mqtt:Compteur Zlinky:teleinformation:easf03:current_tier3_summ_delivered)
EASF04 = HP Weiß (zigbee2mqtt:Compteur Zlinky:teleinformation:easf04:current_tier4_summ_delivered)
EASF05 = HC Rot (zigbee2mqtt:Compteur Zlinky:teleinformation:easf05:current_tier5_summ_delivered)
EASF06 = HP Rot (zigbee2mqtt:Compteur Zlinky:teleinformation:easf06:current_tier6_summ_delivered)

Ich gebe zu, ich habe keine Meinung, das liegt ganz bei dir, was du machen willst :smiley: Der Lixee hat den Vorteil, dass du ihn einfach anschließt und er direkt funktioniert, bei der API musst du ein bisschen arbeiten, du musst selbst entscheiden :wink:

Nein, lass es so, wie Gladys es standardmäßig macht, alles muss ein Kind von Enedis sein, sonst musst du für jedes Gerät an der Wurzel einen Vertrag erstellen (der Vertrag ist mit einem Gerät verbunden).

Danke, aber @mutmut sagte oben, dass diese Funktionen nicht unbedingt Tempo sind, also weiß ich nicht, ob wir da viel machen können, leider :sweat_smile:

Hallo @pierre-gilles,

Vielen Dank für diese tolle Funktion. Ich glaube, ich habe die Dinge in der falschen Reihenfolge gemacht (nachdem ich die Dokumentation gelesen habe :upside_down_face:), und bin in einen seltsamen Bug geraten.

Ich habe den Zlinky und 4 Steckdosen Nous Zigbee, und habe zuerst die Hierarchie erstellt, den Vertrag erstellt und die Berechnungen gestartet, bevor ich die Geräte in der Zigbee-to-MQTT-Integration „aktualisiert“ habe (für die neuen Funktionen). Nachdem ich dieses Update durchgeführt habe, sind die Zigbee-Geräte vollständig aus der Hierarchie verschwunden… Aber das Schlimmste ist, dass, wenn die Hintergrundaufgabe zur Kostenberechnung (erneut) gestartet wird, der CPU auf 100% steigt und die GUI nicht mehr erreichbar ist. Ich musste den Container neu starten. Ich musste den Energietracking-Service deaktivieren.

Gibt es eine Möglichkeit, meine Fehler zu bereinigen und alle Parameter der neuen Integration zurückzusetzen, um von vorne zu beginnen?

Vielen Dank!

David.

Hallo @davidm50,

An sich ist das nicht so schlimm, wenn du die Geräte normal aktualisiert hast, sollten sie sich wieder unter dem Zähler, an den dein Vertrag gebunden ist, platziert haben, oder?

Ah, das ist aber ärgerlich. Hast du Logs, die du mit mir teilen könntest, damit ich versuche, das zu beheben? docker logs gladys --tail=10000 um die letzten 10.000 Zeilen anzuzeigen :slight_smile:

Ich bin mir nicht sicher, ob es dasselbe Problem ist, aber @mutmut hatte vor kurzem ähnliche Probleme, ich würde wirklich gerne verstehen, was passiert!

Du sagst, dass es während der Kostenberechnung passiert?

Vielleicht habe ich eine Idee. In deinem Fall hast du vielleicht versehentlich eine zirkuläre Abhängigkeit zwischen deinen elektrischen Geräten erzeugt

A → B → C → A

Und das erzeugt eine Endlosschleife im Code

Ich werde Code hinzufügen, um solche Fälle zu behandeln!

Ich habe 2 Dinge hinzugefügt:

  1. Erkennung und Anzeige zirkulärer Abhängigkeiten in der Oberfläche mit einem Button zum Beheben:

  1. Im Backend-Code werden zirkuläre Abhängigkeiten erkannt, um die Aufgabe nicht zu blockieren und nicht 100% der CPU zu beanspruchen!

Ich erstelle einen Branch und ein Release mit diesem Fix!

Danke für das Feedback @davidm50 :slight_smile:

Gladys Assistant v4.66.3 ist live, mit:

Energieverfolgung

  • Erkennung von zirkulären Abhängigkeiten, um Blockaden zu vermeiden
  • Wechsel von « Währung » zu « kWh » und dynamische Währungseinheit (Euro und Dollar)
  • DuckDB aktualisiert auf v1.4.3

MQTT

  • Behebung eines Bugs, bei dem numerische Werte nicht als « Zahl » geparst wurden, wenn ein benutzerdefiniertes Topic verwendet wurde, was zu einem nicht gerundeten Rohwert in der Benutzeroberfläche führte.
  • Behebung eines Bugs: Wenn eine Szene auf dasselbe Topic hört wie ein MQTT-Gerät mit benutzerdefiniertem Topic, wird das Topic-Abo für das MQTT-Gerät nicht mehr aufgehoben, wenn die Szene gelöscht wird.

Das vollständige CHANGELOG ist hier verfügbar.

Ich werde mir schließlich einen Lixee zulegen, um mir nicht den Kopf zu zerbrechen.
Allerdings habe ich bei mir den Tarif Vert Électrique Week-End

Die Preise sind hier detailliert aufgeführt: https://particulier.edf.fr/content/dam/2-Actifs/Documents/Offres/grille-prix-vert-electrique-weekend.pdf

Es handelt sich um einen HP/HC-Prinzip, bei dem man seine HC-Zeiten definiert, aber die Wochenenden und Feiertage sind ebenfalls in HC.

Wird dieses Angebot derzeit unterstützt?

Aufgrund der privaten Nachrichten, die @mutmut mir geschickt hat, und der sehr positiven Tests von @Terdious zur Änderung der Speichergrenze von DuckDB, habe ich gerade die Version v3.66.4 veröffentlicht.

Diese Version reduziert die maximale RAM-Nutzungsgrenze von DuckDB von 80 % auf 30 %, um dem System und Gladys mehr Spielraum zu lassen.

Das CHANGELOG ist hier verfügbar.

Dieses Angebot wird nicht unterstützt, und schlimmer noch, wir werden es nicht mit einem einfachen JSON-Definierten Vertrag auf GitHub verwalten können. Wir müssen eine spezielle Logik programmieren, wegen dieser Geschichte mit Wochenenden und Feiertagen :sweat_smile:

Wochenenden sind einfach, aber Feiertage sind die Hölle :joy: Und sag mir nicht, dass du in einer Region mit speziellen Feiertagen wohnst, das wäre der Gipfel :joy:

Ich wohne in Guatemala, wird das funktionieren? :rofl:

Nein, die Feiertage sind in der Nähe von Toulouse die gleichen wie überall in Frankreich, glaube ich. ^^

Tut mir leid, dass ich etwas Hartcodiertes im Code hinzufügen muss!

Und dann siehst du mit einem Klick, dass ein schlecht optimierter roter Tempo-Tag (mit einem nicht ausreichend reduzierten Verbrauch) dich ganz schön was kostet



Danke @pierre-gilles für diese Neuerung!

17€ an einem Tag?? :sob:

Das ist mein Monatsverbrauch, haha

Wärmepumpe im letzten Winter ausgefallen, was mich zwingen würde, auf einen schrecklichen elektrischen Widerstand zum Heizen meines Fußbodenheizung umzusteigen… :sad_but_relieved_face: