Feedback Beta 1

[tobox]

Das mit dem x-fachen Nennstrom ist korrekt. Aber man muss sich auch im klaren darüber sein, dass eine Sicherung, die über Stunden nahe der Nennleistung betrieben wird, deutlich schneller auslöst als eine, die "kalt" ist (zumindest Schmelzsicherungen).

Außerdem sehe ich aktuell keinen Grund, warum nicht alle Autos mit 32A/0W vollgeladen dort stehen können und wenn die Mitarbeiter gleichzeitig die Autos vorheizen (z.B. über Timer), die nicht auch gleichzeitig Leistung ziehen können... Dann hätte ich den Salat

Soll ich logfiles dazu erzeugen oder ist das Problem im Prinzip klar?

[mrinas]

Das mit dem x-fachen Nennstrom ist korrekt. Aber man muss sich auch im klaren darüber sein, dass eine Sicherung, die über Stunden nahe der Nennleistung betrieben wird, deutlich schneller auslöst als eine, die "kalt" ist (zumindest Schmelzsicherungen).

Außerdem sehe ich aktuell keinen Grund, warum nicht alle Autos mit 32A/0W vollgeladen dort stehen können und wenn die Mitarbeiter gleichzeitig die Autos vorheizen (z.B. über Timer), die nicht auch gleichzeitig Leistung ziehen können... Dann hätte ich den Salat

Soll ich logfiles dazu erzeugen oder ist das Problem im Prinzip klar?

Ich denke Logfiles mit Debug Level sind hier sicherlich hilfreich, anders wirds vermutlich schwer zu erkennen woher das genau kommt.

[tobox]

Also das Fehlverhalten ist meiner Meinung nach, dass der freigegebene Ladestrom bestehen bleibt, auch wenn das Auto voll ist und nicht läd. Das ist bei mir reproduzierbar immer so.

Loglevel INFO habe ich dauerhaft an, das könnte ich bereitstellen. Reicht das? Oder soll ich versuchen, auf DETAILS dasselbe Szenario zu loggen?

[mrinas]

Also das Fehlverhalten ist meiner Meinung nach, dass der freigegebene Ladestrom bestehen bleibt, auch wenn das Auto voll ist und nicht läd. Das ist bei mir reproduzierbar immer so.

Vermute mal dass die Ladepunkte auf Sofortladen stehen, ist ein Limit konfiguriert? Ohne konfiguriertes Limit wird Sofortladen immer sofort eine Ladefreigabe geben.

Interessanter ist wohl die Frage ob der Fall mit erteiler, nicht genutzter Ladefreigabe oberhalb des Lastlimits sich wie erwartet verhält.

Loglevel INFO habe ich dauerhaft an, das könnte ich bereitstellen. Reicht das? Oder soll ich versuchen, auf DETAILS dasselbe Szenario zu loggen?

Denke dass Logs mit Details die bessere Option sind, da ist dann sicher alles drin was benötigt werden könnte.

[rleidner]

Ich habe seit einem Update gestern Fehler bei den Ladepunkten.
Ladepunktvorlagen verschwinden nach Neustart der OWB2;
in main.log gibt es zu den Ladepunkten Fehler:

Code: Alles auswählen

atreboot.sh started
Error: Connection refused
no restore pending, normal startup
LAN/WLAN...
apache default site...
...ok
checking required apache modules...
headers (enabled by site administrator)
headers already enabled
ssl (enabled by site administrator)
ssl already enabled
proxy_wstunnel (enabled by site administrator)
proxy_wstunnel already enabled
apt packages...
check mosquitto installation...
mosquitto.conf already up to date
mosquitto openwb.conf already up to date
mosquitto_local.conf already up to date
mosquitto openwb_local.conf already up to date
mosquitto done
python packages...
2022-11-17 18:08:33,273 - {root:134} - {DEBUG:MainThread} - Warten auf das Ende des Boot-Prozesses
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already satisfied: jq==1.1.3 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 1)) (1.1.3)
Requirement already satisfied: paho_mqtt==1.6.1 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 2)) (1.6.1)
Requirement already satisfied: pymodbus==2.5.2 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 3)) (2.5.2)
Requirement already satisfied: pytest==6.2.5 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 4)) (6.2.5)
Requirement already satisfied: requests_mock==1.9.3 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 5)) (1.9.3)
Requirement already satisfied: lxml==4.7.1 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 6)) (4.7.1)
Requirement already satisfied: aiohttp==3.7.2 in ./.local/lib/python3.9/site-packages (from -r /var/www/html/openWB/requirements.txt (line 7)) (3.7.2)
Requirement already satisfied: async-timeout<4.0,>=3.0 in ./.local/lib/python3.9/site-packages (from aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (3.0.1)
Requirement already satisfied: chardet<4.0,>=2.0 in ./.local/lib/python3.9/site-packages (from aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (3.0.4)
Requirement already satisfied: attrs>=17.3.0 in ./.local/lib/python3.9/site-packages (from aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (21.4.0)
Requirement already satisfied: multidict<7.0,>=4.5 in ./.local/lib/python3.9/site-packages (from aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (6.0.2)
Requirement already satisfied: typing-extensions>=3.6.5 in ./.local/lib/python3.9/site-packages (from aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (4.4.0)
Requirement already satisfied: yarl<2.0,>=1.0 in ./.local/lib/python3.9/site-packages (from aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (1.8.1)
Requirement already satisfied: six>=1.15.0 in /usr/lib/python3/dist-packages (from pymodbus==2.5.2->-r /var/www/html/openWB/requirements.txt (line 3)) (1.16.0)
Requirement already satisfied: pyserial>=3.4 in ./.local/lib/python3.9/site-packages (from pymodbus==2.5.2->-r /var/www/html/openWB/requirements.txt (line 3)) (3.5)
Requirement already satisfied: iniconfig in ./.local/lib/python3.9/site-packages (from pytest==6.2.5->-r /var/www/html/openWB/requirements.txt (line 4)) (1.1.1)
Requirement already satisfied: pluggy<2.0,>=0.12 in ./.local/lib/python3.9/site-packages (from pytest==6.2.5->-r /var/www/html/openWB/requirements.txt (line 4)) (1.0.0)
Requirement already satisfied: packaging in ./.local/lib/python3.9/site-packages (from pytest==6.2.5->-r /var/www/html/openWB/requirements.txt (line 4)) (21.3)
Requirement already satisfied: py>=1.8.2 in ./.local/lib/python3.9/site-packages (from pytest==6.2.5->-r /var/www/html/openWB/requirements.txt (line 4)) (1.11.0)
Requirement already satisfied: toml in ./.local/lib/python3.9/site-packages (from pytest==6.2.5->-r /var/www/html/openWB/requirements.txt (line 4)) (0.10.2)
Requirement already satisfied: requests<3,>=2.3 in /usr/lib/python3/dist-packages (from requests_mock==1.9.3->-r /var/www/html/openWB/requirements.txt (line 5)) (2.25.1)
Requirement already satisfied: idna>=2.0 in /usr/lib/python3/dist-packages (from yarl<2.0,>=1.0->aiohttp==3.7.2->-r /var/www/html/openWB/requirements.txt (line 7)) (2.10)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in ./.local/lib/python3.9/site-packages (from packaging->pytest==6.2.5->-r /var/www/html/openWB/requirements.txt (line 4)) (3.0.9)
RTNETLINK answers: Network is unreachable
load versions...
chgrp: cannot access '/var/www/html/openWB/data/restore/*': No such file or directory
chmod: cannot access '/var/www/html/openWB/data/restore/*': No such file or directory
2022-11-17 18:08:39: boot done :-)
2022-11-17 18:08:40,282 - {root:137} - {DEBUG:MainThread} - Boot-Prozess abgeschlossen
2022-11-17 18:08:40,284 - {helpermodules.update_config:320} - {DEBUG:MainThread} - Broker-Konfiguration aktualisieren
2022-11-17 18:08:41,515 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/chargepoint/template/1
2022-11-17 18:08:41,517 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/chargepoint/template/2
2022-11-17 18:08:41,520 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/chargepoint/3/set/required_power
2022-11-17 18:08:41,524 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/chargepoint/4/set/required_power
2022-11-17 18:08:41,527 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/chargepoint/4/get/power_factors
2022-11-17 18:08:41,616 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/command/command_completed
2022-11-17 18:08:41,617 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/command/mqttjs_a900a73a/messages/1668704895504
2022-11-17 18:08:41,619 - {helpermodules.update_config:347} - {DEBUG:MainThread} - Ungültiges Topic zum Startzeitpunkt: openWB/command/mqttjs_a900a73a/messages/1668704907103
2022-11-17 18:08:45,082 - {helpermodules.subdata:705} - {ERROR:Thread-5} - Fehler im subdata-Modul
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/helpermodules/subdata.py", line 703, in process_system_topic
    self.set_json_payload(var["system"].data, msg)
KeyError: 'system'
2022-11-17 18:08:49,884 - {root:63} - {INFO:MainThread} - # ***Start*** 
2022-11-17 18:08:49,910 - {control.data:367} - {ERROR:MainThread} - Fehler im Prepare-Modul für Ladepunkt cp3
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/data.py", line 362, in __copy_cp_data
    self.cp_data[chargepoint].template = self.cp_template_data["cpt" + str(
KeyError: 'cpt1'
2022-11-17 18:08:49,913 - {control.data:367} - {ERROR:MainThread} - Fehler im Prepare-Modul für Ladepunkt cp4
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/data.py", line 362, in __copy_cp_data
    self.cp_data[chargepoint].template = self.cp_template_data["cpt" + str(
KeyError: 'cpt2'
2022-11-17 18:08:49,921 - {control.data:367} - {ERROR:MainThread} - Fehler im Prepare-Modul für Ladepunkt cp3
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/data.py", line 362, in __copy_cp_data
    self.cp_data[chargepoint].template = self.cp_template_data["cpt" + str(
KeyError: 'cpt1'
2022-11-17 18:08:49,922 - {control.data:367} - {ERROR:MainThread} - Fehler im Prepare-Modul für Ladepunkt cp4
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/control/data.py", line 362, in __copy_cp_data
    self.cp_data[chargepoint].template = self.cp_template_data["cpt" + str(
KeyError: 'cpt2'
2022-11-17 18:08:49,925 - {soc.modules.common.component_context:51} - {DEBUG:device2} - Update Komponenten ['Kostal Plenticore Wechselrichter']
2022-11-17 18:08:49,926 - {modules.devices.openwb_evu_kit.device:50} - {DEBUG:device3} - Start device reading {'component8': <modules.devices.openwb_evu_kit.counter.EvuKit object at 0xb26ebb50>}
2022-11-17 18:08:49,927 - {soc.modules.common.component_context:24} - {DEBUG:cp3} - Update Komponente ['Ladepunkt']
2022-11-17 18:08:49,927 - {soc.modules.common.component_context:24} - {DEBUG:device3} - Update Komponente ['EVU-Kit']
2022-11-17 18:08:49,928 - {soc.modules.common.component_context:24} - {DEBUG:cp4} - Update Komponente ['Ladepunkt']
2022-11-17 18:08:49,928 - {modules.chargepoints.mqtt.chargepoint_module:37} - {DEBUG:cp3} - MQTT-Ladepunkte müssen nicht ausgelesen werden.
2022-11-17 18:08:49,930 - {modules.chargepoints.mqtt.chargepoint_module:37} - {DEBUG:cp4} - MQTT-Ladepunkte müssen nicht ausgelesen werden.
2022-11-17 18:08:49,943 - {soc.modules.common.store._api:26} - {DEBUG:device2} - Raw data InverterState(currents=[0.0, 0.0, 0.0], power=0, exported=18011344.0, dc_power=None)
2022-11-17 18:08:50,427 - {modules.common.simcount._simcount:38} - {DEBUG:device3} - Previous state: SimCounterState(timestamp=1668704904.535131, power=400.29, imported=6251862.882563772, exported=9578029.303187123)
2022-11-17 18:08:50,428 - {modules.common.simcount._calculate:13} - {DEBUG:device3} - time passed: 0.00719225, power1: 400.29, power2: 433.72
2022-11-17 18:08:50,428 - {modules.common.simcount._calculate:29} - {DEBUG:device3} - power did not change sign. Total energy: 2.9992
2022-11-17 18:08:50,429 - {modules.common.simcount._simcount:47} - {DEBUG:device3} - imported: 2.9992 Wh, exported: 0 Wh, new state: SimCounterState(timestamp=1668704930.4272268, power=433.71999999999997, imported=6251865.8817674965, exported=9578029.303187123)
2022-11-17 18:08:50,429 - {soc.modules.common.store._api:26} - {DEBUG:device3} - Raw data CounterState(voltages=[229.26, 229.49, 230.06], powers=[37.13, 313.03, 83.56], currents=[0.321, 1.684, 0.516], power_factors=[0.632, 0.9285, 0.8769], imported=6251865.8817674965, exported=9578029.303187123, power=433.71999999999997, frequency=50.05)
2022-11-17 18:08:50,633 - {soc.modules.common.component_context:24} - {DEBUG:component7} - Update Komponente ['Kostal Plenticore Wechselrichter']
2022-11-17 18:08:50,636 - {soc.modules.common.component_context:24} - {DEBUG:cp3} - Update Komponente ['Ladepunkt']
2022-11-17 18:08:50,639 - {soc.modules.common.store._api:26} - {DEBUG:component7} - Raw data InverterState(currents=[0.0, 0.0, 0.0], power=0, exported=18011344.0, dc_power=None)
2022-11-17 18:08:50,644 - {soc.modules.common.component_context:24} - {DEBUG:cp4} - Update Komponente ['Ladepunkt']
2022-11-17 18:08:50,647 - {soc.modules.common.store._api:30} - {DEBUG:component7} - Saving InverterState(currents=[0.0, 0.0, 0.0], power=0, exported=18011344.0, dc_power=None)
2022-11-17 18:08:50,676 - {soc.modules.common.component_context:24} - {DEBUG:component8} - Update Komponente ['EVU-Kit']
2022-11-17 18:08:50,677 - {soc.modules.common.store._api:30} - {DEBUG:component8} - Saving CounterState(voltages=[229.26, 229.49, 230.06], powers=[37.13, 313.03, 83.56], currents=[0.321, 1.684, 0.516], power_factors=[0.632, 0.9285, 0.8769], imported=6251865.8817674965, exported=9578029.303187123, power=433.71999999999997, frequency=50.05)

Key Error cpt1/cpt2 bezieht sich vermutlich auf die Ladepunkt-Vorlagen, die verschwinden.
Was ist zu tun?

EDIT: in MQTT-Explorer kann ich die fehlenden templates n openWB/cp/templates.
Es scheint also die Zuordnung cp->cpt fehlerhaft zu sein.
Wenn ich die Standard-Ladepunkt-Vorlage den Ladepunkten zuweise, verschwindet der Fehler.

Beim Vergleich der Standard-Vorlage (oben) und der neu angelegten (unten) sehen diese leicht unterschiedlich aus (Felder plans und id):

Code: Alles auswählen

{
  "name": "Standard Ladepunkt-Vorlage",
  "autolock": {
    "wait_for_charging_end": false,
    "active": false
  },
  "rfid_enabling": false,
  "valid_tags": []
}

{
  "autolock": {
    "active": false, 
    "plans": {}, 
    "wait_for_charging_end": false
  }, 
  "name": "LPV-ID3", 
  "rfid_enabling": false, 
  "valid_tags": [],
  "id": 1
}

[rleidner]

zum mqtt.log:
Es werden sowohl epoch als auch lesbare timestamps ausgegeben:

Code: Alles auswählen

{"timestamp": 1668707412, "time": "18:50:12", "grid": 0.574, "house-power": 0.574, "charging-all": 0.0, "pv-all": -0.0, "cp3-power": 0.0, "cp4-power": 0.0, "ev2-soc": 91, "ev3-soc": 65}
{"timestamp": 1668707422, "time": "18:50:22", "grid": 0.572, "house-power": 0.572, "charging-all": 0.0, "pv-all": -0.0, "cp3-power": 0.0, "cp4-power": 0.0, "ev2-soc": 91, "ev3-soc": 65}
2022-11-17 18:54:12,834 - Topic: openWB/graph/alllivevaluesJson7, Payload: -
2022-11-17 18:54:18,973 - Topic: openWB/set/chargepoint/3/get/voltages, Payload: [228.4, 227.6, 227.1]

Ich würde empfehlen, das einheitlich (lesbar) zu implementieren.

[LutzB]

zum mqtt.log:
Es werden sowohl epoch als auch lesbare timestamps ausgegeben:

Code: Alles auswählen

{"timestamp": 1668707412, "time": "18:50:12", "grid": 0.574, "house-power": 0.574, "charging-all": 0.0, "pv-all": -0.0, "cp3-power": 0.0, "cp4-power": 0.0, "ev2-soc": 91, "ev3-soc": 65}
{"timestamp": 1668707422, "time": "18:50:22", "grid": 0.572, "house-power": 0.572, "charging-all": 0.0, "pv-all": -0.0, "cp3-power": 0.0, "cp4-power": 0.0, "ev2-soc": 91, "ev3-soc": 65}
2022-11-17 18:54:12,834 - Topic: openWB/graph/alllivevaluesJson7, Payload: -
2022-11-17 18:54:18,973 - Topic: openWB/set/chargepoint/3/get/voltages, Payload: [228.4, 227.6, 227.1]

Ich würde empfehlen, das einheitlich (lesbar) zu implementieren.

Die oberen Zeilen in Deinem Beispiel sind Daten, kein Logging-Zeitstempel.

[rleidner]

zum mqtt.log:
Es werden sowohl epoch als auch lesbare timestamps ausgegeben:
...
Ich würde empfehlen, das einheitlich (lesbar) zu implementieren.

Die oberen Zeilen in Deinem Beispiel sind Daten, kein Logging-Zeitstempel.

OK, verstanden - danke!

[rleidner]

Der 2. Ladepunkt in meiner Konfiguration ist 1-phasig (Ladeziegel).
In den Hardware-Optionen ist eingestellt: Automatische Phasenumschaltung = Nein.

Im main.log steht alle 10 sec dieser Fehler:

Code: Alles auswählen

2022-11-17 22:45:49,238 - {control.chargepoint:642} - {ERROR:MainThread} - Phasenumschaltung an Ladepunkt4 nicht möglich, da der Ladepunkt keine Phasenumschaltung unterstützt.

Das ist doch so konfiguriert und damit kein Fehler, der im 10sec-Abstand mitgeteilt werden muss.

[tobox]

Vermute mal dass die Ladepunkte auf Sofortladen stehen, ist ein Limit konfiguriert? Ohne konfiguriertes Limit wird Sofortladen immer sofort eine Ladefreigabe geben.

Interessanter ist wohl die Frage ob der Fall mit erteiler, nicht genutzter Ladefreigabe oberhalb des Lastlimits sich wie erwartet verhält.

Ja, alle Ladepunkte (2x OpenWB Duo) stehen auf Sofortladen und haben 32A freigegeben.
Limits sind 3-stufig implementiert:

- 1 Virtueller Zähler pro OpenWB Duo mit Einstellungen 22kW/32A
- 1 Modbuszähler der die Wallboxen+PV Anlage in Summe auf 22kW/32A limitiert
- 1 Modbuszähler am Hauptzähler der auf 30kW/45A limitiert

Aktuell habe ich nicht mal mehr die normalern Logfiles, weil die scheinbar relativ schnell gelöscht/überschieben werden.

Vielleicht ist das ein sehr exotischer Wunsch, aber für User von Virtuellen Maschinen / Appliances wäre es sehr schön, wenn die Logfiles länger aufbewahrt werden würden und beim Reboot erhalten bleiben. Es liegt ja eine beliebig große SSD mit nahezu unbegrenzten Schreibzyklen darunter - da brauchte es den ganzen SD-Karten-Schutz nicht, der mit viel Aufwand eingebaut wurde.