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.
Re: MQTT in der App für Status-Infos und zum steuern
Betreff: Home-Assistant-Paket – beliebige Fahrzeuge per MQTT anbinden und die App aus HA bedienen
Ich habe mir das ohnehin für meine eigene Installation gebaut, vielleicht kann es jemand brauchen. Zwei Dinge löst es:
**1. Fahrzeuge, die die App nicht direkt kennt**
Die App kann den SoC ja per MQTT entgegennehmen. Home Assistant hat für so ziemlich jeden Hersteller eine Integration, die den Ladezustand liefert – also reicht eine kleine Automation, die diesen Wert auf ein MQTT-Topic schreibt, und die App rechnet mit dem echten SoC statt mit einer Schätzung. Bei mir ein MG über die mg_saic-Integration, aber das Prinzip ist herstellerunabhängig: Was HA auslesen kann, kann die App darüber verwenden.
**2. Bedienung über die HA-Oberfläche**
Lademodus umschalten, Ladestrom vorgeben, starten und stoppen – alles über wallbox_control/command. Damit lässt sich die App aus HA heraus bedienen, ohne zum Handy zu greifen: als Kachel im Dashboard, per Sprachbefehl, oder eingebunden in eigene Automationen.
Die Regelungslogik bleibt dabei vollständig in der App. HA liefert nur den SoC und schickt Befehle, rechnet aber nichts selbst – zwei Regler auf derselben Einspeisung würden sich gegenseitig hochschaukeln. Es ist also eine Bedienoberfläche und eine Datenquelle, kein zweiter Regler.
=== Inhalt ===
Zwei Dateien, die Ordner im Archiv entsprechen den Zielpfaden unter <config>/:
packages/wallbox_app.yaml
blueprints/automation/soc_an_wallbox_app.yaml
Der SoC-Teil ist ein Blueprint – man wählt seinen Fahrzeugsensor in der Oberfläche aus, statt YAML zu editieren. Topic frei wählbar, muss nur mit dem übereinstimmen, was in der App unter Fahrzeugeigenschaften steht. Optional lässt sich auch das im Auto eingestellte Ladelimit übertragen, dann warnt die App, wenn ihr eigenes Ziel darüber liegt.
Das Package legt diese Entitäten an:
select.wallbox_lademodus Überschuss <-> Manuell, zeigt und schaltet
number.wallbox_ladestrom 6-16 A, zeigt und setzt
sensor.wallbox_app_grund Regelentscheidung im Klartext
sensor.wallbox_app_energiequelle gewählte Quelle
sensor.wallbox_app_aktive_quelle Quelle, die gerade wirklich lädt
sensor.wallbox_app_soc_limit_manuell SoC-Grenze fürs manuelle Laden
binary_sensor.wallbox_app_dienst_lauft Herzschlag der App
binary_sensor.wallbox_app_laedt lädt gerade
script.wallbox_manuell_laden_starten
script.wallbox_laden_stoppen
Den Herzschlag finde ich im Alltag am nützlichsten: Fällt der auf "aus", läuft der Dienst nicht mehr – ohne Meldung merkt man das erst, wenn tagelang aus dem Netz geladen wurde.
Dashboard-Karten sind bewusst nicht dabei, das baut sich ohnehin jeder nach seinem Geschmack.
=== Voraussetzungen ===
- App läuft als Fernbedienungsserver auf einem dauerhaft eingeschalteten Gerät
- Mindestens Build 2430, sonst gehen Befehle verloren (siehe weiter oben im Thread)
- MQTT-Broker, den App und HA beide erreichen
Die Einrichtung steht Schritt für Schritt in der README, samt der Stolpersteine, die mich selbst Zeit gekostet haben: IP-Adresse statt homeassistant.local, der runde Doppelpfeil statt des Test-Buttons, und der Schwall retained messages, der beim Mitschneiden wie eine Antwort aussieht.
=== Zwei Warnungen ===
Der Ladestrom-Regler sendet active=true mit. Wer ihn verstellt, startet damit die Ladung. Ist so gewollt – Strom einstellen heißt laden wollen –, aber nach "Laden stoppen" sollte man nicht daran drehen.
Und falls jemand den Retain-Workaround aus meinem älteren Beitrag übernommen hat: raus damit. Seit Build 2430 lauscht die App dauerhaft, eine liegengebliebene Retain-Nachricht greift jetzt bei jedem Verbinden sofort. Löschen mit leerem Payload und retain=true auf dasselbe Topic.
Getestet mit Build 2439, go-eCharger V3, HA Core 2026.8. Ob der Blueprint mit anderen Fahrzeugintegrationen sauber läuft, konnte ich nur mit meinem MG prüfen – Rückmeldungen dazu gern.
Ich habe mir das ohnehin für meine eigene Installation gebaut, vielleicht kann es jemand brauchen. Zwei Dinge löst es:
**1. Fahrzeuge, die die App nicht direkt kennt**
Die App kann den SoC ja per MQTT entgegennehmen. Home Assistant hat für so ziemlich jeden Hersteller eine Integration, die den Ladezustand liefert – also reicht eine kleine Automation, die diesen Wert auf ein MQTT-Topic schreibt, und die App rechnet mit dem echten SoC statt mit einer Schätzung. Bei mir ein MG über die mg_saic-Integration, aber das Prinzip ist herstellerunabhängig: Was HA auslesen kann, kann die App darüber verwenden.
**2. Bedienung über die HA-Oberfläche**
Lademodus umschalten, Ladestrom vorgeben, starten und stoppen – alles über wallbox_control/command. Damit lässt sich die App aus HA heraus bedienen, ohne zum Handy zu greifen: als Kachel im Dashboard, per Sprachbefehl, oder eingebunden in eigene Automationen.
Die Regelungslogik bleibt dabei vollständig in der App. HA liefert nur den SoC und schickt Befehle, rechnet aber nichts selbst – zwei Regler auf derselben Einspeisung würden sich gegenseitig hochschaukeln. Es ist also eine Bedienoberfläche und eine Datenquelle, kein zweiter Regler.
=== Inhalt ===
Zwei Dateien, die Ordner im Archiv entsprechen den Zielpfaden unter <config>/:
packages/wallbox_app.yaml
blueprints/automation/soc_an_wallbox_app.yaml
Der SoC-Teil ist ein Blueprint – man wählt seinen Fahrzeugsensor in der Oberfläche aus, statt YAML zu editieren. Topic frei wählbar, muss nur mit dem übereinstimmen, was in der App unter Fahrzeugeigenschaften steht. Optional lässt sich auch das im Auto eingestellte Ladelimit übertragen, dann warnt die App, wenn ihr eigenes Ziel darüber liegt.
Das Package legt diese Entitäten an:
select.wallbox_lademodus Überschuss <-> Manuell, zeigt und schaltet
number.wallbox_ladestrom 6-16 A, zeigt und setzt
sensor.wallbox_app_grund Regelentscheidung im Klartext
sensor.wallbox_app_energiequelle gewählte Quelle
sensor.wallbox_app_aktive_quelle Quelle, die gerade wirklich lädt
sensor.wallbox_app_soc_limit_manuell SoC-Grenze fürs manuelle Laden
binary_sensor.wallbox_app_dienst_lauft Herzschlag der App
binary_sensor.wallbox_app_laedt lädt gerade
script.wallbox_manuell_laden_starten
script.wallbox_laden_stoppen
Den Herzschlag finde ich im Alltag am nützlichsten: Fällt der auf "aus", läuft der Dienst nicht mehr – ohne Meldung merkt man das erst, wenn tagelang aus dem Netz geladen wurde.
Dashboard-Karten sind bewusst nicht dabei, das baut sich ohnehin jeder nach seinem Geschmack.
=== Voraussetzungen ===
- App läuft als Fernbedienungsserver auf einem dauerhaft eingeschalteten Gerät
- Mindestens Build 2430, sonst gehen Befehle verloren (siehe weiter oben im Thread)
- MQTT-Broker, den App und HA beide erreichen
Die Einrichtung steht Schritt für Schritt in der README, samt der Stolpersteine, die mich selbst Zeit gekostet haben: IP-Adresse statt homeassistant.local, der runde Doppelpfeil statt des Test-Buttons, und der Schwall retained messages, der beim Mitschneiden wie eine Antwort aussieht.
=== Zwei Warnungen ===
Der Ladestrom-Regler sendet active=true mit. Wer ihn verstellt, startet damit die Ladung. Ist so gewollt – Strom einstellen heißt laden wollen –, aber nach "Laden stoppen" sollte man nicht daran drehen.
Und falls jemand den Retain-Workaround aus meinem älteren Beitrag übernommen hat: raus damit. Seit Build 2430 lauscht die App dauerhaft, eine liegengebliebene Retain-Nachricht greift jetzt bei jedem Verbinden sofort. Löschen mit leerem Payload und retain=true auf dasselbe Topic.
Getestet mit Build 2439, go-eCharger V3, HA Core 2026.8. Ob der Blueprint mit anderen Fahrzeugintegrationen sauber läuft, konnte ich nur mit meinem MG prüfen – Rückmeldungen dazu gern.
- Dateianhänge
-
- wallbox-app-ha.zip
- (9.78 KiB) 1-mal heruntergeladen