UniFi-AP-Status-LED steuern - meine Lösung

[remo]

Vorwort

Ich besitze zwei UniFi-Flex-HD.
Bei denen kann man wunderschön die Farbe des LED-Rings ändern.
Sodass mir die Idee kam, die APs ebenfalls als "Nachtlicht" zu benutzen.
Sinnvollerweise sollten die LEDs nur bei Dunkelheit eingeschaltet sein.

Ich habe das FHEM-UniFi-Modul bisher ausschließlich benutzt,
um mittels switchSiteLEDs den o.g. Wunsch zu realsieren.

So 100%-ig zuverlässig funktionierte das aber nicht.
AP-Update, Controller-Update, Modul-Update ... und ich begann von Neuem.

Laut UniFi selbst ist eine zentrale Schaltung der LEDs kein Site-Setting mehr.
Jeder AP soll nun einzeln behandelt werden.
Zumindest soll die Entwicklung wohl in diese Richtung gehen und betrifft (vorerst) nur die LEDs.
Ich hatte regen eMail-Kontakt mit dem Support und wandte mich an die Community.

Nun war ich auf der Suche nach einer (relativ) nachhaltigen Lösung,
welche ich hier vorstellen möchte.

Auf die Verwendung von 74_UNIFI.pm kann in diesem Szenario gänzlich verzichtet werden.
Die Verwendung des Projektes UniFi-API-Client (GitHub) erschien mir für mein Anliegen etwas overkilled.
Außerdem stellt die syswrapper.sh (Skript direkt auf den UniFi-APs) keine Funktionalität
zur Manipulierung seiner LEDs bereit, sodass ich aktuell auch keine Möglichkeit sehe,
74_UNIFI.pm entsprechend anzupassen (zumindest nicht im Rahmen meiner Möglichkeiten).

Technisch geschieht Folgendes:
Der FHEM-Server (z.B. Debian) stellt per Skript eine SSH-Verbindung zum AccessPint (AP) her.
Dazu muss zwischen dem Server und dem AP zuvor eine Art "Vertrauensstellung" eingerichtet werden.
Ein Teil des Skripts manipuliert dann eine bestimmte Konfigurationsdatei direkt auf dem AP selbst.
Da ein AP aber nach einem Neustart/Update scheinbar seinen SSH-Host-Key neu generiert,
kommt hier SSH-Key-Authentication zum Einsatz; ein von uns generierter SSH-Host-Key wird auf den
AP provisioniert und ist somit immer gleich.
Im Anschluss wird im FHEM selbst die Ausführung des Skripts ermöglicht, sodass eine zeitgesteuerte
Schaltung der LEDs realsiert werden kann.

Nachteile:
- UniFi rät davon ab, APs manuell zu manipulieren. Es könnten Schäden entstehen.
  UniFi supportet maximal die Anpassung direkt über den Controller und seiner API (siehe UniFi-API-Client (GitHub)).
- Der UniFi-Controller erhält niemals Kenntnis über den veränderten Zustand seiner AP-LEDs,
  heißt: startet ein AP neu, erhält er den im Controller eingestellten Wert (zumindest bis FHEM erneut schaltet).
- Die von mir vorgestellte Lösung funktioniert nur in eine Richtung,
  heißt: es ist (aktuell) nicht möglich abzufragen, ob die LED erfolgreich umgeschaltet wurde bzw. ob das Skript erfolgreich ausgeführt wurde.

Jeder muss demnach selbst entscheiden, ob er/sie damit leben kann



Erfolg, ausbleibender Schaden ohne Gewähr.
Ich bin kein studierter Linux-Spezialist.
Meine Kenntnisse erlange ich durch Hobby-Projekte, lesen, probieren und teielweise beruflich.
Außerdem behaupte ich nicht, dass meine Lösung DIE ABSOLUTE sei;
ich bin offen für Kritik und Verbesserungen.





Voraussetzungen:

- SSH-Zugriff auf euren FHEM-Server (in meinem Fall Debian 11)
- SSH-Zugriff auf euren UniFi-AP (aktivierbar über den UniFi-Controller)
- eine DHCP-Servierung oder feste IP-Adresse für euren AP oder einen funktionierenden DSN-Server
- Angaben wie username, passwort, ip/dns-name oder ähnlich sind entsprechend auf eure Gegebenheiten anzupassen.





prüfen (auf FHEM-Server):

Habt ihr bereits einen SSH-RSA-Host-Key erzeugt?

Code Auswählen Erweitern


sudo su
cat /root/.ssh/id_rsa.pub


1. Datei nicht gefunden oder Anzeige leer: nein, habt ihr nicht
2. Ausgabe beginnt mit ssh-rsa xxxxx: ja, habt ihr bereits

wenn nein:

Code Auswählen Erweitern


sudo su
apt-get install sshpass
apt-get install openssh-client
ssh-keygen   # alle Abfragen mit [ENTER] bestätigen
cat /root/.ssh/id_rsa.pub   # komplette Ausgabe in Textdatei parken


wenn ja:

Code Auswählen Erweitern


sudo su
cat /root/.ssh/id_rsa.pub   # komplette Ausgabe in Textdatei parken


in jedem Fall:

Code Auswählen Erweitern


sudo su
ssh-copy-id -i ~/.ssh/id_rsa.pub ap-ssh-username@ap-ip-adresse-oder-ap-dns-name   # AP als known host bekannt machen (eine Art "Vertrauensstellung" erzeugen)




RSA-Key auf UniFi-AP übertragen:

Loggt euch auf eurem UniFi-Controller ein, fügt den in der Textdatei geparkten Key ein (siehe Bild_01.png).
Der Key, der eingefügt werden muss hat dieses Format: ssh-rsa xxxxx...= username@fhem-server
Speichern. Warten bis Provisioning beendet.



Weiter auf dem FHEM-Server:

Ihr benötigt eine Passwort-Datei.
Der FHEM-Server soll sich später per SSH auf den AP verbinden und dort remote Befehle ausführen.

Code Auswählen Erweitern


sudo su
cd /home/username
nano .ap-pw   # dort das SSH-Passwort eures AP eintragen + speichern + nano beenden (im Klartext und als einzelne Zeile)
chmod 600 .ap-pw




Nun werden zwei Skripte erzeugt:

1.

Code Auswählen Erweitern


sudo su
cd /home/username
nano led_ein.sh


Dort bitte einfügen + speichern + nano beenden:

Code Auswählen Erweitern


#!/bin/bash
sudo sshpass -f /home/username/.ap-pw ssh ap-ssh-username@ap-ip-adresse-oder-ap-dns-name "sed -i 's/mgmt.led_enabled=false/mgmt.led_enabled=true/g' /var/etc/persistent/cfg/mgmt;syswrapper.sh reload"
exit 0




2.

Code Auswählen Erweitern


sudo su
cd /home/username
nano led_aus.sh


Dort bitte einfügen + speichern + nano beenden:

Code Auswählen Erweitern


#!/bin/bash
sudo sshpass -f /home/username/.ap-pw ssh ap-ssh-username@ap-ip-adresse-oder-ap-dns-name "sed -i 's/mgmt.led_enabled=true/mgmt.led_enabled=false/g' /var/etc/persistent/cfg/mgmt;syswrapper.sh reload"
exit 0




Berechtigungen setzen:

Code Auswählen Erweitern


sudo su
chmod 777 /home/username/led_*.sh
chown root:root /home/username/led_*.sh
# ToDo: 777 und root:root notwendig?




Erster Test:

Code Auswählen Erweitern


sudo su
cd /home/username
./led_ein.sh
./led_aus.sh




Bestenfalls sollte die LED eures AP nun ein- bzw. ausschalten.
Es kann vorkommen, dass bei der ersten Ausführung der Skripte das AP-SSH-Passwort einmalig abgefragt wird.



FHEM-at-Beispiel:

Code Auswählen Erweitern


define at_Nachtlicht_EIN at *20:00 { system ('sudo /home/username/led_ein.sh&');; }
define at_Nachtlicht_AUS at *06:00 { system ('sudo /home/username/led_aus.sh&');; }






Fazit:

Bei mir läuft dieses Konstrukt seit ein paar Tagen zuverlässig.
Trotz Updates und diverser Reboots schaltet FHEM zuverlässig die LEDs.
Hoffentlich ist nun vorläufig Ruhe mit der Bastelei
Dass ich mich außerhalb der Empfehlungen von UniFi bewege ist für mich persönlich akzeptabel.
Dass meine APs nach einem Neustart wieder die LED-Einstellung vom Controller erhalten ist für mich auch in Ordnung,
da FHEM die Sache dann wieder selbst regelt. Ebenfalls kann ich mit der fehlenden Rückmeldung gut leben.
Sicherlich ließe sich mein Lösungsansatz noch eleganter gestalten, aber bitte betrachtet ihn auch als solchen:
einen ANSATZ.

Viel Spaß beim Ausprobieren.





getestet auf:

Code Auswählen Erweitern


Controller Version: 7.2.93
AP-Firmware: 6.0.21
Stand 01. September 2022


[Wernieman]

Warum installierst Du sshpass?

ssh-keygen ist nicht in dem Packet enthalten .... und eigentlich wird immer von sshpass abgeraten ...

[remo]

Warum installierst Du sshpass?

Um die remote SSH-Verbindung von A nach B mittels Passwortdatei "unattended" per cmd zu ermöglichen.

ssh-keygen ist nicht in dem Packet enthalten

Danke, ist ergänzt.

.... und eigentlich wird immer von sshpass abgeraten ...

Mit welcher Begründung und wo wird davon abgeraten?

[MadMax-FHEM]

Um die remote SSH-Verbindung von A nach B mittels Passwortdatei "unattended" per cmd zu ermöglichen.

Das geht auch ganz einfach, in dem man den public-Key des Users, der sich remote einloggen will auf dem Zielsystem ablegt.
Dann werden diese Schlüssel geprüft, statt einer PW-Abfrage.

Mit welcher Begründung und wo wird davon abgeraten?

An vielen Stellen, inkl. hier im Forum...

Es ist ein "Hacker-Programm"
Und dem gibst du dein Passwort, nur um dir die Eingabe zu sparen...
...was, wie oben geschrieben, auch anders geht.

EDIT:
https://heinz-otto.blogspot.com/2020/09/ssh-mit-public-key.html
https://heinz-otto.blogspot.com/2017/01/per-ssh-remote-befehle-direkt-ausfuhren.html

Gruß, Joachim

[remo]

Gut, danke.
Dann hab ich das wider besseren Wissens verwendet.
Werde mir die andere Lösung mal ansehen.