rtrbt

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

Habe das hier gefunden: https://www.davidbritch.com/2014/08/test-post.html Die PHP-API von curl scheint etwas kompliziert zu sein ;) 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? 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. 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!)

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. 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.

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: 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.

Zeitsynchronisierung an, DHCP ist egal (kann parallel zu einem fest konfigurierten Server verwendet werden). Als Zeitserver kannst du 0.pool.ntp.org eintragen. Das machen wir nicht standardmäßig, weil der NTP-Pool das aus Traffic-Gründen nicht möchte. Siehe hier: https://www.ntppool.org/de/vendors.html (Wir haben uns schon darum gekümmert eine Vendor Zone zu bekommen, das scheint sich aber zu ziehen) Die MQTT-Werte wurden noch nie regelmäßig gepusht, sondern immer nur, wenn es Änderungen an den Werten gab. Dass z.B. evse/state jetzt nicht mehr sekündlich kommt liegt daran, dass die uptime in den low_level_state gewandert ist. Statt evse/energy_meter_values solltest du eher meter/values und meter/phases benutzen. meter/detailed_values wurde in meter/all_values umbenannt. Ich wollte gerade auf die API-Docs verweisen, hatte aber garkeinen Link dazu gepostet. Solange die 2.0.0-Firmwares noch nicht fertig sind, findet ihr die API-Dokumentation hier: https://www.warp-charger.com/api_beta.html Steht doch da? bzw. hier: https://www.warp-charger.com/api_beta.html#mqtt_config noch ein paar Details dazu (der interval-Eintrag).

Gut zu wissen, dann habe ich daran gedacht alle Repos zu pushen :D Noch nichts konkretes, aber das ist in Arbeit.

Ja. Geh aber gleich auf Beta 2, die gerade frisch in dem Thread erschienen ist ;)

Firmware: WARP 1.9.90 (2.0.0 Beta 1) und WARP2 1.9.91 (2.0.0 Beta 2) Details hier:

tl;dr: Ladetracking Beta 2 bzw. Beta 1 für WARP1 Was gibt's neues? Die Änderungen an der Ladecontroller-Firmware, sowie das Ladetracking stehen jetzt auch für WARP1 zur Verfügung. Außerdem gibt es neben einigen Bugfixes jetzt eine neue Konfigurationsunterseite für die Zeitsynchronisierung, Benutzer- und Zeitfilter für das Ladetracking und die Möglichkeit, Wallboxen einen Anzeigenamen zu geben. Zusätzlich haben wir die Verwendung der API vereinfacht und ein konfigurierbares Mindest-Interval für MQTT-Nachrichten eingebaut. API-Änderungen Um es zu erleichtern, die API zu verwenden, haben wir folgende Änderungen vorgenommen: Unter info/features kann eine Liste von Funktionalitäten abgefragt werden, die von der konkreten Wallbox unterstützt werden. Bei einer WARP1 Smart mit nachgerüstetem NFC wird beispielsweise ["evse","nfc"] zurückgegeben, bei einer WARP2 Pro ["evse","cp_disconnect","button_config","ethernet","meter","meter_phases","meter_all_values","nfc"] Die API akzeptiert jetzt auf Topics, die einen leeren Payload erwarten (z.B. Kommandos wie evse/start_charging), nicht nur null, sondern auch folgende JSON-Werte: "", false, 0, [] und {} Kommandos und Konfigurations-Updates, die ein JSON-Objekt mit genau einem Eintrag erwarten, können jetzt direkt mit dem Wert des Eintrags aufgerufen werden. Zum Beispiel akzeptiert evse/external_current_update nicht mehr nur {"current": 13000} sondern auch direkt 13000 Edit: Die für die neue API aktualisierte Dokumentation findet sich hier: https://www.warp-charger.com/api_beta.html Achtung: Solange 2.0.0 noch nicht final veröffentlicht ist, garantieren wir keine API-Stabilität. Große Änderungen sind aber nicht mehr zu erwarten. warp2_firmware_1_9_91_62273012_merged.bin warp_firmware_1_9_90_62272ff1_merged.bin

Hi, The embedded font is Code page 437. For the openHAB bindings I've used the following mapping to convert from UTF-16: static final List<Integer> CP437 = Arrays.asList(0x0000, 0x263A, 0x263B, 0x2665, 0x2666, 0x2663, 0x2660, 0x2022, 0x25D8, 0x25CB, 0x25D9, 0x2642, 0x2640, 0x266A, 0x266B, 0x263C, 0x25BA, 0x25C4, 0x2195, 0x203C, 0x00B6, 0x00A7, 0x25AC, 0x21A8, 0x2191, 0x2193, 0x2192, 0x2190, 0x221F, 0x2194, 0x25B2, 0x25BC, 0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, 0x0028, 0x0029, 0x002A, 0x002B, 0x002C, 0x002D, 0x002E, 0x002F, 0x0030, 0x0031, 0x0032, 0x0033, 0x0034, 0x0035, 0x0036, 0x0037, 0x0038, 0x0039, 0x003A, 0x003B, 0x003C, 0x003D, 0x003E, 0x003F, 0x0040, 0x0041, 0x0042, 0x0043, 0x0044, 0x0045, 0x0046, 0x0047, 0x0048, 0x0049, 0x004A, 0x004B, 0x004C, 0x004D, 0x004E, 0x004F, 0x0050, 0x0051, 0x0052, 0x0053, 0x0054, 0x0055, 0x0056, 0x0057, 0x0058, 0x0059, 0x005A, 0x005B, 0x005C, 0x005D, 0x005E, 0x005F, 0x0060, 0x0061, 0x0062, 0x0063, 0x0064, 0x0065, 0x0066, 0x0067, 0x0068, 0x0069, 0x006A, 0x006B, 0x006C, 0x006D, 0x006E, 0x006F, 0x0070, 0x0071, 0x0072, 0x0073, 0x0074, 0x0075, 0x0076, 0x0077, 0x0078, 0x0079, 0x007A, 0x007B, 0x007C, 0x007D, 0x007E, 0x2302, 0x00C7, 0x00FC, 0x00E9, 0x00E2, 0x00E4, 0x00E0, 0x00E5, 0x00E7, 0x00EA, 0x00EB, 0x00E8, 0x00EF, 0x00EE, 0x00EC, 0x00C4, 0x00C5, 0x00C9, 0x00E6, 0x00C6, 0x00F4, 0x00F6, 0x00F2, 0x00FB, 0x00F9, 0x00FF, 0x00D6, 0x00DC, 0x00A2, 0x00A3, 0x00A5, 0x20A7, 0x0192, 0x00E1, 0x00ED, 0x00F3, 0x00FA, 0x00F1, 0x00D1, 0x00AA, 0x00BA, 0x00BF, 0x2310, 0x00AC, 0x00BD, 0x00BC, 0x00A1, 0x00AB, 0x00BB, 0x2591, 0x2592, 0x2593, 0x2502, 0x2524, 0x2561, 0x2562, 0x2556, 0x2555, 0x2563, 0x2551, 0x2557, 0x255D, 0x255C, 0x255B, 0x2510, 0x2514, 0x2534, 0x252C, 0x251C, 0x2500, 0x253C, 0x255E, 0x255F, 0x255A, 0x2554, 0x2569, 0x2566, 0x2560, 0x2550, 0x256C, 0x2567, 0x2568, 0x2564, 0x2565, 0x2559, 0x2558, 0x2552, 0x2553, 0x256B, 0x256A, 0x2518, 0x250C, 0x2588, 0x2584, 0x258C, 0x2590, 0x2580, 0x03B1, 0x00DF, 0x0393, 0x03C0, 0x03A3, 0x03C3, 0x00B5, 0x03C4, 0x03A6, 0x0398, 0x03A9, 0x03B4, 0x221E, 0x03C6, 0x03B5, 0x2229, 0x2261, 0x00B1, 0x2265, 0x2264, 0x2320, 0x2321, 0x00F7, 0x2248, 0x00B0, 0x2219, 0x00B7, 0x221A, 0x207F, 0x00B2, 0x25A0, 0x00A0); public static String utf16ToCP437(String utf16) { StringBuilder result = new StringBuilder(); utf16.codePoints().map(c -> CP437.indexOf(c)).map(i -> i == -1 ? 0xDB : i) .forEach(c -> result.append((char) c)); return result.toString(); } The lookup table should work in any language. Many programming language standard libraries can do this conversion. For example in Python: 'test ½'.encode('cp437', 'replace') will return b'test \xab' Using 'replace' will insert encoded '?' chars if a non-encodeable unicode character is encountered.

Dass die Box keinen NTP-Server bekommt ergibt Sinn, weil du statische IPs konfiguriert hast. Damit ist DHCP erstmal außen vor. das behebt sich wie gesagt, sobald wir andere Serverquellen haben. Dann ist es seltsam, dass der Zähler da noch nicht gefunden wurde. Ich versuche das hier mal nachzustellen. Was mich zwischenzeitlich auch verwundert hatte war, dass auch das Ende der ersten Ladung keinen Zählerstand hat. Das war aber nur ein Bug in der CSV-Konvertierung, den habe ich gefixt. Hat sich also schon gelohnt ;) Im Debug-Report sehe ich sehr häufige MQTT-Reconnects. Das scheint aber ein Empfangsproblem zu sein. Falls du damit Probleme hast musst du vermutlich einen Repeater aufstellen oder ein LAN-Kabel ziehen o.Ä.

Moin, Ja, hier gehört es hin. Und schonmal danke fürs Testen! Das hängt davon ab, ob deine Box die Zeitsynchronisierung hinbekommen hat. Wirf mal einen Blick in das Ereignislog. Wenn die Zeitsynchronisierung klappt sollte da eine Meldung wie diese hier stehen: 2022-02-28 16:12:50,749 NTP synchronized at 34,286! und alle Meldungen danach haben eine sinnvolle Zeit. Wenn das fehlt kann es sein, dass die Wallbox keinen NTP-Server per DHCP bekommt. Das können leider nicht alle Router. In der fertigen Version werden wir auch andere Zeitserver als die über DHCP zugeteilten benutzen. Das ist seltsam, dass die Zählerstände nicht eingetragen sind. Hast du die Ladung sehr schnell nachdem du die Beta installierst oder nachdem die Wallbox vom Strom getrennt war, gestartet? Eventuell hatte der Ladecontroller den Zähler da noch nicht gefunden. Falls du die Box seit dem nicht neugestartet hast würde mich ein Debug-Report interessieren. Das Log wird binär in den Flash der Wallbox geschrieben. Beim Trennen vom Strom bleibt es erhalten, ein Reset auf Werkszustand löscht es aber. In der fertigen Version 2.0.0 wird es noch etwas GUI dafür geben, wie viele Einträge im Log sind, Einträge zu löschen usw. So wie es aussieht hatte die Wallbox auch beim Ladeende keine Zeitsynchronisierung. Das Erheben der Zeiten funktioniert folgendermaßen: Startzeitpunkt und Entzeitpunkt kommen über die NTP-synchronisierte Zeit. Die Ladedauer ist davon komplett unabhängig, die messen wir über den Ladecontroller. Wir werden das Format auch dokumentieren. Das musst du nicht reverse engineeren. Grüße, Erik

Das wird mit der nächsten Firmware-Version kommen. Eine Beta gibt es schon hier: Der Ladetracker kann 7680 Ladungen speichern. Das reicht bei 10 Ladungen am Tag für ungefähr zwei Jahre und einen Monat.

Hi, Are you doing a full calibration, i.e. "Calibrate Zero" and "Calibrate Weight"? Also please update to the latest Brick Viewer version (2.4.21), maybe this is already fixed.