rtrbt

Moin Chris,

10 hours ago, chris_kmn said:

Wäre das möglich, oder kollidiert das mit anderen Funktionalitäten ?

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

3 hours ago, Pat28 said:

  "tinkerforge/register/motion_detector_v2_bricklet/MPc/get_motion_detected": {"register": true},
    "tinkerforge/request/motion_detector_v2_bricklet/MPc/motion_detected": {"period": 2000}

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.

On 8/2/2022 at 5:21 PM, smoudo said:

das sehe ich nicht so. Wenn ich Nachhause komme und den Stecker ins Auto stecke, dann mit dem NFC einen Ladevorgang freigebe hat der für mein Verständnis sofort loszulegen und nicht erst auf Freigabe von FHEM zu warten.

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.

On 8/2/2022 at 5:21 PM, smoudo said:

Bei uns ist es so, das wenn ich das Auto anstecke und nicht mit NFC freigebe, soll das Laden erst beginnen wenn genug PV Überschuss da ist (1500W Überschuss). Dann gehen wir mit current 6000 und start_charging los. Bei weiterem Überschuss >500W wird current solange im 10 sec takt erhöht bis entweder kein Überschuss mehr da ist oder Max 16000 erreicht ist. Falls weniger Überschuss kommt wird current dementsprechend im 10 sec. takt reduziert.

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.

On 8/2/2022 at 5:21 PM, smoudo said:

Ich habe das ganze jetzt wieder auf 1.1.2 zurückgepatched. Das eigentliche Problem das ich hatte, ist das die box von zeit zu zeit nicht mehr erreichbar war. (uptime >30Tage). Leider nicht so recht reproduzierbar warum. Bei anderen ESP gestützten Systemen die ich laufen habe mache ich einen nächtlichen reboot. Seitdem gibt es dort ähnliche Probleme nicht mehr. Wie schaut es beim warp charger aus? gibt es da Erfahrungen diesbezüglich?

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

5 hours ago, Photon_1978 said:

Wird bei der WARP Spannung und Widerstand gemessen und bewertet?

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

20 hours ago, Pat28 said:

How do for example you can get the motion detection and nfc bricklet mqtt data in a mqtt.txt file?

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.

6 hours ago, Photon_1978 said:

Laut Wiki Ist der Ladeziegel laden nach "Mode 2", Wallbox laden nach "Mode 3". Ob das auch leicht unterschiedliche Verfahren beinhaltet hab ich nicht herausgefunden. Sollte aber eigentlich nicht.

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.

6 hours ago, Photon_1978 said:

Was ich meinte war die Warp 1 hat ja 2021 funktioniert und dann in 2022 irgenwann nicht mehr, also schon vor der Warp2. Deshalb die Frage ob und was könntet ihr geändert haben was diesen Effekt auslösen könnte?

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.

6 hours ago, Photon_1978 said:

Es gibt ja, wenn ich das richtig gelesen habe noch keine Funktion in der Warp die "schlafende" Auto wecken kann, bzw. noch Probleme damit? Vielleicht war dazu früher etwas in der Software was jetzt nicht mehr drin ist?

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.

6 hours ago, Photon_1978 said:

Wäre es das Auto müsste es dann nicht bei jeder AC - Lademöglichkeit so sein?

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.

17 hours ago, smoudo said:

finde ich im gegensatz zur 1.1.2 zu komplex

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/

17 hours ago, smoudo said:

Umgekehrt startet die box auch nicht direkt eine ladung wenn auto gesteckt + nfc aktiv.

Das würde auch wenig Sinn ergeben. Dann kann man NFC gleich deaktivieren.

17 hours ago, smoudo said:

Ist für uns nicht praktikabel und programmtechnisch zu kompliziert.

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.

17 hours ago, smoudo said:

Ist in der Hinsicht zukünftig etwas geplant das man hier nochmal differenzieren kann zwischen laden mit nfc oder direktladen per interface?

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.

6 hours ago, Photon_1978 said:

Sorry das es so lange dauert bis neue Infos von mir kommen, aber da wir nur einmal die Woche laden, kommen da leider schnell größere Zeiträume zusammen.

Kein Problem.

6 hours ago, Photon_1978 said:

Ich verstehe nicht warum es 2021 noch alles problemlos funktioniert hat. Hab Ihr in 2022 irgendwas geändert was das erklären könnte? Es muss was aus der Software sein. An der Hardware hat sich nichts geändert.

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.

6 hours ago, Photon_1978 said:

Gibt es eine Möglichkeit das An und Abstecken des Ladekabels softwareseitig zu simulieren? Immer in die Garage zu laufen ist nicht so schön.

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 ;) )

51 minutes ago, cl- said:

What if I don't have any user data that needs to be input into the callback handler?

You can pass NULL as user data.

51 minutes ago, cl- said:

I am currently postprocessing the spectrum data (getting the ten highest peaks, converting to db(A), etc.) outside the handler function and it works as expected.

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/

50 minutes ago, Pat28 said:

What are the topic names of the air quality bricklet?

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

51 minutes ago, Pat28 said:

Also if you have two or more air quality bricklets on the same broker, can you give every value a specific topic name so you know from witch bricklet for instance the temperature or humidity is coming from ?

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:

On 7/23/2022 at 10:49 AM, Pat28 said:

Copy the tinkerforge-mqtt fle to the /usr/local/bin folder on pi

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.

27 minutes ago, ThomKa said:

Du schreibst von einer Dokumentation. Stehe ein bisschen neben mir... Wo war die noch mal zu finden?

Sollte die hier sein:https://www.tinkerforge.com/de/doc/Software/ESP32_Firmware.html

25 minutes ago, ThomKa said:

Gehe ich über den Button "CODE" und lade dort die DOWNLAOD.ZIP   oder über   16 Tags und dann die warp-2.0.1 als ZIP?

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 )

23 minutes ago, ThomKa said:

Sorry, habe noch 2 Probleme übersehen. Muss damit noch irgendetwas geschehen?..?

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.

17 hours ago, Doncarlos said:

An dem Umbau wäre ich evtl auch interessiert, aber nur bei offiziellem Support.

Deine Aussage dazu sagt aber nur was ihr NICHT übernehmen wollt :-)

Ich würde ungern an der Box basteln und dann nachher keine Firmware Aktualisierung mehr bekommen

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.