Laden über http API ohne Freigabe nfc

[smoudo]

Hallo Community,

 

ich habe die Tage auf die Firmware 2.0.7 geupdatet nachdem ich mit der bisherigen Software 1.1.2 sporadische freezes der wallbox hatte.

 

Ich lade mein Fahrzeug (T7 PHEV) entweder über nfc freigabe direkt an der box oder

per freigabe über fhem wenn ich PV Überschuss habe direkt über setzen der register "current 6000" und "start_charging"

Das hatte bislang supder funktioniert.

 

Mit der neuen Firmware kann ich nur nach freigabe mit dem nfc + des Webinterface laden. Im Ladecontroller zeigt es immer an Benutzer:Blockiert.

Soweit klar, aber wie kann ich wenn ich die box über http anspreche den Benutzer mitgeben das dieser freigibt?

Das Webinterface ist frei zugänglich ohne user abfrage.

Wenn ich den haken bei "benutzerautorisierung" raus nehme lädt es sofort. Dann gibt es aber auch keine nfc abfrage mehr.

Ich werde aus der Benutzerfunktion/Autentification nicht so recht schlau.

 

Ich hoffe mir kann jemand helfen

 

Viele Grüße

 

Matze

 

[rtrbt]

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.

[smoudo]

finde ich im gegensatz zur 1.1.2 zu komplex. Da müsste eine Funktion für gebaut werden. Umgekehrt startet die box auch nicht direkt eine ladung wenn auto gesteckt + nfc aktiv. In dem moment muss per web nochmal gestartet werden. Ist für uns nicht praktikabel und programmtechnisch zu kompliziert. Zumal das in 1.1.2 schon komplett funktionell war.  Werde wieder auf die alte Version zurückgehen. Das entspricht eher meinen Anforderungen.

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

[rtrbt]

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.

[smoudo]

vielen Dank für die schnelle und sehr ausführliche Antwort.

 

vor 56 Minuten schrieb rtrbt:

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

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.

 

Das mit dem vorkonfigurieren und maximalen Ladestrom muss ich gestehen ist eine gute Geschichte um das mit Boardmitteln zu lösen. Hatte ich so vom hintergrund nicht verstanden, ist jetzt klar.

 

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.

Unschlüssig bzw. im Test bin ich noch wie praktikabel es ist den Ladevorgang abzubrechen und bei Überschuss wieder zu starten. Das wird im Herbst/Winter eher nicht funktionieren, weshalb ich das noch als Schalter einbauen werde.

 

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?

bearbeitet August 2, 2022 at 15:27 von smoudo

[rtrbt]

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.