Steff49

Hallo @meierchen006 , ich habe nichts in Frage gestellt, ich wollte nur meine Meinung zum Ausdruck bringen, und die ist nun mal so, das ich auf diese - zugegebenermaßen - doch etwas exotische Möglichkeit in einer Wallbox verzichten kann. Klar das Ding hat einen Rechner aber wo fängst du an und wo hörst du auf? Ich bin mir halt auch sicher das die Leute bei Tinkerforge bestimmt eine ganze Menge in der Pipeline haben, und nicht jedem Wunsch gleich hinterher rennen können. Ich finde die machen einen guten Job und reagieren echt fix auf Fragen der User. Vielleicht gibt es ja später - wenn die Batteriespeicher-Steuerung einmal fix und fertig bei den meisten Usern sauber läuft - auf diese Wünsche einzugehen. Letztendlich geht es ja in diesem Thread um das Testen dieser Steuerung (die prinzipielle Funktion mit verschiedenen Setups), der Rest kommt (vielleicht) später. Gruß Steffen

Nachdem ich diesem Thread nun schon eine Weile folge, wollte ich auch meine Meinung dazu geben... Auch ich habe bei mir einen BYD-Speicher, der am Fronius Symo Gen24 hängt im Keller stehen. Ist das Balancing / BMS von BYD schlecht - keine Ahnung, da bin ich nicht wirklich im Thema. Ja, bei hoher Ladeleistung rennt die eine oder andere Zelle nach oben hin weg. Und ja ich kenne den Ellenlangen Thread im PV-Forum über das Laden der BYD-Akkus auch. Deshalb habe ich auch die Ladeleistung bei höherem SOC begrenzt - ob das wirklich zielführend ist sei mal dahingestellt. Das mache ich aber per Script im ioBroker, weil der eh im Keller vor sich hin werkelt. Ich finde aber, dass das (variable) Begrenzen der (Heimspeicher)-Ladeleistung (wie oben im Thread angesprochen) in einer Wallbox nichts zu suchen hat. Klar ein Entladen den Heimspeichers soll (sofern vom Nutzer gewünscht) verhindert werden. Die Wallbox soll schlicht und ergreifend das tun für was sie konzipiert ist, ein E-Auto Laden und das wenn möglich mit PV-Überschuss (sofern vorhanden) oder bei günstigem Strompreis - alles was darüber hinaus geht, gehört meiner Meinung nach in ein (übergeordnetes) System - ioB, HA, etc. Gruß Steffen

Ok, daran habe ich nicht gedacht. Dann mache ich den Schalter wieder aus. Vielen Dank für den schnellen Support!!

OK, hier mal ein Debug-Report vom gerade eben gestarteten Ladevorgang. Was mir aber noch aufgefallen ist: Ich hatte ja oben geschrieben, "....die WARP3 beginnt mit der Willkommensladung....", das macht sie aber erst NACHDEM ich den NFC-Tag drangehalten habe. Es fehlt im Grunde das gelbe bzw. später das grüne blinken der Status-LED. Und noch eines: Ich hab gerade gesehen, das ich unter Wallbox --> Einstellungen den Schalter "Status-LED-Steuerung" auf Ein habe. Ich steuere die Status-LED aber (noch) nicht von Extern. Blockiert dieser Schalter evtl. das "WARP3-interne" blinken? warp3-2cvd-Debug-Report-2025-12-16T17-33-51-538.txt

Hallo, mir ist aufgefallen, das sich an meinen beiden WARP3 (Firmwarestand: 2.8.13 + 690c79c0) die Status-LED auf ein mal anders verhält. Ich vermute das ist seit diesem Firmwarestand so (ist mir leider erst jetzt aufgefallen, weil ich selten geladen habe in letzter Zeit). Vorher war es so, dass nach dem Anstecken des Fahrzeugs die LED gelb geblinkt hat bis ein gültiger NFC-Tag erkannt wurde (grünes blinken). Jetzt beginnt die Wallbox mit der Willkommensladung ohne gelbes blinken. Wenn ich den NFC-Tag dranhalte kommt auch kein grünes blinken, der Tag wird aber erkannt, in der Weboberfläche wird der Name des Tag-Inhabers angezeigt. Kann das noch jemand bestätigen? Gruß Steffen

Ich habe euren Vorschlag mit der Automatisierungsregel nun umgesetzt und heute das erste mal das Fahrzeug damit geladen. Das sieht nun gut aus. Der Kuga beendet die Ladung und durch die Regel wird der Ladestrom in der WARP3 auf 6A reduziert. Das hin und her geschalte ist nun weg. Vielen Dank für die Hilfe. Gruß Steffen

@MatzeTF, danke für die Rückmeldung, ich werde das in den nächsten Tagen mit den Automatisierungsregeln probieren.

@rtrbt, kein Problem, hier ein Ladeprotokoll und ein Debug-Report vom aktuellen Ladevorgang. Der Kuga wurde bei knapp über 50% eingesteckt und hat dann bei 80% (mein eingestelltes Ladeziel) erreicht. Dann ging das hin und her wieder los. Gruß Steffen warp3-2cvd-Debug-Report-2025-11-11T17-27-28-736.txt warp3-2cvd-EVSE-Ladeprotokoll-2025-11-11T17-27-35-651.txt

Kein Stress, an eine Automatisierungsregel hatte ich auch schon gedacht, war mir aber unsicher wie ich das anpacken kann.

@borg, Mysteriös, der Fahrzeugweckruf ist aus 🤔 Den hatte ich noch nie ein.

Hallo, beim Laden meines Ford Kuga (2024) bekomme ich immer - wenn der Kuga sein Ladeziel erreicht hat - die folgenden Meldungen im Log: 2025-11-10 17:57:38,428 | users | Charger state changed from 2 to 3 2025-11-10 17:57:55,433 | users | Charger state changed from 3 to 2 2025-11-10 17:58:07,444 | users | Charger state changed from 2 to 3 2025-11-10 17:58:24,549 | users | Charger state changed from 3 to 2 2025-11-10 18:01:30,172 | users | Charger state changed from 2 to 3 2025-11-10 18:01:46,201 | users | Charger state changed from 3 to 2 2025-11-10 18:01:58,307 | users | Charger state changed from 2 to 3 2025-11-10 18:02:15,336 | users | Charger state changed from 3 to 2 2025-11-10 18:05:20,848 | users | Charger state changed from 2 to 3 Das zieht sich endlos hin, bis ich den (eigentlich ja beendeten)) Ladevorgang per Stop-Button beende. Gibt es eine Möglichkeit, dieses hin und hergeschalte weg zu bekommen? Im Anhang habe ich einmal ein Ladeprotokoll eingefügt. Gruß Steffen warp3-2cvd-EVSE-Ladeprotokoll-2025-11-10T20-03-29-649.txt

Ich denke ich habe das Problem gefunden. Meine Fritzbox bzw. das Netzteil dafür ist defekt. Bin da gerade noch am testen was es genau ist. Hab jetzt zuerst mal das Netzteil der FB getauscht und bisher ist keiner der o.g, Fehlermeldungen mehr im WARP3 Log aufgetaucht. Als du @rtrbt oben geschrieben hast, das es keinen Zusammenhang zwischen Fernzugriff und Modbus gibt, habe ich erst geschnallt, das mit remote_access ja der Fernzugriff und nicht der Modbus gemeint ist (Modbus ist ja modbus_tcp_srvr). Hab dann mal im FB Log nachgeschaut, und dort waren tatsächlich (kurze) Verbindungsabbrüche aufgezeichnet, die sich mit dem WARP3 Log gedeckt haben. Nach etwas Internetrecherche bin ich dann auf das FB-Netzteil gekommen. Das wäre auch das geringere Übel, eine neue FB ist gleich eine andere Hausnummer. Gruß Steffen

Kein Problem, die WARP3 funktioniert ja trotzdem problemlos. Was ich im Ersten Post nicht geschrieben habe ist, das sich meine zweite WARP3 (identische Firmware / etc.) genauso verhält. Es tauchen ebenfalls die beiden o.g. Meldungen auf. Gruß Steffen

Hallo, ich bin wahrscheinlich nicht wirklich richtig hier mit meinem Anliegen, aber ich hab seit einigen Wochen das Problem, das in meiner WARP3 Wallbox (Firmware: 2.8.8+68935bff) ständig (ca. alle 30 Sekunden) die Meldungen 2025-08-27 17:31:04,128 | remote_access | Management connection timed out 2025-08-27 17:31:33,449 | remote_access | Attempted connect_management again despite being done 2025-08-27 17:32:34,141 | remote_access | Management connection timed out 2025-08-27 17:33:03,507 | remote_access | Attempted connect_management again despite being done auftauchen. Die Wallbox funktioniert an sich problemlos. Ich "frage" die Wallbox per ioBroker MOD-Bus-Adapter ab. Drehe ich den Adapter ab ist sofort Ruhe im Log. Ein Update des MOD-Bus-Adapters kann ich ausschließen, da gab es in letzter Zeit keines. Ab wann die Meldungen so massiv wurden kann ich nicht mit Sicherheit sagen. Die Meldung "Management connection timed out" gab es (zumindest bei mir) ab und an mal vereinzelt im Log. Ich bin mir fast sicher, das die WARP da nix dafür kann. Aber hat vielleicht jemand von Euch eine Ahnung in welcher Richtung ich suchen kann/muss? Ein Debug-Log der WARP habe ich mal angehangen. Gruß Steffen warp3-2ev3-Debug-Report-2025-08-27T17-26-11-467.txt

Sieht unter Android auch gut aus. Werde morgen mal noch während eines Ladevorgangs ein bisschen testen.