Rückmeldungen 2.1.9 Beta 1/2/3

[ChristophR]

Aktueller Master (2025-12-22 08:24:28 +0000 [86a39069c]), Unstimmigkeiten der io-Geräte:
Ich hatte in meinem Testsystem früher mal mein Dimm&Controlkit eingebunden, ist aber schon seit längerem wieder gelöscht.
Im MQTT-Baum sind aber noch alte Einträge der Ein- und Ausgänge vorhanden:
openWB/io/states/0/get/digital_input
openWB/io/states/0/get/analog_input
openWB/io/states/0/set/digital_output
Auch wenn ich es mir nochmal hinzufüge (Natürlich mit der richtigen ID) und danach wieder lösche, bleiben die Einträge bestehen.

Nun habe ich mir testweise mal eine EEBUS Steuerbox angelegt (obwohl ich natürlich keine habe) und dabei folgendes festgestellt:
1. Obwohl die Verbindung fehlerhaft ist, ist die Dimmung Inaktiv, ich hätte erwartet, dass sie wegen Failsafe Aktiv sein müsste.
2. Im Status werden mir die o.g. Eingänge des alten Dimm&Controlkits angezeigt.

2026-01-05 01_02_15-Clipboard.png (34.37 KiB) 469 mal betrachtet

https://paste.openwb.de/cRATlWB7A0Epmw4

[Gero]

Ich hatte mir gemerkt, dass CP Unterbrechung nur für die Phasenumschaltung da ist.

CP-Unterbrechung ist manchmal hilfreich, wenn das eingeschlafene Auto nicht mitbekommt, wenn „Strom anliegt“. Technisch gesprochen wird damit eher die (deaktivierte) überwachung des PWM-Signals des maximalen Ladestroms gemeint sein. Durch trennen und wiederanlegen von CP wird die Interpretation des PWM-Signals bei manchen Autos wieder angeregt. Es ist aber ein und das selbe Kabel, über das wir hier reden.

[Daphne]

Hallo,
wie lautet die Adresszeile im Browser bei Ansicht meines Ladepunktes in der Garage?

Die Adresse von Koala, Standard habe ich.

Vorab vielen Dank.

[Tuffi]

Du meinst die Ansicht die du im Display der openWB hast?
Das wäre:
http://192.168.x.y/openWB/web/display/

[LenaK]

Ich habe festgestellt, dass das Sofort-Laden zunächst in 1p beginnt und dann erst auf 3p umschaltet:
image_2026-01-02_161320666.png
https://paste.openwb.de/TRrDCRnOD3sVteR

- Die openWB stand auf PV (mit unzureichend Überschuss)
- dann wurde das Auto angesteckt
- dann wurde auf Sofort-Laden umgestellt, welches in 1p begann

--> Es wäre sinnvoll in solchen Situationen, gleich in 3p loszuladen.

Ja, das soll auch so sein. Bei series2 kann der Zustand der Schütze nicht ausgelesen werden und die openWB hatte sich als letzten Zustand 3phasig gemerkt und dann nicht umgeschaltet. Das Auto hat dann aber einphasig geladen, deshalb wurde dann nochmal umgeschaltet.

[xwo]

Ich wollte gerade den leicht angepassten Strompreis meines Energieversorgers eintragen. Leider kann ich in der Version nur noch ganze Zahlen eintragen. Sobald ich ein Komma eintippe, wird das Feld auf 0 gesetzt. Die alten Werte mit Komma werden aber korrekt dargestellt. Das ist etwas ungünstig für das Ladeprotokoll jetzt.

Es geht um die drei Felder unter „Ladeeinstellungen->Übergreifendes“.
Edit: wenn ich ein Modul für dynamische Strompreise auswähle, zB $14a, besteht dort das gleiche Problem.

[Tidur]

Rückmeldung zum neuen Modul Marstek Speicher.
1x Venus E (Hw 2.0, Sw V153): nur Wifi - keine native Kommunikation über das owb Modul.
2x Venus E (Hw 3.0, Sw V144): owb kommuniziert erfolgreich mit der LAN Schnittstelle. Verfügbare Werte sind Leistung und SoC.

Modbus scheint bei Venus E nur über LAN möglich. Damit geht nur die neue Hardware-Version V3 des Venus E.
Die alte Hw hat eine lokale API oder RS-485 dafür gibt es HA Integration (mittels TCP Adapter) oder Venus Monitor auf github

Gen2 mittels TCP Adapter sollte eigentlich auch mit dem aktuellen Modul funktionieren, jedenfalls wurde das auf einem Kundensystem (damals mit Protoss) getestet.
Gerne auch ein Support Ticket eröffnen, dann können wir auch alternative Auslesemöglichkeiten direkt an der Hardware testen.

[LutzB]

Ich wollte gerade den leicht angepassten Strompreis meines Energieversorgers eintragen. Leider kann ich in der Version nur noch ganze Zahlen eintragen. Sobald ich ein Komma eintippe, wird das Feld auf 0 gesetzt. Die alten Werte mit Komma werden aber korrekt dargestellt. Das ist etwas ungünstig für das Ladeprotokoll jetzt.

Es geht um die drei Felder unter „Ladeeinstellungen->Übergreifendes“.
Edit: wenn ich ein Modul für dynamische Strompreise auswähle, zB $14a, besteht dort das gleiche Problem.

Bitte sicherstellen, dass Du auch ein Komma und keinen Punkt eintippst. Die Eingabe wird anhand der lokalen Einstellungen für Zahlenformate validiert.

[openWB]

Falscher Wert in der SimpleAPI (2025-12-22 08:24:28 +0000 [86a39069c]):

Ich habe 2 Wechselrichter in der openWB eingerichtet und gerade ist damit eine Unstimmigkeit in der SimpleAPI aufgefallen.

Ich habe folgende Werte:
openWB/simpleAPI/pv/2/get/daily_exported: 916.0
openWB/simpleAPI/pv/3/get/daily_exported: 50.0

openWB/simpleAPI/pv/get/daily_exported wechselt ständig zwischen 916 und 966 hin und her.
Soll an der Stelle der Summenwert wie unter "openWB/pv/get/daily_exported" oder der "ich kann auch keine ID angeben"-Wert aus pv/2 ausgegeben werden?

Ansich der keine ID Wert.
Das skaliert natürlich nur wenn es nur eine PV gibt.
Mit Angabe der ID ists korrekt?

[LenaK]

Die in 2.1.9 geänderte Abfrage-Strategie für dynamische Tarife funktioniert nicht gut, jedenfalls nicht mit ostrom. Ich teste aktuell die Beta 3. Hier scheint es so zu sein, dass die Strompreise nur noch einmal täglich um 14 Uhr abgefragt werden statt wie bisher stündlich. Zu dem Zeitpunkt liefert ostrom aber Daten bis bestenfalls 13 Uhr (Zeitfenster 12-13 Uhr) am nächsten Tag. Weitere Daten werden dann ab variierenden Zeitpunkten zur Verfügung gestellt, die die openWB aber mit der derzeitigen Strategie nicht abruft. Das führt dazu, dass vormittags bis mittags suboptimale Entscheidungen für das Zielladen getroffen werden, weil nicht alle verfügbaren Preisinformationen genutzt werden. Heute wurde sogar ab 12 Uhr das Zielladen gestoppt, weil die openWB nur noch den letzten Preisschritt von 12-13 Uhr hatte, und damit offenbar nicht entscheiden konnte, ob nun noch ein günstiger Zeitpunkt zum Laden war. Der Hinweistext meldete, dass nicht geladen wird, weil jetzt kein günstiger Zeitpunkt zum Laden sei. Das Preis-Diagramm zeigte nur noch eine konstante Linie von 12-13 Uhr. Das Strompreis-Modul stand nicht im Fehler-Zustand, der letzte Abruf war von gestern. Da gab es aber längst weiter in die Zukunft reichende Preise von ostrom. Ich habe dann in den übergreifenden Ladeeinstellungen einmal auf Speichern gedrückt, was einen neuen Preisabruf triggert. Dann hat die Box sofort weiter geladen, weil natürlich bei dem Wind immer noch ein günstiger Strompreis herrscht.

Aus meiner Sicht sollten spätestens dann stündlich/viertelstündlich neue Strompreise abgerufen werden, wenn die verbleibende Preisliste kürzer als eine bestimmte Anzahl an Stunden (z.B. 6) geworden ist.

Im Log steht leider nichts Hilfreiches drin, weil es auf Warnungen und Fehler stand - und es gab ja keinen Fehler.

Ist das hier in et_price_update_required in der optional.py richtig?

Code: Alles auswählen

        if is_tomorrow(get_last_entry_time_stamp()):
            if timecheck.create_timestamp() > self.data.electricity_pricing.get.next_query_time:
                ...

Die beiden verschachtelten Bedingungen können doch nie gleichzeitig erfüllt sein, oder verstehe ich das falsch? Wenn die next_query_time überschritten wurde, ist doch der letzte Zeitstempel in der Liste nie morgen? Umgekehrt, wenn der letzte Zeitstempel (noch) morgen ist, ist sehr wahrscheinlich die next_query_time noch nicht überschritten.

Das erklärt bzw. löst aber nicht das oben beschriebene grundsätzliche Problem.

Im Master werden die Preise nun alle 6 Stunden abgerufen.