- Beim Sony mache sende nach jedem Kommando zusätzlich Abfragen auf gut 10 Eigenschaften, um diese nach dem aktuellen Stand abzufragen. Würde ich über die normale FB den Beamer bedienen, dann bekäme ich das adhoc nicht mit. Das Senden selbst läuft via nc und Hex String auf der Kommandozeile. Eine API ist das nicht
- Bei der Trinnov habe ich einen Kommandozeilen Sniffer (auch via nc) laufen, der dann letztendlich Texte auswertet und in einer Haussteuerung bereit stellt. Das klappt dann auch, wenn ich bspw. den Lautstärkeregeler direkt bediene. Eine API ist auch das nicht.
Ich denke Du bist zu verwöhnt - bist Du Software-Programmierer?
In der Tat, beim Sony musst Du pollen (=regelmäßig die Zustände abfragen) um auf den aktuellen Zustand zu bleiben. Das ist aber in der A/V Automation relativ gängig (wenn auch nicht schön). Wenn Du ADCP benutzt, dann kannst Du aber zumindest in Textstrings kommunizieren und musst keine Hex-Werte auswerten.
Die Trinnov sendet Veränderungen an den Betriebszuständen von alleine - das ist schon mal ein großer Fortschritt zum Pollen. Die Rückmeldungen in ASCII-Strings musst Du dann parsen um die entsprechenden Informationen daraus zu extrahieren, richtig. Aber auch das ist gängige Praxis in der A/V-Automatisierung.
Für Crestron gibt es für beides auch schon fertige Module/Treiber, die man nur einbinden muss, dann muss man sich mit dem Pollen und Parsen auch gar nicht selber rumschlagen. Nur wenn man Funktionen nutzen möchte, die nicht von den Treibern abgedeckt werden muss man selber nochmal ran.
Würde ich über die normale FB den Beamer bedienen, dann bekäme ich das adhoc nicht mit.
Deshalb versucht man wann immer möglich auch in seiner Automatisierung zu bleiben und zu vermeiden, dass von außerhalb Veränderungen an den Betriebszuständen vorgenommen werden. Wenn man eine Automatisierung hat, die sauber funktioniert, ist ja z.B. die Notwendigkeit die Original-FB parallel zu nutzen eigentlich nicht gegeben.