rtrbt

Korrekt, die externe Steuerung kann zwar z.B. 28 Ampere vorgeben, aber wenn du in der GUI 12 Ampere eingestellt hast, dann ist das das Maximum. Wenn die externe Steuerung jetzt aber 10 Ampere vorgibt, dann wird auch nur mit 10 geladen. Eben immer das Minimum aus allen aktiven Ladegrenzen.

Also an Sonderzeichen liegt es vermutlich nicht: Ich habe hier einen Fritz Repeater 2400, habe bei dem versucht alle möglichen Sonderzeichen in das Passwort zu setzen und dabei gelernt, dass AVM nur bestimmte Zeichen erlaubt. Zitat aus der Online-Hilfe:

Quote

Zeichen für Kennwörter und Netzwerkschlüssel

Erlaubte Zeichen	Verbotene Zeichen
Buchstaben von a bis z in Groß- und Kleinschreibung Ziffern 0 bis 9 Leerzeichen Sonderzeichen _ - ! " # $ % & ' ( ) * + , . / : ; < = > ? @ [ \ ] ^ ` { | } ~	Buchstabe ß Umlaute ä, ö, ü (Kleinschreibung) und Ä, Ö, Ü (Großschreibung) Sonderzeichen € § ´

Ich habe dann alle aus der erlaubten Liste benutzt, das funktioniert mit WARP1 Beta 2 ohne Probleme.

Wenn du im Webinterface unter die Netzwerk->WLAN-Verbindung die Netzwerksuche ausführst, taucht den Netzwerk da auf?

14 hours ago, alestrix said:

Was hat es denn mit den verschiedenen Freigaben unter Ladecontroller -> Ladestromgrenzen auf sich?

Das ist noch nicht gut dokumentiert, funktioniert grundlegend aber wie folgt:

Es gibt pro Ladestromgrenze einen Strom und ein Flag das angibt, ob die Grenze aktiv ist. Der Ladecontroller berechnet dann das Minimum aus allen aktiven Grenzen und das ist der Strom mit dem geladen werden kann.

Intern ist es so, dass neben den üblichen Strömen von 6000mA bis 32000mA auch 0 gesetzt werden kann, das bedeutet, dass diese Grenze den Ladevorgang blockiert. Ein Beispiel dafür wäre, das wenn das Lastmangement aktiviert ist, immer 0 in der entsprechenden Grenze steht, bis der Lastmanager eine Ladung freigibt. Dann wird entsprechend die Grenze auf das gesetzt, was der Lastmanager vorgibt.

Da es einige Grenzen gibt, die nur binär auf entweder 0 mA oder 32000 mA gesetzt werden (auch bei 16 Ampere bzw. 11 kW Wallboxen, da limitieren die Ladestromgrenzen von Zuleitung und Typ-2-Kabel entsprechend), habe ich das so gebaut, dass statt 0 mA "blockiert" angezeigt wird und statt 32000 mA "freigegeben".

Die "freigeben"-Buttons rechts neben einigen Grenzen sind dafür da, die entsprechende Grenze komplett aufzuheben, also auf 32000 mA zu setzen.

Die Ladestromgrenze "Konfiguration" ist der Wert, den du auf der Statusseite einstellen kannst. Da ist es aber auf der Statusseite so, dass du maximal das Minimum aus Zuleitungs- und Typ-2-Kabel-Grenze setzen kannst (wir hatten schon Benutzer, die verwirrt hat, dass man seine seine 16 Ampere-Box auf z.B. 24 Ampere konfigurieren kann), ist der Knopf die einzige Möglichkeit die Grenze wieder komplett aufzuheben.

Bei der externen Steuerung kann es hilfreich sein, die Grenze aufzuheben, ohne die externe Steuerung ansich zu deaktivieren. Z.B. wenn du dir ein Script gehackt hast, dass zu bestimmten Tageszeiten das Laden verbietet, das Script aber gerade nicht läuft, aber die Grenze nicht freigegeben hatte. Dann kannst du, wenn du jetzt sofort laden willst, die Grenze aufheben (und damit ggfalls. eine Ladung freigeben die sonst blockiert wäre) und irgendwann später dein Script wieder starten und es funktioniert wieder alles.

14 hours ago, alestrix said:

Ich frage mich, wie sich die MEGA an die OCPP Schnittstelle anbinden will. Mit dem reinen Vorhandensein einer solchen Schnittstelle ist es ja nicht getan, es muss auch einen (gesicherten!) Kommunikationsweg dorthin geben.

Das ist in der Tat seltsam. Auch interessant ist, das eine 11kW-Wallbox bei denen schon Zustimmungspflichtig ist. Bei allen anderen Netzbetreibern die mir so untergekommen sind, liegt die Grenze immer bei > 11kW, nicht bei >= 11 kW.

1 hour ago, gintonicgamer said:

Ich habe jetzt die Warp1 Beta2 drauf, aber noch immer das Problem das ich keine WLAN Verbindung zu meinem Router hinbekomme. 

Das ist wirklich seltsam. Ich teste gleich mal ein Passwort mit allen Sonderzeichen die mir so einfallen durch. Weißt du zufällig noch welche Firmware du vor der Beta installiert hastest? Da hatte es ja funktioniert, oder?

Noch nicht, nein. OCPP wird auf jeden Fall kommen, aber bisher hatten andere Features Vorrang.

Bei welchem Netzbetreiber bist du? Wäre für uns auf jeden Fall interessant deren genauen Anforderungen zu sehen.

Ah, da ist die API-Dokumentation veraltet, das behebe ich gleich. Du musst in dem Fall (immer wenn du Daten zur Wallbox schickst und sei es nur null) HTTP PUT anstelle von POST o.Ä. als Method verwenden.

Edit: gefixt: https://www.warp-charger.com/api_beta.html

Support für POST und die anderen HTTP Methods kommt eventuell wieder, da wehrt sich leider die Webserver-Implementierung etwas: https://github.com/Tinkerforge/esp32-firmware/issues/39

EVCC unterstützt noch nicht die Firmware 2.0.0. Hier wird dran gearbeitet: https://github.com/evcc-io/evcc/pull/1700 Ich glaube aber, dass die Änderung damit EVCC mit einem geänderten MQTT-Sende-Intervall umgehen kann noch nicht im Pull-Request sind.

Die Ladevorgänge werden auch ohne Zähler getrackt, nur der Stromverbrauch fehlt dann. Z.B. so: (Das ist meine Entwicklungsbox deshalb waren das auch nur 6 Sekunden Ladezeit)

Die Smart hat leider keine Möglichkeit zu messen wie viel Strom gezogen wurde.

Je nachdem wie dringend du den Stromverbrauch messen möchtest kannst du den Zähler aber nachrüsten, Details dazu hier:

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.

Variante 2 ist dass du das ganze NFC- und User-System umgehst:

• Auto-Start aus, NFC-Tag kann angelernt sein, muss aber nicht, Ladung ohne Nutzerfreigabe bzw Tag erlaubt
• Deine MQTT-Steuerung sieht sich permanent evse/state["charger_state"] und nfc/seen_tags an. Wenn sich in seen_tags der oberste Eintrag ändert (also wenn die Tag-ID wechselt oder die last_seen-Zeit rückwärts springt) hat jemand ein Tag dran gehalten. Dann prüfst du ob die Tag-ID passt und falls ja schickst du evse/start_charging
• Wenn nachts ein Auto angeschlossen ist (charger_state == 1) schickst du auch evse/start_charging. Wenn du nachts charger_state == 2 siehst heißt das, dass du in dem oberen Fall warst, also per Tag gestartet wurde.

1 hour ago, E-t-h said:

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?

Das ist Absicht, ja. Die Benutzerfreigabe gilt immer nur für den "laufenden" Ladevorgang, der definiert ist als der Zeitraum zwischen dem Anstecken und dem Abziehen des Autos.

12 hours ago, E-t-h said:

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?

12 hours ago, E-t-h said:

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?

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.

Danke für die Rückmeldung! Die Änderung kommt dann in die nächste offizielle Firmware.

Hm, da war ein Typo in der relevanten Zeile. Teste mal diese Variante.

warp2_firmware_1_1_2_622f5066_merged.bin

Das sieht gut aus. Dann würde ich erwarten, dass es mit der Testfirmware funktioniert.

Firmware: WARP 1.9.91 (2.0.0 Beta 2) und WARP2 1.9.92 (2.0.0 Beta 3)

Details hier:

tl;dr: WARP1 Beta 2 bzw. WARP2 Beta 3. Viele Bugfixes.

Was gibt's neues?

Beta 2 (WARP1) bzw. 3 (WARP2) ist größtenteils ein Bugfix-Release. Es gibt aber zwei neue Mini-Features: Die Zeitzone ist jetzt einstellbar und Usernamen (zusätzlich zu Anzeigenamen) werden im Ladelog vermerkt.

Größere Bugfixes

• MQTT sollte wieder alle Nachrichten verschicken
• Es wird jetzt sichergestellt, dass Usernamen eindeutig sind
• Die Anmeldung im Webinterface kann nicht aktiviert werden wenn nicht mindestens ein Benutzer ein Passwort gesetzt hat

warp_firmware_1_9_91_622f4134_merged.bin warp2_firmware_1_9_92_622f4114_merged.bin

Moin,

Deine Mail hat es noch nicht zu mir geschafft. Ich frag gleich mal meine Kollegen. Zum Proxy-Problem:

Das klingt so, als ob die Websocket-Verbindung nicht aufgebaut werden kann. Über die Websockets bekommt das Webinterface den Zustand der Wallbox zugeschickt, unter anderem welche Module angezeigt werden sollen. Wenn das fehlt, sieht das Webinterface so kaputt aus wie du es gesehen hast.

Die Websocket-Verbindung musst du durch deine SSL-Proxy mit durchführen bzw von ws auf wss (das verhält sich genauso wie http zu https) umstellen. Bei nginx scheint das zum Beispiel so zu gehen: https://nginx.org/en/docs/http/websocket.html

Du kannst deine Konfiguration (unabhängig vom Webinterface) z.B. mit websocat testen: https://github.com/vi/websocat z.B. mit

websocat wss://url-zum-nginx.de/ws

sollte dann eine Verbindung aufgebaut werden und relativ viele JSON-Daten ankommen.

Damit das auch mit dem Webinterface funktioniert muss ich eventuell noch eine Änderung vornehmen. Die URL zum Websocket-Server wird sehr naiv gebaut:
https://github.com/Tinkerforge/esp32-firmware/blob/2187de47ea45c73f534e68b5c25634f1040f400f/software/web/src/ts/util.ts#L185
und verwendet deshalb immer ws://. Korrekt wäre falls das Webinterface selbst über HTTPS kam wss:// zu verwenden.

Ich habe dir eine Firmware angehangen, die dieses Problem beheben sollte. Falls du also per websocat eine Verbindung durch deine SSL-Proxy aufbauen kannst, das Webinterface aber immer noch nicht funktioniert, teste bitte mal die angehangene Firmware. Wenn das Problem dann weg ist würde ich die Änderung direkt übernehmen.

warp2_firmware_1_1_2_622712c6_merged.bin

On 3/11/2022 at 4:31 PM, elueckel said:

Ich habe bei POSTFIELDS schon alles mögliche probiert ... da kommt immer 0 zurück. Bei CURLOPT_POST kommt die 405 - somit ist PUT schon mal besser, aber PUT erwartet anscheinend bei PHP eine Datei? Heute komme ich hier anscheinend nicht weiter ... falls Du noch eine Idee hast wäre ich dankbar - sonst muss ich suchen.

Habe das hier gefunden: https://www.davidbritch.com/2014/08/test-post.html

Quote

The conventional technique for invoking a PUT operation is to set CURLOPT_PUT to true. However, this option is used to PUT a file[...] The standard solution is to set CURLOPT_CUSTOMREQUEST to “PUT” in order to specify the request type, and then set the CURLOPT_POSTFIELDS to the JSON data you want to PUT.

Die PHP-API von curl scheint etwas kompliziert zu sein ;)

On 3/11/2022 at 8:31 PM, gintonicgamer said:

Hi, ich habe die Beta für die Warp1 aufgespielt. Ich bekomme aber keine Verbindung zu meiner Fritzbox.

Das ist interessant. Die Wallbox versucht sich ja zu verbinden aber es klappt nicht. Taucht dein WLAN auf wenn du nach Netzwerken scanst oder musstest du die SSID händisch eintragen?

20 hours ago, E-t-h said:

Früher gab es in der NFG Config die Möglichkeit, das einzuschalten:

Ah, ich sehe das Problem: Die ganzen Konfigurationsmöglichkeiten (Auto-Start, NFC, usw.) sind nicht mehr so gekoppelt wie es vor der Beta der Fall war. Wenn du willst, dass man eine Ladung mit einem Tag freigeben muss, dann aber sofort geladen wird, ist die korrekte Konfiguration, dass du Auto-Start und unter Ladecontroller die Benutzerautorisierung aktivierst. Das wird perspektivisch in der Doku bzw. der Anleitung stehen.

20 hours ago, E-t-h said:

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?

Vermutlich, ja. Gib bitte nochmal Bescheid wenn Beta 3 (poste ich in ein paar Stunden) nicht hilft.

Ah Windows. Da muss es

curl -w "%{response_code}" -H "Content-Type: application/json" -X PUT -d "{}" http://123.123.123.123/evse/start_charging

sein, sorry. Also mit " um den Payload statt '.

Was bekommst du, wenn du auf der Kommandozeile

curl -w "%{response_code}" -H "Content-Type: application/json" -X PUT -d '{}' http://123.123.123.123/evse/start_charging

ausführst? (Die Wallbox-IP davor einfügen!)

13 minutes ago, elueckel said:

Das mache ich - der Wert der Zurück kommt ist 0 (also eine null als Zahl) ... als vorher das Kommando falsch war kam eine 405. 

Zumindest auf der Kommandozeile funktioniert ein äquivalenter curl-Aufruf bei mir. Was gibst du curl_getinfo als zweiten Parameter? CURLINFO_RESPONSE_CODE bzw CURLINFO_HTTP_CODE sollten beide funktionieren.

6 minutes ago, elueckel said:

Es scheint auch, dass 

vehicle_state

charge_release

time_since_state_change 

leer bleiben. Auf der Beta kommen die Werte nicht mit - auf meiner 2. Wallbox mit Stable kommen sie. 

Das sind alles geänderte APIs. Die schon an die Beta angepasste Doku findest du hier: https://www.warp-charger.com/api_beta.html

Das kannst du bedenkenlos machen. Bei der aktuellen Firmware-Version setzt sich bei einem Neustart aber Auto-Start wieder auf an und die im Webinterface eingestellte Ladestromgrenze wird zurückgesetzt. Ab Firmware 2.0.0 werden diese Einstellungen auch gespeichert.

Die Doku https://www.php.net/manual/de/function.curl-exec.php sagt, dass du nach curl_exec mit curl_getinfo https://www.php.net/manual/de/function.curl-getinfo.php den HTTP-Return-Code bekommst.

Du musst zum Aufrufen HTTP-PUT statt HTTP-POST verwenden. In deinem Fall wäre das CURLOPT_PUT statt CURLOPT_POST und entsprechend CURLOPT_PUTFIELDS statt CURLOPT_POSTFIELDS.

Danach sollte es z.B. mit "false" funktionieren. Dass "" nicht klappt ergibt Sinn: da kommt bei curl nur ein leerer String an, du musst aber noch eine Stufe tiefer, also als JSON-Payload einen leeren String schicken. Versuche mal

curl_setopt($ch, CURLOPT_PUTFIELDS, "\"\"");

Ich würde erwarten, dass das klapt.

Hm das konnte ich hier gerade auch reproduzieren. Ist jetzt gefixt: https://github.com/Tinkerforge/esp32-firmware/commit/6cf9077bf73f15b0f411637fad3a5dfbffdd0046

Ich fixe noch ein paar kleinere Bugs, morgen kommt Beta 3.

59 minutes ago, MarkG said:

Ich habe Sende-Interwal unter MQTT mit dem Wert 1 gesetzt

Das ist nur ein Maximal-Interval. D.h. wenn du keine Wertänderungen hast weil gerade kein Auto lädt, dann werden auch keine Nachrichten auf das Topic geschickt. Das war aber eigentlich schon immer so.

Hast du das selbe Problem auf wallbox/warp2/meter/values bzw. wallbox/warp2/meter/phases? Dass die evse/energy_meter...-Topics überhaupt rausgegeben wurden war eher unbedacht und sowohl energy_meter_values und energy_meter_state werden vor der finalen 2.0.0 noch entfernt.

Ersatz ist wie gesagt meter/values bzw. meter/phases für evse/energy_meter_values und meter/error_counters for evse/energy_meter_errors.

Fast übersehen, sorry:

14 hours ago, E-t-h said:

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.

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.