Kurzes Update für alle, die auf dasselbe gestoßen sind: Christian hat mir eine Testversion gebaut, und der Fall aus meinem letzten Beitrag ist damit erledigt.
=== Was das Problem war ===
Die App hat wallbox_control/command nur in kurzen Schüben abonniert und sich danach wieder abgemeldet – Fenster von zwei bis dreiundzwanzig Sekunden, dazwischen nichts. Insgesamt war sie in einem 27-Minuten-Fenster rund 80 Sekunden empfangsbereit, also etwa 5 % der Zeit. Bei retain=false verwirft der Broker eine Nachricht, für die gerade kein Abonnent da ist, spurlos. Deshalb blieben ALLE Befehle wirkungslos – auch dumpStates.
=== Was jetzt passiert ===
Mit Build 2430 lauscht die App dauerhaft. Gemessen heute Morgen, Befehle jeweils OHNE retain-Flag:
dumpStates
07:37:30.715 Befehl auf wallbox_control/command
07:37:30.746 Antwort der App (cars/current)
= 31 ms
controlmode -> manual
07:38:19.122 Befehl auf wallbox_control/command
07:38:19.159 state/autoControlActive = false
= 37 ms
danach ca. 6 s später der vollständige Zustand, u.a. energySourceSelectedUI = "Manuelle Steuerung"
controlmode -> auto
sauber zurückgeschaltet
Damit ist die Fernsteuerung aus Home Assistant heraus praktisch nutzbar geworden. Der retain-Workaround, den ich mir vorher gebaut hatte (Befehl mit retain=true absetzen, warten bis die App das nächste Mal abonniert, danach die Retain-Nachricht mit leerem Payload wieder löschen), ist nicht mehr nötig. Wer ihn noch verwendet, sollte ihn ausbauen – eine liegengebliebene Retain-Nachricht wird sonst bei jedem Verbinden erneut ausgeführt.
=== Noch offen ===
Der Parameter "current" wird weiterhin nicht ausgewertet:
{"cmd":"controlmode","param":{"mode":"manual","active":false,"current":8}}
Darauf folgt keinerlei Reaktion, state/manualChargeCurrentA bleibt unverändert. Der Kontrast ist eindeutig: derselbe Befehl ohne "current" quittiert in 37 Millisekunden, mit "current" kommt gar nichts. Christian hat angekündigt, sich die weiteren Punkte anzuschauen.
Ebenfalls noch offen: results/cause kippt im Überschussmodus etwa im 5-Sekunden-Takt zwischen ENOUGH_POWER und NOT_INITIALIZED, während die Ladeleistung um rund 2300 W schwingt.
=== Zwei Tipps aus der Praxis ===
"active": false sperrt die Wallbox, statt zu laden. Damit lässt sich der Modus gefahrlos umschalten, ohne dass ein Ampere fließt – sehr zu empfehlen beim Testen. Mit "active": true legt die Wallbox sofort los, bei mir waren das beim ersten Versuch unfreiwillig 10,5 kW dreiphasig.
Und zur Messmethode, weil ich selbst darauf hereingefallen bin: Beim Abonnieren von wallbox_control/# liefert der Broker sofort einen großen Schwall retained messages. Das sieht aus wie eine Antwort auf dumpStates, ist aber keine. Wer prüfen will, ob Befehle ankommen, lässt den Mitschnitt erst laufen, bis Ruhe herrscht, und sendet dann.
Danke an Christian für die schnelle Umsetzung.
MQTT in der App für Status-Infos und zum steuern
Moderator: c2j2
Re: MQTT in der App für Status-Infos und zum steuern
Nachtrag: Auch die beiden Punkte, die ich oben noch als offen hatte, sind erledigt. Christian hat Build 2439 nachgelegt (laut ihm demnächst auch im Play Store), und damit funktioniert "current" und das NOT_INITIALIZED-Flackern ist weg.
=== 1) "current" wird jetzt übernommen – und liegt real an ===
Getestet mit laufender Ladung, bewusst mit active:true, um nicht nur die Quittung, sondern den tatsächlichen Strom zu sehen:
{"cmd":"controlmode","param":{"mode":"manual","active":true,"current":8}}
Vorher (Überschussmodus, einphasig):
state/manualChargeCurrentA = 16.0
Phasenströme 6,5 / 0 / 0 A, 1520 W
Nachher:
state/manualChargeCurrentA = 8.0 (nach unter 30 Sekunden)
Phasenströme 7,9 / 7,5 / 7,3 A, 5340 W
3 x 8 A x 230 V sind rechnerisch 5520 W, gemessen 5340 W – passt. Der Wert wird also nicht nur quittiert, er wird auch gestellt.
=== 2) NOT_INITIALIZED ist weg ===
Das läuft bei mir seit dem 6. August als Dauermessung mit, ich kann also vorher/nachher direkt gegenüberstellen. Gezählt werden Zustandswechsel von results/cause:
16.08., 11 Stunden, alte Version: 602 Wechsel
17.-18.08., 22 Stunden, Build 2439: 12 Wechsel
Am 16.08. lief das über eine halbe Stunde durchgehend im 5- bis 15-Sekunden-Takt zwischen ENOUGH_POWER und NOT_INITIALIZED. Nach dem Update taucht NOT_INITIALIZED nur noch zweimal auf, jeweils kurz beim Ladestart (11 bzw. 26 Sekunden), danach stabil. Das wirkt wie ein plausibler Initialisierungszustand und nicht mehr wie ein Fehler.
Die Regelung ist entsprechend ruhig geworden. Ladeleistung heute früh über sechs Minuten im Überschussmodus:
1520 / 1500 / 1480 / 1490 / 1500 / 1490 / 1500 / 1510
1500 / 1520 / 1730 / 1720 / 1510 / 1740 / 1730 / 1950
Also rund +/- 220 W, das entspricht genau einer 1-A-Stufe. Zum Vergleich der Stand vom 6. August: 1530 -> 3830 -> 1540 -> 3880 W, also +/- 2300 W. Seit dem Update kein einziger Ladeabbruch mehr.
=== Neue Topics in 2439 ===
Mir sind beim Mitschneiden Topics aufgefallen, die ich vorher nicht hatte – unter wallboxes/<guid>/current_data/:
currentStr Phasenströme im Klartext, Format "6,1 A / 5,8 A / 5,7 A"
currentA Summenstrom
powerW Leistung
sessionEnergyWh Energie der laufenden Sitzung
totalEnergyWh Zählerstand
remainingEnergyWh Restenergie bis zum Ladeziel
und unter cars/<guid>/current_data/battery/ zusätzlich estSoc. Gerade remainingEnergyWh finde ich fürs Dashboard nützlich. Achtung beim Einbinden: Die senden im 5-Sekunden-Takt, wer sie in Home Assistant als Sensor anlegt, sollte an den Recorder denken.
=== Was gleich geblieben ist ===
Ein Moduswechsel schaltet weiterhin von ein- auf dreiphasig, und die Rückschaltung unterliegt der internen Sperrzeit. Das halte ich nach wie vor für richtig so – man sollte nur wissen, dass dreiphasig 6 A Mindeststrom eben 4,1 kW bedeuten. Bei mir hat die Wallbox nach dem Test noch einige Minuten dreiphasig weitergeladen und dabei Netzstrom gezogen, bis die Sperrzeit abgelaufen war. Wer mit wenig Überschuss testet, sollte das einplanen.
Und eine Beobachtung am Rande: Die App schreibt den Ladestrom offenbar nicht über das amp-Feld der Wallbox. Bei mir stand die entsprechende go-e-Entität unverändert auf 6, während real 8 A flossen. Das erklärt rückwirkend eine Diskrepanz, über die ich schon vorher gestolpert war.
Damit sind von meiner Seite alle Punkte abgearbeitet. Danke Christian, das war eine sehr angenehme Zusammenarbeit – vom ersten Befund bis zum Fix keine zwei Wochen.
=== 1) "current" wird jetzt übernommen – und liegt real an ===
Getestet mit laufender Ladung, bewusst mit active:true, um nicht nur die Quittung, sondern den tatsächlichen Strom zu sehen:
{"cmd":"controlmode","param":{"mode":"manual","active":true,"current":8}}
Vorher (Überschussmodus, einphasig):
state/manualChargeCurrentA = 16.0
Phasenströme 6,5 / 0 / 0 A, 1520 W
Nachher:
state/manualChargeCurrentA = 8.0 (nach unter 30 Sekunden)
Phasenströme 7,9 / 7,5 / 7,3 A, 5340 W
3 x 8 A x 230 V sind rechnerisch 5520 W, gemessen 5340 W – passt. Der Wert wird also nicht nur quittiert, er wird auch gestellt.
=== 2) NOT_INITIALIZED ist weg ===
Das läuft bei mir seit dem 6. August als Dauermessung mit, ich kann also vorher/nachher direkt gegenüberstellen. Gezählt werden Zustandswechsel von results/cause:
16.08., 11 Stunden, alte Version: 602 Wechsel
17.-18.08., 22 Stunden, Build 2439: 12 Wechsel
Am 16.08. lief das über eine halbe Stunde durchgehend im 5- bis 15-Sekunden-Takt zwischen ENOUGH_POWER und NOT_INITIALIZED. Nach dem Update taucht NOT_INITIALIZED nur noch zweimal auf, jeweils kurz beim Ladestart (11 bzw. 26 Sekunden), danach stabil. Das wirkt wie ein plausibler Initialisierungszustand und nicht mehr wie ein Fehler.
Die Regelung ist entsprechend ruhig geworden. Ladeleistung heute früh über sechs Minuten im Überschussmodus:
1520 / 1500 / 1480 / 1490 / 1500 / 1490 / 1500 / 1510
1500 / 1520 / 1730 / 1720 / 1510 / 1740 / 1730 / 1950
Also rund +/- 220 W, das entspricht genau einer 1-A-Stufe. Zum Vergleich der Stand vom 6. August: 1530 -> 3830 -> 1540 -> 3880 W, also +/- 2300 W. Seit dem Update kein einziger Ladeabbruch mehr.
=== Neue Topics in 2439 ===
Mir sind beim Mitschneiden Topics aufgefallen, die ich vorher nicht hatte – unter wallboxes/<guid>/current_data/:
currentStr Phasenströme im Klartext, Format "6,1 A / 5,8 A / 5,7 A"
currentA Summenstrom
powerW Leistung
sessionEnergyWh Energie der laufenden Sitzung
totalEnergyWh Zählerstand
remainingEnergyWh Restenergie bis zum Ladeziel
und unter cars/<guid>/current_data/battery/ zusätzlich estSoc. Gerade remainingEnergyWh finde ich fürs Dashboard nützlich. Achtung beim Einbinden: Die senden im 5-Sekunden-Takt, wer sie in Home Assistant als Sensor anlegt, sollte an den Recorder denken.
=== Was gleich geblieben ist ===
Ein Moduswechsel schaltet weiterhin von ein- auf dreiphasig, und die Rückschaltung unterliegt der internen Sperrzeit. Das halte ich nach wie vor für richtig so – man sollte nur wissen, dass dreiphasig 6 A Mindeststrom eben 4,1 kW bedeuten. Bei mir hat die Wallbox nach dem Test noch einige Minuten dreiphasig weitergeladen und dabei Netzstrom gezogen, bis die Sperrzeit abgelaufen war. Wer mit wenig Überschuss testet, sollte das einplanen.
Und eine Beobachtung am Rande: Die App schreibt den Ladestrom offenbar nicht über das amp-Feld der Wallbox. Bei mir stand die entsprechende go-e-Entität unverändert auf 6, während real 8 A flossen. Das erklärt rückwirkend eine Diskrepanz, über die ich schon vorher gestolpert war.
Damit sind von meiner Seite alle Punkte abgearbeitet. Danke Christian, das war eine sehr angenehme Zusammenarbeit – vom ersten Befund bis zum Fix keine zwei Wochen.