Rückmeldungen software2 2.1.8-Alpha 2

[LenaK]

Ich konnte es nur kurz ausprobieren, bevor mein Zähler ganz verstorben ist, leider habe ich kein Log davon.
Kann ich nächste Woche nochmal probieren.

Er hatte jetzt beide Ziele ignoriert, bzw. gemeldet, es wäre kein Ziel aktiv.
Der SoC lag zu diesem Zeitpunkt zwar über dem Ziel-SoC aber nich über dem SoC mit Überschuss, dafür muss das Ziel ja noch aktiv bleiben.
Ich habe dann auf ein Ziel mit höherem Ziel-SoC gestellt, dann startete das Überschussladen wieder.

Ich habe die Berücksichtigung mehrer Pläne nochmal überarbeitet. Steht auch im Hilfe-Text:

...Wenn vom aktuellen Plan Ziel-SoC und SoC-Limit für das Fahrzeug erreicht wurden oder wenn der nächste Plan mit dem Ladestart beginnen muss, wird auf den nächsten Plan umgeschaltet.

Hallo Lena,

ich habe das nochmal beobachtet und mit dem Verhalten noch ein Problem beim Überschuss-Ziel, das vorher m.E. nicht bestand.

Ich nutze ein Ziel (Sa-Mo, Do, 07:00 Uhr) mit Ziel-SoC 45% und 85% mit Überschuss.
Ein zweites Ziel (Di-Mi, Fr, 07:00 Uhr) mit Ziel-SoC 65% und 95% Überschuss.

Der Hintergrund ist, dass ich erst am Tag bevor das "große" Ziel dran ist, bis auf 95% mit PV laden möchte, vorher soll maximal auf 85% mit PV geladen werden, damit die Zeit mit hohem SoC möglichst gering ist, aber trotzdem möglichst viel geladen wird, da mein Akku nicht so groß ist.
Das hat bisher so funktioniert.

Aktuell wird das Ziel 45% / 85% jedoch nach erreichen des Überschuss-Ziels deaktiviert, so dass sofort danach bis 95% geladen wird, da ja als nächstes (Aber ggf. erst in 2-3 Tagen) das Ziel 65% / 95% dran ist.
Vorher blieb das Ziel auch nach erreichen des Überschuss-Ziels noch aktiv, so dass erst 1 Tag vorher bis 95% geladen wurde, wenn das Ziel vom Zeitpunkt her abgelaufen war.

Es dürfte also erst dann auf das nächste Ziel umgeschaltet werden, "Wenn das Zeitfenster des Plans abgelaufen ist (Bei erreichtem Ziel) oder wenn der nächste Plan mit dem Ladestart beginnen muss."
Ist das so nicht mehr realisierbar?

Ein Log von heute, in dem über 85% geladen wurde, anbei. Um 12:07 Uhr habe ich auf Stop gestellt.
Allerdings funktionierte es so, wie Du aus dem Hilfetext zitierst hast, daher hilft das vermutlich nicht viel...

main.log:
https://paste.openwb.de/Kl9yrzLBScPm7zD
https://paste.openwb.de/iQfVBgXOKghXDKa

Ich habe das Verhalten des Zielladen bei mehreren Plänen angepasst: "Es wird nach den Vorgaben des Zeitplans geladen, dessen Zieltermin am nächsten liegt. Ist der Zielzeitpunkt vorbei, wird solange geladen bis, das Ziel erreicht oder das Auto abgesteckt wird. Wenn der Ziel-Termin des nächsten Plans innerhalb der nächsten 12 Stunden liegt, wird auf den nächsten Plan umgeschaltet."

[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

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

Welcher Version hast Du installiert? Sollte mindestens von Heute 10:43 sein.

[LenaK]

weils mir gerade noch mal aufgefallen ist:

Jetzt gerade habe ich reichlich PV-Überschuss während der Strompreis ein Minimum vor dem Zielzeitpunkt hat.

Meine Erwartung wäre, dass bei entsprechendem PV-Ertrag mit mehr Leistung geladen wird, als die Stromvorgabe im Modus "Ziel". Das ist aber nicht der Fall.

ungenutzter-PV-ueberschuss-bei-zielladen-Bildschirmfoto_2025-07-24_13-54-40.png

bye
TW

Bitte ein Log hochladen. Es ist so implementiert, dass falls vorhanden der Überschuss geladen wird, und funktioniert hier auch.

[Frank-H]

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.

Welcher Version hast Du installiert? Sollte mindestens von Heute 10:43 sein.

Ich hatte die nach dem PR 2621, habe aber jetzt noch mal upgedated auf 2025-07-31 13:01:47 +0200 [4e74cc33d]. Geht leider nicht.
Ich habe die Zeitpäne gelöscht, gepeichert und Neustart gemacht. Anschließend neu angelegt. Gleiches Ergebnis.

[LenaK]

Im Log steht die Fehlermeldung Illegal Adress, dh das Register existiert nicht im Zähler. Eine Modbus-Verbindung konnte aufgebaut werden.
Ich habe nachgeschaut, der Port wird mit übergeben. Hast Du nochmal in den Einstellungen geschaut, dass IP und Port richtig sind/keine Zähler vertauscht sind?
ich habe das Logging angepasst, um zu sehen, welches Register nicht vorhanden ist. Also bitte nochmal ein Log posten nach dem Update.

Vorab danke Lena, dass du dich meines Problem annimmst.
Um weiter Werte von den SH-Metern zu erhalten, bin ich auf den vorherigen Master vom 18.06 gewechselt.
hier die Logs :
SH_log_Vers_2025_06_18__14_58_40.txtMain_log_Vers_2025_06_18__14_58_40.txt

Anschliessend direkt auf die aktuelle Version 2025-07-18 14:27:55 +0200 [acffe8ccc] geswitched.
SH_log: SH_log_Vers_2025_07_18__14_27_55.txt
main:https://paste.openwb.de/fyEnXdnxxoxx2Nn
Hier werden die Elgris Smartmeter nicht mehr angezeigt

Hier als Ergänzung zu dem Fehler, dass die SH-Elgris Zähler nicht angezeigt werden:
Im Thread Error Log erscheinen regelmäßig folgende Fehlermeldungen:
"
Uncaught exception in thread:
Type: <class 'AttributeError'>
Value: 'ConfigurableDevice' object has no attribute 'topic'
File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
File "/usr/lib/python3.9/threading.py", line 892, in run
self._target(*self._args, **self._kwargs)
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 116, in update
self.__component_updater(initialized_components, self.error_handler)
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 36, in __call__
error_handler()
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 101, in error_handler
Pub().pub(self.topic, self.error_timestamp)
"
Hat das mit den SH-Zähler Problemen zu tun?

Danke und

Das Problem ist bereits gelöst. Ich hatte ja nochmal das Logging für den Smarthome-Zähler erweitert. Hast Du ein Log, wenn der Elgris nicht antwortet?

[LenaK]

Hast Du ein externes System, dass Werte für den manuellen SoC published? Hast Du das abgeschaltet?

Das published weiter, die Daten werden aber nicht mehr angenommen, daher habe ich das so gelassen.

Das bringt die Berechnung durcheinander. Entweder manueller SoC oder API.

Ich habe ja keine Pro, was passiert denn, wenn man die Option aktiviert hat (Ist ja Quatsch ohne Pro) und keine Pro hat?

Es wird der SoC aus der API verwendet. Wenn man series2 und Pro in der Anlage hat, wird ja auch bei der Pro aus dem Fahrzeug ausgelesen sofern unterstützt und bei der series über die API abgefragt.

[Ihaglc]

Vorab danke Lena, dass du dich meines Problem annimmst.
Um weiter Werte von den SH-Metern zu erhalten, bin ich auf den vorherigen Master vom 18.06 gewechselt.
hier die Logs :
SH_log_Vers_2025_06_18__14_58_40.txtMain_log_Vers_2025_06_18__14_58_40.txt

Anschliessend direkt auf die aktuelle Version 2025-07-18 14:27:55 +0200 [acffe8ccc] geswitched.
SH_log: SH_log_Vers_2025_07_18__14_27_55.txt
main:https://paste.openwb.de/fyEnXdnxxoxx2Nn
Hier werden die Elgris Smartmeter nicht mehr angezeigt

Hier als Ergänzung zu dem Fehler, dass die SH-Elgris Zähler nicht angezeigt werden:
Im Thread Error Log erscheinen regelmäßig folgende Fehlermeldungen:
"
Uncaught exception in thread:
Type: <class 'AttributeError'>
Value: 'ConfigurableDevice' object has no attribute 'topic'
File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
File "/usr/lib/python3.9/threading.py", line 892, in run
self._target(*self._args, **self._kwargs)
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 116, in update
self.__component_updater(initialized_components, self.error_handler)
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 36, in __call__
error_handler()
File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 101, in error_handler
Pub().pub(self.topic, self.error_timestamp)
"
Hat das mit den SH-Zähler Problemen zu tun?

Danke und

Das Problem ist bereits gelöst. Ich hatte ja nochmal das Logging für den Smarthome-Zähler erweitert. Hast Du ein Log, wenn der Elgris nicht antwortet?

Ja Lena, hatte ich direkt auch schon mitgeteilt.
Hier die Logs aus der heutigen Version 2025-07-31 08:24:23 +0200 [177a741f3]

main: https://paste.openwb.de/Z6nTm6VhRzqi69b
SH: https://paste.openwb.de/jNK3nQIwE7RnEtV
thread errors

Code: Alles auswählen

Uncaught exception in thread:
Type: <class 'AttributeError'>
Value: 'ConfigurableDevice' object has no attribute 'topic'
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 122, in update
    self.__component_updater(initialized_components, self.error_handler)
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 36, in __call__
    error_handler()
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 107, in error_handler
    Pub().pub(self.topic, self.error_timestamp)
Uncaught exception in thread:
Type: <class 'AttributeError'>
Value: 'ConfigurableDevice' object has no attribute 'topic'
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 122, in update
    self.__component_updater(initialized_components, self.error_handler)
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 36, in __call__
    error_handler()
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 107, in error_handler
    Pub().pub(self.topic, self.error_timestamp)
Uncaught exception in thread:
Type: <class 'AttributeError'>
Value: 'ConfigurableDevice' object has no attribute 'topic'
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_in

2025-07-31 14_57_27-openWB - SmartHome – Mozilla Firefox.png (10.31 KiB) 183 mal betrachtet

"Einlieger" und "Keller" sind Elgris Smartmeter
Die anderen sind Shellies

Danke für die Unterstützung

[LenaK]

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.

Ein Log erhöht die Chance, die Ursache zu finden, signifikant.
simcount berechnet anhand der Zeit und der Leistung die Zählerstände für Import und Export, dh negative Leistung werden dem Export zugerechnet, positive dem Import. Dadurch kann der Zähler nicht rückwärts zählen.
Ohne Log bleibt offen, was die Geräte für Werte senden, was wird im simcount gerechnet.
Nun nutzt Du HomeAssistant, um ein Log zu bekommen, aber vielleicht könntest Du über das Wochenende nochmal ausprobieren, ob die Drops auch auftreten, wenn Du die Verbindung zwischen HomeAssistant und openWB kappst.

[kai9555]

Dadurch kann der Zähler nicht rückwärts zählen.

Der Fehler war am 29.07. früh um 4, danach gab es den Drop der SimCounter Zähler. Wenn ich das automatische Backup von 29.07. um 2 Uhr einspiele, dann sehe ich bei allen Geräten den höheren SimCounter Zählerstand. Also ein Drop zurück gab es hier nachweislich.

Ein Log erhöht die Chance, die Ursache zu finden, signifikant.

Das versuche ich nun mit meiner Automation zu schaffen. Gibt es einen Plan wann das Detail mainLog wieder länger als 1h laufen wird?

wenn Du die Verbindung zwischen HomeAssistant und openWB kappst.

Es gibt ja nicht wirklich eine aktive "Verbindung" - openWB stellt die Daten via MQTT Broker bereit und die hole ich mir einfach über HA rein. Im MQTT Explorer kann man übrigens auch den Drop nachvollziehen im entsprechenden Topic. Ich würde mal HA die Daten von der openWB weiter abrufen lassen und hoffe das meine Automation greift, damit ich in der openWB das Log rechtzeitig abgreifen kann.

[LutzB]

Ich hatte die nach dem PR 2621, habe aber jetzt noch mal upgedated auf 2025-07-31 13:01:47 +0200 [4e74cc33d]. Geht leider nicht.
Ich habe die Zeitpäne gelöscht, gepeichert und Neustart gemacht. Anschließend neu angelegt. Gleiches Ergebnis.

Funktioniert hier auf mehreren openWB. Mal den Browswer Cache geleert oder mit einem anderen Gerät drauf zugegriffen?
Was steht in der Browser-Konsole? Bei Klick auf die Pläne wird das aktualisierte Template ins Log geschrieben.