poohnet

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