Rückmeldungen software2 2.1.8-Alpha 2

[Daphne]

Dieser Fehler kommt übrigens immer noch, auch mit dem neuesten Update:

2025-07-31 08_10_30-(19) Rückmeldungen software2 2.1.8-Alpha 2 - Seite 58 - openWB Forum.jpg (50.78 KiB) 233 mal betrachtet

Gibt es da evtl. schon eine Lösung?

[LutzB]

Bei gewähltem Modum "Zielladen" kann der gewählte Ladeplan nicht durch einfachen Klick auf aktiv gesetzt werden, sondern man muß immer in Ladeprofil, um den Ladeplan zu aktivieren.

Nachtrag bei mir: Deaktivieren klappt, nur nicht das aktivieren.

Ist behoben: https://github.com/openWB/core/pull/2621

[Frank-H]

Bei gewähltem Modum "Zielladen" kann der gewählte Ladeplan nicht durch einfachen Klick auf aktiv gesetzt werden, sondern man muß immer in Ladeprofil, um den Ladeplan zu aktivieren.

Nachtrag bei mir: Deaktivieren klappt, nur nicht das aktivieren.

Ist behoben: https://github.com/openWB/core/pull/2621

Geht bei mir leider immer noch nicht. Weder aktivieren noch deaktivieren. Unter Koala und Colors gehts.

[fawick]

Installierte Version: 2025-07-31 08:24:23 +0200 [177a741f3]

Shelly Plug S (gen1) als Wechselrichter, seit #2591 gemerged und im Master ist, sehe ich folgenden Fehler im Status und es fehlt die PV-Leistung im Graphen:

Alle Wechselrichter:

Code: Alles auswählen

Modulmeldung: Bitte die Statusmeldungen der Wechselrichter prüfen. Es konnte kein aktueller Zählerstand ermittelt werden, da nicht alle Module Werte liefern.

Shelly Wechselrichter:

Code: Alles auswählen

Modulmeldung: <class 'UnboundLocalError'> ("local variable 'currents' referenced before assignment",)

[kai9555]

Leider habe ich erneut unter 2025-07-28 15:43:49 +0200 [18611be30] einen plötzlichen Rückgang der Zählerstände aller SimCounter feststellen müssen. Wie auch bei den vorherigen Vorfällen kann ich kein Log zum exakten Zeitpunkt beisteuern, da das MainLog nur 1 Stunde zurückreicht und mir das Problem leider erst ca. 3 Stunden später aufgefallen ist. Der Vollständigkeit halber dennoch hier das aktuelle Log:
https://paste.openwb.de/UrEi15DBf2fsTDc

Ich hatte dieses Verhalten bereits mehrfach unter 2.1.8 Alpha 2 gemeldet, möchte es aber nochmals schildern – auch weil auf meine bisherigen Beiträge leider keine Reaktion erfolgte und ich deshalb unsicher bin, ob es überhaupt gesehen wurde. Mir ist sehr wichtig, dass der Fehler identifiziert wird, da er alle Statistiken zerstört, sobald Zählerstände unbemerkt zurückspringen.

Konfiguration:

Das Netzwerk ist stabil und die Geräte sind nativ in openWB (kein Proxy oder dergleichen dazwischen) eingebunden. Die Geräte werden auch nur von openWB abgefragt. Die betroffenen Geräte verwenden keine echten Zählerstände, sondern SimCounter von openWB:
• PV: Sungrow
• Speicher: Victron
• Zähler: Victron

Fehlerbild am heutigen Tag (04:15 Uhr):
Alle SimCounter-Zählerstände sind sprunghaft gefallen:
• PV (Sungrow): 4.524 kWh → 4.165 kWh (−359 kWh)
• Speicher Entladung (Victron): 3.061 kWh → 2.924 kWh (−137 kWh)
• Speicher Ladung (Victron): 3.137 kWh → 3.007 kWh (−130 kWh)
• Zähler Import (Victron): 2.697 kWh → 2.531 kWh (−166 kWh)
• Zähler Export (Victron): 941 kWh → 811 kWh (−130 kWh)

Unauffällig:
Geräte, die echte Zählerwerte übermittelt bekommen (z. B. per MQTT vom PV-Wechselrichter), sind nicht betroffen.

Ich erkenne bislang keinerlei Muster oder äußeren Auslöser und bitte dringend um Unterstützung, da dieser Fehler die Langzeitstatistiken erheblich verfälscht und ich keine Möglichkeit sehe, ihn selbst einzugrenzen. In dem Diagramm ist zu sehen, dass scheinbar zum besagten Zeitpunkt ein Problem bestand, da die Zähler auf 0 gingen. Zu dem Zeitpunkt wurde bei keinem Geräten (openWB, Endgeräte, Switch etc) ein Update durchgeführt. Ich habe das Netzwerk geprüft und an keinem Port wurde eine Fehlerhaftes Paket gesendet oder Empfangen - Alles auf 0. Ich wüsste nicht was ich noch tun. kann.

Aber selbst wenn die openWB ein externes Kommunikationsproblem hätte (davon gehe ich aber im Moment nicht aus) , dürften doch nicht die virtuellen Zähler zurückspringen. Es müsste nach meinem Verständnis möglich sein den SimCounter ein Rückspringen zu verbieten?!

Ich wollte euch noch ein kleines Update zu dem bekannten Thema mit den SimCountern geben – konkret geht es um den inzwischen wieder aufgetretenen Zählerstand-Drop am 29.07.2025 bei mir unter 2.1.8 Alpha 2.

Was ist passiert?

Wie auch in den früheren Fällen sind bei allen virtuellen Zählern plötzlich die Zählerstände zurückgesprungen – und in der Monatsübersicht tauchen an diesem Tag für alle betroffenen Geräte plötzlich null Werte auf. (siehe Anhang)

Konkret betrifft es folgende Komponenten, die alle via SimCounter arbeiten:
• PV (Sungrow)
• Speicher (Victron) – Laden & Entladen
• Zähler (Victron) – Import & Export

Alle Geräte mit echten Zählerwerten (z. B. MQTT-Wechselrichter) sind davon nicht betroffen.
Das Logfile, wie schon beim letzten Mal, kann ich leider nicht beisteuern – es war wieder zu spät, um noch in das 1-Stunden-Fenster des Mainlogs zu fallen.

Jetzt aber zur eigentlichen Bitte:

Ich weiß, alle haben viel um die Ohren – und das Projekt ist groß, lebendig und voller Baustellen – aber ich würde mich wirklich freuen, wenn ich zu diesem Thema vielleicht mal ein kurzes Lebenszeichen bekommen könnte.

Bisher kam zu genau diesem Thema:
viewtopic.php?p=130846#p130846
viewtopic.php?p=130115#p130115
viewtopic.php?p=129989#p129989
viewtopic.php?p=129971#p129971
viewtopic.php?p=129257#p129257

leider keinerlei Rückmeldung – obwohl ich sonst bei anderen gemeldeten Bugs immer eine super Kommunikation erlebt habe (viele Grüße an Lena an der Stelle, das war immer top!).

Mir ist auch völlig klar, dass nicht jede Meldung sofort aufgegriffen werden kann – ich möchte nur wissen, ob der Fehler überhaupt auf dem Radar ist oder ob ich vielleicht noch etwas Konkreteres beitragen kann, um weiterzuhelfen. Mein Setup ist recht stabil (LAN, keine Proxys, alles nativ eingebunden), und ich wäre wirklich sehr daran interessiert, mit euch gemeinsam die Ursache zu finden – bevor das Ganze irgendwann in die Beta oder gar den Release wandert.

Danke euch schon mal fürs Lesen – und wie gesagt: Ich helfe wirklich gerne weiter, wenn ich irgendwie kann. Ich möchte nur nicht ins Leere funken.

[seaspotter]

leider keinerlei Rückmeldung – obwohl ich sonst bei anderen gemeldeten Bugs immer eine super Kommunikation erlebt habe (viele Grüße an Lena an der Stelle, das war immer top!).

Mir ist auch völlig klar, dass nicht jede Meldung sofort aufgegriffen werden kann – ich möchte nur wissen, ob der Fehler überhaupt auf dem Radar ist oder ob ich vielleicht noch etwas Konkreteres beitragen kann, um weiterzuhelfen. Mein Setup ist recht stabil (LAN, keine Proxys, alles nativ eingebunden), und ich wäre wirklich sehr daran interessiert, mit euch gemeinsam die Ursache zu finden – bevor das Ganze irgendwann in die Beta oder gar den Release wandert.

Danke euch schon mal fürs Lesen – und wie gesagt: Ich helfe wirklich gerne weiter, wenn ich irgendwie kann. Ich möchte nur nicht ins Leere funken.

Generell muss man verstehen das nur die Live-Ansicht auf den aktuellen Messwerten (Erzeugung, Verbrauch, EVU Zähler) basiert. Jegliche Diagramm-Ansichten für die Statistiken basieren auf den Zählerständen und nicht den Messwerten. Das ist eine wichtige Info, weil einige doch immer wieder denken die Messwerte werden dort dargestellt.

Weiterhin kann ich deine Beobachtung nicht teilen, auch ich habe Geräte mit Simcounter Zählern, weil die Geräte nicht hochauflösend genug die Zählerstände übermitteln (Sungrow z.b.). Ich habe keinerlei Drops in den Zählerständen.

Ursachen-Vermutung meinerseits: In einer deiner vielen Screenshots ist mal ein "Drop" nachts um 4 Uhr gewesen, das kann mit eventuell aktivem Auto-Backup zusammenhängen welches immer Grob in dieser Zeit ein Backup erstellt und dann für kurze Zeit eventuell keine Zählerstände gespeichert werden. Andererseits könnte das aktuelle Problem der auftretenden Abstürze auch eine Ursache sein, falls du davon betroffen bist? Ein anderer Grund kann einfach auch im Netzwerk liegen, dass openWB für kurze Zeit keine Zählerstände bekommt.

[kai9555]

leider keinerlei Rückmeldung – obwohl ich sonst bei anderen gemeldeten Bugs immer eine super Kommunikation erlebt habe (viele Grüße an Lena an der Stelle, das war immer top!).

Mir ist auch völlig klar, dass nicht jede Meldung sofort aufgegriffen werden kann – ich möchte nur wissen, ob der Fehler überhaupt auf dem Radar ist oder ob ich vielleicht noch etwas Konkreteres beitragen kann, um weiterzuhelfen. Mein Setup ist recht stabil (LAN, keine Proxys, alles nativ eingebunden), und ich wäre wirklich sehr daran interessiert, mit euch gemeinsam die Ursache zu finden – bevor das Ganze irgendwann in die Beta oder gar den Release wandert.

Danke euch schon mal fürs Lesen – und wie gesagt: Ich helfe wirklich gerne weiter, wenn ich irgendwie kann. Ich möchte nur nicht ins Leere funken.

Generell muss man verstehen das nur die Live-Ansicht auf den aktuellen Messwerten (Erzeugung, Verbrauch, EVU Zähler) basiert. Jegliche Diagramm-Ansichten für die Statistiken basieren auf den Zählerständen und nicht den Messwerten. Das ist eine wichtige Info, weil einige doch immer wieder denken die Messwerte werden dort dargestellt.

Weiterhin kann ich deine Beobachtung nicht teilen, auch ich habe Geräte mit Simcounter Zählern, weil die Geräte nicht hochauflösend genug die Zählerstände übermitteln (Sungrow z.b.). Ich habe keinerlei Drops in den Zählerständen.

Ursachen-Vermutung meinerseits: In einer deiner vielen Screenshots ist mal ein "Drop" nachts um 4 Uhr gewesen, das kann mit eventuell aktivem Auto-Backup zusammenhängen welches immer Grob in dieser Zeit ein Backup erstellt und dann für kurze Zeit eventuell keine Zählerstände gespeichert werden. Andererseits könnte das aktuelle Problem der auftretenden Abstürze auch eine Ursache sein, falls du davon betroffen bist? Ein anderer Grund kann einfach auch im Netzwerk liegen, dass openWB für kurze Zeit keine Zählerstände bekommt.

Generell muss man verstehen das nur die Live-Ansicht auf den aktuellen Messwerten (Erzeugung, Verbrauch, EVU Zähler) basiert. Jegliche Diagramm-Ansichten für die Statistiken basieren auf den Zählerständen und nicht den Messwerten. Das ist eine wichtige Info, weil einige doch immer wieder denken die Messwerte werden dort dargestellt.

Das ist richtig. Hier stimmt aber etwas nicht, denn in der Tagesansicht erhalte ich Summen der SimCounter, in der Monatsansicht steht jedoch überall 0 bei den SimCountern. (siehe Anhang)

Danke für deine Rückmeldung und die Anhaltspunkte - ich geh mal durch:

das kann mit eventuell aktivem Auto-Backup zusammenhängen welches immer Grob in dieser Zeit ein Backup erstellt

Interssant Gedankengang. Ich habe geprüft und dann diesem Tag wurde das Backup um 01-52-58 Uhr erstellt und 07:54 geschrieben. Würde also sagen daran liegt es nicht

Andererseits könnte das aktuelle Problem der auftretenden Abstürze auch eine Ursache sein

Davon bin ich bisher nicht betroffen. Kein Aufhängen oder Abstürze der openWB.

Ein anderer Grund kann einfach auch im Netzwerk liegen, dass openWB für kurze Zeit keine Zählerstände bekommt.

Im Grunde ist mein Netzwerk sehr robust (wie bereits beschrieben). Es werden auch keine Auto Updates gefahren. Aber trotz allen Potenzialen dürfte es bei einer Verbindungsstörung oder anderen Fehlern doch niemals passieren, dass die SimCounter zurückdrehen. Programmierseitig müsste dem ein Riegel vorgeschoben werden. Gesamtzählerstände sollten nur in eine Richtung zählen.

[fawick]

Installierte Version: 2025-07-31 08:24:23 +0200 [177a741f3]

Shelly Plug S (gen1) als Wechselrichter, seit #2591 gemerged und im Master ist, sehe ich folgenden Fehler im Status und es fehlt die PV-Leistung im Graphen:

Alle Wechselrichter:

Code: Alles auswählen

Modulmeldung: Bitte die Statusmeldungen der Wechselrichter prüfen. Es konnte kein aktueller Zählerstand ermittelt werden, da nicht alle Module Werte liefern.

Shelly Wechselrichter:

Code: Alles auswählen

Modulmeldung: <class 'UnboundLocalError'> ("local variable 'currents' referenced before assignment",)

Hier noch der relevante Auszug aus dem main.log:

Code: Alles auswählen

2025-07-31 10:51:51,385 - {modules.common.fault_state:45} - {ERROR:device3} - ERROR:modules.common.fault_state:Shelly Wechselrichter: FaultState FaultStateLevel.ERROR, FaultStr <class 'UnboundLocalError'> ("local variable 'currents' referenced before assignment",), Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 32, in __call__
    self.__updater(component)
  File "/var/www/html/openWB/packages/modules/devices/shelly/shelly/device.py", line 60, in <lambda>
    component_updater=IndependentComponentUpdater(lambda component: component.update())
  File "/var/www/html/openWB/packages/modules/devices/shelly/shelly/inverter.py", line 72, in update
    currents=currents
UnboundLocalError: local variable 'currents' referenced before assignment

2025-07-31 10:51:53,057 - {modules.common.utils.component_parser:43} - {ERROR:MainThread} - ERROR:modules.common.utils.component_parser:Fehlerstatus in Komponente Shelly Wechselrichter. Werte werden nicht aktualisiert.
2025-07-31 10:51:55,215 - {control.counter_all:172} - {WARNING:MainThread} - WARNING:control.counter_all:Komponente inverter4 ist im Fehlerzustand und wird nicht berücksichtigt.

[seaspotter]

Das ist richtig. Hier stimmt aber etwas nicht, denn in der Tagesansicht erhalte ich Summen der SimCounter, in der Monatsansicht steht jedoch überall 0 bei den SimCountern. (siehe Anhang)

Vielleicht geht es nicht nur mir so, aber diese Info ist für mich komplett neu und offenbar der Kern deine Aussage? Manchmal ist weniger Text und weniger Prosa mehr und konkrete Angaben wo etwas nicht stimmt. Vielleicht habe ich es auch einfach schlicht überlesen.
Weil du aber der Einzige bist der dieses Thema anmerkt: Entweder ist es weiterhin ein lokales Problem bei dir oder niemand schaut sich das an und niemandem ist es aufgefallen?

[kai9555]

Das ist richtig. Hier stimmt aber etwas nicht, denn in der Tagesansicht erhalte ich Summen der SimCounter, in der Monatsansicht steht jedoch überall 0 bei den SimCountern. (siehe Anhang)

Vielleicht geht es nicht nur mir so, aber diese Info ist für mich komplett neu und offenbar der Kern deine Aussage? Manchmal ist weniger Text und weniger Prosa mehr und konkrete Angaben wo etwas nicht stimmt. Vielleicht habe ich es auch einfach schlicht überlesen.
Weil du aber der Einzige bist der dieses Thema anmerkt: Entweder ist es weiterhin ein lokales Problem bei dir oder niemand schaut sich das an und niemandem ist es aufgefallen?

Du hast recht – meine Beiträge enthalten oft recht viele Details. Das liegt daran, dass ich versuche, so viele Infos wie möglich mitzugeben, um das Problem nachvollziehbar einzugrenzen. Aber ich verstehe deinen Punkt: Etwas mehr Struktur und eine klarere Kernaussage würden sicher helfen. Ich nehme das gern mit.

Was du zitiert hast, ist nicht die zentrale Aussage, sondern eher eine Auswirkung dessen, was ich eigentlich beschreiben möchte.

Die eigentliche Kernbeobachtung ist folgende:

Bei allen mir konfigurierten Geräten mit SimCounter (also virtuelle Zähler in openWB wie Victron oder Sungrow) kommt es in unregelmäßigen Abständen zu einem plötzlichen Rückgang des Zählerstandes – und zwar:
• nicht zu festen Zeiten
• nicht um konstante Werte
• nicht bei Geräten mit realen Zählern

Das passiert mal einmal pro Woche, mal zwei- oder dreimal – völlig unvorhersehbar. Die Beträge, um die die Zähler „springen“, variieren stark (mal 130 kWh, mal 300+ kWh) und sind nicht nachvollziehbar erklärbar (z. B. durch Reboot, Stromausfall, etc.).

Auswirkungen davon:
• In der openWB-Tagesansicht sieht man noch Werte.
• In der Monatsübersicht steht dann z. B. beim PV-Ertrag plötzlich eine 0, obwohl der Tag definitiv Ertrag hatte.
• Auch MQTT-Daten stimmen ab dem Drop nicht mehr, was man z. B. in Home Assistant schön sieht: Dort wird der Verlauf des Gesamtzählerstandes als Historie dargestellt – und da ist mir der Drop überhaupt erst richtig aufgefallen.

Ob es ein lokales Problem bei mir ist oder ob es anderen nur (noch) nicht aufgefallen ist – das ist genau das, was ich herausfinden möchte. Dafür bräuchte ich etwas mehr Rückmeldung, damit ich ggf. gezielter weiter analysieren kann. Ein zentrales Problem bei der Analyse ist derzeit, dass das Main-Log im Detailmodus nur eine Stunde zurückreicht – wodurch ich im Grunde nie rechtzeitig einen passenden Logauszug beisteuern kann, da mir der Drop oft erst Stunden oder sogar erst am nächsten Tag auffällt, wenn ich die Daten durchsehe.Ich habe mir jetzt aber mit einer kleinen Home Assistant-Automation beholfen, die mir sofort eine kritische Push-Nachricht sendet, sobald ein Zählerstand droppt. Ich hoffe, dass ich dadurch künftig schnell genug reagieren kann, um den passenden Log-Schnipsel direkt aus openWB zu sichern.