Rückmeldungen 2.1.9 Alpha 2/3

[miradarya]

Für das neue Home Assistant SoC-Modul hätte ich noch einen Wunsch: Könnt ihr das noch so erweitern, dass man optional vor dem SoC-Abruf noch einen Service (per POST an /api/services/...) triggern kann? Darüber könnte man z.B. bei der Hyundai/Kia Integration die force_update Aktion ausführen, damit aktuelle Daten vom Auto angefordert werden. Ansonsten werden ggf. veraltete, gecachete Daten geliefert. Bei der Stellantis/PSA Integration ist es ähnlich, wahrscheinlich bei anderen Herstellern ebenfalls. Der Timeout für die Antwort des POST-Requests muss vermutlich ziemlich groß sein, da es z.B. bei Stellantis oft im Bereich einer halben Minute dauert, bis das Auto aufwacht (oder der Server reagiert). Ggf. könnte man das Timeout auch konfigurierbar machen?

[Frank-H]

Fehlerbild fehlender/verspäteter Logeintrag besteht weiterhin

Aktueller Master: beim Abstecken nach Ladung gestern nachmittag erfolgt weiterhin kein Logeintrag, sondern die Lademenge und Kilometer bleiben weiterhin in der Ladepunktansicht (s. vorherige Fehlermeldung). Auch Wechsel des Lademodus brachte keine Änderung.

Nach testweisem Anstecken heute morgen, kurzer Sofortladung und wieder Abstecken wurde die gesamte Ladung ins Log übernommen.

Vor dem Anstecken heute morgen hatte ich auf Details umgeschaltet (7:45 Uhr): https://paste.openwb.de/fTdjqsSZPK6Wc8L

[Tidur]

Für das neue Home Assistant SoC-Modul hätte ich noch einen Wunsch: Könnt ihr das noch so erweitern, dass man optional vor dem SoC-Abruf noch einen Service (per POST an /api/services/...) triggern kann? Darüber könnte man z.B. bei der Hyundai/Kia Integration die force_update Aktion ausführen, damit aktuelle Daten vom Auto angefordert werden. Ansonsten werden ggf. veraltete, gecachete Daten geliefert. Bei der Stellantis/PSA Integration ist es ähnlich, wahrscheinlich bei anderen Herstellern ebenfalls. Der Timeout für die Antwort des POST-Requests muss vermutlich ziemlich groß sein, da es z.B. bei Stellantis oft im Bereich einer halben Minute dauert, bis das Auto aufwacht (oder der Server reagiert). Ggf. könnte man das Timeout auch konfigurierbar machen?

Tendenziell möglich. Wird an "/api/services/..." dann ebenfalls die Entitäts-ID angehangen oder etwas Anderes?
Wird etwas beim Post request übergeben, was genau? Ist das dann abhängig von der Integration (sollte also ebenfalls variabel sein)?

[miradarya]

Für das neue Home Assistant SoC-Modul hätte ich noch einen Wunsch: Könnt ihr das noch so erweitern, dass man optional vor dem SoC-Abruf noch einen Service (per POST an /api/services/...) triggern kann? Darüber könnte man z.B. bei der Hyundai/Kia Integration die force_update Aktion ausführen, damit aktuelle Daten vom Auto angefordert werden. Ansonsten werden ggf. veraltete, gecachete Daten geliefert. Bei der Stellantis/PSA Integration ist es ähnlich, wahrscheinlich bei anderen Herstellern ebenfalls. Der Timeout für die Antwort des POST-Requests muss vermutlich ziemlich groß sein, da es z.B. bei Stellantis oft im Bereich einer halben Minute dauert, bis das Auto aufwacht (oder der Server reagiert). Ggf. könnte man das Timeout auch konfigurierbar machen?

Tendenziell möglich. Wird an "/api/services/..." dann ebenfalls die Entitäts-ID angehangen oder etwas Anderes?
Wird etwas beim Post request übergeben, was genau? Ist das dann abhängig von der Integration (sollte also ebenfalls variabel sein)?

Die komplette URL ist /api/services/<domain>/<service>. Der Teil <domain>/<service> sollte konfigurierbar sein. Bei der Kia Integration wäre die URL z.B. /api/services/kia_uvo/force_update. Optional unterstützt die REST API in den Daten ein JSON-Objekt, das dem Service dann als service_data übergeben wird. Ich würde vermuten, dass keine Auto-Hersteller-Integration das für diesen Zweck benötigt. Bei Kia und Stellantis ist es nicht erforderlich.

[LenaK]

Nachtrag/Ergänzung s. unten

Master Alpha 3 vom 29.10.25, 15:24:

Nach Ladung heute nacht erfolgten keine Eintragungen im Ladelog, weder nach Ende der Ladung noch nach Wechsel des Lademodus noch nach Abstecken des Fahrzeugs. Auch in der herunterladbaren CSV-Datei ist kein Eintrag vorhanden. Im Fenster bleiben die Ladedetails erhalten und werden nicht zurückgesetzt.

Mainlog: https://paste.openwb.de/k48eVOow8MRqHnN

Screenshot 2025-10-30 095338.jpg

Bitte nochmal testen, ob es nun funktioniert. Bei mir konnte ich es nicht nachtsellen. Kannst Du dabei bitte das Loglevel auf Details stellen und auch einen längeren Auszug von http://<IP>/openWB/ramdisk/chargelog.log posten, fall es erneut auftritt?

[LenaK]

Noch eine Ergänzung:

trotz Einstellung "volle Entladesperre" wurde der Speicher während der Fahrzeugladung anscheinend mit Hausverbrauch entladen. Vor einigen Versione hat dies noch wie gewünscht funktioniert (Mainlog s.o.).

Screenshot 2025-10-30 100452.jpg

Da bräuchte ich auch ein main.log mit Details-Level, um zu sehen, wo die Regelung nicht passt

[Ihaglc]

....
Das betifft anscheinend nur SDM 120/630 an PE11 oder EE11
Die Shellys gehen .

Ist behoben, bitte ein Update machen.

Kann ich nicht bestätigen:
2025-10-30 08:57:27 +0100 [ccb0086ca] aktuelle Masterversion

Leider erhalte ich bei den Smarthomegeräten mit Elgris Zählern ( kompatibel zu SDM 630 mit Port 502 ) keine Werte mehr.
Zähler wurde nach Update aus der Konfig genommen und als "kein Zähler" eingefügt.
In der Auswahl der Zähler sind die SDM630/Elgris jetzt auch nicht mehr sichtbar/anwählbar
Bitte wieder einfügen.

https://paste.openwb.de/ukkAwtRS3WezWOQ

Mit der aktuellen Masterv. 2025-10-31 11:08:11 +0100 [46d37dfec] zeigen die Elgris Zähler wieder Werte an.
Vielen Dank, Lena

[E_Esteban]

Hi, hat noch jemand das Problem, dass die RS485 Kommunikation zum internen LP ausfällt mit dem Update auf Alpha 3?

Ich habe es mittlerweile bei zwei unterscheidlichen Anlagenstandorten reproduzieren können:

Hier mit 3x openWB customs unterschiedlicher Anschaffungsjahre.

Seit eben lt. Kundenrückmeldung auch bei einer Anlage mit 3x openWB Duo unterschiedlicher Anschaffungsjahre. (Kunde wollte unbedingt auf master-Zweig - seit dem telefonieren wir recht viel

Nach Downgrade auf Alpha 2 sind die Zähler sofort wieder "da" und Ladepunktfehler weg.

Bei meinen Boxen konnte ich lediglich den "neueren" RS485 Konverter identifizieren >> und in der Box keine Probleme.

In den älteren Boxen mit der "Platinenversion des RS485 Konverters" fällt mit dem Update die Kommunikation sofort aus. Mit dem einspielen des Downgrades auf Alpha2 sofort wieder behoben.

Der "leider übliche und denkbare Ausfall des SDM72" scheint es auch nicht zu sein. Alle Phasen und Frequenzanzeigen stabil und i.O. Und nachdem Downgrade wieder i.O. Somit würde ich die Zähler auch aus dem Fokus der Betrachtung rausnehmen.

Beim Kunden laufen die neueren der drei Boxen auch mit der Alpha3 problemlos. Lediglich die ältere Box im Verbund (wobei "alt" ~BJ2022 bedeutet) zeigt das Fehlerbild bei Installation der Alpha3.

Bei downgrade auf Alpha2 sofort wieder stabiler und problemloser Betrieb!

Bin mit genannten Fehlerbild auch schon mit dem Support in Kontakt. Wir waren bis vor gut 60min auch der Meinung, dass es eher unwahrscheinlich ist, dass der Fehler in der Software zu suchen ist. Bei mir war der Fehler reproduzierbar mit dem Wechsel zwischen Alpha2 und 3 abzubilden.

Nachdem der Kunde mir heute das gleiche Problem servierte bin ich nun recht sicher.

Aber kann ja nicht sein, dass es keinem anderen auffällt?? Daher hier meine Nachfrage in die Community der master-Zweig User.

Oder sind Eure Boxen alle so "neu" (< 2 Jahre mit den neuen Konvertern? - insofern diese ursächlich sind)

VG St.

[Hefer]

Bei mir ist auch bei der Masterbox nach Update auf die Alpha3 das Problem das der Zähler nicht ausgelesen werden kann. Ein Downgrade auf Alpha2 und der Fehler ist weg.

mfg
Hefer

[E_Esteban]

welcher rs485 Adapter in der Box ? Ne welcher Zähler ?

Besten Gruss