rtrbt

Die NFC-Aufkleber sind kompatibel. Prinzipiell kannst du jedes Tag benutzen, dass NFC-Forum-Typ 1 bis 4 ist. (Die Aufkleber sind Typ 2)

Die Meldung kannst du ignorieren. Die wird manchmal erzeugt, wenn man den Browser-Tab mit dem Webinterface schließt und die Wallbox Pech mit dem Timing hat. Kritisch wirds nur, wenn die Meldung dauerhaft und sehr hochfrequent (lies: mehrfach pro Sekunde) auftaucht. Leider gibt es derzeit keine Möglichkeit Debug-Meldungen zu erzeugen, die dann im Debug-Report, aber nicht im "normalen" Ereignis-Log auftauchen. Damit wäre die Ansicht für dich als Nutzer übersichtlicher. Habe dafür mal ein Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/155

Moin Chris, Das würde anderen Benutzern der button_press_time möglicherweise die Skripte brechen. Außerdem würde ich den Button in seiner Reinform (händisch button_press_time zu benutzen ergibt ja nur Sinn, wenn der Ladecontroller nichts anderes bei Knopfdruck tut) nicht wieder an das restliche Verhalten des Ladecontrollers koppeln wollen. Im Moment kann man ja beliebige Dinge mit dem Button machen. Für deinen Use-Case müsstest du neben dem Reagieren auf Änderungen der button_press_time nur nachsehen, ob der iec_state != 0 ist, oder übersehe ich da etwas?

Du solltest, wenn du in channel_request[channel] ein false hast eher mit set_value das Relay dauerhaft auf offen setzen. Monoflops funktionieren in beide Richtungen, d.h. wenn du tf_industrial_quad_relay_v2_set_monoflop(...0, false, 1000) aufrufst dann wird (egal was der aktuelle Zustand ist!) Channel 0 eine Sekunde öffnen und danach wieder schließen. Du hast also _immer_ einen Zustandsübergang am Ende des Monoflops, egal ob es am Anfang einen gab.

For the NFC Bricklet it's way easier to use the simple mode, as you don't have to implement a state machine to use it: "tinkerforge/request/nfc_bricklet/Y2U/set_mode": {"mode: "simple"} Unfortunately there is no callback for the simple mode, so you have to periodically send {"index": 0} to the topic tinkerforge/request/nfc_bricklet/Y2U/simple_get_tag_id You can't set a period for the motion_detected callback. Also the registration topic is "tinkerforge/register/motion_detector_v2_bricklet/MPc/motion_detected": {"register": true} (as is documented)

Sure, As per https://www.tinkerforge.com/en/doc/Software/API_Bindings_Go.html#from-source and https://go.dev/doc/gopath_code there should be a directory named "go" in your home directory (so /home/[your_username], C:\Users\[your_username], or similar). In the zip there is a github.com directory. Put this directory into .../go/src/ so that afterwards you have .../go/src/github.com/Tinkerforge/... If is already a github.com directory in ../go/src (as you've already got an older version of the bindings installed), you can either remove .../go/src/github.com/Tinkerforge/ or overwrite all files when extracting the zip.

Da haben wir aneinander vorbei geredet. Ich meinte es ergibt keinen Sinn, dass das Auto sofort startet, wenn NFC aktiv ist und du nicht den Ladevorgang per Tag freigibst, sorry. D.h. du brauchst folgendes: Ladestart wenn X Überschuss vorhanden ist oder ein NFC-Tag gesehen wurde Ladestrom bei Überschuss dynamisch, bei NFC-Tag fest Das ist in der Tat der eine Anwendungsfall, der durch die neue API seit 2.0.0 etwas verkompliziert wird. Die grundlegende Annahme die wir da treffen ist, dass alle Möglichkeiten die Box zu limitieren/blockieren unabhängig voneinander sind. Du willst jetzt aber das Limit des Überschussstroms per NFC überschreiben. Das kannst du z.B. so bauen, dass du zwei NFC-Tags anlernst (eins davon muss kein echtes sein, sondern nur eins, dass du per nfc/inject_tag verwendest), dem echten Tag einen Benutzer zuordnest, der den "normalen" Ladestrom bekommt und dem Fake-Tag einen Benutzer zuordnest, der 32 A als Maximalstrom bekommt. Per FHEM musst du dann nachsehen, wer gerade versucht zu laden (z.B. mit https://www.warp-charger.com/api.html#charge_tracker_current_charge) und, falls es das "echte" NFC-Tag ist, setzt du den Ladestrom auf den gewünschten, falls es das nicht ist, setzt du ihn auf den aktuellen Überschuss (das kannst du auch machen wenn gerade keine Ladung läuft, da der Ladevorgang erst beginnt wenn du ein Tag an die Box hältst) Anstatt dass du dir die Überschusssteuerung selbst baust könnte es eventuell einfacher sein, wenn du EVCC verwendest: https://evcc.io/ Dann musst du den Überschussstrom nicht manuell per FHEM an die Box schicken. Das kannst du prinzipiell auch machen: https://www.warp-charger.com/api.html#reboot Ich würde das aber als Bug betrachten, dem wir gerne nachgehen können. Dazu musst du aber definitiv auf die aktuelle Firmware updaten. Es ergibt keinen Sinn potenziell schon gefixte Bugs zu jagen.

Looks like this is a bug in the streaming implementation of the go bindings. Does it work with the attached version of the bindings? tinkerforge_go_bindings_2_0_13_beta_1.zip

Ja, das ist genau die Geschichte mit den 2700 bzw. 880 Ohm, die wir messen.

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.