Apple TV

Apple-TV-Knoten für Node-BLUE auf Basis von pyatv. Meldet Ein-/Ausschalten, Abspielstatus und Inhalt als Ereignisse und nimmt Power- und Fernbedienungsbefehle entgegen.

Voraussetzungen

Auf dem Homegear-Host, für den Benutzer, unter dem Node-BLUE läuft:

pip3 install pyatv

Getestet mit pyatv 0.18.0. Ältere Versionen ohne die Storage-API (pyatv.storage) funktionieren nicht, weil der Knoten die Credentials darüber ablegt.

Unterstützt werden Apple TV 4 und 4K (tvOS). Ein Apple TV 3 spricht nur DMAP und liefert keinen Power-State.

Einrichtung

1. Knoten in den Flow ziehen und deployen. Suchen und Pairen laufen im Knotenprozess, funktionieren also erst, wenn der Knoten läuft.
2. Dialog öffnen, Suchen anklicken und das Gerät auswählen — oder stattdessen die IP-Adresse eintragen. Eines von beidem genügt.
3. Pairing starten. Das Apple TV muss wach sein. Es zeigt nacheinander für AirPlay und Companion je eine PIN, die im Dialog eingegeben wird.
4. Deployen. Der Knoten verbindet sich und meldet ab jetzt Ereignisse.

Die Credentials liegen in Homegears Node-Data und überstehen ein erneutes Deployment. Ein Backup der Homegear-Datenbank enthält sie mit.

Adressierung

Gerät und IP-Adresse sind gleichwertige Alternativen; ist beides gesetzt, gewinnt die IP.

Bei der Adressierung über die ID merkt sich der Knoten die Adresse, unter der er das Gerät zuletzt erreicht hat, und fragt sie beim Verbinden zuerst direkt ab. Das ist nicht nur schneller als ein mDNS-Scan, sondern oft der einzige Weg: ein Apple TV im Ruhezustand fehlt regelmäßig komplett in der Suche. Erst wenn die gemerkte Adresse nicht antwortet — etwa nach einem DHCP-Wechsel — sucht der Knoten wieder per mDNS und merkt sich die neue Adresse.

Ein- und Ausschalten

PWR meldet nur echte Wechsel. „Aus" heißt Standby, nicht stromlos — nur deshalb ist das Gerät überhaupt noch abfragbar. Ein wirklich vom Netz getrenntes Apple TV meldet sich über INIT ab; der Power-State ist dann unbekannt und wird bewusst nicht geraten. Nach einem Verbindungsabbruch verbindet sich der Knoten mit Backoff (5 s bis 60 s) neu und gibt den dann tatsächlichen Zustand aus.

Der Zustand gehört zum Apple TV, nicht zum Fernseher. Per HDMI-CEC folgt das eine meist dem anderen, garantiert ist das aber nicht.

Ein- und Ausgänge

Ein
0	PWR	true/false schaltet ein bzw. aus
1	RMT	Fernbedienungsbefehl als String, siehe Knotenhilfe

Aus
0	INIT	Verbindungsstatus
1	PWR	ein/aus
2	PLAY	Abspielstatus als String
3	CONT	Struktur mit Inhalt und Status

Watchdog

Eine Sitzung kann verstummen, ohne dass es jemand merkt: die TCP-Verbindungen bleiben stehen, es fließen weiter Bytes, und trotzdem liefert pyatv keine Ereignisse mehr. Beobachtet nach 2,8 Tagen Laufzeit — ein echtes Ein- und Ausschalten erzeugte keinen einzigen Callback. Weder das Betriebssystem noch pyatv melden das, also prüft der Knoten selbst.

Der Watchdog schaut minütlich hin und wird erst nach längerer Stille tätig:

Stille	Reaktion
bis 5 min	nichts — ein unbenutztes Apple TV sendet nichts
ab 5 min	aktive Anfrage an das Gerät; keine Antwort ⇒ Reconnect
ab 15 min	Sitzung wird neu aufgebaut, auch wenn das Gerät antwortet

Der Power-State wird zusätzlich alle 30 s aktiv abgefragt — über Companions Attention-State, also eine echte Anfrage ans Gerät und kein zwischengespeicherter Push-Wert. Anlass: ein Ausschalten kam nur als Playstatus-Änderung an, nie als Power-Ereignis, und eine neu aufgebaute Sitzung meldete Unknown. Weicht der abgefragte Zustand vom zuletzt gemeldeten ab, wird er nachgereicht. Ein falsch gemeldeter Zustand hält damit höchstens 30 s.

Neuaufbauten des Watchdogs sind für den Flow unsichtbar: INIT flappt nicht, und die zuletzt gemeldeten Werte bleiben stehen — die frische Sitzung gibt nur aus, was sich tatsächlich unterscheidet. Scheitert der Wiederaufbau, wird daraus ein echter Ausfall mit INIT = false.

Hängt der Prozess trotzdem einmal, liefert kill -USR1 <pid> die Stacks aller Threads ins Knotenlog.