Eigene Skripte per Automation in Home Assistant einbinden
- Wenn Home Assistant den LAN-Server anstoßen soll
- Voraussetzungen
- Home Assistant OS richtig einordnen
- 1. SSH-Schlüssel und Hostschlüssel vorbereiten
- 2. Berechtigung auf einen einzelnen Dienst begrenzen
- 3. shell_command definieren
- 4. Automation auslösen
- Alternative: rest_command
- Fehlersuche
- Fazit
- Quellen und technische Dokumentation
Wenn Home Assistant den LAN-Server anstoßen soll
MQTT eignet sich gut für fortlaufende Zustände, die REST-API für Aufrufe von außen. Bei einer Automation läuft die Richtung andersherum: Ein Trigger in Home Assistant startet eine klar begrenzte Aufgabe auf dem LAN-Server. Dafür kommen shell_command über SSH oder rest_command über einen abgesicherten HTTP-Endpunkt infrage.
Voraussetzungen
- Home Assistant und LAN-Server erreichen sich im lokalen Netz oder über ein VPN.
- Die auszuführende Serveraufgabe liegt bereits als systemd-Service vor.
- Für SSH existiert ein eigener, nicht privilegierter Dienstbenutzer.
- Hostschlüssel und Zugangsdaten werden nicht im YAML-Text versteckt oder ungeprüft akzeptiert.
Home Assistant OS richtig einordnen
Unter Home Assistant OS läuft shell_command im homeassistant-Container – nicht im Terminal-/SSH-Add-on und nicht direkt auf dem HAOS-Host. Laut Home-Assistant-Dokumentation stehen dort unter anderem ssh, curl und sh zur Verfügung. Der Arbeitsordner ist /config; nur dort abgelegte Schlüssel bleiben persistent. Befehle werden nach 60 Sekunden beendet.
Das ist der Grund, warum der entfernte Prozess nur gestartet werden sollte. Die eigentliche Sicherung läuft anschließend unabhängig als systemd-Service auf dem LAN-Server.
1. SSH-Schlüssel und Hostschlüssel vorbereiten
Der private Schlüssel liegt beispielsweise unter /config/.ssh/id_ed25519_lanserver und ist nur für Home Assistant lesbar. In known_hosts muss der zuvor über einen vertrauenswürdigen Weg geprüfte Hostschlüssel stehen. StrictHostKeyChecking=no wäre bequem, beseitigt aber genau diese Identitätsprüfung und gehört nicht in eine belastbare Konfiguration.
2. Berechtigung auf einen einzelnen Dienst begrenzen
Der entfernte Benutzer darf nicht pauschal jedes Kommando per sudo ausführen. Eine Datei wie /etc/sudoers.d/homeassistant-backup wird mit visudo -f geprüft und beschränkt die Freigabe auf den benötigten Aufruf:
homeassistant ALL=(root) NOPASSWD: /usr/bin/systemctl start backup.service
Der genaue Pfad von systemctl lässt sich mit command -v systemctl prüfen. Der Dienst selbst muss feste Pfade verwenden und darf keine vom SSH-Aufruf übernommenen, ungeprüften Parameter ausführen.
3. shell_command definieren
shell_command:
lanserver_backup_starten: >-
ssh -i /config/.ssh/id_ed25519_lanserver
-o BatchMode=yes
-o ConnectTimeout=10
-o UserKnownHostsFile=/config/.ssh/known_hosts
homeassistant@SERVER-IP
'sudo /usr/bin/systemctl start backup.service'
Nach Änderungen wird die Integration unter Entwicklerwerkzeuge → YAML oder über die Aktion shell_command.reload neu geladen.
4. Automation auslösen
automation:
- alias: "Nächtliches Backup auf dem LAN-Server starten"
triggers:
- trigger: time
at: "02:00:00"
conditions: []
actions:
- action: shell_command.lanserver_backup_starten
response_variable: backup_start
- if:
- condition: template
value_template: "{{ backup_start.returncode != 0 }}"
then:
- action: notify.notify
data:
message: "Der Backup-Dienst konnte nicht gestartet werden: {{ backup_start.stderr }}"
response_variable enthält stdout, stderr und returncode des kurzen SSH-Aufrufs. Sie sagt nicht, ob der anschließend gestartete Backup-Dienst erfolgreich fertig wurde. Dafür braucht es eine eigene Statusdatei, einen MQTT-Status oder einen separaten Prüf-Endpunkt.
Alternative: rest_command
Ein HTTP-Endpunkt ist häufig leichter zu kapseln als SSH. Er muss authentifiziert sein, nur POST akzeptieren, Eingaben validieren und möglichst per HTTPS oder ausschließlich über ein vertrauenswürdiges internes Netz/VPN erreichbar sein:
rest_command:
lanserver_backup_starten:
url: "https://lanserver.example.lan/api/backup"
method: POST
headers:
Authorization: "Bearer {{ token }}"
content_type: "application/json"
payload: '{"job":"backup"}'
Das Token wird nicht fest in eine veröffentlichte Konfiguration geschrieben. Ein ungeschütztes backup-trigger.php über HTTP wäre kein gleichwertiger Ersatz.
Fehlersuche
1. Den SSH-Befehl zunächst im tatsächlichen shell_command-Laufzeitkontext testen.
2. Dateirechte von Schlüssel und known_hosts prüfen.
3. Auf dem LAN-Server journalctl -u ssh und journalctl -u backup.service auswerten.
4. Bei Rückgabecode 124 oder abgebrochenen Aufrufen die 60-Sekunden-Grenze beachten.
5. Bei REST-Aufrufen HTTP-Status, TLS-Zertifikat und Serverprotokoll prüfen.
Fazit
Home Assistant sollte einen externen Job auslösen, nicht selbst dessen gesamte Laufzeit verwalten. Ein eingeschränkter SSH-Benutzer oder ein authentifizierter REST-Endpunkt hält die Rechte klein; systemd übernimmt die eigentliche Arbeit und deren Protokollierung.
