rtrbt

Wenn der Taster nicht angesteckt ist, denkt die Box permanent, dass er gedrückt wäre. Das ist erstmal nicht schlimm (weil der Ladecontroller auf Knopfdruckänderungen reagiert, d.h. dir wird nicht die ganze Zeit die Ladung abgebrochen), wird mit der nächsten Firmware-Version aber dazu führen, dass die Wallbox ~ 30 Sekunden langsamer bootet.

Wenn du willst kannst du, damit der Taster die ganze Zeit gedrückt ist, Pin 3 und 4 der entsprechenden Buchse verbinden.

Was du tun musst hängt davon ab, ob in der neuen Firmware (oder falls du Updates überspringst in irgendeiner zwischen der installierten und der die du neu installieren willst) die EVSE-Firmware aktualisiert wurde. Das erkennst du daran, dass dann im Changelog etwas in Richtung "[Änderung...] (durch Update auf Ladecontroller-Firmware 2.1.6)" steht.

Falls das nicht der Fall ist, kannst du:

• Das esp32-firmware-git pullen
  (da du keine Änderungen außer der Firmware-Datei haben solltest, müsste das immer klappen)
• Dann sicherheitshalber ein git checkout warp2-x.y.z machen
  (Ich tagge immer den Commit, der dem Stand einer veröffentlichten Firmware entspricht. Das sorgt dafür, dass du auf einem definierten Stand bist und nicht ein paar unveröffentlichte Änderungen mitnimmst. Eigentlich sollte die Firmware auf jedem Commit funktionieren, aber bei größeren Änderungen kann das zwischenzeitlich auch mal nicht klappen.)
• Deine Firmware sollte dann noch in esp32-firmware/software/src/modules/evse_v2 liegen
• Die ESP-Firmware neu kompilieren und flashen

Wenn es eine neue Ladecontroller-Firmware gibt, musst du folgendes davor in evse-v2-bricklet/ tun:

• Mit git stash deine Änderungen bei Seite legen
• Mit git pull unsere Änderungen holen
• Dann git checkout vX.Y.Z damit du auch hier auf dem Stand einer veröffentlichten Firmware bist.
• Deine Änderungen wieder anwenden mit git stash apply
  (Falls das nicht klappt musst du nachsehen, was sich an der Code-Struktur geändert hat)
• EVSE-Firmware neubauen und wieder nach esp32-firmware/software/src/modules/evse_v2 packen
• Dann die Schritte von oben um die neue ESP-Firmware zu bauen

On 7/11/2022 at 4:45 PM, Photon_1978 said:

880 Ohm und 2700 Ohm wie groß ist der Toleranzbereich beim messen?

Ziemlich groß: https://github.com/Tinkerforge/evse-v2-bricklet/blob/90b0d370b231c3ca5b2ce9f093d318d988541c94/software/src/iec61851.c#L42-L56

Also alles < 1790Ω betrachten wir als 880Ω (State C = Laden), alles über 1790Ω als 2700Ω (State B = Auto will keinen Strom).

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Ich kann die Widerstände ja im Ladecontroller sehen. Gibt es eine Möglichkeit diese zu loggen?

Wenn dir einmal pro Sekunde reicht könntest du das z.B. über MQTT machen, oder mit einem Script dass http://warp2-xyz/evse/low_level_state abfragt.

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Vielleicht hab ich ja ein Problem mit den Widerständen?

Das wäre prinzipiell möglich, würde ich aber nicht mitten beim Laden erwarten. Wäre trotzdem interessant, wenn du das mal loggst.

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Wer kommt überhaupt auf die Idee im Zeitalter der digitalen Kommunikation analoge Widerstände zu messen??

Das ist absichtlich darauf ausgelegt, dass man theoretisch ohne Digitaltechnik auskommt, siehe auch hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Ich habe im Log viele wifi Abbrüche was merkwürdig ist da die Fritzfunke keine 80cm über der Wallbox sitzt.

Hm vielleicht ein Problem mit der Antennenausrichtung bzw. anderen Netzen auf dem Kanal? Ist das ein Repeater? Vielleicht versucht die Box sich zu einem anderen AP deines Netzes zu verbinden (dann wäre die BSSID-Sperre an). Alternativ: Wenn das nur 80cm sind, kannst du viell ein LAN-Kabel verlegen.

On 7/11/2022 at 4:45 PM, Photon_1978 said:

Tja, ansonsten wenn ich herausfinden will warum der U5 was wie macht muss ich wohl erst chinesisch lernen, aber darum sollte er das laden abbrechen?

Was mir in einem der EVSE-Logs aufgefallen war, ist dass die Spannung auf L1 relativ niedrig ist, wenn er lädt. Meine mich an 216V erinnern zu können. Vielleicht bricht die Ladung ab wenn die Spannung unter irgendeinen Grenzwert fällt?

10 hours ago, Andreas_Mainz said:

Ich habe auch schon das Zbin File in das passende Directory vom Esp32 gelegt und mit Vsc eine neue Version gebaut.

Hast du den Dateinamen in z.B. bricklet_evse_v2_firmware_2_1_6.zbin geändert und die Firmware die da schon liegt z.b. in .zbin.old umbenannt? Der Bauprozess erzeugt die evse_v2_bricklet_firmware_bin.embedded.h/cpp automatisch aus einer Firmware-Datei die auf das Schema passt.

Ein Trick aus der Praxis damit man mit den Firmware-Dateien nicht durcheinander kommt: Die Versionsnummer ist in evse-v2-bricklet/software/src/configs/config.h hinterlegt. Für Entwicklungs-Firmwares kannst du die  FIRMWARE_VERSION_REVISION auf z.b. 99 ändern, die Firmware neu kompiliern und als bricklet_evse_v2_firmware_2_1_99.zbin nach esp32-firmware/software/src/modules/evse_v2/esp32-firmware/software/src/modules/evse packen. Das reduziert die Wahrscheinlichkeit, dass du durcheinander kommst welche Firmware jetzt gerade eingebettet wird/auf dem EVSE läuft.

10 hours ago, Andreas_Mainz said:

Dann habe ich das Merge File in die Wallbox runtergeladen und immerhin hat diese ganz normal wieder eingeschaltet. Es war nur alles in englischer Sprache, wo kann man die verwendete Sprache einstellen?

Das Webinterface kann deutsch und englisch und zeigt dir die Sprache an, die dein Browser als die bevorzugte angibt. Da sollte also zwischen den Firmwares kein Unterschied bestehen, wenn du nicht gerade deine Browser-Einstellungen geändert hast. Du kannst mit der Entwicklerkonsole deines Browsers nachsehen welche Sprachen er anfordert, indem du

navigator.languages

eingibst. Bei mir kommt z.B.

Array(3) [ "de", "en", "en-US" ]

als Ergebnis, also wird Deutsch vor Englisch bevorzugt.

On 7/9/2022 at 9:21 AM, Photon_1978 said:

Ich kann im Log der Box nur sehen wann es passiert, aber nicht von welcher Seite. Wird das irgendwo protokolliert?

Hast du im Ereignislog Ausgaben dieser Art?

Charger state changed from 0 to 2

Das ist der Fahrzeugstatus, also

• 0: Nicht angeschlossen
• 1: Angeschlossen aber Wallbox verbietet das Laden (rein technisch: Die Wallbox ein CP-PWM von 0% an)
• 2: Angeschlossen, Wallbox erlaubt das Laden (CP-PWM >= 10%), Auto müsste jetzt damits losgeht 880Ω anlegen
• 3: Lädt: Auto hat 880Ω angelegt, Schütz ist geschaltet
• 4: Fehler

D.h. wenn dein Ladevorgang mit einem

Charger state changed from 3 to 2

endet, dann hat das Auto wieder 2,7kΩ angelegt, also keinen Strom mehr angefordert -> Daraufhin hat die Box das Schütz abgeschaltet.

Wenn der Ladevorgang mit

Charger state changed from 3 to 1

endet, dann hat die Box den Ladevorgang beendet.

Bezüglich der Stromtests: Wir haben das mit dem Oszilloskop nochmal nachgezogen, das CP-PWM passt zu dem Wert den der Ladecontroller ausgibt. Das hängt natürlich (bzgl. Flankensteilheit usw.) auch davon ab, wie dein Auto genau misst. Aber: Was auf jeden Fall seltsam ist, ist dass du nie über die 15,7A kommst. Ich habe spontan nichts über das Ladeverhalten von dem Aiways U5 finden können, aber kann es sein, dass die Regelung über 16A dann nicht mehr linear ist sondern z.B. erst ab 25A die Ladeleistung erhöht wird?

Wie hast du bei dem Ladeziegel gemessen, dass das Auto dann wirklich 16A zieht?

On 7/8/2022 at 3:44 PM, Photon_1978 said:

Könnt ihr die realen Ampere aus dem Zähler auslesen? Und diese als Limit setzen?

Auslesen ja (siehst du auf der Stromzählerseite wenn du die Details aufklappst) Nachregeln nein: Das Limit nachregeln wenn ein Auto weniger zieht ist extrem gefährlich, falls es sich nicht linear verhält.

Wenn du willst kann ich dir kurz ein Python-Script schreiben, dass von 6 bis 20 Ampere in 0,1A Schritten abfährt, immer kurz wartet (damit das Auto reagieren kann) und dann Zählerwerte und PWM von der Box liest. Aber ich erwarte nicht, dass da mehr rauskommt, als das was du schon gemessen hast.

Noch ein Einwurf: Wenn du /home/andreas/git/evse-v2-bricklet/software/build gelöscht hast, sieh in /home/andreas/git/evse-v2-bricklet/ mit git status mal nach, dass du nicht noch andere Änderungen hast.

Aber auf /recovery kommst du? Dann zieh mal einen Debug-Report. Bei den Bricks auf meinem Tisch funktioniert das anstandslos.

You can enumerate all connected bricks and bricklets without knowing their UIDs:

https://www.tinkerforge.com/de/doc/Software/IPConnection_Python.html#enumerate

2 hours ago, Andreas_Mainz said:

Könnte man nicht einen Compilerschalter einführen, wie “External_Fi_Type_B“ available

Das können wir machen (als Compile-Flag in der EVSE-Firmware bzw. ein Define das gesetzt sein muss). Das führt natürlich trotzdem dazu, dass du bei jedem Wallbox-Firmware-Update, das eine neuere EVSE-Firmware mitbringt die EVSE-Firmware neu kompilieren und flashen musst.

2 hours ago, Andreas_Mainz said:

sogar als Parameter im Spiffs?

Persistent bzw. ohne dass du "manuell" eingreifen musst würde ich das nicht bauen wollen. Der DC-Schutz ist immerhin ein relativ wichtiger Sicherheitsmechanismus.

14 hours ago, Doncarlos said:

Langfristig wäre es schön, wenn der Lastmanager selbst wüsste was in seinem Cluster verbraucht wird.

Wir haben ein paar Ideen, wie man den Lastmanager effizienter machen kann, dafür bräuchte er dann auch die Zählerwerte der gesteuerten Boxen. D.h. langfristig könnte das kommen ;)

14 hours ago, Doncarlos said:

Alternativ , etwas weniger schön, wäre es, wenn in der charge_manager/state Liste mit den WARPs auch die IP Adresse der einzelnen Boxen mitübertragen werden würden.

Sieh dir mal charge_manager/config an. Damit kannst du von Namen auf Hosts mappen.

7 hours ago, Doncarlos said:

Der einzelne EVSE liefert das ja , aber ich möchte das ja über das ganze Cluster haben. Gibt es das irgendwo ?

Meinst du den aktuell erlaubten Strom pro Wallbox oder den aktuell verbrauchten Strom den der Stromzähler liest?

Ersteres bekommst du aus charge_manager/state (jeweils allowed_current). Den wirklich gezogenen Strom musst du von den Wallboxen selbst runterkratzen. Das Lastmanagement benutzt die Information nicht, weswegen wird das Stand jetzt nicht zwischen den Boxen kommuniziert.

On 7/1/2022 at 4:32 PM, timmy said:

Nun erhoffe ich mir, dass ich in der Wallbox den WLAN-Access-Point einrichten kann, sodass sich das E-Auto damit und weiter via Ethernet bis ins Internet verbinden kann. Kann bestätigt werden, dass das klappen sollte?

Stand jetzt geht das nicht. Ich hatte das vor längerem versucht zum Laufen zu bekommen, das ist aber leider komplex, deshalb hatte ich da nicht mehr Zeit investiert. https://github.com/Tinkerforge/esp32-firmware/issues/14 ist das Issue dazu. Unabhängig davon ist der Durchsatz des WLAN-APs aber auch eher schlecht (selbst wenn gerade nicht Bugs wie dieser https://github.com/espressif/arduino-esp32/issues/6706 auftreten kommt man nur auf 20 MBit/s) Eventuell lohnt es sich also einen kleinen WLAN-AP mit zwei Ethernet-Ports (einen für die Verbindung nach außen, einen für die Wallbox) in die Tiefgarage zu hängen.

On 7/1/2022 at 4:32 PM, timmy said:

OCPP implementieren. Ich lese, das wird kommen. Geht sich das innerhalb der nächsten 6-9 Monate aus?

Versprechen kann ich das nicht, aber ich gehe stark davon aus. Ich arbeite gerade an der OCPP-Implementierung.

Ah das erklärt einiges.

Dann musst du wie oben beschrieben dir eine Firmware für den Ladecontroller (das EVSE 2.0 Bricklet) kompilieren.

On 6/30/2022 at 9:09 AM, rtrbt said:

- Um eine neue EVSE Bricklet-Firmware zu bauen brauchst du den ganzen PlatformIO-Kram nicht. Das ist ein eigener Mikrocontroller mit eigener Firmware. Die Build-Umgebung dafür läuft in Docker, hier gibt es eine Anleitung zum Aufsetzen: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html#docker

Nach dem Aufsetzen der Build-Umgebung kannst du dir hier https://github.com/Tinkerforge/evse-v2-bricklet den Quellcode der EVSE-Firmware besorgen und dann software/src/dc_fault.c patchen. Auf den ersten Blick musst du nur sicherstellen, dass dc_fault.state immer auf DC_FAULT_NORMAL_CONDITION bleibt.

Die Firmware kannst du dann mit make im software-Verzeichnis kompilieren (das benutzt automatisch die Docker-Build-Umgebung wenn du alles richtig eingerichtet hast), dann solltest du in software/build eine evse-v2-bricklet-firmware.zbin bekommen.

Die Firmware musst du dann auf den Ladecontroller bekommen. Dafür gibt es folgende Möglichkeiten:

• Du kannst das EVSE Bricklet an einen ESP Brick anschließen, dann über http://[IP-deines-ESP-Bricks]/hidden_proxy den Proxy-Modus aktivieren und dich dann mit Brick Viewer zu eben dieser IP verbinden. Da sollte das EVSE als Unknown Bricklet auftauchen. Unter Updates/Flashing -> Bricklets kannst du als Firmware "custom" auswählen, dann mit Browse deine FIrmware auswählen und flashen
• Falls du einen Master Brick oder RPi HAT hast kannst du das EVSE Bricklet direkt an deinen PC anschließen und genauso flashen (dann unter localhost statt der IP des ESPs)
• Die robusteste Variante ist, deine EVSE-Firmware in eine Wallbox- (also ESP-)Firmware einzubetten. Dazu brauchst du das ganze PlatformIO-Setup, einen Klon von https://github.com/Tinkerforge/esp32-firmware und packst die evse-v2-bricklet-firmware.zbin nach esp32-firmware/software/src/modules/evse_v2/ Da müsste schon eine bricklet_evse_v2_firmware_x_y_z.zbin liegen, die musst du überschreiben. Beim Bauen der Wallboxfirmware wird eine .zbin mit exakt diesem Namensschema automatisch eingebettet. Beim Starten prüft die Wallbox-Firmware, ob auf dem EVSE Bricklet eine Firmware mit der erwarteten Versionsnummer läuft (das x_y_z aus dem Dateinamen) und wenn das nicht passt wird das Bricklet auf die eingebettete Firmware umgeflasht. Du kannst aber auch (falls auf dem EVSE schon eine Firmware mit der selben Version läuft) über das Webinterface unter Ladecontroller->Low-Level-Zustand ganz unten das neuflashen erzwingen.

In allen Fällen musst du mit deiner gepatchten EVSE-Firmware dann mit dem "upstream", lies uns Schritt halten, falls du die Wallbox-Firmware aktualisierst. Sonst verlierst du deine EVSE-Änderungen falls wir eine neuere Firmware einbetten.

Das dürfte schon immer so gewesen sein. Auch bei den alten Firmwares reagieren evse/current_limit und evse/start_charging nicht auf HTTP GET (das ist was dein Browser macht wenn du die URL aufrufst) sondern nur auf HTTP PUT. Bei den Node-RED HTTP-Knoten kannst du die Method aber einstellen.

18 hours ago, Little_Company said:

Generell sollte hier das „Core Profile“ für den Betrieb ausreichen.

Das ist die relevante Information ;). Ich hätte für den Anfang auch nur auf das Core Profile abgezielt. OCPP kann noch durch weitere Profiles erweitert werden, z.B. für Reservierungen, Lastmanagement, Authorisierungscaches usw. die wir ggfalls nachziehen können. Der aktuelle Plan ist aber, sobald das "minimale" Feature-Set des Core Profiles läuft mal eine Alpha-Version zu veröffentlichen und die gegen verschiedene Backends zu testen. Dauert aber wie gesagt noch etwas.

4 hours ago, wuesten_fuchs said:

Ich halte das eigentlich für durchaus ziemlich wichtig

Verständlich. Aber wenn man nach der Menge der Anfragen geht sind andere Features (allem voran OCPP an dem ich gerade arbeite) wichtiger.

Nein, die Box startet absichtlich neu. Es fehlte aber ein Hinweis in dem Modalfenster, dass sich öffnet wenn man auf Löschen klickt. Den habe ich mal eingebaut.

12 minutes ago, Doncarlos said:

Nette Features , vielen Dank!

Immer gerne :)

10 minutes ago, Doncarlos said:

Gibt es Best-Practises zum Thema Lastmanager ? In welchen Zyklen ist es geschickt den Strom zu steuern ? Gibt es Nachteile, wenn der Regelkreis wegen kleineren Leistungen nachregelt ?

Im Idealfall gibst du öfter als alle 30 Sekunden den Strom vor. Dann kannst du den Watchdog aktivieren, der, falls deine Steuerung ausfällt, den verfügbaren Strom auf den "Voreingestellt verfügbarer Strom" zurücksetzt. Den kannst du dann z.B. auf 6A stellen, damit falls deine Steuerung ausfällt du immer noch laden kannst (dann möglicherweise mit Netzbezug). Du kannst ihn auch auf 0A setzen, dann werden alle Ladevorgänge gestoppt falls deine Steuerung ausfällt.

Wenn du den Strom sehr hochfrequent aktualisierst sollte auch nichts passieren: Der Lastmanager regelt alle 10 Sekunden, ggfalls. gehen also Zwischenwerte verloren, was ja aber nicht schlimm ist.

Wenn du kleine Leistungsänderungen regelst, kann es sein, dass die angeschlossenen Autos nicht so genau nachziehen, wie man das gerne hätte. Das haben die EVCC-Leute für ein paar Autos ausprobiert: https://github.com/evcc-io/evcc/discussions/3261

Typischerweise dauert es auch ein paar Sekunden (ich glaube die Spezifikation schreibt < 5 Sekunden vor), bis ein Auto auf einen geänderten Ladestrom reagiert, zusätzlich zu den bis zu 10 Sekunden Latenz durch das Regelintervall des Lastmanagers.

3 minutes ago, Andreas_Mainz said:

Ohne Patch wird doch ein Fehler angezeigt, oder..Ich denke der Patch ist notwendig. Oder hat der Fehlerstrom Fehler keine Auswirkungen auf den Ladevorgang?

Doch der Fehlerstrom-Fehler bricht den Ladevorgang ab. Den würdest du ja aber nur erzeugen, wenn du die Fehlerstromüberwachung (Hardware!) aus der Wallbox ausbaust.

Ich meinte, dass du einfach die (soft- und hardwareseitig!) unmodifizierte Wallbox hinter einem Typ-B-FI betreiben kannst. D.h. es ist garnicht notwendig, die Fehlerstromüberwachung auszubauen.

30 minutes ago, Doncarlos said:

Muss ein Auto der Wallbox sagen wieviel Leistung es nun gerne nehmen würde ? Oder tut es das Auto einfach ? Mit Ankündigung müsste die Firmware das ja regeln können. Ohne ists doof.

Es ist doof :D Die Wallbox sagt dem Auto per PWM z.B. "Es sind gerade 10,6 Ampere verfügbar" und das Auto darf dann bis zu 10,6A auf allen Phasen ziehen, muss aber nicht.

31 minutes ago, Doncarlos said:

Bestenfalls geht es noch darüber zu sagen " Der Wallbox Verbund dürfte gerade mit X Leistung laden, der Warp-Cluster verbraucht aber nur 0,3X, dann ist es wohl ein PluginHybrid und ich kann die Amperes noch höher setzen".

Das würde funktionieren. Wenn es mal daneben trifft, (weil z.B. ein Auto spontan von 1 auf 3phasig wechsel, was theoretisch geht, aber mir unbekannt wäre, dass es das gibt) wäre das in deinem Setup ja nicht sehr schlimm, dann würdest du kurz mehr Strom aus deinem Hausanschluss ziehen und der Regelkreis korrigiert dann.

Das geht aber z.B. nicht wenn die Lastmanagement benutzt wird um sicherzustellen, dass ein Hausanschluss nicht überlastet wird.

Du kannst dann auf Nummer Sicher gehen und den "maximal verfügbaren Ladestrom" beim Lastmanagement-Master auf das Maximum, was die Leitungen und der Hausanschluss hergeben, konfigurieren, damit selbst wenn dein Regelkreis durchdreht nichts passiert.

12 hours ago, Doncarlos said:

Angenommen, ich setze jetzt 10A. Wie wird das genau umgesetzt ? Dann macht die Wallbox auf drei Phasen 10A. richtig?

Das stimmt. Die Verteilung ist immer auf alle Phasen und strombezogen (der Kommunikationskanal mit dem Auto geht auch über Ströme)

12 hours ago, Doncarlos said:

Ich fände es glaub ich eine feine Sache, dem Lastmanager eine Watt Zahl zu geben, die er dann selbständig verteilt.

Grundlegend kann der Lastmanager nicht Strom zwischen Phasen verteilen. Wenn du z.B. 16 Ampere pro Phase zu verteilen hast, kannst du nicht 24 Ampere auf eine Phase und dafür nur 12 auf eine andere legen.

12 hours ago, Doncarlos said:

Angenommen, die Solaranlage liefert 4000Watt. 4000/230/3 wären in etwa 6A, die ich dann dem Lastmanager mitteilen würde. Da jetzt mein PluginHybird aber nur auf einer Phase lädt, würde der wiederrum nur mit  1380Watt laden.

Wenn du dir sicher bist, was dein Auto tut, dann kannst du dir das /3 sparen und entsprechend 4000 / 230 ~ 17 Ampere setzen. Das ist nur nichts was wir in der Firmware tun können, weil es keine Garantie dafür gibt, dass ein Auto nicht spontan doch dreiphasig lädt bzw. du nicht irgendwann ein anderes Auto anschließt, dass dreiphasig lädt.

Eine Variante das "sicher" zu machen wäre mit einer 1p-3p-Umschaltung, wie es z.B. unser Energie-Manager können soll.

Ah sorry, war gerade dabei auf deine Mail zu antworten. Dann lieber hier ;)

Erstmal grundlegend: Wenn du einen Typ-B FI hast dann brauchst du die interne Fehlerstromüberwachung nicht, du musst sie aber auch nicht ausbauen. Je nachdem ob der FI oder die interne Überwachung eher auslöst fliegt dann eins von beidem, falls ein Fehlerstrom auftritt. D.h. es ist nicht notwendig, die EVSE-Firmware zu patchen. Falls du das trotzdem machen willst:

- Du kannst das EVSE Bricklet flashen wenn du wie oben beschreiben den Proxy-Modus des ESPs aktivierst und dich dann zur IP des ESPs (also der Wallbox) verbindest. Das EVSE taucht vermutlich als Unknown-Bricklet auf, Flashen kannst du trotzdem.

- Um eine neue EVSE Bricklet-Firmware zu bauen brauchst du den ganzen PlatformIO-Kram nicht. Das ist ein eigener Mikrocontroller mit eigener Firmware. Die Build-Umgebung dafür läuft in Docker, hier gibt es eine Anleitung zum Aufsetzen: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html#docker

- Deine gepatchte Firmware kannst du entweder über Brick Viewer flashen Achtung! Dafür müssen die Versionsnummern passen. Die Wallboxfirmware prüft periodisch ob die passende EVSE-Firmware läuft und flasht selber neu, falls sie nicht passt.

- Oder du baust eine neue Wallbox-Firmware, bei der du deine EVSE-Firmware einbettest. Dazu musst du sie (mit passendem Dateinamen) in den esp32-firmware/software/src/modules/evse_v2-Ordner packen.

Hier die Testfirmware. Damit sollte das schnelle Hin-und-Herschalten bei deinem spezifischen Schützfehler behoben sein (falls du das nochmal erzeugt bekommst). Außerdem sollte das PWM jetzt genauer sein, d.h. dein Auto hoffentlich jetzt wirklich mit 16 Ampere laden.

Edit: Veraltete Firmware entfernt.

1 hour ago, Home_Charger said:

besteht dennoch eine Möglichkeit den Unbekannten Benutzer umzubenennen?

Das könnte man relativ einfach implementieren.

1 hour ago, Home_Charger said:

Quasi ein "Standard Fahrzeug" festzulegen? Ich stelle es mir so vor, dass wenn kein NFC Tag vorgehalten wird ist es immer Auto A, wenn ein Tag vorgehalten wird, ist es das mit dem Tag verknüpfte Fahrzeug. 

Das wiederum ist kompliziert. Wenn du kein Tag vorzeigst startet die Ladung nicht, wenn die Benutzersteuerung aktiv ist. Wenn sie nicht aktiv ist, wird der Ladestart sofort aufgezeichnet (und dem unbekannten Nutzer zugeordnet). Das würde ich auch nur ungern ändern, weil das auf maximale Robustheit ausgelegt ist, damit möglichst nie Ladevorgänge verloren gehen.

Prinzipiell ist es so, dass wenn du bestimmten Nutzern Ladevorgänge zuordnen willst, du die Benutzerfreigabe aktivieren musst. Ab dem Punkt können aber keine Ladevorgänge mehr auf den unbekannten Nutzer laufen, d.h. es muss immer ein Tag an die Wallbox gehalten werden. Was du dann machen kannst wäre einen zweiten Nutzer anzulegen für das Standardfahrzeug und dessen NFC-Tag z.B. neben die Wallbox zu legen. Wenn du dann das spezielle Fahrzeug mit eigenem Tag laden willst, hältst du statt dem Standard-Tag entsprechend das andere an die Wallbox.

Wenn du ein bisschen programmieren kannst, könntest du dir auch z.B. ein Python-Script schreiben, das über die API prüft, ob ein Fahrzeug angeschlossen ist und wenn z.B. 5 Minuten lang kein Ladevorgang per Tag gestartet wurde, kannst du über die API den Ladevorgang starten.

1 hour ago, Home_Charger said:

BTW: Funktioniert die "Benutzersteuerung" auch ohne das ich die Anmeldung zwanghaft aktiviere? 

Ja das ist komplett getrennt voneinander. Es ist geplant, dass man künftig wenn die Anmeldung aktiviert ist auch über das Webinterface einen Ladevorgang als der entsprechende Benutzer starten kann. Das ist aber noch nicht implementiert.

Das klingt soweit sinnvoll.

1 hour ago, Little_Company said:

Gibt es vielleicht auch einen persönlichen / nicht öffentlichen Chat Kanal um die Informationen auszutauschen?

Du kannst mir eine PM schreiben, oder eine Mail an info@tinkerforge.com (mit z.B. einen Link auf den Thread).

Es wird aber noch etwas dauern, bis die OCPP-Implementierung steht, da kann ich auch gerne einfach hier nochmal bescheid sagen.