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

[KrailPV]

Ergänzung:
Ich habe die OpenWB jetzt mal neu gestartet, und die Regelung funktioniert wieder perfekt, ich kann es mir absolut nicht erklären.

[zut]

Ich habe seit März die 2.1.7-patch 2 auf der Wallbox. Uptime ist knapp 58 Tage.

Bildschirmfoto_20250627_083533.png (130.59 KiB) 945 mal betrachtet

Seit etwa einer Woche habe ich mein Ressourcen-Monitor-Skript wieder am Start und zwar so umgebaut, daß es mir die gefilterte System Load wie auch den verfügbaren Speicher per MQTT verteilt und ich sie in Grafana ansehen kann.

Während der Display-Chromium durch den 48-stündigen periodischen Neustart kein Speicherproblem mehr darstellt, nimmt vermutlich die Haupt-Regelschleife seit 3 Tagen zunehmen mehr Speicher in Anspruch:

Bildschirmfoto_20250627_083622.png (19.72 KiB) 945 mal betrachtet

Code: Alles auswählen

pi@openwb-2:~$ ps 2105
  PID TTY      STAT   TIME COMMAND
 2105 ?        Ssl  15780:31 python3 /var/www/html/openWB/packages/main.py

Falls ich bis heute abend noch etwas untersuchen kann, gebt mir gerne Bescheid - ich werde abends einen Neustart machen, um nicht in Probleme zu laufen.

Mein Skript:

Code: Alles auswählen

[pi@openwb-2:~$ cat wbwatch.py 
#!/usr/bin/env python3

"""
frage periodisch den freien Speicherplatz und die CPU-Last der Wallbox ab und schreibe die Ergebnisse an den lokalen moquitto-broker
"""

import sys
import time
import os
import paho.mqtt.publish as publish

while True:
    stat = os.popen('cat /proc/loadavg').read()
    list = stat.split()
    publish.single('others/wbwatch/load5', list[1])
    time.sleep(1)
    stat = os.popen('free').read()
    list = stat.split()
    publish.single('others/wbwatch/memavail', list[12])
    time.sleep(299)
/code]

[eike.schuster]

Hallo zusammen,

ich habe heute auf Patch 3 aktualisiert.

Auf einmal funktioniert die Auslese des EVU-Kits nicht mehr.
Ich bekomme zwei Fehlermeldungen:

"Modulmeldung: <class 'Exception'> ("modules.common.modbus <class 'Exception'> modules.common.modbus Modbus Error: [Input/Output] [Errno 104] Connection reset by peer",)"

sowie

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

Kann es mir nicht erklären, ich habe die Konfiguration nicht angefasst. Davor funktionierte alles problemlos.

[eike.schuster]

Kurzes Update zum letzten Post: Fehler hängt doch nicht mit Patch 3 zusammen. Habe in den Statistiken gesehen, dass das Problem schon bestand, bevor ich das Update gefahren habe.

[Eckhard]

Wenn ihr nachträglich einen Patch zu einem Release hinzufügt, gebt bitte in der Ankündigung das Datum an!

[blam09]

Rückmeldung zu Patch 4
Auslesen des SoC klappt an meiner Pro noch immer nicht. Es wird statt dem aktuellen SoC (lt. connect.php bspw. 40%) wieder der SoC nach dem vorherigen abstecken des Fahrzeugs (in diesem Fall 80%) angenommen und nicht weiter geladen (weil Ziel-SoC von 80% erreicht sei).

VG
B.L.

[LenaK]

Rückmeldung zu Patch 4
Auslesen des SoC klappt an meiner Pro noch immer nicht. Es wird statt dem aktuellen SoC (lt. connect.php bspw. 40%) wieder der SoC nach dem vorherigen abstecken des Fahrzeugs (in diesem Fall 80%) angenommen und nicht weiter geladen (weil Ziel-SoC von 80% erreicht sei).

VG
B.L.

Das ist in der Alpha behoben und kommt ins nächste Release.

[Kaubacke]

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 (640.24 KiB) 364 mal betrachtet

[Chargee]

Ich hab jetzt auch endlich von 1.9 auf v2 geupdatet. v2 ist toll geworden, herzlichen Dank für die harte Arbeit!

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

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

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.

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. Danke schonmal!

[Gero]

Das physische Display geht auf jedem Browser: http://192.168.8.11/openWB/web/display/