Re: MQTT in der App für Status-Infos und zum steuern
Verfasst: 11.Aug 2026, 05:49
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.
=== 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.