OpenWB Zeitweise falsche Werte über MQTT

[CChris]

Hallo Zusammen,

das Thema wurde bereits hier kurz angesprochen...

Jap, ist bei mir auch so. Seit dem Update auf 2022.10 kommen diese Logs.

Ich habe aber auch schon lange ein anderes Problem. Wenn ich HASS neustarte werden mir in die Sensoren immer irgendwelche alten Daten geschrieben die mehrere Tage alt sind. Noch schlimmer ist es wenn ich die OpenWB neustarte. Dann stehen sogar in der OpenWB völlig falsche Verbrauchswerte drin. Hat das auch schon mal jemand beobachtet?

Ich habe meine OpenWB in ein Smarthome-System eingebunden und lese dort entsprechend die Werte aus, welche über MQTT von der OWB kommen.
In der Vergangenheit hatte ich immer mal wieder das Problem, dass bei einem Neustart der OWB - oder meines Smarthome-Systems alte Daten in den MQTT Topics versendet wurden.
Da stand dann auf einmal der Zähler-stand von vorletzter Woche... und es hat etwas gedauert, bis wieder die korrekten Daten gesendet wurden.

In diesem Fall hatte ich ein wenig weiter recherchiert und gesehen, dass die Daten (zumindest bei einem Neustart der Smarthome-Software) von einem lokalen MQTT Broker kamen, welcher als Bridge zwischengeschaltet war.

Weitere Suche ergab, dass das Verhalten vorkommen kann, wenn der Broker die Verbindung verliert - bzw. nicht korrekt beendet war und dann ggf. vom letzten reboot Daten in einer internen DB ziwschengespeichert hat.

Evenutell relevante Informationen können hier gefunden werden, oder wenn man generell nach "persistence" in Verbindung mit MQTT sucht.

Ich habe vor einigen Tagen mein System neu aufgesetzt - und mich dabei direkt zum MQTT Broker der OWB verbunden - um das "Problem" mit der Bridge zu umgehen.
Zwischenzeitlich sah alles i.O. aus - mehrere Neustarts des Systems zeigten keine Auffälligkeit - bis ich mir die Daten heute morgen wieder angeschaut habe.

Aufgefallen ist mir das, da ich in meinem Smarthome-System einige Zähler implementiert haben, welche die Daten der OpenWB erfassen (openWB/lp/1/kWhCounter) - aber sich in bestimmten Intervallen dann wieder Zurück setzen.
So bekomme ich in meinem System eine Statistik über die Nutzung Wöchentlich / Monatlich / etc.

Auffällig war, dass einige dieser Zähler einen höheren Stand hatten als die OpenWB gesamt geliefert hat.
Die Historie für die Sensoren zeigte dann, dass - nahezu ALLE - Topics zur selben Uhrzeit auf einen vorherigen Zustand zurückgesetzt wurden - und dann nach ca. 5 Minuten wieder den korrekten Wert übermittelt haben.

Hier ein paar Beispiele:

Ladepunkt aktiv:

Ladepunkt freigegeben:

Zählerstand geladene Energie (LP1) gesamt:

2022-10-19_06h01_37.png (8.97 KiB) 1352 mal betrachtet

Zählerstand geladene Energie (LP1) seit Anstecken:

Zähler der OpenWB mit aktuellen Werten verglichen mit den Aufsummierten Zählerwerten der eigenen Zähler - der Zähler zählt nur in eine Richtung die Differenz - da die Werte der Quelle zuvor kleiner waren als Ursprünglich und dann wieder nach oben korrigiert wurden, wird dieser Anstieg erneut gezählt.

Leider habe ich im Moment keinen Zugriff auf die Logs der OWB - um zu prüfen ob zu diesem Zeitpunkt ein Neustart stattfand ... es KANN allerdings sein, dass zu dieser Zeit ein neustart meiner Smarthome-Lösung durchgeführt wurde... Leider stehen mir die Logs hierfür auch nicht mehr zur Verfügung.

Da ich aber - wie bereits erwähnt habe, keinen Broker als Bridge zwischen meinem System und der OWB habe, kommen diese Werte diesmal definitiv von der OpenWB.
Mir ist durchaus schon aufgefallen, dass die OpenWB auf irgendwelchen Topics "alte" Daten liefert - Topics, welche es inzwischen offizell gar nicht mehr gitb und noch aus einem älteren SW Stand kommen dürften...
Hier wäre es schön, wenn das Thema "persistence" der Nachrichten ggf. noch einmal aufgegriffen werden kann...

Denn die MQTT Schnittstelle wird sicherlich in einigen Fällen als Quelle für Datenlogger und ähnlichem genutzt werden - und die alternative wäre, dass man hier für jedes entsprechende System eine eigene Fehlerbehandlung implementieren muss (was ggf. nicht ohne Weiteres möglich ist)

[yankee]

Erinnert mich an #2430 bei dem es darum ging, dass retained-Nachrichten in der Cloud festhingen, weil sie wegen unterschiedlichen QoS in falscher Reihenfolge gesendet wurden. In dem Kontext ging es um set-topics, bei dir geht es um Zählerstände, insofern versuche ich hier keinen direkten Zusammenhang, aber es könnte eine ähnliche Ursache sein.

Die Historie für die Sensoren zeigte dann, dass - nahezu ALLE - Topics zur selben Uhrzeit auf einen vorherigen Zustand zurückgesetzt wurden - und dann nach ca. 5 Minuten wieder den korrekten Wert übermittelt haben.

Hilfreich wäre ein Debug-Log aus der OpenWB mit Loglevel 2 zum fraglichen Zeitpunkt. Tritt das häufiger auf? Wenn ja, Loglevel hochdrehen und beim nächsten Vorkommen Log ziehen.

[CChris]

Hi, danke - werde ich machen.
Das Problem: wenn das Problem bisher in meiner alten Installation auftrat, lag das an dem zwischengeschalteten Broker... das konnte ich mit dem MQTT Explorer nachvollziehen - da sich die Daten des Brokers aus der OpenWB NICHT verändert hatten.

Jetzt, mit der neuen Installation ist mir das erst ein mal aufgefallen - und eben leider zu spät, sodass ich keine Logs dazu habe (ich kann ggf. heute Nachmittag schauen, ob & was die OWB geloggt hat)...

Ich werde das auf jeden Fall noch im Auge behalten - und noch ein paar weitere Tests später machen um das ganze ggf. zu reproduzieren. (Log-Level erhöhen, OWB neustarten ... etc.)

[LutzB]

Dein Issue auf Github schließe ich mal, damit nicht an zwei verschiedenen Stellen gesucht wird und Infos verloren gehen.

Ich habe meine openWB seit nun über zwei Jahren mit openHab über MQTT verbunden und noch nie solche Sprünge gehabt. Von daher würde ich die Ursache jetzt nicht pauschal bei openWB suchen. Mit HomeAssistant kenne ich mich nicht aus. Bei IOBroker musste man noch eine Einstellung anpassen, damit solche veralteten Daten nicht bei einer Neuverbindung in die openWB gelangen. Vielleicht ist das hier auch der Fall?

[CChris]

Hi,

Es gibt nicht wirklich eine Option in HomeAssistant die man einstellen könnte.
In meiner alten Installation - konnte ich sehen, dass alte Daten von dem "Bridge Broker" versendet wurden...


In der jetzigen Installation ist eben nichts dazwischen geschaltet.
Es wird eine Verbindung zum Broker aufgebaut und auf das Topic registriert, welches man hinterlegt hat.

Danach wird alles empfangen, was ankommt.
Aber ich werde hier ggf. noch mal weiter mit MQTT Explorer und co. versuchen das weiter einzugrenzen... VIELLEICHT ist es ein issue in den Sourcen des Empfängers...
Um das auszuschließen, werde ich ggf. noch andere Empfänger mit einbinden - bei einem Problem seitens der OpenWB sollte sich dies dann ja übergreifend zeigen.

[DirkS]

Ich finde es super, dass du dich da so vertiefst. Ich habe bisher noch keinen Kopf dazu gehabt mich weiter damit zu befassen aber ärgere mich jedes Mal wenn da wieder falsche Daten stehen und starte daher ungern HASS oder die OpenWB neu.

Ich habe die Verbindung vom HA MQTT AddOn zur OpenWB über eine mosquitto.conf in Homeassistant/share/mosquitto eingerichtet.

Code: Alles auswählen

connection openwb
address 123.123.123.100:1883 # IP der openWB
start_type automatic
topic openWB/# both 2
local_clientid openwb.mosquitto
try_private false
cleansession false

[CChris]

So, es gibt wieder ein paar Neuigkeiten - wobei... ich der tatsächlichen Ursache noch nicht weiter auf die Spur gekommen bin

Ich habe gestern im laufe des Tages eine neue Version des HomeAssistant OS installiert.
Soweit sah alles gut aus, gestern abend sind mir dann aber ein paar generelle Probleme aufgefallen, welche hier erst einmal keine Rolle spielen.

Allerdings war auch in der Historie der Open WB wieder ein Sprung zu erkennen...
Zeitlich kann ich das aber nicht zu 100% dem Update zuordnen:

Ein Sprung von 701.34 kWh Zählerstand - auf 689,75 kWh

Schaut man sich die Daten genauer an, sieht man, dass der Stand von 689,75 kWh genau einem früheren Zählerstand entspricht - vor einer der letzten Ladungen:

Leider hatte ich 'natürlich' zu diesem Zeitpunkt keine weitere Protokollierung via MQTT Broker, oder ähnlichem ... und auch die Logs waren aufgrund der viel offensichtlicheren Fehlerbehebungen nach dem update und einigen Neustarts inzwischen nicht mehr vorhanden

Heute morgen habe ich dann angefangen, noch ein wenig an meiner Installation zu arbeiten - bisher lief noch eine alte HomeAssistant installation parallel mit, welche ich in eine Testumgebung umwandeln wollte.
Diese hatte ich gestern komplett herunter gefahren, da diese 'vermutlich' für die anderen Beobachteten Probleme verantwortlich war.

In dieser Installation - läuft ein MQTT Broker (als Bridge) - welcher sich mit der OpenWB verbindet - und auch dort rufe ich die Daten der OpenWB ab.
Nachts hatte ich noch eine "schnelle" Ladung durchgeführt - und heute morgen sah erst einmal alles i.O. aus.

Ich fuhr die "alte" HomeAssistant installation wieder hoch... und habe vorsichtshalber dort den Bridged-MQTT deaktiviert und alles soweit ausgeschaltet.

Zusätzlich lief MQTT Explorer mit... und dort ist mir dann folgende Historie aufgefallen:

Im MQTT Explorer fällt der Zählerstand um 08:15:51 auf 701,34 kWh zurück und um 08:16:51 springt er wieder auf 708,044 kWh hoch.
708,044 kWh war der Zählerstand nach der letzten Ladung.

2022-10-28 08_35_59-Window.png (8.37 KiB) 1188 mal betrachtet

2022-10-28 08_35_52-MQTT Explorer.png (6.68 KiB) 1188 mal betrachtet

Die 701,34 kWh aber - entsprechen wieder dem Ladestand bevor die letzte Ladung begonnen hat

[Aufgrund der Begrenzung an Dateianhängen - neuer Beitrag]

[CChris]

[weiterführung]

In diesem Bild sehen wir die beiden letzten Rücksetzer - jeweils auf die vorherigen Zählerstände...
Mich hat dann interessiert, ob es hier eventuell mit der "alten" Installation noch eine Verbindung geben könnte - auch, wenn ich nicht davon ausgehe...

Diese wurde lt. Logs gegen 08:24: hochgefahren, bzw. zu diesem Zeitpunkt war das System bereit.
Auffällig hierbei ist eigentlich nur, dass die "alte" Installation zum selben Zeitpunkt ein "Update" der Zählerstände erhällt.
Da sie gestern abend - während die Ladung aktiv war heruntergefahren wurde, stoppt der Zähler bei ca. 706 kWh.
Nach hochfahren der Instanz bekommt sie den neuen Zählerstand übermittelt.
Mehr oder weniger Zeitgleich finden die Sprünge in der neuen Installation statt.

Allerdings - Aufgrund einer leichten Ungenauigkeit zwischen den Zeiten auf meinem Server und meinem Rechner - passen auch diese Sprünge tatsächlich zusammen...

[CChris]

Ich finde es super, dass du dich da so vertiefst. Ich habe bisher noch keinen Kopf dazu gehabt mich weiter damit zu befassen aber ärgere mich jedes Mal wenn da wieder falsche Daten stehen und starte daher ungern HASS oder die OpenWB neu.

Ich habe die Verbindung vom HA MQTT AddOn zur OpenWB über eine mosquitto.conf in Homeassistant/share/mosquitto eingerichtet.

Code: Alles auswählen

connection openwb
address 123.123.123.100:1883 # IP der openWB
start_type automatic
topic openWB/# both 2
local_clientid openwb.mosquitto
try_private false
cleansession false

Hi @David,
Also solange ich einen MQTT Broker ziwschen der OpenWB und HomeAssistant als Bridge laufen hatte, hatte ich das Problem wirklich mit JEDEM neustart - entweder von seiten der OpenWB oder von HomeAssistant.

Teilweise sogar so massiv, dass sich die Daten über mehrere Stunden hin nicht wieder "korrigiert" hatten.
Das konnte ich zwar etwas abmildern, indem ich in etwas regelmäßigeren Abständen - bzw. nach einem Reboot ein "resendMQTT" an die Openwb geschickt hatte, aber eine wirklich Nachhaltige Lösung war das nicht.

Bei der Verwendung mit der Bridge kommt es jetzt m.E. darauf an fest zu stellen, von welchem Broker die alten Daten kommen.
Das kannst du ggf. beobachten, indem du dich mit MQTT Explorer sowohl direkt auf den Broker der OpenWB verbindest - als auch in einer zweiten Instanz auf den Broker deiner HA installation.

Bei mir war es zumindest in den meisten Fällen so, dass die falschen Daten vom Broker in der HA installation kamen.

Das hängt vermutlich an folgendem:
1. Der HA MQTT-Broker läuft als Addon in HomeAssistant.
Das bedeutet eigentlich nichts anderes als: Innerhalb deiner HomeAssistant Installation wird ein Docker-Image mit dem Broker ausgeführt.
Dieser MQTT Broker verbindet sich mit dem Broker deiner Wallbox.

Nun hast du die MQTT Integration, welche sich auf deinen HA Broker verbindet und das Topic OpenWB abgreift.

Vermutlich nutzen BEIDE (!) MQTT-Broker, sowohl der auf der OpenWB, wie auch der in HomeAssistant >Retained< informationen.
d.h. sie speichern sich nachrichten in einer lokalen Datenbank ab.

Dies passiert i.d.R. z.B. vor einem Reboot.
Wenn du jetzt dein HomeAssistant neu startest, bedeutet dies allerdings nicht, dass auch der Broker (welcher in HA läuft) neu gestartet wird.
Der Docker-Container läuft weiter - speichert sich also die aktuelle Nachricht nicht ab.

Dennoch "verliert" der Broker die Verbindung zu deinem Client... sobald diese wieder hergestellt wird, sendet er daher die "Retained" Topics wieder ab... dein System bekommt den falschen, zuletzt abgespeicherten Zustand.

Es gibt diverse Hinweise im Netz, wie man hier mit "Persistent-Nachrichten" usw. in der Konfiguration umgehen kann um solche Phänomene zu umgehen.

Allerdings hat das bei mir zumindest mit der Bridge nicht funktioniert...

Aktuell konnte ich das Verhalten eben insofern abmildern, dass ich diesen Bridged-Broker aus der gleichung heraus genommen habe.
Doch wie man in diesem Beitrag leider sehen kann, tritt das Problem nach wie vor auf - wenn auch inzwischen DEUTLICH seltener.

Ob meine alte HomeAssistant Installation, in welcher die Bridge noch aktiv war - hier irgendwie eine Rolle gespielt hat, kann ich aktuell nicht sagen.
Dazu müsste ich das Szenario bei einem der nächsten Updates noch einmal durchspielen.
Inzwischen habe ich die Bridge komplett offline genommen und auch aus dem alten System heraus genommen.

[DirkS]

Hat es evtl doch was mit der HASS Integration zu tun? Ich baue mir grade einen Volkszähler MQTT Input und bin dabei auf das gestoßen:

Restoring sensor states
Sensors which restore the state after restart or reload should not extend RestoreEntity because that does not store the native_value, but instead the state which may have been modifed by the sensor base entity. Sensors which restore the state should extend RestoreSensor and call await self.async_get_last_sensor_data from async_added_to_hass to get access to the stored native_value and native_unit_of_measurement.

https://developers.home-assistant.io/do ... last_reset