rtrbt

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.

Das ist soweit beabsichtigt, ja. Die Ladezeit ist eher die Standzeit. Es könnte ja bzw. ist dir auch passiert, dass dein Fahrzeug Stunden nachdem der Akku voll war sich wieder soweit entladen hat, dass es wieder Strom ziehen wollte. Das wird auf den selben Ladevorgang aufgezeichnet. Deshalb endet der Ladevorgang erst wenn du das Fahrzeug abziehst, oder (falls du die NFC-Freigabe benutzt) wenn du mit dem selben Tag, dass den Ladevorgang erlaubt hat diesen beendest. Analog benutzen wir als Ladestart für die Aufzeichnung entweder den Zeitpunkt an dem das Fahrzeug angesteckt wurde (ohne NFC-Freigabe) bzw. den Zeitpunkt an dem ein Tag den Ladevorgang erlaubt hat (mit NFC-Freigabe).

Gibt noch nichts offizielles, nein. Du brauchst ein NFC-Bricklet, ein 7-Pol-Kabel, am besten 15cm (kannst du auf der Seite gleich dazu bestellen) und zur Befestigung etwas Spiegelklebeband. An der besten Positionierung scheiden sich die Geister, auf jeden Fall solltest du es eher von innen an eine der seitlichen Gehäusewände kleben, die Frontplatte ist geerdet, da geht NFC nicht durch.

Das ist interessant, auch mit den Infos aus diesem Thread. Ich hatte für die 2.0.0 (ohne Beta) und entsprechend auch die 2.0.1 kurzerhand noch WPA3-Unterstützung mit reinkompiliert. Mich wundert vor allem, dass die Unterstützung in den Betas nicht enthalten war, d.h. wenn da etwas klemmt dürfte es eigentlich nicht davor aufgetreten sein. Ich habe aber gestern im privaten Umfeld mitbekommen, dass Fritzboxen wohl Probleme beim WPA2+WPA3-Modus haben. Siehe hier: https://bbs.archlinux.org/viewtopic.php?id=273651 und https://lists.infradead.org/pipermail/hostap/2022-February/040209.html Es ist wohl so, dass die Fritzboxen sich nicht an die Spezifikation halten, laut https://lists.infradead.org/pipermail/hostap/2022-February/040212.html und dass die Probleme teilweise auch im WPA2-Only-Modus auftreten: https://bugzilla.opensuse.org/show_bug.cgi?id=1195395#c40 Wenn ich die aufgelaufenen Sachen aus meiner Urlaubswoche aufgeholt habe teste ich auf jeden Fall nochmal alle Varianten durch. Es bleibt spannend ;)

Theoretisch geht das. Es gibt aber zwei Probleme: 1. Der Platz: Die LAN-Buchse des Ethernet Bricks ist höher, deshalb kannst du ihn nicht auf den Berührschutz in einer WARP1 schrauben, außerdem musst du für das LAN-Kabel ein Loch ins Gehäuse bohren. Je nach persönlichem Anspruch an rumfliegende Platinen ist das eventuell machbar. 2. Die Firmware: Die WARP1-Firmware unterstützt kein Ethernet, die WARP2-Firmware nicht den "alten" Ladecontroller der in der WARP1 verbaut ist. Du kannst dir aber eine Firmware kompilieren, mit der das funktionieren müsste. Dazu musst du dir das Firmware-Git klonen und dann in der platformio.ini das WARP-Environment so ändern, dass du bei den Backend-Modulen statt ESP32 Brick ESP32 Ethernet Brick benutzt und zusätzlich das Ethernet-Backend- und -Frontend-Modul reinbaust. (Das kannst du dir am WARP2 Environment weiter unten abschauen) Das ist alles nicht offiziell unterstützt und auf eigene Gefahr. Falls du dir das aber hacken willst und dabei Firmware-Probleme findest, gib gerne Bescheid.

Wenn du es noch ein paar Mal probierst sollte es klappen. Es gab in der alten Firmware zwei Bugs die verkettet dazu führen, dass fälschlicherweise dieser Fehler ausgegeben wird. In Wirklichkeit bricht nur die Verbindung weg, über die das Update übertragen wird, das ist aber nicht so kritisch wie die Fehlermeldung es vermuten lässt.

Ich verstehe nicht, was du mir damit sagen willst. Ich fürchte etwas mehr Kontext musst du schon bieten, damit man dir helfen kann. Programmierst du gegen die API oder machst du direkt Dinge im Browser, so wie du es in deinem anderen Thread geschrieben hattest? Wenn du ein Programm schreibst in welcher Sprache? Warum weist du Fehlermeldungen der Wallbox auf eine Variable zu?