poohnet

Hallo zusammen, der Übersichtlichkeit halber starte ich für das Thema "WARP on Steroids", d. h. den Umbau von WARP1 auf den ESP32 Ethernet Brick, sowie die hierfür notwendige Firmware-Anpassung mal ein neues Topic. Damit wird die in https://www.tinkerunity.org/topic/8025-anschluss-von-warp-charger-pro-1-an-citywatt-abrechnungssystem/?do=findComment&comment=46114 begonnene Diskussion fortgesetzt. Anbei schon mal die aktuelle Firmware-Version 2.1.1 (Stand TF 31.03.2023)... Gruß Thomas Admin-Edit: Veraltete Firmware entfernt.

Moin Oliver, ich selbst stelle die Zählerdaten zwar per MQTT bereit (d. h ich habe in der Box keinen Zähler und kein RS485-Bricklet verbaut) habe die zugehörigen Firmware-Module der Pro-Version aber trotzdem alle mit compiliert. Somit sollte die „WARP on Steroid“ Firmware eigentlich in allen Ausbaustufen funktionieren. Gerne kann ich heute Abend oder morgen nochmal eine aktuelle Version bereitstellen; hier wäre dann auch meine Erweiterung des Charge Trackers enthalten… Gruß Thomas

Moin @rtrbt, während der OCPP-Betaphase waren wir ja bereits intensiv in Kontakt bzgl. Fehlern in der Kommunikation zwischen WARP und eCarUp. Habt ihr zwischenzeitlich bereits eine Rückmeldung von eCarUp erhalten? Ich habe nämlich leider weiterhin immer wieder mal das Problem, dass das Ladeende (bzw. die geladenen kWh) nicht korrekt registriert wird und die OCPP-Kommunikation aufgrund fehlender Heartbeats nur durch einen Neustart wiederhergestellt werden kann... 2023-03-30 06:55:29,920 Sending Heartbeat.req. 171337619 171337619 171397619 60000 2023-03-30 06:55:30,013 Received Heartbeat.conf for connector 0 2023-03-30 06:56:29,534 Sending StatusNotification.req: Status SuspendedEVSE for connector 1 2023-03-30 06:56:29,639 Received StatusNotification.conf for connector 1 2023-03-30 06:56:29,944 Sending Heartbeat.req. 171397657 171397657 171457657 60000 2023-03-30 06:56:30,057 Received Heartbeat.conf for connector 0 2023-03-30 06:56:30,107 Charger state changed from 2 to 1 2023-03-30 06:57:29,969 Sending Heartbeat.req. 171457740 171457740 171517740 60000 2023-03-30 06:57:30,066 Received Heartbeat.conf for connector 0 2023-03-30 06:58:30,943 Sending Heartbeat.req. 171517781 171517781 171577781 60000 2023-03-30 06:58:31,501 Received Heartbeat.conf for connector 0 2023-03-30 06:58:47,985 Received RemoteStopTransaction.req for txn 1680150326 2023-03-30 06:58:47,986 TRANSACTION -> FINISHING_UNLOCKED 2023-03-30 06:58:48,032 Sending StatusNotification.req: Status Finishing for connector 1 2023-03-30 06:58:48,043 Sending StopTransaction.req at connector 1 for tag at 824.036 kWh. StopReason 7 2023-03-30 06:58:48,075 Sending RemoteStopTransaction.conf Accepted (connector 0) 2023-03-30 06:58:48,093 Evaluating charging profiles 2023-03-30 06:58:48,093 Connector 1 2023-03-30 06:58:48,094 Profile evaluation done. Distributing limit 2023-03-30 06:58:48,104 Currents distributed: 2023-03-30 06:58:48,104 ConnID Allowed Phases MinRate 2023-03-30 06:58:48,115 0 32.000 3 0.000 2023-03-30 06:58:48,115 1 32.000 3 0.000 2023-03-30 06:58:48,115 Next check: never 2023-03-30 06:58:48,126 2023-03-30 06:58:48,126 Setting connector 1 limit to 32000 2023-03-30 06:59:30,529 Sending Heartbeat.req. 171577869 171577869 171637869 60000 2023-03-30 07:00:30,589 Sending Heartbeat.req. 171637929 171637929 171697929 60000 --- 17,666 MQTT: Connected to broker. 21,312 IDLE -> NO_TAG 21,312 Sending StatusNotification.req: Status Preparing for connector 1 21,314 Evaluating charging profiles 21,324 Connector 1 21,324 Profile evaluation done. Distributing limit 21,340 Currents distributed: 21,341 ConnID Allowed Phases MinRate 21,341 0 32.000 3 0.000 21,352 1 32.000 3 0.000 21,353 Next check: never 21,363 21,363 Setting connector 1 limit to 32000 2023-03-30 07:01:47,925 NTP synchronized at 21,649! 2023-03-30 07:01:48,124 Evaluating charging profiles 2023-03-30 07:01:48,124 Connector 1 2023-03-30 07:01:48,125 Profile evaluation done. Distributing limit 2023-03-30 07:01:48,135 Currents distributed: 2023-03-30 07:01:48,135 ConnID Allowed Phases MinRate 2023-03-30 07:01:48,146 0 32.000 3 0.000 2023-03-30 07:01:48,146 1 32.000 3 0.000 2023-03-30 07:01:48,146 Next check: never 2023-03-30 07:01:48,157 2023-03-30 07:01:48,157 Setting connector 1 limit to 32000 2023-03-30 07:01:48,614 OCPP WEBSOCKET CONNECTED 2023-03-30 07:01:48,678 Sending BootNotification.req. 22402 0 60000 60000 2023-03-30 07:01:48,782 Received BootNotification.conf for connector 0. Interval 60 2023-03-30 07:01:48,000 Sending StatusNotification.req: Status Available for connector 0 2023-03-30 07:01:48,011 Sending StatusNotification.req: Status Preparing for connector 1 2023-03-30 07:01:48,022 Sending StatusNotification.req: Status Available for connector 0 2023-03-30 07:01:48,386 Received StatusNotification.conf for connector 0 2023-03-30 07:01:48,636 Received StatusNotification.conf for connector 1 2023-03-30 07:01:48,859 Received StatusNotification.conf for connector 0 2023-03-30 07:02:36,685 Received RemoteStopTransaction.req for txn 1680150326 2023-03-30 07:02:36,685 Sending RemoteStopTransaction.conf Rejected (unknown transaction id) 2023-03-30 07:02:41,822 This is warp2-XSS (warp2-XSS), a WARP2 Charger Pro 11kW 2023-03-30 07:02:46,875 Tag timeout! 2023-03-30 07:02:46,875 NO_TAG -> FINISHING_UNLOCKED 2023-03-30 07:02:46,876 Sending StatusNotification.req: Status Finishing for connector 1 2023-03-30 07:02:46,981 Received StatusNotification.conf for connector 1 2023-03-30 07:02:47,900 Sending Heartbeat.req. 82407 82407 142407 60000 2023-03-30 07:02:47,995 Received Heartbeat.conf for connector 0 2023-03-30 07:03:47,915 Sending Heartbeat.req. 142418 142418 202418 60000 2023-03-30 07:03:48,018 Received Heartbeat.conf for connector 0 Vielen Dank & Gruß Thomas

Hallo zusammen, ich habe mal etwas "gebastelt" und das Modul "charge_tracker" erweitert, sodass der aktuelle Strompreis per MQTT-Topic "charge_tracker/electricity_price_update" gesetzt werden kann. Zusätzlich wird der Preis nun beim Start einer Ladung gespeichert und in allen Auswertungen bei der Berechnung der Ladekosten verwendet: Wie von @rtrbt geschrieben ändert sich hierdurch allerdings die Struktur und Größe der Einträge, sodass diese leider nicht mehr kompatibel mit den bisherigen Aufzeichnungen sind und sicherheitshalber in einem separaten Ordner im Flash gespeichert werden. Alte Ladevorgänge werden somit nicht mehr angezeigt! Darüber hinaus habe ich den PDF-Export noch etwas nach meinem Geschmack angepasst: @wuesten_fuchs Ich sende per Node-RED den stündlich wechselnden Preis von Tibber, du könntest aber genauso einfach die gewünschte HT/NT-Umschaltung realisieren... Gruß Thomas

Danke für die Blumen 🙂 Die Kommunikation zwischen den einzelnen Komponenten erfolgt über Speedwire.

Hallo zusammen, falls jemand PV-Komponenten von SMA im Einsatz hat und selbst eine Überschussladung realisieren möchte: Der SMA Energy Meter 2.0 (bzw. Sunny Home Manager 2.0) sendet zyklisch UDP Multicast-Telegramme (608 Bytes) mit den aktuellen Messwerten und Zählerständen an die IP-Adresse 239.12.255.254, Port 9522. Ich habe daher ein kleines Modul zum Empfangen und Dekodieren dieser Daten implementiert, mit dem die Firmware des WARP-Chargers bzw. WARP Energy Managers entsprechend erweitert werden kann. Die aktuellen Daten werden per MQTT unter den Topics "sem20/values" bzw. "sem20/all_values" bereitgestellt und im Webinterface angezeigt: Bedient euch bei Bedarf gerne an meinem Fork des Repos... 🙂 Gruß Thomas

Stimmt, das "Post-Mortem-Debugging" hatte ich gar nicht mehr auf dem Schirm! Vielen Dank 🙂

Alles klar, vielen Dank. Aktuell arbeite ich weiter an einem Backend-Modul zum Auslesen der Daten des SMA Energy Meter / Home Manager 2.0, da passiert viel mit Arrays und Pointern und man hat schnell Abstürze provoziert, die ausschließlich mit Logging etwas mühselig zu finden sind. Vielleicht ist das Modul später auch mal für den WARP Energy Manager interessant...

Das hatte ich auch befürchtet. Die vorhandenen IO-Ports passen ja leider auch nicht wirklich (außer man könnte diese umdefinieren). @rtrbt, @photron: Wie debugged ihr den ESP32-Brick? Auch nur über Logging oder gibt es vielleicht ein "inoffizielles" Debug-Bricklet o. ä.? Danke & Gruß Thomas

Moin, das EVSE 2.0 Bricklet wird nicht benötigt, man muss aber die WARP2-Firmware so anpassen, dass das „alte“ Bricklet (und ggf. der Modbus-Zähler) unterstützt wird. Bei Bedarf kann ich die aber gerne zur Verfügung stellen… Gruß Thomas

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 Modedit: Veraltete Firmware entfernt.

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