rtrbt

For that you have to "translate" the MQTT examples in the same format as the Air Quality Bricklet requests.

Jeder Punkt auf dem Graph ist ein Mittelwert über ~ 4 Minuten. Da der Ladevorgang da gerade gestartet ist, wäre es also möglich, dass das noch Datenpunkte sind, wo der "Vollausschlag" nicht erreicht war. Falls sich das nach ein paar Minuten aber nicht behoben hat, muss ich dem nochmal nachgehen. Bist du auf der aktuellen WARP1 Firmware 2.0.6? Nicht dass wir alte Bugs jagen.

Wenn ich https://de.wikipedia.org/wiki/IEC_62196#Mode_2 richtig interpretiere, wird bei Mode 2 der Widerstandswert komplett ignoriert, d.h. das Auto kann nicht signalisieren, dass es keinen Strom mehr möchte. Es muss aber natürlich keinen Strom ziehen, was aber bei Mode 3 genauso funktioniert. Das würde bedeuten, dass das Auto bei Mode 2 irgendwann beschließt eine Ladepause einzulegen und kurze Zeit später wieder anfängt zu laden, bei Mode 3 das selbe machen will, aber dann "vergisst" wieder die 880 Ohm anzulegen? Das würde nicht erklären, warum es an anderen AC-Säulen geht und bei WARP2 nicht. Laut der Commit-Historie des Ladecontrollers haben wir vom 27.10.2021 bis 07.06.2022 (da müssten auch kurz danach jeweils Firmware-Releases erfolgt sein) nichts geändert, was den Effekt direkt auslösen könnte. Es gab zwischenzeitlich (im März) noch die große Änderung für die Ladeslots, das sollte aber keine Auswirkung auf das Ladeverhalten an sich haben (sondern nur steuern wann geladen werden darf, lies: wann Zustandsübergänge von 0/1 nach 2 erlaubt sind). Eventuell haben wir uns da noch einen Bug eingetreten, aber ich wüsste spontan nicht, wie bzw. wo. Prinzipiell ist fast alles was wir am Ladeverhalten ändern nur in die Richtung, dass VWs besser laden können. Die sind in Kombination mit der Art wie wir bei WARP1 messen etwas schwierig, weshalb wir an z.B. diversen Stellen die Timing-Anforderungen etwas entspannen. Da sollte sich nichts geändert haben. Der übliche Weg um schlafende Autos bzw. Ladeelektroniken zu wecken ist die CP-Unterbrechung, also das was du über evse/control_pilot_configuration_update steuern kannst. Bei WARP1 gab es keine Hardware, die die CP-Unterbrechung direkt machen kann, bei WARP2 haben wir ein Relais dafür verbaut, das wird aber noch nicht verwendet (ist also immer verbunden), wenn du nicht die evse/control_pilot_configuration-API von Hand benutzt. Wir haben vor das irgendwann zu implementieren, bisher hat aber noch kein Fahrzeug, bei dem das Problem der einschlafenden Ladeelektronik, die man so wieder wecken muss, seinen Weg zu uns gefunden. Selbst die eCorsas die zwei meiner Kollegen jetzt fahren, scheinen das Problem nicht (mehr?) zu haben. Scheinbar patchen die Autohersteller das raus. Würde ich erstmal auch so sehen, ja. Langer Rede kurzer Sinn: Wenn du das nächste Mal lädst und die Ladung abbricht, versuch mal eine CP-Unterbrechung auszulösen.

I'm assuming that $.temperature should work as JSONPath expression. You basically have to teach openHAB which keys to follow and $ is the root-node.

Das hat die Komplexität, die es braucht, damit sinnvoll Ladevorgänge aufgezeichnet werden können. Dazu hatten wir im 2.0.0-Blogpost auch was geschrieben: https://www.tinkerforge.com/de/blog/new-features-and-changes-in-warp2-firmware-200/ Das würde auch wenig Sinn ergeben. Dann kann man NFC gleich deaktivieren. Wenn du ein separates Tag (das muss keine echte ID haben, 00:11:22:33 o.Ä. geht auch) mit einem Maximalstrom von 6A konfigurierst musst du sogar weniger in FHEM machen als in der alten Variante: Davor musstest du 6000 an evse/max_charging_current_update und null an evse/start_charging schicken, jetzt dann nur noch Tag-ID und -Typ an nfc/inject_tag. Das ist nur ein API-Aufruf statt wie davor zwei. Ja künftig kannst du wenn der Webinterface-Login aktiviert ist, über das Webinterface eine Ladung starten, die dann dem User, der angemeldet ist, zugeordnet wird. Das ist aber noch nicht implementiert.

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