rtrbt

Kein Problem. Hattest du da nicht den Wechsel von einer WARP1 auf eine WARP2 dazwischen? Das wäre ja schon eine Hardware-Änderung. Wird der U5 OTA-aktualisiert? Vielleicht hat sich da ja etwas geändert. Wobei einfach sporadisch den Ladevorgang zu beenden schon eher seltsam ist. Gibt es bei WARP2, ist aber noch nicht dokumentiert. Du kannst eine 0 an evse/control_pilot_configuration_update schicken, dann wird das Kabel "getrennt", wenn du eine 2 schickst wird es wieder verbunden. Den aktuellen Zustand kannst du über evse/control_pilot_configuration abfragen. Das ist nicht persistent, also wenn du den Ladecontroller neustartest (z.B. indem du die Wallbox kurz vom Strom trennst), sollte alles wieder funktionieren.

NULL is the marker that no handler is registered, so yes, you have to register an empty handler in order for the bindings to run the callback payload reassembly (i.e. the low level stuff ;) ) You can pass NULL as user data. This is dangerous: If your post processing takes too long, the next spectrum can already be transmitted. So this would either block the bricklet (if you do this in the thread/task that you run the tick/other bindings functions in) or (if this runs concurrently) the spectrum data is overwritten while you post process it. The safe way to do this is to either run the post processing in the callback handler or use memcpy etc. to pull the data out. Basically the callback handler signals that it is now safe to access the passed in buffer and if you leave the callback handler, the bindings assume that they are allowed to continue using the buffer as necessary. Another thought: If you are only interested in some of the spectrum data, for example the highest peaks, you can use the low_level callback directly and then don't have to allocate a potentially big buffer. (This is especially helpful if one wants to use the bindings on the more limited platforms such as ATMega microcontrollers). Of course you then would have to use the low level chunk variables to determine in what bin you currently are, etc.

Im Debug-Log sehe ich, dass die Wallbox permanent die Netzwerk-Verbindung verliert und wieder aufbauen kann, ungefähr alle halbe Sekunde. Steckt eventuell das Ethernet-Kabel nicht richtig bzw. hat die Kabeldurchführung einen Schuss? Das kannst du testen, indem du das Kabel testweise direkt an den Ethernet-Port in der Box anschließt. Dazu müsstest du die Box einmal aufschrauben wie in der Anleitung beschrieben.

Ah this is a bug in the microcontroller bindings documentation. It looks like high-level callbacks are not documented yet, but you can actually register the high-level callback with int tf_sound_pressure_level_register_spectrum_callback(TF_SoundPressureLevel *sound_pressure_level, TF_SoundPressureLevel_SpectrumHandler handler, uint16_t *spectrum_buffer, void *user_data) In contrast to the "normal" C/C++ bindings, you have to pass a buffer as the spectrum parameter that is big enough to hold one complete spectrum (so the required size depends on what you've passed to set_configuration) This buffer is used to accumulate the spectrum values (basically the same way as get_spectrum() works internally).

Moin, Wenn die Benutzerautorisierung aktiv ist, dann muss jede Ladung einem Benutzer zugeordnet werden. Stand jetzt geht das entweder über NFC direkt, oder du kannst über die API so tun, als ob ein Tag an die Box gehalten wurde. Sieh dir mal die Funktionen https://www.warp-charger.com/api.html#nfc_inject_tag usw. an.

There is a tutorial available here: https://www.openhab.org/addons/transformations/jsonpath/

The topics are not expanded for single values. So you have to use (for example) a JSON PATH transformation to extract the values out of the .../all_values Topic The UID of the Bricklet is part of the topic name.

The problem is that the MQTT examples are only descriptions what to do with your specific MQTT client, they are not written in the syntax used by init files. Basically you have to translate the content of tf_mqtt.txt to a valid init file as described here:https://www.tinkerforge.com/en/doc/Software/API_Bindings_MQTT.html#loading-initial-messages-from-a-file In your case this would look like this: { "pre_connect": { "tinkerforge/register/air_quality_bricklet/XYZ/all_values": {"register": true} }, "post_connect": { "tinkerforge/request/air_quality_bricklet/X3s/set_all_values_callback_configuration": {"period": 1000, "value_has_to_change": false} } } You still have to replace XYZ with your bricklet's UID here. By the way: This should not be necessary if you've installed the bindings via apt.

Die mit _merged ist die richtige. Ich suche mir mal eine passende Stelle in der Dokumentation um das hinzuzufügen.

evcc fragt nicht über die WARP ab, sondern benutzt die Cloud des Fahrzeug-Herstellers, so es eine gibt. Das geht komplett an der Wallbox vorbei.

Sollte die hier sein:https://www.tinkerforge.com/de/doc/Software/ESP32_Firmware.html Ersteres. warp2-2.0.1 war das letzte Tag, das bei uns gesetzt war als @mattsches das Repo geforkt hat. D.h. da sind die ganzen Änderungen noch nicht drin. Seine Kopie zieht dann standardmäßig nicht neue Tags nach. Funktionieren sollte also 1. Wechseln auf den phase_switcher Branch 2. Code 3. Download zip (oder einfach dieser Link hier: https://github.com/mattsches1/esp32-firmware/archive/refs/heads/phase_switcher.zip ) Das sollte okay sein, die Ordner gibt es wirklich nicht, brauchts aber auch nicht.

Nein die Bibliotheken musst du nicht selbst bauen. Die Anleitung im lib_builder-Ordner ist eher kurz weil das eher eine Erinnerungsstütze für mich ist. Eigentlich sollte pio -e prepare wie gehabt die Bibliotheken runterladen und nach esp32-firmware/software/packages packen (wo sie bei dir auch schon liegen sollten?). Der einzige Unterschied ist jetzt, dass davor platformio eine Kopie der jeweiligen Unterordner (also z.B. esp32-firmware/software/packages/arduino-esp32-warp2-2.0.2 gezogen hat und jetzt diese per Symlink reinzieht. Das spart etwas Platz und führt vorallem dazu, dass man Dinge ändern kann und die sofort in die Firmware kompiliert werden ohne Verrenkungen.

Offiziellen Support gibt es nicht. Du brauchst zwingend die Firmware-Modifikation, damit die drei Schütze geschaltet werden, den Code übernehmen wir aber nicht -> Du brauchst die Firmware mit den Änderungen von mattsches, die er (oder irgendjemand anderes, ist ja alles open source) zumindest gegen die jeweils aktuelle Version einmal kompilieren muss und gegebenenfalls anpassen, falls wir die Interna verändert haben. Wir helfen natürlich, wenn es da Fragen gibt, aber sozusagen ohne Erfolgsgarantie.

Du kannst (wenn du das nicht in der brickd.conf umkonfiguriert hast) von anderen Rechnern aus auf einen Brick Daemon zugreifen. D.h. funktioniert einfach, wenn du in deiner Software "localhost" auf die IP oder den Hostnamen des anderen Rechners änderst, an dem alle Bricks angeschlossen sind. (auf dem anderen Rechner muss natürlich auch Brick Daemon installiert sein) Alternativ kannst du WiFi- oder Ethernet-Extensions benutzen oder alle Stapel mit RS485-Extensions zusammenschalten.

Hm da habe ich gleich was gelernt, danke :) https://httpwg.org/specs/rfc7230.html#header.content-length sagt Der Ladetracker benutzt Transfer-Encoding: Chunked damit der ESP nicht das ganze Ladelog gleichzeitig im RAM halten muss. Die Content-Length wird gesetzt, für den Fall dass das Log groß ist und die Netzwerk-Verbindung langsam. Dann kann der Download ein paar Sekunden dauern. Zumindest die Browser verstehen das und man bekommt eine sinnvolle Fortschrittsanzeige. Da jetzt aber der Normalfall ist, dass man das Ladelog über das Webinterface runterlädt, dass die Binärdatei in Javascript noch in eine CSV umbaut, sieht man sowieso die Browser-Fortschrittsanzeige nicht. D.h. ich nehme das Setzen der Content-Length einfach raus, dann müsste es in Node-Red mit der nächsten Firmware auch funktionieren: https://github.com/Tinkerforge/esp32-firmware/commit/4b21a005257d08c44ac553315b744aff5da9532f

Zumindest den Teil dass du per MQTT die Stromzählerwerte setzen kannst haben wir schon: https://www.warp-charger.com/api.html?v=2#meter_state_update (und die Funktionen danach) Den Software-Support für den Umbau auf drei Schütze, die dann nicht direkt vom EVSE gesteuert werden, werden wir nicht übernehmen. @mattsches weil ich gerade nochmal über den Code gescrollt bin: Du solltest hier: sicherheitshalber https://www.tinkerforge.com/en/doc/Software/Bricklets/IndustrialQuadRelayV2_Bricklet_uC.html#c.tf_industrial_quad_relay_v2_set_monoflop statt set_value verwenden, zumindest für die Channels bei denen du das Schütz durchschaltest. Das hat den Vorteil, dass falls der ESP aus irgendeinem Grund abschmiert oder hängt, das Quad Relay abschaltet, wenn der Monoflop abgelaufen ist.

Genau.

Habe mal den Hardware-Entwickler gefragt, das Netzteil, dass die 12V für den Ladecontroller macht, funktioniert bis auf 85V runter, d.h. das sollte es nicht sein. Nur wenn du Lastmanagement machst. Genau, dann würde die Wallbox das als 2,7k interpretieren, dementsprechend das Schütz abschalten und auf State 2 gehen.

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

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). 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. Das wäre prinzipiell möglich, würde ich aber nicht mitten beim Laden erwarten. Wäre trotzdem interessant, wenn du das mal loggst. Das ist absichtlich darauf ausgelegt, dass man theoretisch ohne Digitaltechnik auskommt, siehe auch hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung 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. 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?

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. 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.

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? 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.