rtrbt

Kurzes Update zu den "Ignore unknown configuration option"-Warnungen: Stellt sich raus das die Warnungen nicht kommen, wenn die Optionen die man einfügt mit custom_ anfangen. Das habe ich zumindest gerade aus dem platformio-core Code gekratzt: https://github.com/platformio/platformio-core/blob/c0cfbe2ce0e62f37708f16b4d5496dad009b6364/platformio/project/config.py#L158 Dementsprechend habe ich die Optionen alle umbenannt: https://github.com/Tinkerforge/esp32-firmware/commit/349be90e0f1839d7b6837aa6b6073cc52e690b58 Danke für den Anstoß ;)

Ja das ist höchst wahrscheinlich das Problem. Falls du über das Webinterface kein Firmware-Update mehr hochladen kannst, geh stattdessen mal auf http://10.0.0.1/recovery

Moin Andreas, Kann es sein, dass dir diese Datei von VSCode angelegt wurde? Im Repo gibt es die nicht. Wenn du mit VSCode nicht den Repo-Ordner selbst, sondern den Software-Unterordner öffnest, dann sollte es das eigentlich verstehen. lib gibt es nicht, weil alle Abhängigkeiten in der platformio.ini (bzw. in den .ini-Dateien pro Firmware-Typ, in pio-Sprech "environment", also z.B. warp2.ini) angegeben sind. Wir liefern im Repo selber keine Bibliotheken aus. include gibt es nicht, alle Header liegen mit in src. Das ist sicherlich Geschmackssache, aber es wird ja eine Firmware gebaut, das ganze wird keine Bibliothek bei der man ein öffentliches Interface über Header definiert. Prinzipiell ist das korrekt, alle Befehle in software auszuführen. Die Warnungen kannst du ignorieren, pio unterstützt Custom Options (dokumentieren sie sogar!), aber trotzdem wird, sobald man die verwendet diese Warnung ausgegeben. Bekommst nach den ganzen Warnungen (und dem Teil der tatsächlich etwas tut) folgendes? Environment Status Duration ------------- -------- ------------ prepare SUCCESS 00:00:00.507 (Zeit darf variieren, bei mir musste das gerade nichts tun) Falls ja sollte pio run -e warp2 (im software-Verzeichnis) funktionieren.

Sowohl als auch. Der SDM72 V2-Support ist tatsächlich sehr neu. Der SDM630 misst außerdem ein paar Werte mehr. Zum Beispiel Phasenwinkel, Total-Harmonic-Distortion-Werte und ein paar Mittelwerte über ein konfigurierbares Intervall.

Kurzer Einwurf: Damit global_current gesetzt werden kann musst du die externe Steuerung nicht aktivieren. Das brauchst du nur, wenn du evse/external_current benutzt und der Ladecontroller das auch berücksichtigen soll. Prinzipiell wäre es aber eine gute Idee auf external_current zu wechseln, global_current ist der Strom, der auch im Webinterface gesetzt werden kann. Die beiden Eingaben (also was der Nutzer möchte und was die IOBroker-Steuerung) zu trennen ist hilfreich, damit sich nicht beide Seiten permanent überschrieben.

Ah sorry, die Addresseinstellung hatte ich vergessen zu erwähnen. Das ist eine gute Erklärung, warum es erst nicht geklappt hat. Da musst du eventuell bei EVCC nochmal fragen, aber ja das liegt vermutlich daran, dass kein EV angeschlossen ist. EVCC fragt periodisch bei der Wallbox ab, ob eins eingesteckt ist.

Moin, Ich habe den Code etwas umgebaut, so funktioniert es bei mir: <?php $d1 = $_GET["d1"]; if ($d1 == 'ein'){ $url = "http://192.168.0.140/evse/start_charging"; senden($url, "null"); } if ($d1 == 'aus'){ $url = "http://192.168.0.140/evse/stop_charging"; senden($url, "null"); } if ($d1 == '6A'){ $url = "http://192.168.0.140/evse/global_current_update"; senden($url, '{"current": 6000}'); } if ($d1 == 'strom'){ $url = "http://192.168.0.140/evse/global_current"; echo senden($url, ''); } function senden($url, $payload) { $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_ENCODING, "utf-8"); if ($payload != "") { // Payload ist nicht leer, wir wollen Daten zur Wallbox schicken. Benutze PUT und setze payload curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json','Content-Length: ' . strlen($payload))); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'PUT'); curl_setopt($ch, CURLOPT_POSTFIELDS, $payload); } else { // Payload ist leer, wir wollen Daten von der Wallbox empfangen. Benutze GET curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET'); } $content = curl_exec($ch); $ergebnis = curl_error ($ch ); echo $ergebnis."\r\n"; curl_close($ch); return $content; } ?> Ich habe den Code, der die Dateien liest und schreibt erstmal weggelassen, habe ja nicht die selben Dateien bei mir wie du. Die senden-Funktion bekommt die Daten, die sie schicken soll übergeben, wenn du da einen leeren String übergibst, kannst du stattdessen Daten von der Wallbox lesen. Zusätzlich zu ?d1=ein und ?d1=aus habe ich eingebaut, dass du das Script mit ?d1=6A, aufrufen kannst (als Beispiel für komplexere Daten), damit wird der Ladestrom auf 6 Ampere gesetzt. Außerdem kannst du auch ?d1=strom benutzen, als Beispiel, wie du Daten von der Wallbox lesen kannst. Damit wird der Strom wieder abgefragt. Das ist der selbe Ladestrom, den du auf dem Webinterface der Wallbox sehen kannst. Für MQTT musst du erst einen Broker aufsetzen und die Verbindung auf der Wallbox konfigurieren. Prinzipiell funktioniert die Benutzung über MQTT dann aber fast genauso wie die über HTTP. Also wenn du z.B. über HTTP den Ladestrom auf 8 Ampere setzen willst, musst du {"current": 8000} an http://192.168.0.140/evse/global_current_update schicken. Über MQTT kannst du die selben Daten, also {"current": 8000} an warp/AbC/evse/global_current_update schicken. warp/AbC ist dabei der Präfix, den du auf der MQTT-Seite der Wallbox konfigurieren kannst. Zum Schicken per MQTT kannst du z.B. mosquitto_pub benutzen. Es gibt hier: https://www.warp-charger.com/api.html#mqtt_section noch ein paar Erklärungen zur Verwendung davon.

Also have a look at https://rpilocator.com/

Firmware: WARP 2.0.4 und WARP2 2.0.4 Unbenutzbares Webinterface durch WebSocket-Race-Condition repariert Download: WARP 2.0.4 bzw. WARP2 2.0.4

Falls du Commit a6ca582a hast: Ruf mal http://123.123.123.123/info/ws auf und ziehe dann über http://123.123.123.123/event_log das Log runter (IP ersetzen nicht vergessen ;) ) Ich würde erwarten, dass du am Ende Ausgabe mit worker_active yes und queue_len > 0 bekommst. Falls ja, dann hast du die Race Condition getroffen, die ich auch gerade gefunden habe. Fix ist hier https://github.com/Tinkerforge/esp32-firmware/commit/7b28f480 Firmware 2.0.4 kommt gleich.

Prinzipiell ist es so, dass du über einen Master Brick ~ 1000 Nachrichten pro Sekunde verarbeiten kannst. D.h. wenn du z.B. nur Getter benutzt schaffst du nur 500 Abfragen pro Sekunde, weil das ja die Abfrage-Nachricht und die Antwort involviert. Deshalb sind die Callbacks effizienter. Theoretisch kannst du jetzt also durchrechnen, wie viele Nachrichten das Continuous-Acceleration Callback bei deiner Konfiguration erzeugt, z.B. wie folgt: In einer Nachricht sind bei 16-Bit Messwerten 30 Werte enthalten D.h. bei 1000 Nachrichten pro Sekunde schaffst du es 30000 Messwerte rauszuziehen D.h. wenn du z.B. zwei Achsen verwendest kannst du pro Achse und Sekunde 15000 Messwerte verwenden -> 15000 Hz ist die maximal sinnvolle Messfrequenz, konfigurieren kannst du dann 12800 Hz (So werden z.B. die Werte in der Tabelle hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/AccelerometerV2_Bricklet_Python.html#BrickletAccelerometerV2.set_continuous_acceleration_configuration berechnet) Wenn du jetzt das Counter-Bricklet parallel abfragen willst (sinnvollerweise auch per Callback), musst du von den verfügbaren 1000 Nachrichten in der Rechnung so viele abziehen, wie du für den Counter zur Verfügung haben willst. Wenn du z.B. alle 10 Millisekunden den aktuellen Encoder-Wert bekommen willst, heißt dass, dass 100 Nachrichten vom Counter-Bricklet erzeugt werden. Du kannst dann also nur noch 900 Nachrichten für das Accelerometer-Bricklet verwenden, also 27000 Messwerte, bei zwei Achsen also max. 13500 Hz, d.h. die (konfigurierbaren) 12800 Hz schaffst du weiterhin. Soweit die Theorie. In der Praxis musst du das dann natürlich ausprobieren und gegebenenfalls die Timings nicht ganz so eng wählen. Falls sich Nachrichten beim Brick aufstauen, kann es passieren, dass du dann veraltete Werte bekommst. Noch ein paar Performance-Optimierungs-Ideen: Du kannst die Datenrate der Kommunikation zwischen Master und Bricklets erhöhen: https://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Python.html#BrickMaster.set_spitfp_baudrate. Der Default sind 1,4 MHz, je nach Bricklet sind aber bis zu 2 MHz drin. Falls du einen Raspberry Pi und ein HAT Brick zur Hand hast, kannst du versuchen die Bricklets da anzuschließen. Der Pi kann, je nach Modell, in Summe mehr als 1000 Nachrichten pro Sekunde von allen angeschlossenen Bricklets lesen.

Stand jetzt nicht. Das steht aber auf der (langen) Liste an Features die wir eventuell implementieren. Wie wir das konkret umsetzen ist aber noch unklar.

Hast du die aktuelle Firmware (2.0.3) installiert? Die brauchst du, damit der SDM72 V2 unterstützt wird. Ansonsten prüfe nochmal die Verkabelung, aus persönlicher Erfahrung weiß ich, dass man die Kabel sehr gut vertauschen kann. Das EVSE sollte die Standardparameter des Zählers kommunizieren, also Half-Duplex, 9600 Baud, 8N1.

Ah ich glaube ich sehe das Problem: Du kompilierst noch gegen arduino-esp mit dem Stand von WARP 2.0.0: https://github.com/poohnet/esp32-firmware/blob/9c79722309dc1e29b3142aacdb87cfb2159bbce6/software/poohnet_warp.ini#L4 Wenn du da auf file://packages/arduino-esp32-warp-2.0.2 wechselst und die update_packages.py aus unserem Repo nachziehst, sollte es wieder funktionieren. Das Problem ist, dass in arduino-esp32 eine vorkompilierte Variante des esp-idf eingebettet ist. Ich habe für die Wallbox-Firmware einen Fork angelegt, damit ich eigene Versionen vom esp-idf einbetten kann, da wir ein paar Patches fahren müssen (die liegen hier: https://github.com/Tinkerforge/esp32-firmware/tree/master/software/patches) Nach dem 2.0.0 Release ist ein Patch dazugekommen, der sicherstellt, dass der Web-Server vom ESP-IDF meinen Code benachrichtigt wenn ein WebSocket-Close-Frame empfangen wird. Wenn der Patch fehlt, dann funktioniert die Keep-Alive-Logik nicht sauber und die Verbindungen funktionieren irgendwann nicht mehr. Ich setze hier trotzdem mal einen Langzeittest auf, nicht dass es unabhängig davon noch einen Bug mit dem MQTT-Stromzähler gibt.

Moin, In WARP 2.0.3 ist ein experimenteller Support für den SDM630 und den SDM72DM V2 enthalten. Experimentell deshalb, weil man die Zähler auf 3-phasigen bzw. 1-phasigen Betrieb konfigurieren muss und die Firmware das noch nicht kann. D.h. das musst du erstmal selbst von Hand machen, wie in der Anleitung des SDM630 beschreiben. D.h. zuerst (Seite 8) das Passwort eintippen damit du in die Einstellungen kommst (falls du es nicht verändert hast ist das 1000) und dann (Seite 11 unten) SYS auf 3p4 (dreiphasig mit Neutralleiter) oder 1p2 (einphasig mit Neutralleiter) konfigurieren.

Firmware: WARP 2.0.3 und WARP2 2.0.3 Sichtbarkeit der WLAN-Scan-Ergebnisse repariert Download: WARP 2.0.3 bzw. WARP2 2.0.3

Firmware: WARP 2.0.2 und WARP2 2.0.2 Behandlung der WebSocket-Verbindungen komplett überarbeitet API zum Einfügen der Werte eines externen Zählers hinzugefügt WARP2: Unterstützung für SDM72DM V2 hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.3) WARP1: Experimentelle Unterstützung für SDM630 und SDM72DM V2 hinzugefügt Ladecontroller-Einstellungen werden bei Reset auf Werkseinstellungen oder Konfigurations-Reset auch zurückgesetzt (durch Update auf Ladecontroller-Firmware 2.1.1 (WARP) bzw. 2.1.3 (WARP2)) Unterseiten-Überschriften am oberen Rand verankert Speichern-Button von Konfigurations-Unterseiten neben die Überschrift bewegt Scroll-Verhalten bei Unterseiten-Wechsel in Chrome repariert Download eines leeren Ladeprotokolls repariert Download: WARP 2.0.2 bzw. WARP2 2.0.2

Bevor du gleich über die halb-fertigen Forms im Webinterface stolperst: Es kommen gleich noch ein paar Commits ;)

Hm in der API-Dokumentation ist das auf jeden Fall veraltet, wenn du Auto-Start per evse/auto_start_charging_update deaktivierst sollte es auch aus bleiben. Der Code sieht soweit auch sinnvoll aus: https://github.com/Tinkerforge/esp32-firmware/blob/e664dd7ede9021185c7eca8871ffc5cd705d73e5/software/src/modules/evse_v2/evse_v2.cpp#L750-L772 Ich habe das gerade nochmal mit der Box auf meinem Tisch getestet, fairerweise: mit dem aktuellen Stand im Git, nicht der 2.0.1, wie sie veröffentlicht ist. Aber die Stelle haben wir das letzte Mal vor drei Monaten verändert. Wenn ich Auto-Start im Webinterface abschalte, die Box vom Strom trenne und wieder hochfahre, dann ist es weiterhin aus. Da du das über MQTT machst: Hast du eventuell Nachrichten retained, die entweder Auto-Start wieder aktivieren oder zumindest Home Assistant so verwirren, dass dir angezeigt wird, dass das der Fall ist?

Moin Thomas, Geh mal mindestens auf diesen Commit https://github.com/Tinkerforge/esp32-firmware/commit/8839c4f65a1b78e17ccfe419c5eca638ea074df5. Ich habe in den letzten Wochen recht viel an den WebSockets gearbeitet, du bist da auf einem Zwischenstand, bei dem es noch einen Bug in der Verbindungsbehandlung gab. Wie üblich: Falls es dann immer noch kaputt ist, bitte nochmal Bescheid sagen ;) Grüße, Erik

Moin Thomas, Das ist soweit bekannt, ja. Das EnergyMeter-Modul ist noch nicht robust dagegen, wenn man eins der Wert-Updates aufruft, bevor das State-Update kam. Ist noch in Arbeit ;) Grüße, Erik

Moin, Das ist die Funktion des RS232 (1.0) Bricklets, du benutzt aber sonst immer die vom RS232 2.0. Folgendes sollte funktionieren: rs232_v2_set_configuration(reinterpret_cast<RS232V2 *>(psTemp_Device->vDevice), 115200, RS232_V2_PARITY_EVEN, RS232_V2_STOPBITS_1, RS232_V2_WORDLENGTH_8, RS232_V2_FLOWCONTROL_OFF);

Das klingt nach einer guten Idee. Wir müssen damit intern mal experimentieren, auch wie die Kompatibilität nicht nur zu Home Assistant, sondern auch zu z.B. openHAB ist. Ich habe mal ein Issue aufgemacht, damit der Gedanke nicht verloren geht: https://github.com/Tinkerforge/esp32-firmware/issues/135

Wenn du 100% sichergehen willst warte mal noch bis ~ nächsten Montag. Ich muss noch ein bis zwei Details klären, dann kann ich wilde Versprechungen geben, wann das fertig ist.

Ich habe mir das mal angesehen, Support für die beiden neueren Zähler hinzuzufügen sollte kein größeres Problem sein (Ein Prototyp für dem SDM630 ist schon im Repository). Kommt mit einer der nächsten Firmware-Versionen.