Mehrere Messwerte auf einem Topic auseinanderhalten

Der go-eCharger schickt sechzehn Zahlen als JSON-Feld auf einem einzigen
Topic, die Wechselrichter und die WLAN-Felder machen es aehnlich. Welcher
Teil der Nutzlast gemeint ist, steht im value_template der
Home-Assistant-Discovery - das Modul las es bisher nur, um den Datentyp zu
raten, und warf es dann weg. Alle sechzehn Messwerte bekamen denselben
Rohtext.

actor_states hat jetzt eine Spalte value_path: ein Pfad in die Nutzlast, in
derselben Schreibweise, die WLED schon benutzt ("[4]", "ssid",
"seg[0].col[0]"). NULL heisst weiterhin: die ganze Nutzlast.

Gelesen wird aus dem Template nur der einfache Fall - ein Zugriff auf
value_json und was danach an Punkten und Klammern folgt. Von den 40
Vorlagen, die hier auf dem Broker liegen, sind 28 genau das. Die uebrigen
zwoelf sind entweder die ganze Nutzlast (dann ist NULL richtig) oder
Werttabellen wie ['Idle','Charging'][value_json|int] - das ist kein Pfad,
sondern eine Uebersetzung von Zahl nach Text, und dort bleibt es beim
bisherigen Verhalten. Kein einziger Fehltreffer: die Werttabellen liefern
sauber None statt eines erfundenen Pfades.

Die Pfad-Auswertung stand schon im WLED-Transport; sie ist jetzt eine
gemeinsame Funktion, die sich beide teilen. MQTT wertet die Nutzlast einmal
je Nachricht aus und verteilt sie danach an alle Messwerte des Topics.

Nachgemessen: die sechzehn nrg-Werte liefern jetzt sechzehn eigene Zahlen
statt sechzehnmal dasselbe, die Leseabdeckung bleibt bei 440 von 441, und
ein weiterer Discovery-Lauf aendert keine Zeile.

Die restlichen geteilten Topics sind kein Fehler: bei den Wechselrichtern
lesen "Limit Persistent" und "Limit NonPersistent" wirklich denselben Wert
und unterscheiden sich nur im Kommando-Topic, und beim Thermostat liest die
Klima-Entity dieselbe Temperatur wie der Sensor.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

restricted/autoActions/README.md

@@ -116,7 +116,7 @@ Welcher Weg zum Gerät führt, entscheidet die URL des Aktors in `actors`:
 
 | URL | Messwert (`actor_states.url`) | Kommando (`actor_commands.command_url`) |
 |---|---|---|
-| `mqtt://…` | vollständiges Topic, abonniert | Nutzlast auf das Parameter-Topic |
+| `mqtt://…` | vollständiges Topic, abonniert; bei mehreren Messwerten je Topic zusätzlich `value_path` | Nutzlast auf das Parameter-Topic |
 | `http://…` | Feldname in der JSON-Antwort, gepollt | Abfrageargumente an die Geräte-URL (`turn=on`) |
 | `wled://…` | Pfad in `/json/state` (`seg[0].col[0]`), gepollt | JSON-Vorlage mit Platzhaltern, als Ganzes gesendet |
 | Tahoma | Statusname (`core:ClosureState`), gepollt | `exec/apply` an die Box |
@@ -132,6 +132,20 @@ und `internal://` für die Alarmanlage. Ohne `pin` in der `config.ini` ist
 niemand zuständig — dann meldet der Runner beim Auslösen „kein Transport",
 statt still nichts zu tun.
 
+Mehrere Messwerte teilen sich oft **ein Topic**: der go-eCharger schickt
+sechzehn Zahlen als JSON-Feld auf `…/nrg`, und erst das `value_template` der
+Home-Assistant-Discovery sagt, dass „Strom L1" das fünfte Element ist. Diese
+Angabe steht in `actor_states.value_path` — in derselben Schreibweise, die
+auch WLED benutzt: `[4]`, `ssid`, `seg[0].col[0]`. Ohne Pfad gilt die ganze
+Nutzlast.
+
+Gelesen wird nur der einfache Fall aus dem Template: ein Zugriff auf
+`value_json` und was danach an Punkten und Klammern folgt. Werttabellen wie
+`{{ ['Idle','Charging'][value_json|int] }}` sind keine Pfade, sondern eine
+Übersetzung von Zahl nach Text — dort bleibt es beim Rohwert. Das betrifft
+hier acht Messwerte (Ladezustand, Fehlercode und Ähnliches am go-eCharger);
+sie sind als Zahl vergleichbar, nur nicht als Klartext.
+
 Bei WLED trägt die Kommando-Vorlage alles: `{"seg":[{"col":[[%red%,%green%,%blue%]]}]}`
 wird mit den Parameterwerten gefüllt und am Stück geschickt. Deshalb haben die
 Parameter dort keine eigene URL — ihr Name *ist* der Platzhalter.