Colors-Theme 2.0

[Meth]

Auffällig ist, dass die Simcount-Warnungen im Kontext der Speicher-Komponenten angezeigt werden, bei denen die falschen Tageswerte angezeigt werden:

Code: Alles auswählen

2025-11-29 00:40:18,244 - {modules.common.component_context:29} - {DEBUG:device0} - Update Komponente [' Kostal Plenticore 5.5 Garage']
2025-11-29 00:40:18,250 - {modules.common.simcount._simcount:42} - {DEBUG:device0} - Previous state: SimCounterState(timestamp=1764373191.5644138, power=0, imported=0.03649567034500018, exported=23927752.360001095)
2025-11-29 00:40:18,253 - {modules.common.simcount._simcount:51} - {WARNING:device0} - Time difference between previous state and current state is too large. Set time difference to control interval.

Was auch noch auffällt, sind diese Einträge im Log:

Code: Alles auswählen

BatData(get=Get(currents=[0.0, 0.0, 0.0], soc=4, daily_exported=95.0, daily_imported=7.0, imported=6232920.5, exported=5666650.5, fault_state=0, fault_str='Kein Fehler.', power=0, power_limit_controllable=True), set=Set(power_limit=None))
2025-11-29 00:41:06,971 - {control.data:295} - {INFO:MainThread} - bat9
BatData(get=Get(currents=[0.0, 0.0, 0.0], soc=5, daily_exported=45.0, daily_imported=3.0, imported=7307102, exported=6579255, fault_state=0, fault_str='Kein Fehler.', power=0, power_limit_controllable=True), set=Set(power_limit=None))
2025-11-29 00:41:06,974 - {control.data:295} - {INFO:MainThread} - bat10
BatData(get=Get(currents=[0, 0, 0], soc=12, daily_exported=0.0, daily_imported=1639.0, imported=1761508.12, exported=1492437.25, fault_state=0, fault_str='Kein Fehler.', power=0, power_limit_controllable=True), set=Set(power_limit=None))
2025-11-29 00:41:06,978 - {control.data:295} - {INFO:MainThread} - bat11
BatData(get=Get(currents=[0, 0, 0], soc=4, daily_exported=0.0, daily_imported=0.0, imported=1896950.38, exported=1567041.75, fault_state=0, fault_str='Kein Fehler.', power=0, power_limit_controllable=True), set=Set(power_limit=None))
2025-11-29 00:41:06,981 - {control.data:295} - {INFO:MainThread} - bat7
BatData(get=Get(currents=[0.0, 0.0, 0.0], soc=4, daily_exported=0.0, daily_imported=0.0, imported=15012808.5, exported=13591442, fault_state=0, fault_str='Kein Fehler.', power=0, power_limit_controllable=True), set=Set(power_limit=None))
2025-11-29 00:41:06,985 - {control.data:262} - {INFO:MainThread} - bat_all_data

Da stehen auch jeweils die falschen daily_imported Werte drin.

Ich kenne mich da leider zu wenig aus. Vielleicht liest ja hier jemand mit, der die Simcount-Komponente kennt. Sonst müsstest Du vielleicht mal in einem anderen Thread posten (z.B. der zum aktuellen Master).

Hallo

Anbei mal das log
https://paste.openwb.de/ZqZTEOd9nBsoqdh
Das stehen viele Einträge mit simcount und so weiter.
Ich nuss ehrlich sagen ich habe da keine Ahnung

Danke !
Werde ich mal machen

[Thomas aus W]

Sorry für die späte Antwort.

Hm, das sieht in der Tat seltsam aus. Wobei mir noch nicht klar ist, warum dieser Effekt auftritt.

In erster Linie, weil ich neben dem SH-gerät noch einen OWB-Zähler eingerichtet habe, der den selben Hardware-Zähler ab fragt und auch nicht in den Hausverbrauch eingerechnet wird. Das ist ein Workarout um den Verbrauch der WP in der Standard-Ansicht angezeigt zu bekommen.
Daher ja auch mein Wunsch, dass Du nach Zählern suchst, die den selben Namen wie das SH-Gerät haben und die Du dann passend verrechnest.

Bildschirmfoto_2025-11-29_12-05-40.png (51.75 KiB) 526 mal betrachtet

Bildschirmfoto_2025-11-29_12-16-46.png (30.94 KiB) 526 mal betrachtet

Bildschirmfoto_2025-11-29_12-22-05.png (20.89 KiB) 526 mal betrachtet

Code: Alles auswählen

[{"id": 2, "type": "counter", "children": [{"id": 12, "type": "inverter", "children": [{"id": 13, "type": "bat", "children": []}]}, {"id": 10, "type": "counter", "children": []}, {"id": 11, "type": "counter", "children": [{"id": 5, "type": "cp", "children": []}, {"id": 6, "type": "cp", "children": []}]}]}]

Das sieht fast so aus, als würde die WP zweimal vom Hausverbrauch abgezogen und damit einen negativen Hausverbrauch erzeugen. In den Daten von der openwb sieht aber alles ok aus. Könntest Du den Debug-Modus aktivieren und in der Console die Daten kopieren, die an den Graphen gehen (die ersten 7-8 Elemente sollten reichen):.

Die Stelle, Die Du möchtest finde ich im MQTT-Viewer irgendwie nicht, daher hier der Log-Eintrag:

Bildschirmfoto_2025-11-29_12-23-33.png (5.68 KiB) 526 mal betrachtet

https://paste.openwb.de/raWBUspPemrBXtu

und noch mal die aktuellen Ansicht:

Bildschirmfoto_2025-11-29_12-05-40.png (59.07 KiB) 526 mal betrachtet

bye
TW

[Extrahirn]

Hi,

Ich verwende den manuellen SOC.

Bei der Eingabe des SOC habe ich zwei Probleme:

- bei der Eingabe „schlägt“ anscheinend alle paar Sekunden ein Timer zu und
Sorgt dafür, dass die Eingabe wieder mit den vorherigen Werten überschrieben wird,
Weil ich nicht schnell genug war und die Eingbe über „Ok“ abgespeichert habe…
Kann man den manuellen SOC während der Eingabe von der Aktualisierung ausnehmen ?

- Ich muss den neuen SOC Wert immer zwei Mal eingeben. Wenn ich nach der ersten Werteingabe den OK-Button drücke und
dann Die Browseranzeige aktualisiere, steht wieder der vorherige Wert drin.
Nach dem zweiten Mal werden die Eingaben übernommen.

OpenWB Version Release 2.1.8-Patch.4, Safari-Browser auf dem iPad

[electron]

Danke für den Hinweis. Ich schaue mal, wie ich das beheben kann.

Hi,

Ich verwende den manuellen SOC.

Bei der Eingabe des SOC habe ich zwei Probleme:

- bei der Eingabe „schlägt“ anscheinend alle paar Sekunden ein Timer zu und
Sorgt dafür, dass die Eingabe wieder mit den vorherigen Werten überschrieben wird,
Weil ich nicht schnell genug war und die Eingbe über „Ok“ abgespeichert habe…
Kann man den manuellen SOC während der Eingabe von der Aktualisierung ausnehmen ?

- Ich muss den neuen SOC Wert immer zwei Mal eingeben. Wenn ich nach der ersten Werteingabe den OK-Button drücke und
dann Die Browseranzeige aktualisiere, steht wieder der vorherige Wert drin.
Nach dem zweiten Mal werden die Eingaben übernommen.

OpenWB Version Release 2.1.8-Patch.4, Safari-Browser auf dem iPad

[Philip]

Das ist super, @electron. Ich habe dieses Problem der "frickeligen" Eingabe auch - selbst am Display der openWB...

[phelix]

Ich weiß nicht, ob es schon irgendwo angesprochen wurde oder gar in einer nightly-Version gefixt wurde: Mir ist heute aufgefallen, dass in der Monatsanzeige
- die letzten Tage keine Datumszahl (28 / 29 / 30 / 31, je nach länge des Monats) aufweisen.
- der letzte Tag des Monats fehlt und ggf. mit dem Tag davor verrechnet wird. Die Balken sind am vorletzten Tag immer deutlich höher, als der Rest.

_bug_letzter_Tag_im_Monat.PNG (64.22 KiB) 197 mal betrachtet

Betrifft die 2.1.8-Patch.4
Schönen Gruß!

[electron]

Ja, das ist in den aktuellen Nightly-Versionen gefixt.

Ich weiß nicht, ob es schon irgendwo angesprochen wurde oder gar in einer nightly-Version gefixt wurde: Mir ist heute aufgefallen, dass in der Monatsanzeige
- die letzten Tage keine Datumszahl (28 / 29 / 30 / 31, je nach länge des Monats) aufweisen.
- der letzte Tag des Monats fehlt und ggf. mit dem Tag davor verrechnet wird. Die Balken sind am vorletzten Tag immer deutlich höher, als der Rest.

_bug_letzter_Tag_im_Monat.PNG

Betrifft die 2.1.8-Patch.4
Schönen Gruß!

[Philip]

Das ist super, @electron. Ich habe dieses Problem der "frickeligen" Eingabe auch - selbst am Display der openWB...

@electron: Wenn ich dazu noch einen Wunsch äußern darf: Wenn man am Display nicht nur den aktuellen SoC des Autos eingeben könnte, sondern auch den einmaligen Ziel-Ladestand, wäre das ein Träumchen!

Anwendungsfall: Ich habe im Winter Zielladen i.d.R. auf 60% SoC gestellt, weil wir den meistens benötigen, wenn wir laden. Wenn der Strompreis günstig ist, lade ich aber auch gerne mal auf 90%. Um diese Einstellung zu ändern, muss ich dann tief ins openWB-Menü einsteigen. Und wenn ich's dort ändere, ist die Einstellung dauerhaft geändert, nicht nur für den einen Ladevorgang (ich muss es also wieder zurückstellen...).

Danke sehr!
Gruß
Philip