duffyduckandClaude Opus 4.8
47735642f2
Der Satellit kann Android-Geraete im LAN erkennen und die Agent-APK ausrollen, statt sie von Hand aufs Geraet zu kopieren. - satellite.py: adb.devices/connect/install/shell. _apk_fetch laedt die APK per HTTP (gecached in /data/apk, sha256 optional) statt sie durchs RVS zu schicken — der RVS ist ein BROADCAST-Relay (jede base64-APK ginge an alle Clients, und das Satelliten-max_size liegt bei 8 MB). adb.install ist selbstheilend (connect -> install -r) und uebersetzt die typischen Fehler in klare Ansagen (unauthorized, Signatur-Mismatch, Speicher voll). Imports lokal in den Funktionen (Hausmuster). - Discovery: mDNS-Typen _amzn-wplay/_adb-tls-connect/_androidtvremote2, _mdns_kind -> firetv/android-adb/androidtv, plus _enrich_adb (TCP-Probe 5555) -> adbCapable. - Dockerfile: adb; compose: HOME=/data (ADB-Key persistent, sonst fragt das Geraet nach jedem Rebuild neu) + ANDROID_ADB_SERVER_PORT=5038 (Host-Kollision). - .env.example: neue Aktionen + Warnung, dass die Allowlist den Code-Default ueberschreibt (sonst lehnt ein bestehender Satellit adb.* ab). - Brain: adb.* in der satellite_command-Beschreibung; WICHTIG Timeout 200s fuer adb.*/ssh.exec — der Bridge-Default von 20s haette jede Installation abgewuergt. - Diagnostic: sat_command (Browser->RVS) und sat_result (RVS->Browser) gab es bisher GAR NICHT; beide ergaenzt. 📦-Button je ADB-faehigem Geraet + Rollout- Modal mit Status/Log, ADB-Tag in der Geraeteliste. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.0.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.0.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. Das Script lädt die .env selbst (muss im
satellite/-Ordner liegen):
cd satellite
cp .env.example .env # RVS-Zugang + SATELLITE_LOCATION eintragen
pip install -r requirements.txt
python satellite.py # liest .env automatisch
(Echte Umgebungsvariablen haben Vorrang — export RVS_TOKEN=... überschreibt die
.env, falls du das lieber magst.)
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").
Satellit im selben Netz wie der RVS (z.B. Rechenzentrum, direkt auf die
interne IP statt NAT-Hairpin): RVS_HOST=<interne-ip> + RVS_SNI=<zert-name>
(der Name, für den das Caddy-Zertifikat gilt). Ohne das scheitert TLS an
tlsv1 alert internal error. Zuhause / normal: RVS_SNI leer lassen.
Kontrolle: im Log/Diagnostic muss primary_ip im Ziel-LAN liegen
(192.168.0.x) — steht da 192.168.65.x oder 172.x, sitzt der Satellit im
falschen (Docker-)Netz.
Als Dienst installieren (Autostart, ohne Docker)
Legt automatisch ein .venv an, installiert die Requirements und richtet einen
Dienst ein, der bei Boot startet und bei Absturz neu hochkommt. .env vorher
anlegen.
Linux (systemd) / macOS (launchd):
cd satellite
bash install.sh # installieren + starten
bash install.sh uninstall # entfernen
- Linux-Logs:
journalctl -u aria-satellite -f - macOS-Logs:
tail -f satellite.log(evtl. „Lokales Netzwerk"-Zugriff erlauben)
Windows (Scheduled Task) — PowerShell als Administrator:
cd satellite
powershell -ExecutionPolicy Bypass -File install.ps1 # installieren + starten
powershell -ExecutionPolicy Bypass -File install.ps1 -Uninstall # entfernen
- Log:
Get-Content -Wait satellite.log
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.