Feedback Alpha 4

[mrinas]

Hallo zusammen,

ja, ich weiß, dass dies ist kein support Channel für Linux ist. Wollte trotzdem das Feedback geben

Seit längerem hatte ich einen 4er Pi mit einer geupdateten alpha1 am laufen.
Da ich relativ viel remprobiert hatte, wollte ich diesen mit dem alpha 4 Image neu aufsetzen.
Allerdings startet die "Regelung openWB 2.0" nicht.

Anderer 4er Pi oder SD schafft auch keine abhilfe.

Kannst du mal in die main.log schauen, womöglich findet sich dort der Grund fuer den fehlgeschlagen Start des service.

[Heuberg]

Danke @Martin.
Es lag an der Berechtigungsverwaltung der User.

Und schon ist mir etwas aufgefallen:
Bei einem Virtuellen Zähler kann kein Kommawert eingestellt werden.
Meine Garage mit 2 LPs hängt aktuell noch an einer 3x1,5² (Neue Leitung liegt schon parat ).
Die zwei Boxen würde ich gern auf 2,5 kW begrenzen, es lassen sich aber nur 2, oder 3 kW einstellen.

Zusätzlich wäre die Nachfrage zum Herunterfahren des Systems gut gegen Fehlbedienung.

[mrinas]

In Deinem Fall stammt das Limit ja aus der Verkabelung, hier spielt die Leistung genau genommen gar keine Rolle - viel mehr ist der Strom ausschlaggebend. Wenn Du den auf 11A begrenzt kommst Du ja recht genau an die 2,5kW ran (11A*230V=2530W). Zudem hilft die Strombegrenzung auch bei 1p und 3p Betrieb um die Leitung zu schützen, das wäre mit einer reinen kW-Limitierung vermutlich nicht der Fall.

Die Leistungsbegrenzung (kW) ist m.E. vorallem dann hilfreich wenn man nur eine Anschlussleistung gegenüber dem Netzbetreiber einhalten muss. Z.b. Mehrere Ladepunkte welche sich die angemeldeten 11kW teilen sollen.

[rleidner]

Betrifft das UI:
In Einstellungen - Konfiguration - Fahrzeuge - Fahrzeug-Vorlagen fehlt noch die Möglichkeit, das SOC-Abfrage-Verhalten zu ändern.
d.h. diese Unterstruktur im topic openWB/vehicle/template/ev_template/[template-id]
"soc": {
"request_interval_charging": 5,
"request_interval_not_charging": 720,
"request_only_plugged": false
}
Es kann via mqtt verändert werden, aber im UI wäre es praktischer.

[Heuberg]

In Deinem Fall stammt das Limit ja aus der Verkabelung, hier spielt die Leistung genau genommen gar keine Rolle - viel mehr ist der Strom ausschlaggebend. Wenn Du den auf 11A begrenzt kommst Du ja recht genau an die 2,5kW ran (11A*230V=2530W). Zudem hilft die Strombegrenzung auch bei 1p und 3p Betrieb um die Leitung zu schützen, das wäre mit einer reinen kW-Limitierung vermutlich nicht der Fall.

Die Leistungsbegrenzung (kW) ist m.E. vorallem dann hilfreich wenn man nur eine Anschlussleistung gegenüber dem Netzbetreiber einhalten muss. Z.b. Mehrere Ladepunkte welche sich die angemeldeten 11kW teilen sollen.

Die Ampere Begrenzung macht wegen dem Leitungsquerschnitt natührlich mehr sinn.
Allerdings sind nur Werte größer gleich 16A einstellbar.
Da gerade nur eine 1p Leitung vorhanden ist, war die kW Version mit 2 oder 3 kW näher drann als 16A

[rleidner]

Beim Testen der SOC-Module ist mir ein unschönes Verhalten aufgefallen:

Wenn bei einem neu konfigurierten Fahrzeug der SOC-Modul mit Fehler antwortet, wird dieses SOC-Modul in jedem Regeldurchlauf aufgerufen, d.h. die Intervalle in der Fahrzeug-Vorlage werden in diesem Fall nicht berücksichtigt.
Das passiert unabhängig davon ob das Fahrzeug einem Ladepunkt zugeordnet ist, ob es lädt oder nicht.

Das liegt m.E. daran, dass der soc_timestamp bei Fehler nicht gesetzt wird und daher bei jedem Regeldurchlauf soc_timestamp_expired angenommen wird.
Damit wird u.U. der Server des Fahrzeugherstellers mit ungültigen Versuchen bombardiert.

Workaround: den SOC-Modul des Fahrzeugs auf einen funktionierenden Modul umzustellen oder auf "kein Modul".
Das muss man aber im soc.log sehen.

Ich denke es sollten in diesem Fall die Abfrage-Intervalle eingehalten werden oder nach einer Reihe von Fehlversuchen das Abfragen für dieses Fahrzeug gestoppt werden.
Dieser Stopp könnte z.B. durch einen manuellen SOC-Abruf im Dashboard wieder entfernt werden - was natürlich bedingt das Fahrzeug einem Ladepunkt zuzuordnen.

[mrinas]

Lena, ich hab' auch noch einen zum SoC Modul. Derzeit wird der SoC nach Zeitplan aktualisiert, was noch fehlt ist eine Aktualisierung direkt nach dem Anstecken, kann das sein?

[Xerion]

Hallo ich habe in der Main.log ständig Einträge von einem LP (11) der mal angelegt war und wieder gelöscht wurde. Dieser scheint aber im Hintergrund noch aktiv zu bleiben da dieser einerseits im Log und in der UI Statistik (Legende) weiterhin auftaucht.

Code: Alles auswählen

File "/var/www/html/openWB/packages/control/chargepoint.py", line 861, in _get_charging_ev
    charging_ev = ev_list[f"ev{vehicle}"]
KeyError: 'ev<property object at 0xb6013cf8>'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 850, in update
    ev_list[f"ev{vehicle}"].data.control_parameter.submode = "stop"
KeyError: 'ev<property object at 0xb6013cf8>'
2022-11-08 05:46:21,520 - {control.loadmanagement:288} - {ERROR:MainThread} - Fehler im Lastmanagement-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/loadmanagement.py", line 260, in _check_max_currents
    currents_used[phase] = data.data.counter_data[counter].data["set"]["currents_used"][phase] + \
IndexError: list index out of range
2022-11-08 05:46:21,529 - {control.process:51} - {ERROR:MainThread} - Fehler im Process-Modul für Ladepunkt cp11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/process.py", line 49, in process_algorithm_results
    modules_threads.append(self._start_charging(chargepoint))
  File "/var/www/html/openWB/packages/control/process.py", line 110, in _start_charging
    return threading.Thread(target=chargepoint.chargepoint_module.set_current,
AttributeError: 'NoneType' object has no attribute 'set_current'
2022-11-08 05:46:31,413 - {modules.loadvars:51} - {ERROR:MainThread} - Fehler im loadvars-Modul bei Element 11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 48, in _set_values
    modules_threads.append(threading.Thread(target=cp.chargepoint_module.get_values,
AttributeError: 'NoneType' object has no attribute 'get_values'
2022-11-08 05:46:31,494 - {control.chargepoint:849} - {ERROR:MainThread} - Fehler im Prepare-Modul für Ladepunkt 11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 774, in update
    charging_ev = self._get_charging_ev(vehicle, ev_list)
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 861, in _get_charging_ev
    charging_ev = ev_list[f"ev{vehicle}"]
KeyError: 'ev<property object at 0xb6013cf8>'
2022-11-08 05:46:31,496 - {control.chargepoint:858} - {ERROR:MainThread} - Fehler bei Ladepunkt 11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 774, in update
    charging_ev = self._get_charging_ev(vehicle, ev_list)
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 861, in _get_charging_ev
    charging_ev = ev_list[f"ev{vehicle}"]
KeyError: 'ev<property object at 0xb6013cf8>'

[LenaK]

Beim Testen der SOC-Module ist mir ein unschönes Verhalten aufgefallen:

Wenn bei einem neu konfigurierten Fahrzeug der SOC-Modul mit Fehler antwortet, wird dieses SOC-Modul in jedem Regeldurchlauf aufgerufen, d.h. die Intervalle in der Fahrzeug-Vorlage werden in diesem Fall nicht berücksichtigt.
Das passiert unabhängig davon ob das Fahrzeug einem Ladepunkt zugeordnet ist, ob es lädt oder nicht.

Das liegt m.E. daran, dass der soc_timestamp bei Fehler nicht gesetzt wird und daher bei jedem Regeldurchlauf soc_timestamp_expired angenommen wird.
Damit wird u.U. der Server des Fahrzeugherstellers mit ungültigen Versuchen bombardiert.

Workaround: den SOC-Modul des Fahrzeugs auf einen funktionierenden Modul umzustellen oder auf "kein Modul".
Das muss man aber im soc.log sehen.

Ich denke es sollten in diesem Fall die Abfrage-Intervalle eingehalten werden oder nach einer Reihe von Fehlversuchen das Abfragen für dieses Fahrzeug gestoppt werden.
Dieser Stopp könnte z.B. durch einen manuellen SOC-Abruf im Dashboard wieder entfernt werden - was natürlich bedingt das Fahrzeug einem Ladepunkt zuzuordnen.

Danke für den Hinweis, ich habe es korrigiert.

[LenaK]

Hallo ich habe in der Main.log ständig Einträge von einem LP (11) der mal angelegt war und wieder gelöscht wurde. Dieser scheint aber im Hintergrund noch aktiv zu bleiben da dieser einerseits im Log und in der UI Statistik (Legende) weiterhin auftaucht.

Code: Alles auswählen

File "/var/www/html/openWB/packages/control/chargepoint.py", line 861, in _get_charging_ev
    charging_ev = ev_list[f"ev{vehicle}"]
KeyError: 'ev<property object at 0xb6013cf8>'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 850, in update
    ev_list[f"ev{vehicle}"].data.control_parameter.submode = "stop"
KeyError: 'ev<property object at 0xb6013cf8>'
2022-11-08 05:46:21,520 - {control.loadmanagement:288} - {ERROR:MainThread} - Fehler im Lastmanagement-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/loadmanagement.py", line 260, in _check_max_currents
    currents_used[phase] = data.data.counter_data[counter].data["set"]["currents_used"][phase] + \
IndexError: list index out of range
2022-11-08 05:46:21,529 - {control.process:51} - {ERROR:MainThread} - Fehler im Process-Modul für Ladepunkt cp11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/process.py", line 49, in process_algorithm_results
    modules_threads.append(self._start_charging(chargepoint))
  File "/var/www/html/openWB/packages/control/process.py", line 110, in _start_charging
    return threading.Thread(target=chargepoint.chargepoint_module.set_current,
AttributeError: 'NoneType' object has no attribute 'set_current'
2022-11-08 05:46:31,413 - {modules.loadvars:51} - {ERROR:MainThread} - Fehler im loadvars-Modul bei Element 11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/loadvars.py", line 48, in _set_values
    modules_threads.append(threading.Thread(target=cp.chargepoint_module.get_values,
AttributeError: 'NoneType' object has no attribute 'get_values'
2022-11-08 05:46:31,494 - {control.chargepoint:849} - {ERROR:MainThread} - Fehler im Prepare-Modul für Ladepunkt 11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 774, in update
    charging_ev = self._get_charging_ev(vehicle, ev_list)
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 861, in _get_charging_ev
    charging_ev = ev_list[f"ev{vehicle}"]
KeyError: 'ev<property object at 0xb6013cf8>'
2022-11-08 05:46:31,496 - {control.chargepoint:858} - {ERROR:MainThread} - Fehler bei Ladepunkt 11
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 774, in update
    charging_ev = self._get_charging_ev(vehicle, ev_list)
  File "/var/www/html/openWB/packages/control/chargepoint.py", line 861, in _get_charging_ev
    charging_ev = ev_list[f"ev{vehicle}"]
KeyError: 'ev<property object at 0xb6013cf8>'

Das sieht nach einem Problem beim Löschen aus. Ich mache mich auf die Suche nach der Ursache.
Um die Ladepunkt-"Leiche" bei Dir wieder loszuwerden: Hast Du noch ein Backup, bevor Du den LP gelöscht hast? Das könntest Du einspielen und dann nochmal den LP löschen.(Grundsätzlich sollte das funktionieren)