poohnet

Super, vielen Dank 😊 Gruß Thomas

Moin, normalerweise baue ich die WARP/ESP32-Firmware unter Linux (Ubuntu Server 22.04 LTS) und hatte dort bislang auch noch keine Probleme. Am Wochenende habe ich die Buildumgebung dann auch mal unter Windows und Visual Studio Code eingerichtet, der Build schlägt allerdings bei "Checking translation completeness" fehl: Checking translation completeness Traceback (most recent call last): File "Z:\warp\esp32-firmware\software\web\check_translation_completeness.py", line 98, in <module> main() File "Z:\warp\esp32-firmware\software\web\check_translation_completeness.py", line 53, in main used_placeholders, template_literals = util.parse_ts_files(ts_files) File "Z:\warp\esp32-firmware\software\util.py", line 216, in parse_ts_files parse_ts_file(f, os.path.basename(f), used_placeholders, template_literals) File "Z:\warp\esp32-firmware\software\util.py", line 195, in parse_ts_file content = f.read() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\encodings\cp1252.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 12263: character maps to <undefined> CalledProcessError: Command '['C:\\Users\\thein\\.platformio\\penv\\Scripts\\python.exe', '-u', 'check_translation_completeness.py', 'device_name', 'proxy', 'network_start', 'network', 'wifi', 'ntp', 'wireguard', 'network_end', 'interfaces_start', 'mqtt', 'interfaces_end', 'system_start', 'authentication', 'event_log', 'firmware_update', 'system_end', 'tf_branding']' returned non-zero exit status 1.: File "C:\Users\thein\.platformio\penv\lib\site-packages\platformio\builder\main.py", line 181: env.SConscript(item, exports="env") File "C:\Users\thein\.platformio\packages\tool-scons\scons-local-4.4.0\SCons\Script\SConscript.py", line 597: return _SConscript(self.fs, *files, **subst_kw) File "C:\Users\thein\.platformio\packages\tool-scons\scons-local-4.4.0\SCons\Script\SConscript.py", line 285: exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals) File "Z:\warp\esp32-firmware\software\pio_hooks.py", line 816: main() File "Z:\warp\esp32-firmware\software\pio_hooks.py", line 678: subprocess.check_call([env.subst('$PYTHONEXE'), "-u", "check_translation_completeness.py"] + [x.under for x in frontend_modules]) File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\subprocess.py", line 373: raise CalledProcessError(retcode, cmd) Kommentiert man den folgenden Aufruf aus, so geht's erstmal bis weiter bis "Checking HTML ID usage": print('Checking translation completeness') with ChangedDirectory('web'): subprocess.check_call([env.subst('$PYTHONEXE'), "-u", "check_translation_completeness.py"] + [x.under for x in frontend_modules]) Checking HTML ID usage Traceback (most recent call last): File "Z:\warp\esp32-firmware\software\web\check_id_usage.py", line 36, in <module> content = f.read() File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\encodings\cp1252.py", line 23, in decode return codecs.charmap_decode(input,self.errors,decoding_table)[0] UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 12263: character maps to <undefined> CalledProcessError: Command '['C:\\Users\\thein\\.platformio\\penv\\Scripts\\python.exe', '-u', 'check_id_usage.py', 'device_name', 'proxy', 'network_start', 'network', 'wifi', 'ntp', 'wireguard', 'network_end', 'interfaces_start', 'mqtt', 'interfaces_end', 'system_start', 'authentication', 'event_log', 'firmware_update', 'system_end', 'tf_branding']' returned non-zero exit status 1.: File "C:\Users\thein\.platformio\penv\lib\site-packages\platformio\builder\main.py", line 181: env.SConscript(item, exports="env") File "C:\Users\thein\.platformio\packages\tool-scons\scons-local-4.4.0\SCons\Script\SConscript.py", line 597: return _SConscript(self.fs, *files, **subst_kw) File "C:\Users\thein\.platformio\packages\tool-scons\scons-local-4.4.0\SCons\Script\SConscript.py", line 285: exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals) File "Z:\warp\esp32-firmware\software\pio_hooks.py", line 816: main() File "Z:\warp\esp32-firmware\software\pio_hooks.py", line 810: subprocess.check_call([env.subst('$PYTHONEXE'), "-u", "check_id_usage.py"] + [x.under for x in frontend_modules]) File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\lib\subprocess.py", line 373: raise CalledProcessError(retcode, cmd) Kommentiert man auch diesen Aufruf aus, so wird die Firmware erfolgreich gebaut. print("Checking HTML ID usage") with ChangedDirectory('web'): subprocess.check_call([env.subst('$PYTHONEXE'), "-u", "check_id_usage.py"] + [x.under for x in frontend_modules]) Habe ich bei der Einrichtung etwas vergessen oder evtl. nicht die richtigen Versionen installiert? Vielen Dank & Gruß Thomas

Leider gar keine. Der AC-Landestandard sieht lediglich vor, dass die Wallbox dem Auto (über einen definierten Widerstandswert) "mitteilt", wieviel Strom sie denn liefern kann/soll. Das Auto zieht daraufhin maximal eben diesen Strom (oder auch weniger), kann der Wallbox aber keinerlei weitere Informationen zurückliefern. Hierfür gibt es schlichtweg keine Datenleitungen o. ä.

Hallo zusammen, gibt es eine Möglichkeit Programme, die auf dem ESP32-Brick laufen, zu debuggen? Für die „normalen“ ESP32-Boards gibt es ja z. B. den ESP-Prog, der im Zusammenspiel mit Visual Studio Code gut funktioniert. Wie macht ihr das bei der Entwicklung? Ausschließlich über den Logger oder gibt es noch andere Möglichkeiten? Vielen Dank und Gruß Thomas

Die grundsätzliche Frage ist wahrscheinlich erstmal, ob der Batteriespeicher berücksichtigt (d. h. entladen) werden soll, wenn WARP aktiv ist. Ich steuere die max. Entladeleistung über Node-Red, d. h. wenn der Strom gerade günstig ist, dann soll die Batterie nicht entladen werden, ansonsten auch nur bis x% SOC. Gruß Thomas

@TMA84 Klar, kein Problem. flows.json

Du kannst die Daten eines externen Zählers per MQTT bereitstellen (Topics „values_update“, „phases_update“ usw.). Mein Modbus-Zähler hängt auch in der UV, die Daten werden per Node-Red ausgelesen und dann per MQTT gesendet. Funktioniert 1a! Gruß Thomas

Vielleicht ein Modul "Lagelog 2.0" spendieren?!

Moin @rtrbt, das wäre doch eine sinnvolle Erweiterung, oder? Gerade bei HT/NT oder dynamischen Tarifen kann der im Charge Tracker ausgewiesene Preis älterer Ladevorgänge (z. T. deutlich) vom tatsächlichen abweichen. Daher wäre es gut, wenn der (beim Start) geltende Preis mit abgespeichert würde und sich eine nachträgliche Änderung nicht auf alle vorherigen Ladevorgänge auswirken würde... Gruß Thomas

Klar, kein Problem. Melde dich einfach, wenn du soweit bist. Anbei schon mal der Entwicklungstand von letzter Woche heute (Version 2.1.0)... Gruß Thomas warp2_firmware_2_1_0_63fe49f6_7af044a16ebdb7b_merged.zip

Mit etwas Geschick kann man WARP1 problemlos auf den ESP32-Ethernet-Brick aufrüsten 😊 s. Gruß Thomas

... oder vielleicht sogar eine direkte Anbindung der API von tibber? Alternativ den Preis vor dem Start der Ladung per MQTT setzen? Gruß Thomas

Guten Morgen, gibt es zu euren Gehäusen für die Bricks/Bricklets zufällig STL-Files oder andere Dateien, mit denen man einen 3D-Drucker füttern könnte? Vielen Dank & Gruß Thomas

Moin @Fabix, der in der WARP1 verbaute ESP32-Brick ist leider etwas zu "schwachbrüstig" für die OCPP-Funktionen. Ich habe meinen WARP-Charger daher auf den ESP32-Ethernet-Brick aufgerüstet und die Firmware entsprechend angepasst, sodass diese auch mit dem "alten" Ladecontroller funktioniert. Guck' mal hier: Gruß Thomas

Alles klar, besten Dank 😊 Ich ziehe die letzten Anpassungen dann auch noch nach und teste weiter. Falls wir uns nicht mehr hören sollten, so wünsche ich euch auf jeden Fall schon mal frohe Weihnachten und einen guten Rutsch. Ich bin froh, mich vor mittlerweile fast zwei Jahren für WARP entschieden zu haben und bin gespannt, was ihr 2023 noch so alles implementieren werdet… Gruß Thomas

Hallo @rtrbt, ich bin jetzt mal auf die aktuelle Version gegangen und habe unter "lib_deps" die neueste Revision von tfocpp eingebunden (9856852). Leider gibt es hier jetzt einen Compile-Fehler: src/modules/ocpp/ocpp.cpp: In member function 'void Ocpp::setup()': src/modules/ocpp/ocpp.cpp:117:109: error: no matching function for call to 'OcppChargePoint::start(const char*, const char*)' cp.start(config.get("url")->asEphemeralCStr(), (String(BUILD_HOST_PREFIX) + '-' + local_uid_str).c_str()); ^ In file included from src/modules/ocpp/ocpp.h:23, from src/modules/ocpp/ocpp.cpp:20: .pio/libdeps/warp2_poohnet/TFOCPP/src/ocpp/ChargePoint.h:46:10: note: candidate: 'void OcppChargePoint::start(const char*, const char*, const char*)' void start(const char *websocket_endpoint_url, const char *charge_point_name, const char *basic_auth_pass); ^~~~~ .pio/libdeps/warp2_poohnet/TFOCPP/src/ocpp/ChargePoint.h:46:10: note: candidate expects 3 arguments, 2 provided Anscheinend fehlt da noch was im Repo... Gruß Thomas

Moin @rtrbt, vielen Dank für die Rückmeldung. Sind denn alle relevanten Commits auch im GitHub-Repo? Dann würde ich die nochmal in meinen Fork nachziehen und weiter testen... Gruß Thomas

Hallo @rtrbt, konntet ihr zwischenzeitlich schon etwas herausfinden? Ich hatte gestern wieder den Fall, dass das Ende der Ladung bei eCarUp nicht korrekt erkannt wurde und diese nun mit 0,0 kWh in der App steht... Vielen Dank & Gruß Thomas

Alles klar, danke :-)

Moin @rtrbt, gibt es schon irgendwelche neuen Erkenntnisse? Vielen Dank & Gruß Thomas

Hi @rtrbt, wie versprochen hier die Vorgehensweise zur Reproduktion des Problems mit SteVe: Fahrzeug verbinden EVCC nicht (!) freigeben RemoteStartTransaction senden etwas warten RemoteStopTransaction senden --> Transaktion bleibt in SteVe aktiv RemoteStopTransaction erneut senden --> Transaktion wird rejected Anbei noch das Log... Gruß Thomas steve.txt

Hab ich mich noch nicht getraut, aber wahrscheinlich laufe ich demnächst eh wieder in eine Situation, bei dem ich den OCPP-Status zurücksetzen muss… 🙃 Ich probiere das morgen Nachmittag nochmal aus und hänge die Logs an.

'n Abend @rtrbt, ich habe mich heute Nachmittag mal etwas mit SteVe beschäftigt und kann das Problem auch hier reproduzieren. Wenn zwischen "RemoteStartTransaction" und "RemoteStopTransaction" kein "Sending StatusNotification.req: Status Charging for connector 1" gesendet wird, dann wird "RemoteStopTransaction" zwar mit "Accepted" quittiert, die Transaktion bleibt aber offen. Weitere "RemoteStopTransaction" werden von WARP dann mit "unknown transaction id" rejected. Ist das evtl. eine Definitionslücke in der Spezifikation? Gruß Thomas

Hallo @rohrbage, hast du evtl. versehentlich den max. Strom begrenzt? Falls nein, geh mal auf die Seite „Ladecontroller“ und erstelle ein Ladeprotokoll (d. h. Ladeprotokoll starten, Ladung starten, ein paar Minuten laufen lassen, Ladung beenden und Ladeprotokoll herunterladen). Das Protokoll kannst du hier anhängen, sodass die Jungs von TF es analysieren können… Gruß Thomas

Moin @rtrbt, so, ich habe heute Vormittag eine ganze Reihe Tests gemacht und die gute Nachricht ist, dass im Normalfall nun anscheinend alles richtig funktioniert! Vielen Dank dafür 🙂 Allerdings habe ich es (mit einer zugegebenermaßen nicht ganz sauberen Vorhensweise) trotzdem reproduzierbar geschafft, WARP und eCarUp doch noch aus dem Tritt zu bringen. Wenn man nämlich eine Ladung über die eCarUp-App startet und diese anschließend wieder beendet, ohne zuvor EVCC freigegeben zu haben (also letztendlich gar nicht lädt), dann bleibt der Ladevorgang in der App weiterhin aktiv und WARP bekommt wieder keine Heartbeats mehr: 2022-11-26 12:20:34,132 Sending Heartbeat.req. 197608 197608 257608 60000 2022-11-26 12:20:34,230 Received Heartbeat.conf for connector 0 2022-11-26 12:21:33,961 Sending Heartbeat.req. 257669 257669 317669 60000 2022-11-26 12:21:34,059 Received Heartbeat.conf for connector 0 2022-11-26 12:21:46,422 IDLE -> NO_TAG 2022-11-26 12:21:46,423 Sending StatusNotification.req: Status Preparing for connector 1 2022-11-26 12:21:46,512 Received StatusNotification.conf for connector 1 2022-11-26 12:21:46,885 Charger state changed from 0 to 1 2022-11-26 12:22:17,600 Wrote last uptime to flash 2022-11-26 12:22:20,942 Received RemoteStartTransaction.req for connector 1 and tag TV2DVLAZELX3FLCHVS5A 2022-11-26 12:22:20,942 Sending RemoteStartTransaction.conf Accepted 2022-11-26 12:22:20,958 NO_TAG -> TRANSACTION 2022-11-26 12:22:21,001 Sending StartTransaction.req at connector 1 for tag TV2DVLAZELX3FLCHVS5A at 741.195 kWh. 2022-11-26 12:22:21,007 Sending StatusNotification.req: Status SuspendedEVSE for connector 1 2022-11-26 12:22:21,022 Evaluating charging profiles 2022-11-26 12:22:21,022 Connector 1 2022-11-26 12:22:21,023 Profile evaluation done. Distributing limit 2022-11-26 12:22:21,033 Currents distributed: 2022-11-26 12:22:21,033 ConnID Allowed Phases MinRate 2022-11-26 12:22:21,044 0 32.000 3 0.000 2022-11-26 12:22:21,044 1 32.000 3 0.000 2022-11-26 12:22:21,045 Next check: never 2022-11-26 12:22:21,055 2022-11-26 12:22:21,055 Setting connector 1 limit to 32000 2022-11-26 12:22:21,106 Received StartTransaction.conf for connector 1 2022-11-26 12:22:21,172 Evaluating charging profiles 2022-11-26 12:22:21,173 Connector 1 2022-11-26 12:22:21,173 Profile evaluation done. Distributing limit 2022-11-26 12:22:21,183 Currents distributed: 2022-11-26 12:22:21,183 ConnID Allowed Phases MinRate 2022-11-26 12:22:21,194 0 32.000 3 0.000 2022-11-26 12:22:21,195 1 32.000 3 0.000 2022-11-26 12:22:21,195 Next check: never 2022-11-26 12:22:21,205 2022-11-26 12:22:21,206 Setting connector 1 limit to 32000 2022-11-26 12:22:21,263 Received StatusNotification.conf for connector 1 2022-11-26 12:22:33,910 Sending Heartbeat.req. 317677 317677 377677 60000 2022-11-26 12:22:34,002 Received Heartbeat.conf for connector 0 2022-11-26 12:23:33,985 Sending Heartbeat.req. 377754 377754 437754 60000 2022-11-26 12:23:34,088 Received Heartbeat.conf for connector 0 2022-11-26 12:23:48,441 Received RemoteStopTransaction.req for txn 1669461741 2022-11-26 12:23:48,442 TRANSACTION -> FINISHING_UNLOCKED 2022-11-26 12:23:48,476 Sending StatusNotification.req: Status Finishing for connector 1 2022-11-26 12:23:48,522 Sending StopTransaction.req at connector 1 for tag at 741.195 kWh. StopReason 7 2022-11-26 12:23:48,553 Sending RemoteStopTransaction.conf Accepted (connector 0) 2022-11-26 12:23:48,570 Evaluating charging profiles 2022-11-26 12:23:48,571 Connector 1 2022-11-26 12:23:48,571 Profile evaluation done. Distributing limit 2022-11-26 12:23:48,581 Currents distributed: 2022-11-26 12:23:48,582 ConnID Allowed Phases MinRate 2022-11-26 12:23:48,592 0 32.000 3 0.000 2022-11-26 12:23:48,593 1 32.000 3 0.000 2022-11-26 12:23:48,593 Next check: never 2022-11-26 12:23:48,603 2022-11-26 12:23:48,604 Setting connector 1 limit to 32000 2022-11-26 12:23:48,658 Received StatusNotification.conf for connector 1 2022-11-26 12:24:33,899 Sending Heartbeat.req. 437757 437757 497757 60000 2022-11-26 12:25:33,998 Sending Heartbeat.req. 497857 497857 557857 60000 2022-11-26 12:25:51,441 FINISHING_UNLOCKED -> IDLE 2022-11-26 12:25:51,442 Sending StatusNotification.req: Status Available for connector 1 2022-11-26 12:25:52,015 Charger state changed from 1 to 0 2022-11-26 12:26:34,021 Sending Heartbeat.req. 557879 557879 617879 60000 Beim Zurücksetzen des OCPP-Status bin ich dann auch noch über einen bösen Bug gestolpert, denn dieser scheint in der aktuellen Version nun einem Factory-Reset gleichzukommen. Jedenfalls war anschließend meine gesamte Konfiguration inkl. aller aufgezeichneter Ladevorgänge weg... 😢 Nachdem ich alles wieder richtig eingestellt hatte, hat es übrigens noch fast 20 Minuten gedauert, bis WARP und eCarUp wieder "in sync" waren. Die App hat nämlich im Minutentakt weiterhin "RemoteStopTransaction.req" gesendet, die aber von WARP zurückgewiesen wurden. Irgendwann hat das dann aber aufgehört und die Box wurde wieder als "frei" aufgeführt. 16,564 OCPP WEBSOCKET CONNECTED 16,642 Sending BootNotification.req. 16641 0 60000 60000 16,744 Received BootNotification.conf for connector 0. Interval 60 2022-11-26 12:39:00,000 Sending StatusNotification.req: Status Available for connector 0 2022-11-26 12:39:00,011 Sending StatusNotification.req: Status Available for connector 1 2022-11-26 12:39:00,030 Sending StatusNotification.req: Status Available for connector 0 2022-11-26 12:39:00,046 Evaluating charging profiles 2022-11-26 12:39:00,047 Connector 1 2022-11-26 12:39:00,047 Profile evaluation done. Distributing limit 2022-11-26 12:39:00,057 Currents distributed: 2022-11-26 12:39:00,057 ConnID Allowed Phases MinRate 2022-11-26 12:39:00,068 0 32.000 3 0.000 2022-11-26 12:39:00,069 1 32.000 3 0.000 2022-11-26 12:39:00,069 Next check: never 2022-11-26 12:39:00,079 2022-11-26 12:39:00,079 Setting connector 1 limit to 32000 2022-11-26 12:39:00,147 Received StatusNotification.conf for connector 0 2022-11-26 12:39:00,287 Received StatusNotification.conf for connector 1 2022-11-26 12:39:00,399 Received StatusNotification.conf for connector 0 2022-11-26 12:39:04,077 NTP synchronized at 20,446! 2022-11-26 12:39:24,242 Received RemoteStopTransaction.req for txn 1669461741 2022-11-26 12:39:24,242 Sending RemoteStopTransaction.conf Rejected (unknown transaction id) 2022-11-26 12:39:49,672 This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW 2022-11-26 12:40:00,344 Sending Heartbeat.req. 76713 76713 136713 60000 2022-11-26 12:40:00,442 Received Heartbeat.conf for connector 0 2022-11-26 12:40:25,495 Received RemoteStopTransaction.req for txn 1669461741 2022-11-26 12:40:25,495 Sending RemoteStopTransaction.conf Rejected (unknown transaction id) 2022-11-26 12:40:59,951 Sending Heartbeat.req. 136763 136763 196763 60000 2022-11-26 12:41:01,946 Received Heartbeat.conf for connector 0 2022-11-26 12:41:29,315 Received RemoteStopTransaction.req for txn 1669461741 2022-11-26 12:41:29,315 Sending RemoteStopTransaction.conf Rejected (unknown transaction id) 2022-11-26 12:42:00,084 Sending Heartbeat.req. 196843 196843 256843 60000 2022-11-26 12:42:00,182 Received Heartbeat.conf for connector 0 2022-11-26 12:42:29,979 Received RemoteStopTransaction.req for txn 1669461741 2022-11-26 12:42:29,979 Sending RemoteStopTransaction.conf Rejected (unknown transaction id) Gruß Thomas