rtrbt

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.

Sorry, den Post hatte ich übersehen. max_current_configured war der Wert, den du im Webinterface setzen kannst. Das ist jetzt evse/global_current.

Moin, EVCC kann Ladungen derzeit noch nicht Nutzern zuordnen, Gedanken zur Implementierung gibt es aber bereits: https://github.com/evcc-io/evcc/discussions/3190 Die Nutzerzuordnung läuft aber derzeit nur über NFC (bzw. über gefakte NFC-Tags über die API, das benutzt EVCC dann auch). Da die WARP1 Smart kein NFC-Bricklet hat (du kannst dir aber eins nachrüsten ;) ), kannst du erstmal keine Ladungen zu Nutzern zuordnen. Da wird es künftig aber sicherlich irgendeine Lösung geben. Habe dafür mal ein Issue aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/133

Hm da liest man seine eigenen Posts und merkt dass man Schwachsinn geschrieben hat. Bei WARP1 kann man das Bricklet schlecht an die Seitenwand kleben, da ist der Berührschutz im Weg. Wenn das Bricklet hinter dem Deckel ist, z.B. oben oder unten links, dann kann es ganz gut NFC-Tags lesen, die von oben bzw. unten an die Wallbox gehalten werden. Am besten machst du das Bricklet erst einmal temporär fest und probierst, ob die Tags gefunden werden. Das geht nach einem Neustart der Wallbox ohne Konfiguration, die LED in der Frontplatte blinkt mit dem "Tag nicht bekannt"-Muster wenn du irgendwelche Tags dranhältst.

Moin, Der Rückstellzeitpunkt wird jetzt gespeichert: https://github.com/Tinkerforge/esp32-firmware/commit/5656fc9bfa52740fb69c54cccfb0f5f485d2eed3 Die Funktion wird mit der nächsten Firmware-Version kommen. Du kannst dann auf meter/last_reset den Zeitpunkt (als Unix-Timestamp) abfragen.

Das ist bisher so. Der SDM72(V1) benutzt andere Register als der SDM630 und der SDM72V2. Möglicherweise baue ich den SDM630-Support aber noch ein. Ich melde mich Montag nochmal.

Das stimmt die Platte gibt es im Shop (noch?) nicht. Wenn du keine Lust auf Sägen hast kannst du, falls du Zähler und Bricklet bei uns bestellst, Bescheid sagen, dann legen wir dir eine Platte mit ins Paket.

Ja. Zähler und Kabel verkaufen wir beide als Ersatzteile: https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/stromzaehler-sdm630.html https://www.tinkerforge.com/de/shop/warp/warp2-spare-parts/jst-cable-for-sdm630.html Im Stromlaufplan steht, wie du das (RS485/JST)-Kabel anschließen musst: https://www.warp-charger.com/documents/WARP2_Stromlaufplan.pdf

Da hat dein Golf von sich aus entschieden, wieder zu laden. Alle Freigaben die die Wallbox macht (also z.B. Lastmanagement, NFC, Auto-Start usw.) bleiben freigegeben, bis entweder das Auto abgezogen wird oder die Freigabe widerrufen wird. D.h. wenn du händisch PV-Überschussladen machst, dann musst du auch händisch wenn die Sonne nicht mehr scheint die Freigabe wieder wegnehmen, eben durch Tag nochmal an die Box halten, im Webinterface auf Stop klicken, über die API usw. Sieh dir mal EVCC an, damit kannst du PV-Überschussladen automatisieren.