Zahlencodes als Klartext

Manche Geraete schicken eine Zahl und meinen einen Zustand - der
go-eCharger etwa 2 fuer "Charging". Welche Zahl welchen Namen hat, steht im
value_template der Home-Assistant-Discovery als Werttabelle:

    {{ ['Unknown','Idle','Charging','WaitCar','Complete','Error'][value_json|int] }}

Das ist kein Pfad in die Nutzlast, sondern eine Uebersetzung, und sie wurde
bisher verworfen. Jetzt landet sie in possible_values - in derselben
Schreibweise, die WLED fuer seine Effektliste schon benutzt, naemlich einer
Liste aus {Wert: Bezeichnung}. Damit versteht der Editor sie ohne
Zusatzarbeit und macht eine Auswahlliste daraus. Ein Versatz im Ausdruck
wandert in die Schluessel: aus [value_json|int-3] wird {"3":"Default"}.

Der Runner uebersetzt beim Lesen, eine Bedingung vergleicht also den
Klartext. Steht die Zahl nicht in der Tabelle, bleibt sie stehen - ein
erfundener Name waere schlimmer als ein roher Wert.

Dabei ist ein Folgefehler aufgefallen: Auswahlwerte in dieser Schreibweise
kamen im Editor als "[object Object]" an. Die alte addOptions kannte die
Form, der neue Modell-Aufbau nicht - aufgefallen ist es nie, weil WLED beim
Umbau abgeschaltet war. Der Katalog liefert Auswahlwerte jetzt einheitlich
als {value, label}, und zwar seitenrichtig:

    Messwert   angezeigt Charging, gespeichert Charging
               (der Runner hat schon uebersetzt)
    Parameter  angezeigt Blink,    gespeichert 1
               (das Geraet will die Zahl)

Die Uebersicht loest die Bezeichnung ebenfalls auf: "Effekt (Blink)" statt
"Effekt (1)".

Nachgemessen: alle fuenf Werttabellen auf dem Broker richtig erkannt,
einschliesslich des Versatzes, kein Fehltreffer unter den 35 uebrigen
Vorlagen. Live liefert der go-eCharger jetzt Idle, Neutral, Auto, Eco und
None statt 1, 0, 0, 4, 0. Ein weiterer Discovery-Lauf aendert keine Zeile.

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

restricted/autoActions/README.md

@@ -140,11 +140,34 @@ 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.
+`value_json` und was danach an Punkten und Klammern folgt.
+
+### Werttabellen
+
+Manche Geräte schicken eine Zahl und meinen einen Zustand:
+
+```
+{{ ['Unknown','Idle','Charging','WaitCar','Complete','Error'][value_json|int] }}
+{{ ['Default','Eco','NextTrip'][value_json|int-3] }}
+```
+
+Das ist kein Pfad, sondern eine Übersetzung von Zahl nach Text. Sie landet in
+`possible_values` — in der Schreibweise, die WLED für seine Effektliste schon
+benutzt: eine Liste aus `{Wert: Bezeichnung}`. Ein Versatz im Ausdruck wandert
+dabei in die Schlüssel, aus `[value_json|int-3]` wird also `{"3":"Default"}`.
+
+Der Runner übersetzt beim Lesen: aus der gesendeten `2` wird `Charging`. Eine
+Bedingung vergleicht damit genau den Klartext, den der Editor zur Auswahl
+stellt. Steht die Zahl nicht in der Tabelle, bleibt sie stehen — ein
+erfundener Name wäre schlimmer als ein roher Wert.
+
+Auf beiden Seiten des Editors steckt dieselbe Tabelle, aber der gespeicherte
+Wert ist ein anderer:
+
+| | angezeigt | gespeichert |
+|---|---|---|
+| **Messwert** (Bedingung) | `Charging` | `Charging` — der Runner hat schon übersetzt |
+| **Parameter** (Aktion) | `Blink` | `1` — das Gerät will die Zahl |
 
 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