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

[rekker]

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.

[rekker]

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.

[rekker]

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.

[c2j2]

Neue Doku zu den Werten, wozu hat man einen willigen Kollegen namens Claude:

MQTT-Schnittstelle der Wallbox-Steuerung

Die Wallbox-Steuerung kann ihren kompletten internen Zustand an einen MQTT-Broker senden und nimmt dort auch Kommandos entgegen. Damit lässt sich die App in FHEM, ioBroker, Home Assistant, Node-RED und alles andere einbinden, was MQTT spricht.

Dieser Beitrag listet alle Topics auf, die die App sendet und versteht.

────────────────────────────────────────────────────────

Grundlagen

• Wurzel-Topic: wallbox_control. Alle Topics unten sind relativ dazu, vollständig also z. B. wallbox_control/state/controlmode.
• Es sendet nur das Gerät, auf dem der Dienst läuft. Eine App, die als Fernbedienung eingerichtet ist, sendet nichts.
• Retained: unten je Topic angegeben. Grundregel: Einstellungen und Stammdaten sind retained, laufende Messwerte nicht.
• Leere Werte: Ist ein Wert nicht bekannt, wird das Topic beim Broker gelöscht, statt einen Platzhalter zu senden.

Wann wird gesendet?

• Sobald die Verbindung zum Broker steht, geht der komplette Zustand raus — ebenso auf das Kommando dumpStates.
• Bei jeder Abfrage der Wallbox, der Stromquellen und des Fahrzeug-Ladestands werden die jeweiligen Messwerte aktualisiert.
• Jede Änderung einer Einstellung wird sofort gesendet.
• Beim Beenden des Dienstes wird service/running auf false gesetzt.

Autos und Wallboxen, die es in der App nicht mehr gibt, werden beim Vollabgleich automatisch aus dem Broker entfernt.

────────────────────────────────────────────────────────

service/ — Zustand des Dienstes

Code: Alles auswählen

service/running     retained   true beim Start, false beim Beenden
service/error       -          Fehlertext zu einem empfangenen Kommando

────────────────────────────────────────────────────────

cars/ — Fahrzeuge

<carId> ist die interne ID des Fahrzeugs.

Code: Alles auswählen

cars/current                    ID des aktuell ausgewählten Fahrzeugs
cars/<carId>/name      retained Anzeigename
cars/<carId>/vin       retained Fahrgestellnummer
cars/<carId>/phases    retained "1 fixed" / "2 fixed" / "3 fixed"

Ladestand und Fahrzeugdaten — nur wenn für das Fahrzeug eine automatische Abfrage eingerichtet ist. Alles retained:

Code: Alles auswählen

cars/<carId>/current_data/battery/soc              Ladestand in %, abgerundet
cars/<carId>/current_data/battery/estSoc           geschätzter Ladestand, 2 Nachkommastellen
cars/<carId>/current_data/battery/timestamp        Zeitstempel dazu, lesbar
cars/<carId>/current_data/battery/timestampUTC     derselbe Zeitstempel in Millisekunden
cars/<carId>/current_data/battery/apiTimestamp     Zeitpunkt der letzten echten Abfrage am Fahrzeug
cars/<carId>/current_data/battery/apiTimestampUTC  derselbe Zeitpunkt in Millisekunden
cars/<carId>/current_data/battery/rangeKm          Restreichweite in km
cars/<carId>/current_data/state                    Fahrzeugzustand laut Hersteller ("asleep", ...)
cars/<carId>/current_data/error                    letzte Fehlermeldung der Abfrage

Wichtig zu den beiden Zeitstempeln: soc und timestamp gehören zusammen, und soc kann eine Hochrechnung des Ladevorgangs sein. rangeKm kommt dagegen immer direkt vom Fahrzeug. Wie alt dieser Wert ist, sagt apiTimestamp — der Zeitpunkt der letzten echten Abfrage. Wer das Alter der Fahrzeugdaten anzeigen will, nimmt also apiTimestamp, nicht timestamp.

Hat das Fahrzeug noch nie geantwortet, fehlen apiTimestamp, apiTimestampUTC und rangeKm.

────────────────────────────────────────────────────────

wallboxes/ — Wallboxen

Code: Alles auswählen

wallboxes/current                             ID der aktiven Wallbox
wallboxes/<wbId>/name                retained Anzeigename
wallboxes/<wbId>/type                retained Gerätetyp (go-e, nrgkick, cfos, openwb, ...)
wallboxes/<wbId>/assignedCarId       retained fest zugeordnetes Fahrzeug
wallboxes/<wbId>/watchForCarConnection retained Überwachung auf angestecktes Fahrzeug

Laufende Messwerte:

Code: Alles auswählen

wallboxes/<wbId>/current_data/state              Zahlencode, siehe unten
wallboxes/<wbId>/current_data/state_str          derselbe Zustand als Text
wallboxes/<wbId>/current_data/totalEnergyWh      retained  Zählerstand der Wallbox in Wh
wallboxes/<wbId>/current_data/sessionEnergyWh    Energie der laufenden Sitzung in Wh
wallboxes/<wbId>/current_data/currentA           Gesamtstrom in A (nur beim Laden)
wallboxes/<wbId>/current_data/currentStr         Ströme je Phase als Text (nur beim Laden)
wallboxes/<wbId>/current_data/powerW             Ladeleistung in W (nur beim Laden)
wallboxes/<wbId>/current_data/remainingEnergyWh  noch zu ladende Energie in Wh
wallboxes/<wbId>/current_data/error              Fehlertext, sonst leer

Die Zustandscodes:

Code: Alles auswählen

 0  kein Auto, Ladepunkt aus       no_car locked
 1  kein Auto, Ladepunkt bereit    no_car ready_to_charge
 2  Auto lädt                      car charging
 3  Auto angesteckt, wartet        car waiting
 4  Auto fertig                    car finished
 5  unbekannt                      unknown
98  keine Verbindung
99  Wallbox meldet einen Defekt

sessionEnergyWh gibt es nur bei Wallboxen, die den Sitzungszähler selbst liefern. currentA und currentStr nur bei Wallboxen, die die Ströme melden.

────────────────────────────────────────────────────────

sources/ — Stromquellen (Wechselrichter, Speicher, Zähler)

<id> ist bei der Hauptquelle der eingestellte Gerätetyp, bei zusätzlichen Quellen deren interne ID.

Code: Alles auswählen

sources/<id>/type     retained   Gerätetyp     ]
sources/<id>/name     retained   Anzeigename   ]- nur bei zusätzlichen Quellen
sources/<id>/enabled  retained   true / false  ]

Laufende Messwerte, nichts davon retained:

Code: Alles auswählen

sources/<id>/current_data/error                 Fehlertext, sonst leer
sources/<id>/current_data/storage/productionW   Speicherleistung in W (Entladung positiv)
sources/<id>/current_data/storage/soc           Ladestand des Hausspeichers in %
sources/<id>/current_data/storage/workingState  Betriebszustand, siehe unten
sources/<id>/current_data/storage/workingMode   Betriebsart, siehe unten
sources/<id>/current_data/pv/productionW        PV-Erzeugung in W
sources/<id>/current_data/grid/productionW      Netzleistung in W (Einspeisung positiv)
sources/<id>/current_data/home/consumptionW     Hausverbrauch in W

Mögliche Werte für workingState:

Code: Alles auswählen

STATE_ERROR  STATE_STARTING  STATE_NOT_ACTIVE
STATE_ACTIVE_GRID  STATE_ACTIVE_GRID_REDUCED  STATE_ACTIVE_ISLAND

Mögliche Werte für workingMode:

Code: Alles auswählen

NOT_SUPPORTED  UNKNOWN  AUTOMATIC  PASSIVE  FORCED_CHARGING
PASSIVE_30  PASSIVE_40  PASSIVE_50  PASSIVE_60
PASSIVE_70  PASSIVE_80  PASSIVE_90
FORCED_DISCHARGING  ZERO_EXPORT

Liefert ein Gerät eine Grösse nicht, wird das jeweilige Topic gelöscht — ohne Hausspeicher fällt der komplette Zweig storage weg.

────────────────────────────────────────────────────────

state/ — Einstellungen und Betriebszustand

Alles hier ist retained, ausser wo ausdrücklich anders vermerkt.

Lademodus und Ladegrenzen

Code: Alles auswählen

state/controlmode                        auto / manual
state/autoControlActive                  Automatik läuft gerade
state/manualChargingActive               manuelles Laden aktiv
state/manualChargeCurrentA               Ladestrom im manuellen Modus in A
state/manualCharging_HomeStorage_passive Hausspeicher dabei passiv halten
state/chargemin                          Mindest-SoC, ab dem geladen wird, in %
state/chargeminSoc                       dasselbe nach Änderung per MQTT-Kommando
state/carSoCMax_auto                     Ziel-SoC im PV-Überschussmodus, %
state/carSoCMax_flex                     Ziel-SoC im Tarifmodus, %
state/carSoCMax_manual                   Ziel-SoC im manuellen Modus, %
state/maxEnergyToCharge_kWh_auto         Zielenergie PV-Überschuss, kWh
state/maxEnergyToCharge_kWh_flex         Zielenergie Tarifmodus, kWh
state/maxEnergyToCharge_kWh_manual       Zielenergie manuell, kWh
state/autoactivateAutoMode               0 / 1 / 2
state/forcedUnlimitedCharging            erzwungenes ungeregeltes Laden

Zusätzlich wird bei jeder Neuberechnung gesendet, welche Grenze gerade überhaupt gilt — nützlich, wenn man nicht selbst herausfinden will, ob das Fahrzeug einen Ladestand liefert:

Code: Alles auswählen

state/chargelimit/mode              soc oder energyWh
state/chargelimit/AUTO/soc          Ziel-SoC             ]
state/chargelimit/FLEX/soc          Ziel-SoC             ]- nur bei mode = soc
state/chargelimit/MANUAL/soc        Ziel-SoC             ]
state/chargemin/soc                 Mindest-SoC          ]
state/chargelimit/AUTO/energyWh     retained  Zielenergie in Wh   ]
state/chargelimit/FLEX/energyWh     retained  Zielenergie in Wh   ]- nur bei mode = energyWh
state/chargelimit/MANUAL/energyWh   retained  Zielenergie in Wh   ]

Energiequelle

Code: Alles auswählen

state/energySourceActive      0 = nur PV, 1 = PV und Tarif, 2 = nur Tarif
state/energySourceSelected    derselbe Modus als Text:
                              PV_ONLY / PV_AND_SMART / SMART_ONLY
state/energySourceSelectedUI  Klartext, warum dieser Modus gerade aktiv ist

Hausspeicher und Leistungsreserve

Code: Alles auswählen

state/reservedPowerW               reservierte Leistung in W
state/boost/minSoC                 Mindest-SoC des Hausspeichers für den Boost, %
state/boost/power                  Boost-Leistung in W
state/grid/boost                   aktuell wirksame Boost-Leistung in W
state/grid/boostMinSoc             zugehöriger Mindest-SoC, %
state/grid/reservedByHSPriorityW   von der Speicher-Strategie reservierte Leistung in W

Die drei state/grid/…-Werte sind nicht retained und kommen nur, während die jeweilige Regel tatsächlich greift.

Flexibler Tarif — alle Werte true / false

Code: Alles auswählen

state/flexTariffCarControlEnabled                  Fahrzeugsteuerung über den Tarif
state/flexTariffStgControlEnabled                  Speichersteuerung über den Tarif
state/flexTariffZeroExportActive                   Nulleinspeisung
state/flexTariffExportNoForcedCharging             kein Zwangsladen während der Einspeisung
state/flexTariffStorageForecastDrivenOptimization  prognosegestützte Speicheroptimierung
state/flexTariffStorageForecastOptEna              dieselbe, freigeschaltet
state/flexTariffStorageForecastOptReExEna          Rückspeisung dabei erlaubt
state/flexTariffStorageOptimizerPeakPriceActive    Optimierung auf Preisspitzen
state/flexTariffStorageOptimizerWithExportActive   Optimierung mit Export
state/flexTariffStorageOptimizerPreferPvCharging   PV-Ladung bevorzugen

────────────────────────────────────────────────────────

smarttariff/ — Börsenpreise

Code: Alles auswählen

smarttariff/provider   retained  Name des Tarifanbieters
smarttariff/prices               JSON-Array aller bekannten Intervalle
smarttariff/price_cur            Preis des laufenden Intervalls in ct/kWh

Aufbau eines Eintrags in prices:

Code: Alles auswählen

{
  "timestamp":    "lesbare Startzeit",
  "timestampUTC": 1756339200000,
  "duration_ms":  3600000,
  "price_est":    24.71
}

Ist kein Tarifanbieter eingerichtet, wird der ganze Zweig smarttariff gelöscht.

────────────────────────────────────────────────────────

command — die App fernsteuern

Die App hört auf wallbox_control/command und erwartet ein JSON-Objekt mit cmd und meist param. Was nicht verstanden wird, landet als Klartext auf service/error.

Code: Alles auswählen

{"cmd": "dumpStates"}

Sendet den kompletten Zustand neu. Praktisch nach einem Neustart des Brokers.

Code: Alles auswählen

{"cmd": "chargeminSoc", "param": {"soc": 20}}

Setzt den Mindest-Ladestand, ab dem geladen wird.

Code: Alles auswählen

{"cmd": "chargelimit", "param": {"mode": "smarttariff", "soc": 80}}
{"cmd": "chargelimit", "param": {"mode": "manual", "energy": 12.5}}

Setzt die Ladegrenze für einen Modus. Erlaubte Werte für mode: pv bzw. auto, smarttariff, manual. soc in Prozent, energy in kWh. soc: 0 löscht die Grenze.

Code: Alles auswählen

{"cmd": "energySourceActive", "param": {"mode": 1}}

Schaltet die Energiequelle um: 0 = nur PV, 1 = PV und Tarif, 2 = nur Tarif.

Code: Alles auswählen

{"cmd": "controlmode", "param": {"mode": "auto", "active": true}}
{"cmd": "controlmode", "param": {"mode": "manual", "active": true, "current": 10}}

Schaltet den Lademodus um. Im manuellen Modus können zusätzlich current (mindestens 6 A und höchstens der Maximalstrom der Wallbox) und energy mitgegeben werden.

Code: Alles auswählen

{"cmd": "autoactivateAutoMode", "param": {"mode": 1}}

Steuert, ob der Überschussmodus automatisch aktiviert wird. Erlaubt sind 0, 1 und 2.

Code: Alles auswählen

{"cmd": "car",     "param": {"id": "<carId>"}}
{"cmd": "wallbox", "param": {"id": "<wbId>"}}

Wählt Fahrzeug bzw. Wallbox aus. Die IDs stehen unter cars/current und wallboxes/current bzw. in den jeweiligen Zweigen.