PHC Remote: neue iOS App, etwas Hilfe benötigt

1. Mitschnitt der alten iOS-App
Der wichtigste Einstieg war ein Mitschnitt des Datenverkehrs der offiziellen
iOS-App zum STM, unter anderem mit `mitmproxy`. Dadurch war klar, wie die App überhaupt mit dem Steuermodul spricht:

Die offizielle App nutzt im normalen LAN-Betrieb nur wenige XML-RPC-Methoden:



Damit waren die großen Fragen beantwortet: Port, Transport, Pfad,
Authentifizierung, Parameter-Reihenfolge und die Tatsache, dass das iPhone keine rohen RS-485-Frames sendet.
Es übergibt dem STM nur eine Busadresse und einen Inhalt; das STM kümmert sich um die eigentliche Buskommunikation.

2. Projektdatei vom STM
`readFile` liefert die Anlagenkonfiguration als ZIP-Archiv. Darin liegen unter anderem:



für die App reicht aktuell vor allem `project.ppfx`: Daraus werden Stockwerke, Kategorien und Geräte erzeugt. Die Namen der Kanäle folgen in unserer Anlage einem Schema wie:


Lichter und Steckdosen kommen aus Ausgangsmodulen, Rollläden werden über die zugeordneten Eingangskanäle `heben`/`senken` gefunden.
Ein kleiner Stolperstein: Das ZIP vom STM gesendet setzt in den Einträgen das General-Purpose-Flag Bit 3. Die Größen der einzelnen Dateien in der ZIP stehen also nicht im lokalen Header,
sondern im nachgelagerten Data Descriptor; außerdem sind die Einträge rohes DEFLATE. Ein handgeschriebener ZIP-Parser war dafür keine gute Idee. Gelöst ist es jetzt sauber mit **ZIPFoundation**, das das zentrale Verzeichnis am Ende des Archivs auswertet.

3. Handbuch und dekompilierte PHC-Systemsoftware
Der Mitschnitt der alten App erklärt den LAN-Weg zum STM. für viele Befehlscodes ist aber die **PHC-Systemsoftware** wertvoller:
In den dekompilierten Dateien wie `modules.xml`, `functions.xml`, `ModulLinks.xml` und `EXT_*.xml` steckt sehr viel Struktur.
Daraus lässt sich zum Beispiel ablesen:
- welche Module welche Ausgangs-/Eingangskanäle haben,
- welcher Kanaltyp welche Funktionsliste benutzt,
- welche `com`-Codes für Ein/Aus, Dimmen, JRM/Rollladen usw. existieren,
- welche Befehle Zusatzparameter wie Laufzeit, Dimmzeit oder Zielwert brauchen,
- und bei Extended-Modulen, wie die längeren Payloads aufgebaut sind.
Das Handbuch hilft beim Gegenprüfen der Bedeutung und Reihenfolge dieser
Befehle. Kurz gesagt: Der Mitschnitt hat gezeigt, **wie** mit dem STM gesprochen wird; Handbuch und Systemsoftware erklären zu einem großen Teil, **was** die einzelnen Modulbefehle bedeuten.


Das Polling nutzt ebenfalls `sendTelegram`: Ein Aufruf pro AMD-Modul liefert
eine Bitmaske, in der die Ausgangszustände aller Kanäle stecken.
Rollläden werden in der App nicht direkt über JRM-Ausgangstelegramme gefahren.
Stattdessen simuliert die App die vorhandenen Tastereingaben:




Dimmer sind noch **nicht** real implementiert. Im Demo-Modus gibt es zwar einen Slider, aber bei einer echten STM-Verbindung erzeugt der Parser derzeit keine Dimmergeraete, und `setBrightness` ist nur ein Ein/Aus-Stub.
Was inzwischen gut verstanden ist: Die Befehlscodes aus der Systemsoftware.
Klassische Dimmerkanaele (`DIM_AUS`, `DIM_AUS_EH`) nutzen wie andere Ausgaenge ein `shift="5"`-Schema:


Wichtige Codes:


Bei Extended-/DALI-Dimmern gibt es zusätzlich längere Payloads aus
`EXT_DIM_AUS_EXT.xml`, z. B. mit Zielwert und Zeitglied.
Was noch fehlt, ist ein Mitschnitt gegen echte Dimmer-Hardware. Offen sind vor allem:
- die numerische Busadress-Klasse für DIM-Module im STM-LAN-Aufruf,
- wie `sendTelegram` im XML-RPC-Pfad mehrteilige Payloads übergibt,
- wie Zielwert/Zeit in der echten Rückmeldung skaliert werden,
- und wie die offizielle App Dimmerzustand liest bzw. darstellt.