Rückmeldungen 2.1.7 Release & Release Patch 1/2/3/4/5

[LutzB]

Ich hatte auch die Schwierigkeit dass ich keinen eigenen NTP-Server setzen konnte. Die Standard-Konfig dafür von meinem DHCP Server (Kea) wollte die OpenWB nicht nehmen (2.1.7-Patch.4).

Wenn jemand manuelle DHCP Einstellungen kennt die funktionieren (042 oder 004 oder ...), bitte Bescheid geben

Ich nutze hier zwar noch den isc-dhcp auf meiner opnsense, aber das funktioniert einwandfrei mit den Standardeinstellungen des Servers. Einfach unter "NTP" die IP des Gateways eintragen und der Raspi übernimmt den per DHCP. Sollte beim Kea auch so sein. Ansonsten mal auf einem anderen Linux System das erhaltene DHCP Lease anzeigen lassen.

Code: Alles auswählen

sudo dhcpcd -U eth0

Als Workaround habe ich ein NAT bzw. Redirection (Firewall) eingestellt, die alle NTP Verbindungen auf den eigenen NTP Server umlenkt, das funktioniert.

Ist auch eine Möglichkeit und sollte generell so gemacht werden, um auch andere Geräte einfangen zu können.

Wenn ich das richtig gesehen hatte, ist die Systemzeit am physikalischen Display einsehbar, aber nicht an der Weboberfläche. Oder hatte ich die vielleicht doch irgendwo übersehen? In den Debug Logs sieht man sie jedenfalls. Falls sie noch ganz präsent in die Weboberfläche kommen könnte (unter System Information beispielsweise), wäre das toll.

Die Systemzeit wird nur im Regelzyklus an das Frontend übertragen und kann daher je nach Einstellung schon mal 10-60 Sekunden daneben liegen, daher ist das nicht implementiert. Das Display nutzt die Zeit des Clients, der hier natürlich identisch zum System ist. Daher gibt es dort das Problem nicht.

Wenn in einem zukünftigen Release die Weboberfläche noch die Authentisierungs-Funktionalität bekommt und ein optionales Umschalten auf HTTPS (gerne mit eigenen Zertifikaten, ggf. CertBot), wäre das auch noch absolut Sahne.

HTTPs ist aktuell schon aktiviert, wenn auch mit selbstsignierten Zertifikaten. Es erfolgt jedoch keine Weiterleitung von HTTP nach HTTPs. Absicherung mit Kennwort steht auch schon länger auf der ToDo-Liste. Mangels Kapazitäten ist das noch nicht angegangen worden. Die einfache HTTP-Basic-Auth Variante von 1.9 wird es zumindest so nicht mehr geben, da sich zu viele Anwender ausgesperrt haben und dann der Support eingreifen musste. Falls jemand ein schlüssiges Konzept zu einer Benutzeranmeldung inkl. Rücksetzfunktion dazu erstellen kann, wäre uns sehr geholfen.

[Chargee]

Hi Gero, Lutz,

danke für eure Antworten.

Das Display per Web anzuschauen ist pfiffig, danke für den Tip.

Das NTP Problem ist wohl ein DHCP Problem und kann ich behalten. Im Sniff hat sich gezeigt, dass zwar in anderen Netzen (bei gleichen Einstellungen) der NTP Server als Option 42 mitkommt. Bei dem DHCP Offer an die OpenWB ist die Option 42 dann aber nicht mit dabei gewesen. Ich hab probeweise (an der Firewall, wo der Kea läuft) die NTP-Definition nochmal auf den Scope des statischen Leases für die OpenWb gehangen. Das hat leider nichts geändert. Woran das jetzt genau liegt erschliesst sich mir nicht. Theoretisch könnte der Raspi anders anfragen, oder ich hab einen Schluckauf in meiner DHCP Konfig. Genug Zeit investiert für heute und eins klüger als vorher.

Danke für den Tipp das HTTPS schon da ist, wunderbar. Das hätte ich auch probieren können. Self-Signed ist ok, dann ists schonmal verschlüsselt.

Eine Absicherung mit Kennwort, kein leichtes Thema. Ich bin da eher Traditionalist. Mit der althergebrachten Herangehensweise (pw reset = neuinstallation) ärgern sich die Kunden. Mit einer gewissen User Convenience ists dann halt wiederum nicht so sicher. Den physikalische PW-Reset (SD-Karte ziehen, .passwd neu schreiben und wieder stecken) finde ich recht bequem, das spart einem Neuinstallation und Supportcall. PW-Reset per Supportcall ist schon ein echtes Convenience Feature.
Und ich drücke die Daumen - ist sicherlich nicht ohne das zu implementieren.

[Finders]

Hallo zusammen,

seit dem Update auf openWB Version 2.1.7-Patch.4 funktioniert bei mir der parallele Zugriff per Modbus TCP auf meinen SMA Sunny Tripower Smart Energy 8.0 (SE 8.0) nicht mehr.

Vor dem Update konnte ich sowohl mit openWB als auch parallel mit EVCC (laufend auf Home Assistant) auf den Wechselrichter zugreifen – beide Systeme haben regelmäßig Werte per Modbus TCP (Port 502, Unit ID 3) abgefragt.

Seit dem Update bekomme ich in openWB folgende Fehlermeldung:

<class 'pymodbus.exceptions.ConnectionException'> ('Failed to connect[ModbusTcpClient(192.168.xxx.xxx:502)]', 'Modbus-Client konnte keine Verbindung zu 192.168.xxx.xxx:502 aufbauen. Bitte Einstellungen, IP-Adresse und Port sowie Netzwerk-Anschluss prüfen.')

Sobald ich EVCC auf Home Assistant stoppe oder den Zugriff dort deaktiviere, funktioniert openWB wieder ohne Probleme. Sobald EVCC wieder aktiv ist, schlägt die Verbindung in openWB wieder fehl.

**Was ich bereits geprüft habe:**
- IP-Adresse korrekt (192.168.xxx.xxx)
- Modbus TCP am SMA aktiviert
- Unit ID = 3
- Modbus funktioniert einzeln mit beiden Systemen zuverlässig
- Das Verhalten trat exakt seit dem Update auf 2.1.7-Patch.4 auf
- Bei einem anderen SMA WR (STP 20000TL) funktioniert paralleler Zugriff auch nach dem Update weiterhin problemlos

Hat jemand ähnliche Probleme mit parallelem Modbus-Zugriff auf den SMA SE 8.0 seit dem Update?
Gibt es Lösungsansätze oder Workarounds, um openWB und EVCC parallel mit Modbus auf den Wechselrichter zugreifen zu lassen?

Danke im Voraus für eure Unterstützung!

[openWB]

Gibt es Lösungsansätze oder Workarounds, um openWB und EVCC parallel mit Modbus auf den Wechselrichter zugreifen zu lassen?

ModbusTCP ist meist nicht für den parallel Zugriff ausgelegt.
Eine Krücke die meistens aber ganz gut funktioniert ist ein Modbus Proxy.

[Finders]

Danke für die Rückmeldung.

Ich greife zusätzlich auch über die offizielle SMA-Integration in Home Assistant auf den Wechselrichter zu – dort funktioniert der parallele Betrieb mit openWB problemlos, ohne dass es zu Verbindungsabbrüchen kommt. Probleme treten nur dann auf, wenn EVCC über Modbus TCP auf den SMA SE 8.0 zugreift und openWB gleichzeitig aktiv ist. Sobald EVCC startet, verliert openWB die Verbindung.

Interessant ist, dass das Verhalten ausschließlich beim SMA SE 8.0 auftritt.
Mit dem SMA Tripower 20000TL sowie dem SMA SunnyBoy 1.5 funktioniert der parallele Zugriff von openWB und EVCC weiterhin ohne Einschränkungen – auch nach dem Update auf openWB 2.1.7-Patch.4.

Vor dem Update war der parallele Zugriff mit dem SE 8.0 ebenfalls problemlos möglich.
Daher meine Frage: Gab es in Patch 2.1.7-Patch.4 Änderungen am Modbus-Verhalten (z. B. Verbindungshandling, Timeouts, verwendete pymodbus-Version o. ä.), die dieses Verhalten erklären könnten?

Vielen Dank für weitere Hinweise oder Ideen.

[LutzB]

Vor dem Update war der parallele Zugriff mit dem SE 8.0 ebenfalls problemlos möglich.
Daher meine Frage: Gab es in Patch 2.1.7-Patch.4 Änderungen am Modbus-Verhalten (z. B. Verbindungshandling, Timeouts, verwendete pymodbus-Version o. ä.), die dieses Verhalten erklären könnten?

Nein, gab es nicht. https://github.com/openWB/core/commits/Release/

[Finders]

ModbusTCP ist meist nicht für den parallel Zugriff ausgelegt.
Eine Krücke die meistens aber ganz gut funktioniert ist ein Modbus Proxy.

Habe mir einen Proxy gebaut, jetzt laufen beide Anwendungen wieder parallel. Danke für den Support

[LenaK]

Rückmeldung zu Patch 4 (2.1.7-Patch.4)

@LenaK ich finde Deinen Einsatz und Dein Engagement echt klasse, herzlichen Dank dafür!

Ich bin von Master wieder auf diesen Release gewechselt, weil das Runterzählen der Zeitverzögerung für den Phasenwechsel seit dem letzten Update nicht mehr funktioniert hat bzw. nicht mehr zurückgesetzt wurde.
Leider funktioniert es in diesem Patch auch nicht. Unsere ZOE steigt nach 2-4 maligem Phasenwechsel einfach aus und verweigert weiteres Laden.

Der Screenshot zeigt das Laden meines Model S.
Würde das Runterzählen der Zeitverzögerung des Phasenwechsels wieder von Neuem beginnen, wäre das Problem gelöst.

Der Support hat mir bereits beim letzten Update zugesichert, dass diese Funktionalität wieder implementiert wäre. Leider ist dem nicht so bzw. klappt das nicht....

Screenshot_20250720_140941_Chrome.jpg

Das ist in der Alpha umgesetzt, nicht in der Patch-Version.
"Wartezeit Ladestart & Phasenzuschaltung: Wenn die Pufferzeit zwischen zwei automatischen Phasenumschaltungen abgelaufen ist, wird die hier eingestellte Wartezeit abgewartet. Wenn die Pufferzeit zwischen zwei Umschaltungen noch nicht erreicht ist, wird die längere der beiden Zeiten abgewartet: entweder die verbleibende Pufferzeit oder die Wartezeit."
Sonst bitte ein Log einstellen.

[HansR]

IMG_1008.png

(511.82 KiB) Noch nie heruntergeladen

Hallo,

ich habe seit heute (zumindest ist es mir heute erstmalig aufgefallen) das “Problem”, dass laut openWB ein Auto geladen wird obwohl kein Auto angesteckt ist, Lademodus ist Stop und der Ladepunkt ist gesperrt.

Siehe Screenshot.

Reboot von beiden Boxen ist bereits erfolgt, keine Besserung.

Welches Log braucht es zur weiteren Analyse, MainLog oder Log des internen Ladepunktes?

Installierte Version: 2025-07-15 11:42:24 +0200 [563e25db4]

Gruß
Hans

[aiole]

IMG_1008.pngHallo,
ich habe seit heute (zumindest ist es mir heute erstmalig aufgefallen) das “Problem”, dass laut openWB ein Auto geladen wird obwohl kein Auto angesteckt ist, Lademodus ist Stop und der Ladepunkt ist gesperrt.

Siehe Screenshot.

Reboot von beiden Boxen ist bereits erfolgt, keine Besserung.
Welches Log braucht es zur weiteren Analyse, MainLog oder Log des internen Ladepunktes?
Installierte Version: 2025-07-15 11:42:24 +0200 [563e25db4]

Gruß
Hans

Du meinst die 24W bei 0A Sollvorgabe? Das ist sicher keine "echte" Ladung.
Bitte mal in der WB den Zähler prüfen, ob da auch 24W angezeigt werden. Ansonsten an den Support wenden.