rtrbt

Dem ESP ist egal an welchen Port du RS485, NFC und EVSE Bricklet anschließt ;) Die Software unterstützt beide. Das Issue (https://github.com/Tinkerforge/esp32-firmware/issues/134 ) dafür ist noch offen, weil die Detektion, ob ein Zähler vorhanden ist, nicht so robust ist wie ich das gerne hätte. Ich räume das mal kurz auf. Edit: jetzt hier: https://github.com/Tinkerforge/esp32-firmware/issues/160 Ist notiert. https://github.com/Tinkerforge/esp32-firmware/issues/159

Gute Idee! https://github.com/Tinkerforge/esp32-firmware/issues/158 Das klingt seltsam. Bekommst du aus den EVCC-Logs raus welche Ladeströme gesetzt werden? 1A ist nur der Default-"Sprung", 3 Nachkommastellen sind erlaubt. Noch ein Gedanke: Hast du Auto-Start wieder aktiviert? Sonst kommt EVCC vermutlich durcheinander. (Auto-Start ist unabhängig von der externen Steuerung)

Das funktioniert soweit, wenn du den Ioniq nicht erst nach 22 Uhr anschließt. Das start_charging würde in dem Fall nicht funktionieren, weil es ignoriert wird, wenn kein Auto angeschlossen ist. Du kannst aber folgendes machen: 22:00 curl -X PUT -d 32000 http://warp2.fritz.box/evse/external_current_update 06:00 curl -X PUT -d 0 http://warp2.fritz.box/evse/external_current_update (musst dann aber die externe Steuerung im Webinterface unter Ladecontroller aktivieren).

Moin, Für OCPP kommt hoffentlich heute noch (spätestens morgen, muss zwei Wochen Forum usw. aufholen) eine erste Test-Version. Hatte es vor meinem Urlaub nicht mehr geschafft. Grüße, Erik

Klappt es mit der Firmware aus diesem Post? Dann ist es wirklich ein Genauigkeitsproblem beim PWM-Signal. Je nachdem wie das Auto (was ist das btw für eins?) das PWM misst könnte diese Firmware helfen.

Das ist leider etwas kompliziert: Die Ladezeit auf der Statusseite berechnen wir über den aktuellen Zeitpunkt (seit Start der Wallbox) und benutzen die echte Zeit deines Browsers. Für den Ladetracker braucht die Wallbox selbst die aktuelle Zeit, die sie sich per NTP, also Netzwerkzeitsynchronisierung besorgt. Dafür braucht die Wallbox die Möglichkeit, einen Zeitserver zu erreichen. Passen eventuell die Netzwerkeinstellungen nicht? (z.B.: statische IPs aber kein DNS-Server eingetragen) Falls du die Wallbox nicht ins Internet lassen willst, aber z.B. eine Fritzbox als Router in deinem Heimnetz hast, kannst du die IP der Fritzbox (typischerweise 192.168.178.1 ) als Zeitserver eintragen. Künftig wird das auch komplett ohne Netzwerk gehen, wenn du ein Real-Time-Clock-Bricklet einbaust: https://github.com/Tinkerforge/esp32-firmware/issues/26 Das ist aber noch nicht implementiert.

Vermutlich war Teil des Problems, dass du (zmdst laut dem debug-report) Auto-Start deaktiviert hattest. Das hat nichts mit der externen Steuerung zutun, sondern ist nur dafür da, dass du selbst per API oder Webinterface den Ladevorgang freigeben kannst.

Du brauchst, damit der Zähler von der WARP 1 ausgelesen werden kann noch ein RS485 Bricklet: https://www.tinkerforge.com/de/shop/rs485-bricklet.html und, damit du ihn sinnvoll einbauen kannst, den Berührschutz mit dem entsprechenden Ausschnitt. (Der Klemmenblock ist nicht so hoch wie der Zähler, deshalb ist da kein Loch bei der Smart) Dafür müsstest du eine Mail an info@tinkerforge.com schicken, am besten mit einem Hinweis auf den Foren-Thread hier wegen Kontext. Für NFC brauchst du das Bricklet und das 15cm-Kabel, das ist korrekt. Da werde ich dich nicht von abhalten ;)

Nope, you have to pass a buffer with enough space for 256(!) entries. The station IDs are collected in this buffer and the Bricklet can detect up to 256 stations. Theoretically you cound call tf_outdoor_weather_get_station_identifiers(&this->ow, nullptr, &station_nb); first to get the number of stations and then creating a buffer that is large enough, for example with uint8_t *stations_id = (uint8_t*) malloc(stations_nb * sizeof(uint8_t)); However this is dangerous, as the Bricklet could receive another new station after the call to get the number of stations, but before the second call to get the station IDs. So don't do this!

Yeah, the MQTT bindings map 1:1 to the Bricklet API, so they are more complicated to use. tag_type, id and last_seen are the response values, you only have to pass the index. For example if you put a tag on the bricklet and then send (Remember to switch to simple mode before doing this) you should get a response like this: This looks okay. What errors are you getting? Those are examples showing how to use the API?

Wenn du auf Ethernet verzichten kannst, ist es vermutlich sinnvoll, nur NFC und Stromzähler nachzurüsten. Wenn du von v1 auf v2 aufrüsten willst, musst du im Endeffekt alles außer Gehäuse, Schütz und Typ-2-Kabel wechseln. Das kannst du anhand der Ersatzteile https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts.html durchrechnen, ich komme auf grob 450€ bzw. 650€ wenn du gleich auf Pro wechseln willst. Du kannst natürlich erstmal NFC und Zähler nachrüsten und wenn du später beschließt doch Ethernet bzw. den neueren Ladecontroller haben zu wollen, kannst du den Rest immer noch nachkaufen ;)

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.