openWB Forum

zut hat geschrieben: Fr Jan 02, 2026 9:39 am Ich hatte mir gemerkt, dass CP Unterbrechung nur für die Phasenumschaltung da ist.

mattberlin hat geschrieben: Fr Jan 02, 2026 3:15 pm 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.

_daniel hat geschrieben: Fr Jan 02, 2026 12:53 pm 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

xwo hat geschrieben: Di Jan 06, 2026 7:36 am 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.

ChristophR hat geschrieben: Do Jan 01, 2026 6:33 pm 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?

miradarya hat geschrieben: Do Jan 01, 2026 12:55 pm

miradarya hat geschrieben: Do Jan 01, 2026 12:34 pm 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.