E-t-h

Falls es von Interesse ist, bei mir waren nach dem letzten Update Warp2 die Einstellungen für WiFi , derUser und NFC weg. Im Log ist zu finden: 

2022-03-24 22:06:52,784      **** TINKERFORGE WARP2 CHARGER V1.9.93-6239e590 ****
2022-03-24 22:06:52,784           316K RAM SYSTEM   268248 HEAP BYTES FREE
2022-03-24 22:06:52,795  READY.
2022-03-24 22:06:52,860  Mounted data partition. 65536 of 3538944 bytes (1.9 %) used
2022-03-24 22:06:52,965  WARP2 Charger config version: 2.0.0
2022-03-24 22:06:52,966  ESP32 Ethernet Brick UID: X7s
2022-03-24 23:06:53,390  Set timezone to Europe/Berlin
2022-03-24 23:06:53,485  Failed to restore persistent config wifi_ap_config: String of maximum length 15 was expected, but got 19
2022-03-24 23:06:53,603  Had to configure soft AP IP address 1 times.
2022-03-24 23:06:53,603  Wifi soft AP started
2022-03-24 23:06:53,603      SSID: warp2-X7s
2022-03-24 23:06:53,943      MAC address: .....
2022-03-24 23:06:53,943      IP address: 10.0.0.1
2022-03-24 23:06:57,978  Ethernet started
2022-03-24 23:06:58,225  Found 1 records. First is 1, last is 1
2022-03-24 23:06:58,288  Last charge record size is 416 (416, 0)
2022-03-24 23:06:58,709  mDNS responder started
2022-03-24 23:06:58,770  Wifi connecting to xyz
2022-03-24 23:06:58,785  This is warp2-X7s (warp2-X7s), a WARP2 Charger Pro 22kW
2022-03-24 23:07:02,035  Wifi connected to xyz
2022-03-24 23:07:02,066  Wifi MAC address: ....
2022-03-24 23:07:02,068  Wifi got IP address: 192.168.xyz. Connected to BSSID ....
2022-03-24 23:07:02,134  MQTT: Connected to broker.
2022-03-24 23:07:04,478  httpd_ws_recv_frame failed to get frame len with 259
2022-03-25 09:45:28,615  NTP synchronized at 30,874!

Ein leerer User existierte noch, das (derzeit einzige) NFC-Tag war auch "leer". MQTT Einrichtung war noch vorhanden.

Ich komme nicht aus der Ladebranche, bin gerade auf die ISO 15118 gestossen, die das bidirektionale Laden zum Inhalt hat. Die kennt Ihr sicher? Die Jungs von EVCC geben in diesem Artikel auch etwas dazu zum Besten. Wisst Ihr wie die physikalisch Datenschnittstelle dazu aussehen soll?

vor 18 Stunden schrieb alestrix:

Schau Dir mal die Erklärung oben zu den einzelnen Ladegrenzen an. Der Slot mit Index 6 ist die Benutzer-Grenze, also die durch RFID gesetzte und 0A= blockiert, weil kein Tag rangehalten wurde.

Alles klar, Danke alestrix! Slot=Ladegrenze. Gibts irgendwo noch eine Übersicht welcher Slot was ist?

Nachtrag:

Sorry für die Frage, ich hätte selber drauf kommen können, steht ja alles in der esp32-firmware/software/src/modules/evse_v2/evse_v2.h. Für diejenigen die es vielleicht auch wissen wollen:
#define CHARGING_SLOT_INCOMING_CABLE 0
#define CHARGING_SLOT_OUTGOING_CABLE 1
#define CHARGING_SLOT_SHUTDOWN_INPUT 2
#define CHARGING_SLOT_GP_INPUT 3
#define CHARGING_SLOT_AUTOSTART_BUTTON 4
#define CHARGING_SLOT_GLOBAL 5
#define CHARGING_SLOT_USER 6
#define CHARGING_SLOT_CHARGE_MANAGER 7
#define CHARGING_SLOT_EXTERNAL 8

@rtrbt

Ich habe die Lösung 1 zu dem Thema mit den NFC-Tags zum Sofort-Start und dem nfc/inject_tag ausprobiert: funktioniert. Nun bin ich zufrieden (mal sehen wie lange ;-) ), Danke auf jeden Fall für Deine Hilfe! Werde das jetzt in meinem FHEM reinbasteln. Wenn jemand Interesse daran hat bitte melden.

Kleines Feedback meinerseits: Ich finde die Box gelungen und mit dem NFC und dem Aufzeichnen der Verbräuche und dem Lastmanagement nun auch für Firmenparkplätze gut geeignet. Und der Support hier ist a class of its own..

Am 16.3.2022 um 09:06 schrieb rtrbt:

D.h. das NFC-Tag ist nur das Signal für "Ich möchte jetzt laden, nicht erst heute Nacht"? Da fallen mir zwei Varianten zur Umsetzung ein. Variante 1:

• Auto-Start an, NFC-Tag angelernt und Nutzer zugeordnet, Ladung nur mit Nutzerfreigabe bzw. Tag
• Wenn du das Auto ansteckst und dann das Tag dranhältst, wird sofort geladen
• Wenn du kein Tag dranhältst kann deine MQTT-Steuerung Nachts nachsehen, ob 1. evse/state["charger_state"] == 1 und 2. evse/slots[6]["max_current"] == 0 ist. Das bedeutet, dass du in dem Zustand bist, dass die Box nicht lädt weil kein NFC-Tag gesehen wurde. In diesem Fall machst du ein nfc/inject_tag dann sollte der Ladevorgang beginnen und auf das entsprechende Tag getrackt werden.

Da ist noch etwas unschön, dass du evse/slots benutzen musst. Ich füge mal (allein der Vollständigkeit halber) noch ein Topic für den Strom der Benutzerfreigabe hinzu, das gibt es für die anderen Stromslots auch.

 

Hi,

danke für dies Tips. Ich verstehe ledier das Konzept mit den Slots noch nicht, habe auch nichts finden können. Hast Du mal was zum nachlesen?

Danke..

vor 22 Stunden schrieb rtrbt:

Das stimmt über den Ladestandard bekommen wir keine Fahrzeug-ID.

Du kannst https://www.warp-charger.com/api_beta.html#nfc_inject_tag benutzen um über MQTT eine Ladung auf einen bestimmten User zu starten. Schwierig ist dann in der Tat nur die Zuordnung dazu, welcher Benutzer das ist. Eine Idee dazu:

Deine MQTT-Steuerung hat bisher doch entschieden, ob Auto-Start an oder aus ist bzw. Auto-Start war immer aus und über MQTT kam früher oder später ein evse/start_charging-Aufruf. Das kannst du weiterhin so machen, also dass du Auto-Start ausschaltest und die ganze NFC-Tracking-Sache zusätzlich dazu benutzt. Du musst dann nur daran denken, wenn du das Auto ansteckst die entsprechende Karte dranzuhalten, wie bisher. Die Benutzerfreigabe bleibt dann erhalten bis das Auto abgezogen wird, deine MQTT-Steuerung kann also Stunden später erst start_charging aufrufen und das wird funktionieren.

 

Verstehe, bin aber nicht so glücklich damit. Kurz zum Szenario: Einfamilienhaus, Parlplatz vor Haus, von aussen zugänglich. Hybridwagen (=kleiner Akku). Wenn man tagsüber kurz unterwegs war soll schnell mal geladen werden. Das wurde bisher über den NFC gemacht. Wenn ich nicht mehr los will, soll das Fahrzeug nachts laden. Das NFC ist hier also eher ein verschlüsselter Taster (der richtige ist abgeschaltet) und erspart einem das gefummle auf den Telefon. Wichtig ist also: die Entscheidung ich will jetzt gleich laden oder das soll über Nacht passieren wird beim Anschliessen getroffen. Soll auch unbedingt geladen werden wenn man den Tag vergisst. Wenn keiner da ist (Urlaub) wird die Box deaktiviert.

Die Zuordnung zur Person ist hier sogar eher nachrangig, weil 2. Auto = 2. Box (wegen Load Balancing und ggf. späterer Eigenverbrauchssteuerung). Eine Box für Papi (der rechnet ab), eine für Mami. Wenn Gäste kommen gibts dafür einen eigenen Tag.

Aus meiner Sicht gäbe es hier nur 2 Möglichkeiten: Autostart am Nutzer oder Tag anbinden oder Authentifizierung beim Start über MQTT. Oder übersehe ich das was?

Ich hatte auch mal geschaut ob folgendes geht (Autostart = Ein): Wagen abstellen, zur Box, Tag ranhalten, Kabel stecken. Lädt nicht sofort. Musste erst Tag nochmal dranhalten. Ist das so gewollt? Man könnte vielleicht auch folgendes ralisieren: Auto abstellen, Tag an Box und Reinstecken: läd wann das System das entscheidet, oder Tag an Box + Taster drücken und Reinstecken : läd sofort.

Danke und viele Grüße!

So, ich will jetzt hier nicht so viel zitieren deswegen mal so:

Ich hatte die Probleme mit 1. "Früher gab es in der NFG Config die Möglichkeit, das einzuschalten:"

So wie Du das beschreibst (Autostart, NFC) geht das nun. Aber wie bekomme ich einen Ladevorgang per MQTT zur Nachtzeit gestartet? Das geht nun nicht mehr auf Grund der fehlenden Authentifizieung?

und 2.: "Gerade noch eine neue Beobachtung: zumindest das Topic iec61851_state wird nicht geupdated, ..."

Das kommte jetzt alles. Sieht also gut aus.

Wenn mir noch was auffält melde ich mich selbstredent. Nur das Thema mit dem MQTT-Start wäre mir noch wichtig. Vielleicht am User oder NFC-Tag die Berechtigung zu starten verankern, sodass es auch ohne Authentifizierung geht? Es ist ja ohnehin nicht klar, welches Fahrzeig beim nächtlichen Start am Kabel gehangen hat. Ich kenne jetzt den IEC61851 nicht, aber an eine Fahrzeug-ID wird man wohl nicht kommen., oder?

Danke & Viele Grüße!

Am 9.3.2022 um 09:21 schrieb rtrbt:

Fast übersehen, sorry:

Hast du nachdem du den User zugeordnet hattest die Wallbox neugestartet? Sonst werden die NFC- und User-Konfigurationen nicht angewandt. Wie verhält es sich denn? Kannst du mit der Konfiguration garnicht mehr laden oder wartet die Wallbox nicht auf ein NFC-Tag? Schick mir mal einen Debug-Report.

Hat etwas gedauert: Ich lade normalerweise duch einen Start per MQTT um Mitternacht. Das geht so noch. Das Starten per WEB Oberfläche geht auch. Autostart (wenn eingeschaltet) auch.

Parallel hatt ich mit einem NFC Chip sofort gestartet. Das klappte so auch. Nun nicht mehr. User habe ich angelegt, Tag zugeordnet, auch neu gestartet. Die Tags musste ich ja sowieso neu anlegen, waren nach dem Update alle weg. Das Neustarten kann man ja auch eigentlich nicht umgehen.

Halte ich das Tag an das NFC Modul blinkt er 3x kurz (soll wohl heissen akzeptiert). Es startet aber keine Ladung. Früher gab es in der NFG Config die Möglichkeit, das einzuschalten:

Das finde ich nicht mehr. Vielleicht liegt es daran?

Hier noch das Debugfile im Anhang.

debug-report-warp2-X7s-2022-03-13T12-09-47-709.txt

Gerade noch eine neue Beobachtung: zumindest das Topic iec61851_state wird nicht geupdated, wenn ich z.B. den Stecker am Fahrzeug ziehe (WEB Oberfläche state=A, MQTT =1). Ist dass das gleiche Problem was mit Beta 3 behoben sein soll?

Hi,

ich habe schon seit der 1. Beta den Eindruck, dass einige MQTT Werte nicht mehr regelmäßig gepusht werden. Ich habe 

/evse/state, 

/evse/energy_meter_values

/meter/detailed_values

abonniert. Darüber habe ich den aktuellen Ladestrom, Ladeleistung, Konnektierung (Vehicle_state) visualisiert. All diese Werte werden jetzt nicht mehr gepusht ( ich beobachte das mit dem MQTT-Explorer). Nur evse/low_level_state kommt kontinuierlich mit der neu einstellbaren Zeit. 

Zweites Problem: Das Starten einer Ladung mittels NFC-Tag scheint auch nicht zu klappen. Vielleicht mache ich was falsch: User anlegen, Tag anlegen (Mitfare Classic) und User zuordnen, Charge Controller/User Autorization einschalten, muss da noch was gemacht werden? Das Starten über die WEB-Oberfläche klappt. Auto ist jetzt voll, teste das morgen dann weiter.

Fall noch jemand das Problem hat, hier gibts Beispiele für beides:

https://forum.fhem.de/index.php/topic,123901.0.html

Am 16.4.2021 um 09:27 schrieb michael99:

Ja, das wäre doch erfreulich, denn was jede Sekune gesendet wird, belastet unnötig das Netz. Bei mird es auch noch von FHEM gespeichert.

Du kannst im FHEM unter DbLogInclude die Intervalle zum abspeichern einstellen (gehe davon aus dass Du in eine DB loggst).
Bsp.
attr GT_Warp_1 DbLogInclude energy_abs:3600,energy_rel:3600,vehicle_state:3600