duffyduckandClaude Opus 4.8
57e13800e0
Symptom: Satellit fand nur Docker-Container (192.168.65.x / 172.18.x) statt der echten LAN-Geraete. Ursache ist kein Bug, sondern das Deployment-Netz: auf Docker Desktop (Mac/Windows) ist network_mode:host das Docker-VM-NAT, nicht das echte LAN — mDNS/SSDP erreichen die realen Geraete nicht. - satellite.py: _net_context() ermittelt primary_ip + alle IPs und WARNT, wenn der Satellit in einem Docker-/NAT-Netz laeuft (192.168.65.x oder 172.16-31.x). Netz- Info wird in sat_hello + sat_devices mitgeschickt und beim Start geloggt. - Diagnostic: zeigt Netz (primary_ip) pro Satellit + eine rote ⚠-Box mit der Warnung, wenn er im falschen Netz sitzt. - README/compose: klar dokumentiert, dass der Satellit im ECHTEN Ziel-LAN laufen muss (Linux Docker Engine ODER nativ python satellite.py); Docker-Desktop-Falle. py/node clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.2 KiB
ARIA Satellit 🛰️
Ein eigenständiger Außenposten-Container für ein fremdes Netz (Büro, Werkstatt, Ferienwohnung …). Er verbindet sich als RVS-Client in Stefans Raum und gibt ARIA Augen und Hände in genau diesem Netz — ohne dass der Haupt-Stack dort stehen muss.
- Augen (Info): entdeckt Geräte via mDNS/Zeroconf (Chromecast, AirPlay, Sonos, Drucker, NAS …), SSDP/UPnP + DIAL (Smart-TVs, Fire TV) und der ARP-Tabelle (rohe Hosts). Meldet ARIA ein Live-Inventar.
- Hände (Steuerung): DIAL-App-Launch (z.B. YouTube-Video auf dem Fire TV), Wake-on-LAN, generisches HTTP. Nur wenn freigeschaltet (siehe Sicherheit).
⚠️ Wichtig: der Satellit MUSS im echten Ziel-LAN laufen
Discovery (mDNS/SSDP-Multicast + ARP) funktioniert nur, wenn der Prozess
tatsächlich im selben LAN wie die Geräte hängt — z.B. 192.168.177.0/24, wo der
Fire TV steht.
Docker Desktop (Mac/Windows) geht NICHT. Dort ist network_mode: host das Netz
der Docker-Linux-VM (NAT, 192.168.65.x / 172.x), nicht dein echtes LAN.
Der Satellit sieht dann nur Docker-Container statt der echten Geräte. (Der Satellit
erkennt das selbst und meldet eine ⚠-Warnung im Diagnostic + Log.)
Richtig deployen — zwei Wege:
A) Linux-Box im Ziel-LAN mit Docker Engine (empfohlen, z.B. Raspberry Pi / NUC im Büro):
cd satellite
cp .env.example .env # RVS-Zugang + SATELLITE_LOCATION
docker compose up -d --build
docker compose logs -f # "Netz: primary_ip=192.168.177.x" + "[scan] N Geraete"
network_mode: host (schon gesetzt) gibt hier echtes LAN + Multicast.
B) Nativ als Python-Prozess (für Mac/Windows-Test oder ohne Docker) — läuft direkt auf einer Maschine im Ziel-LAN:
cd satellite
pip install -r requirements.txt
export RVS_HOST=... RVS_TOKEN=... SATELLITE_LOCATION="Wohnung" CONTROL_ENABLED=true
python satellite.py
RVS_HOST/PORT/TLS/TOKEN identisch zum Haupt-Stack (gleicher Raum, damit ARIA
den Satelliten erreicht). SATELLITE_LOCATION ist der Name, über den ARIA das Netz
anspricht („Büro").
Kontrolle: im Log/Diagnostic muss primary_ip im Ziel-LAN liegen
(192.168.177.x) — steht da 192.168.65.x oder 172.x, sitzt der Satellit im
falschen (Docker-)Netz.
So nutzt ARIA es
ARIA hat drei Brain-Tools:
satellite_list— welche Netze/Satelliten sind online + was können sie.satellite_devices(satellite)— Inventar eines Netzes.satellite_command(satellite, device, action, params)— Aktion ausführen.
Beispiel „YouTube-Video auf dem Büro-Stick":
satellite_command(satellite="Büro", device="Fire TV",
action="dial.launch", params={"app":"YouTube","v":"<videoId>"})
Sicherheit
Der Satellit scannt ein Netz und ist über einen Cloud-Relay erreichbar — deshalb:
- Reagiert nur auf den eigenen RVS-Raum (Token).
CONTROL_ENABLED=false= reiner Info-Satellit (steuert nichts). Standard-sicher.- Bei
true: nur Aktionen ausCONTROL_ALLOWLIST, alles andere wird abgelehnt. - Jede ausgeführte Aktion wird geloggt.
- Keine offenen Ports — reiner Client.
Empfehlung: in vertrauenswürdigen Netzen CONTROL_ENABLED=true mit enger Allowlist;
sonst false und nur beobachten.