MQTT in der App für Status-Infos und zum steuern

[c2j2]

Hm, eigentlich trivial.. IP Adresse eingeben und "Test"... Mehr später, bin in Kanada im RV.

[Fossilbaer]

Danke, so war es dann erfolgreich. Erste Testdaten habe ich auch schon austauschen können.

Meine Pläne: Meinen Zweitwagen, der kein eigenes Ladelimit kennt (MINI) nur bis 9x % laden und dazu die Daten der Anbindung in HA als Steuerung nutzen.

Eine Art Fernsteuerung für die Überschuss - App über HA, den wir über VPN auch aus der Ferne erreichen können.

[c2j2]

Wenn Du im HA den SoC des Mini hast, nutze MQTT, worüber sie den SoC vom HA bekommt (SoC Abfrage 'MQTT"), dann macht meine App das automatisch.

Ferngesteuert werden kann die App auch...

[Fossilbaer]

Hallo Christian!

Ich habe die Stelle dafür unter den "Fahrzeugeigenschaften" gefunden-
Der Dialog ist ja ähnlich der "Haupt-Einrichtung MQTT". Allerdings fehlt der Button "Test".
Wenn ich die Adresse & Zugangsdaten speichere, den Dialog verlasse und wieder hineingehe sind die Felder wieder leer.

[c2j2]

danke - ich schaue mir das die nächsten Tage an... Bin noch am Aufarbeiten der Sachen, die während meines Urlaubs liegen geblieben sind. Seltsam, das mit dem Dialog.

[c2j2]

Ah klar. Der "Test"-Button dient zum Versand von Test-Daten an den MQTT-Server. Du musst den runden Doppelpfeil neben der Zertifikatseinstellung drücken für einen Verbindungsaufbau. OK, ist etwas unübersichtlich, das ändere ich noch.

[rekker]

Hallo Christian,

die App weist darauf hin, dass die MQTT-Struktur überarbeitet wurde, und verlinkt auf diesen Thread. Der inhaltliche Stand hier ist der Beitrag vom 22.01.2026 ("ab Build 2123"), ich bin auf 2.306.2422. Ich habe deshalb einen Tag lang systematisch gemessen – drei Befunde, mit Belegen.

=== Aufbau ===

App Pro 2.306.2422 auf einem eigenen stationären Android-Gerät, dauerhaft am Strom, ausschließlich als Fernbedienungsserver (Rolle SERVER), Fernsteuerungsmodus aktiv. MQTT-Publisher eingerichtet, Broker ist Mosquitto als Home-Assistant-Add-on mit eigenem Benutzerkonto. Wallbox go-eCharger V3, PV Fronius mit Ohmpilot, Auto MG MGS6.

Vorweg das Positive: Der SoC-Push funktioniert tadellos. Ich liefere den Ladezustand des MG aus Home Assistant per MQTT, die App übernimmt ihn exakt (estSoc stimmt auf die Nachkommastelle mit dem Fahrzeugwert überein). Genau das, was keylox im Mai angeregt hatte. Danke dafür.

=== 1) Die App ist nur etwa 5 % der Zeit empfangsbereit ===

Das ist der wichtigste Befund, und er erklärt vermutlich auch keylox' Beobachtung vom 02.05.

Alle meine Befehle blieben zunächst wirkungslos – auch dumpStates. Im App-Logfile steht der Grund: Die App abonniert wallbox_control/command nur in kurzen Schüben und meldet sich danach wieder ab.

11:33:47.729 subscribed → 11:33:50.369 unsubscribed (3 s)
11:33:52.618 subscribed → 11:33:58.601 unsubscribed (6 s)
11:33:59.494 subscribed → 11:34:22.415 unsubscribed (23 s)
11:34:33.973 subscribed → 11:34:35.774 unsubscribed (2 s)
11:34:36.466 subscribed → 11:34:37.417 unsubscribed (1 s)
11:34:38.093 subscribed → 11:34:39.042 unsubscribed (1 s)
11:34:39.542 subscribed → 11:35:02.286 unsubscribed (23 s)
11:38:17.866 subscribed → 11:38:26.011 unsubscribed (8 s)
11:40:27.457 subscribed → 11:40:31.873 unsubscribed (4 s)
11:41:21.363 subscribed → 11:41:25.615 unsubscribed (4 s)
11:44:14.719 subscribed → 11:44:20.515 unsubscribed (6 s)
11:45:06.077 subscribed

In 27 Minuten war die App insgesamt rund 80 Sekunden empfangsbereit. Bei retain=false und Clean Session verwirft der Broker eine Nachricht, für die gerade kein Abonnent da ist – spurlos. Jeder meiner Befehle fiel in eine Lücke; ein dumpStates um 11:44:32 verfehlte das Fenster um zwölf Sekunden.

WORKAROUND, der funktioniert: den Befehl mit retain=true senden. Dann liefert der Broker ihn aus, sobald die App das nächste Mal abonniert. Latenz ein bis drei Minuten. Verifiziert und mehrfach reproduziert:

11:54:xx retained gesendet {"cmd":"controlmode","param":{"mode":"manual","active":true,"current":6}}
11:55:28 state/controlmode = manual
11:56:35 nach {"mode":"auto","active":true} wieder auto

Wichtig dabei: Die Retain-Nachricht muss danach mit leerem Payload gelöscht werden, sonst wird sie bei jedem künftigen Abonnieren erneut ausgeführt.

Frage: Ist das Ab- und Anmelden Absicht (Batterie?), oder sollte die App dauerhaft abonniert bleiben? Auf einem Gerät, das ohnehin als Server am Strom hängt, wäre eine dauerhafte Subscription die einfachere Lösung als Retain-Nachrichten auf Anwenderseite.

=== 2) Der Parameter "current" wird nicht übernommen ===

Zwei Varianten getestet, beide erfolglos:

a) Moduswechsel und Strom in einem Befehl:
{"cmd":"controlmode","param":{"mode":"manual","active":true,"current":6}}
→ Modus wechselt korrekt auf manual, aber state/manualChargeCurrentA bleibt auf 16.0, und die Wallbox lädt mit 16 A (kurzzeitig 10,5 kW dreiphasig).

b) Erst Modus setzen, dann in bereits aktivem Manuellmodus den Strom:
{"cmd":"controlmode","param":{"mode":"manual","active":false}}
→ Modus wechselt, Wallbox gesperrt, 0 W. Soweit korrekt.
{"cmd":"controlmode","param":{"mode":"manual","active":false,"current":8}}
→ state/manualChargeCurrentA bleibt auf 16.0.

Der Wert hat sich über den gesamten Beobachtungszeitraum kein einziges Mal geändert. Heißt der Parameter inzwischen anders, oder ist das ein Fehler?

Das "active"-Flag funktioniert dagegen wie dokumentiert: mit false wird die Wallbox gesperrt, es fließt nichts. Das ist sehr praktisch zum gefahrlosen Testen.

Nebenbei: Ein Moduswechsel schaltet die Phasenzahl von 1 auf 3 um. Die Rückschaltung unterliegt danach der internen Sperrzeit, was ich für richtig halte – nur sollte man es wissen, weil dreiphasig 6 A eben 4,1 kW Mindestleistung bedeuten statt 1,4 kW.

=== 3) results/cause kippt zyklisch auf NOT_INITIALIZED ===

Mitschnitt von wallbox_control/results/#, Auto angesteckt, Sonne da:

11:44:06 charging=true cause=ENOUGH_POWER energySourceActive=pv
11:44:12 charging=false cause=NOT_INITIALIZED energySourceActive=-
11:44:17 charging=true cause=ENOUGH_POWER energySourceActive=pv
11:44:39 charging=false cause=NOT_INITIALIZED energySourceActive=-
11:44:45 charging=true cause=ENOUGH_POWER energySourceActive=pv
11:44:51 charging=false cause=NOT_INITIALIZED energySourceActive=-
11:44:56 charging=true cause=ENOUGH_POWER energySourceActive=pv

Das läuft über Minuten so. NOT_INITIALIZED sieht für mich nicht nach einer Regelentscheidung aus, sondern danach, dass die Berechnung bei jedem zweiten Zyklus nicht anläuft.

Die Ladeleistung folgt dem Muster (aus der go-e ausgelesen, 5-Sekunden-Takt):

11:43:39 1530 W
11:43:44 3830 W
11:43:59 1540 W
11:44:05 3880 W
11:44:31 2470 W
11:44:46 3820 W
11:45:11 1750 W
11:45:26 1550 W

Rund 2300 W Ausschlag alle zehn bis fünfzehn Sekunden. Anlagenwerte zur selben Zeit: PV 4588 W, Einspeisung 790 W, Ohmpilot 0 W – Überschuss ist also vorhanden und der Arbeitspunkt stimmt ungefähr, die Regelung schwingt nur sehr stark darum herum.

An anderen Tagen führt dasselbe Muster zu echten Ladeabbrüchen: am 31.07. zwischen 13:07 und 13:32 rund 25 Zyklen Laden/Abgeschlossen mit Ladephasen von fünf bis zwanzig Sekunden, am 02.08. zwischen 15:54 und 16:25 rund 20 Zyklen. Der Reboot-Zähler der Wallbox steht bei 371. Da leidet auf Dauer der Schütz, deshalb würde ich das gern verstehen.

Ist NOT_INITIALIZED ein bekannter Zustand? Gibt es eine Einstellung, die ich übersehe?

=== 4) Kleinigkeiten ===

- Auf state/controlmode kommt etwa alle fünf bis zehn Minuten genau ein Zyklus mit einem Payload, der weder "auto" noch "manual" ist, danach wieder normal. Jede Automation, die auf den Modus reagiert, braucht deshalb eine Entprellung.
- state/manualChargingActive steht bei mir dauerhaft auf true, während state/controlmode "auto" meldet. Was ist der Unterschied zwischen beiden?
- chargelimit/AUTO/soc und chargelimit/MANUAL/soc gibt es bei mir nicht. Stattdessen carSoCMax_auto, carSoCMax_manual, carSoCMax_flex, chargemin und chargeminSoc.
- Gibt es eine aktuelle Beschreibung der überarbeiteten Struktur? Der Hinweis in der App zeigt hierher, der Stand hier ist aber älter als mein Build.

Hinweis zur Messmethode für alle, die das nachstellen: 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 – ich bin selbst darauf hereingefallen. Sauber messen heißt: Mitschnitt laufen lassen, bis Ruhe herrscht, dann erst den Befehl senden.

Logfiles, vollständige Topic-Dumps oder längere Mitschnitte kann ich jederzeit liefern.

Danke und viele Grüße

[c2j2]

Super, vielen Danke für die Diagnosen!

Ich hoffe, dass ich die nächsten Tage Zeit dazu habe, die Probleme anzugehen.

[rekker]

Danke für die schnelle Rückmeldung, und lass Dir Zeit – hier brennt nichts.

Die Überschussregelung läuft ja im Alltag gut, es sind Feinheiten, die mir beim Anbinden an Home Assistant aufgefallen sind. Falls Du beim Draufschauen weitere Messungen brauchst: Ich habe den MQTT-Baum jetzt dauerhaft in Home Assistant, kann also über Tage mitschneiden und Dir gezielt Zeitreihen liefern – etwa wie oft results/cause auf NOT_INITIALIZED kippt, oder wie sich das Ganze bei wechselnder Bewölkung verhält. Sag einfach, was hilfreich wäre.

Und falls es beim Priorisieren hilft: Das Sub/Unsub-Verhalten auf wallbox_control/command wäre für mich das Interessanteste, weil sich damit die Fernsteuerung überhaupt erst zuverlässig nutzen lässt. Mit retain=true komme ich vorerst gut zurecht.

Vielen Dank jedenfalls für die App – die MQTT-Schnittstelle hat mir schon jetzt einiges ermöglicht, vor allem den SoC-Push aus Home Assistant.

Schöne Grüße