openWB Forum

Ihaglc hat geschrieben: Fr Jul 18, 2025 1:38 pm

LenaK hat geschrieben: Fr Jul 18, 2025 12:31 pm

Ihaglc hat geschrieben: Mi Jul 16, 2025 10:02 am




Habe es heute noch einmal probiert mit der SW 2025-07-14 11:25:39 +0200 [7f16bd75f] meine SH_ Elgris Smartmeter abzurufen.
Leider immer noch gleiches Verhalten, wie zuvor: Es werden keine Werte angezeigt.
Spiele ich ein Backup von Juni 2025 auf, erhalte ich Werte von den beiden Zählern.
Könnt Ihr Euch das bitte noch mal ansehen?
SH_log_16_07_25.txtmain_log_16_07_25.txt

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

Alles neu eingerichtet

lordblobo hat geschrieben: Sa Jul 26, 2025 6:11 pm I aktuellen Master (2.1.8 Alpha 2) war der EVCC-API-Aufruf "broken", ich habe das gefixt und einen Pull Request erstellt:
https://github.com/openWB/core/pull/2598

Details im Pull Request.

EDIT: Es müssen wohl noch die protos für PB2 angepasst und kompiliert werden.

Woran erkennt man eigentlich, wann der Request den Weg in die FR gefunden hat?


Geht es dabei um diesen Fehler?:

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?!

ChristophR hat geschrieben: Mi Jul 16, 2025 12:33 pm Aktueller master (2025-07-15 14:00:06 +0200 [1c775295b]).
Aktualisierung des SoC beim Anstecken.
Ich probiere gerade das neue Cupra SoC Modul aus, bisher habe ich den manuellen SoC genutzt.
Daher habe ich die Aktualisierungseinstellung geändert:

SoC direkt aus Fahrzeug auslesen: Nein
Während der Ladung: 5 min
Ohne laufende Ladung: 90 min
Nur aktualisieren, wenn angesteckt: Nein

Angesteckt habe ich das erste Mal gegen 11:33 Uhr.
Dabei wurde der SoC jedoch nicht aktualisiert (War das früher nicht so, dass beim Anstecken immer einmal aktualisiert wurde?)

Dann habe ich mir gedacht, ich stelle mal die Option um:
SoC direkt aus Fahrzeug auslesen: Ja
Steht zwar nicht in der Hilfe, dass dann auch eine Aktualisierung des SoC-Moduls angestoßen wird, aber einen Versuch ist ja mal wert, da ich keine andere Option gefunden habe.

Angesteckt habe ich dann nochmal gegen 12:35 Uhr.
War aber anscheinend eine blöde Idee, da ich keine Pro habe, wurde der SoC mit 0% übergeben und meine Zwangsladung unter 20% startete:
2025-07-16 14_14_32-openWB und 4 weitere Seiten - Persönlich – Microsoft​ Edge.png
Habe um 12:57 Uhr wieder auf manuellen SoC umgestellt, damit die Ladung wieder beendet wird, das gehört dann also nicht mehr dazu.

Kann das Auslesen eines 0% SoC evtl. in solchen Fällen verhindert werden und nur erfolgen, wenn ein "echter" Fehler auftritt?
Sonst sollte noch eine Warnung in den Hilfetext, damit man nicht so einen Quatsch macht wie ich.

Kann der SoC generell beim Anstecken immer einmal aktualisiert werden, wenn angesteckt wird?

main.log:
https://paste.openwb.de/upux7oWzBB6BZQ0
https://paste.openwb.de/sOn8IBcGgdvyVtt

soc.log:
https://paste.openwb.de/ueEPxUZKvVVI6M0

Hast Du ein externes System, dass Werte für den manuellen SoC published? Hast Du das abgeschaltet?
Welches Theme hast Du verwendet? force_soc_update wurde im Koala gefixt.
Die Pro setzt None, wenn kein SoC aus dem Fahrzeug ausgelesen wird. Dann wird das ausgewählte Modul verwendet.

Aktueller Master von heute:

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.

mattberlin hat geschrieben: Fr Jul 18, 2025 5:38 pm Bei der Phasen Umschaltung passt immer noch was nicht :
Grundloser Ladestation mit 3 Phasen

Screenshot_20250718_193410_Opera.jpg

https://paste.openwb.de/tbhwJVU16ibMhgc

Ist behoben.

In der aktuellen Master-Version bekomme ich gar keine Werte mehr vom Kostal Plenticore-Zähler. In der Version vom 22.7. war alles noch gut.
Vermutlich hat es was mit diesem PR zu tun:
2025-07-23 10:40:17 +0200 [31c95a81e] - Merge pull request #2588 from ndrsnhs/fix-Kostal-Plenticore

Im Status vom Zähler steht das hier:
Modulmeldung: <class 'Exception'> ("modules.common.modbus <class 'Exception'> modules.common.modbus Exception Response(131, 3, IllegalAddress)",)

therobbot hat geschrieben: Mi Jul 30, 2025 10:30 am In der aktuellen Master-Version bekomme ich gar keine Werte mehr vom Kostal Plenticore-Zähler. In der Version vom 22.7. war alles noch gut.
Vermutlich hat es was mit diesem PR zu tun:
2025-07-23 10:40:17 +0200 [31c95a81e] - Merge pull request #2588 from ndrsnhs/fix-Kostal-Plenticore

Im Status vom Zähler steht das hier:
Modulmeldung: <class 'Exception'> ("modules.common.modbus <class 'Exception'> modules.common.modbus Exception Response(131, 3, IllegalAddress)",)

Dort wurde aber nur was am Inverter also dem WR geändert und nichts am Counter. Das Modbusregister 1066 für die PV Leistung wurde hinzugefügt. Ein Log ist aber immer mehr aussagekräftig als nur eine Statusmeldung

seaspotter hat geschrieben: Mi Jul 30, 2025 10:42 am

therobbot hat geschrieben: Mi Jul 30, 2025 10:30 am In der aktuellen Master-Version bekomme ich gar keine Werte mehr vom Kostal Plenticore-Zähler. In der Version vom 22.7. war alles noch gut.
Vermutlich hat es was mit diesem PR zu tun:
2025-07-23 10:40:17 +0200 [31c95a81e] - Merge pull request #2588 from ndrsnhs/fix-Kostal-Plenticore

Im Status vom Zähler steht das hier:
Modulmeldung: <class 'Exception'> ("modules.common.modbus <class 'Exception'> modules.common.modbus Exception Response(131, 3, IllegalAddress)",)

Dort wurde aber nur was am Inverter also dem WR geändert und nichts am Counter. Das Modbusregister 1066 für die PV Leistung wurde hinzugefügt. Ein Log ist aber immer mehr aussagekräftig als nur eine Statusmeldung

Ich kann nur einen Log von meinem Testsystem (Rasbpi) liefern, wo kein Ladepunkt eingerichtet ist. Das Verhalten war beim Produktivsystem aber dasselbe:

MQTT-Log: https://paste.openwb.de/gMhCD8asO35Fs3T
Main-Log: https://paste.openwb.de/IMlFkJhMCEOMsZr

Ich habe mir den PR nicht näher angeschaut, aber es war das einzige, was in der letzten Woche am Kostal Modul geändert wurde.