Bruecke nimmt jetzt auch Kommandos entgegen

Der Schreibweg wattpilot/properties/<schluessel>/set war unbenutzbar. Die
Bibliothek reichte Zahlen als Zeichenkette an die Wallbox weiter
("value must be uint8_t"), griff bei unbekannten Namen und bei
Eigenschaften ohne rw-Angabe ungeprueft zu - ftt und fte haben keine, ein
Klick auf die Ladeplanung haette den paho-Callback getoetet - und meldete
nichts zurueck.

Jetzt bekommt der Wert den Typ aus der API-Beschreibung, so dass die
Wallbox 'lmo = 4' genauso nimmt wie 'lmo = Awattar'. Unbekanntes und
Schreibgeschuetztes wird abgelehnt statt zu werfen, und das Ergebnis geht
auf <schluessel>/result - genau wie es der go-e tut. Damit laesst sich das
Dashboard auf einen Weg fuer beide Wallboxen umstellen.

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

autoActions/README.md

@@ -280,6 +280,17 @@ von paho abgelehnt — gut vier von zehn Zeilen im alten Log.
 Feld einmal mit einer Warnung im Log. `startWattpilotMQTT.sh` startet seither
 die Brücke statt der `wattpilotshell` direkt.
 
+Seit dem 04.09.2026 trägt dieselbe Brücke auch die Gegenrichtung. Sie nimmt
+Kommandos auf `wattpilot/properties/<schlüssel>/set` entgegen und meldet auf
+`<schlüssel>/result`, ob die Wallbox sie genommen hat — dasselbe Muster, das
+der go-e von Haus aus spricht. Das Dashboard steuert damit beide Wallboxen
+über einen Weg (`restricted/wallboxen.php`) und startet für die Wattpilot
+keinen eigenen Python-Prozess mehr. Nötig waren dafür drei Reparaturen an der
+Bibliothek: Zahlen kamen als Zeichenkette bei der Wallbox an
+(`value must be uint8_t`), ein unbekannter Name und jede Eigenschaft ohne
+`rw`-Angabe — `ftt` und `fte` zum Beispiel — töteten den paho-Callback, und
+eine Rückmeldung gab es überhaupt nicht.
+
 `fetch_calendar.py` gehört einmal jährlich in den Cron:
 
 ```