Modul: 74_UnifiSwitch - Auslesen und Steuern von UnifiSwitches (USW)

Begonnen von Wuehler, 12 Mai 2018, 00:37:44

Vorheriges Thema - Nächstes Thema

sledge

Zitat von: Wuehler am 14 Mai 2018, 21:56:03
Hi,

im ersten Post eine neue Version sowie Infos über die Anpassungen. Falls ihr noch ein upgrade auf dem USW machen könnt bitte eine Info, welcher code dabei angezeigt wird, dann baue ich eine Übersetzung ein. (1= connected; 5 = provisioning; 2-4=?; ?=upgrading)

....

Leider steht bei mir nur ein Update für den USG an - von daher kann ich Dir den Gefallen nicht tun.

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Wuehler

OK, einigen wir uns auf Unentschieden  ;)
Vorschlag (gilt nur für Clients):
- Modul UnifiClients.pm
- kann mehrere Clients mit den zugehörigen Readings anzeigen
- kann per RegExp eingeschränkt werden
- es kann mehrere Clients-Devices geben mit unterschiedlichen RegExp
  - Problem: Es entsteht ggf. recht viel Overhead in fhem.pl, wenn jeder client einzeln verarbeitet wird (60x Dispatch()-Funktion bei 60 Clients)
  - Man braucht ein zusätzliches Attribut in UnifiClients.pm: UpdateOrder, da eine Nachricht nur genau von einem Clients-Device verarbeitet werden wird (falls ein Client bei mehreren RegExp positiv sein würde und man z.B. eine ClientsRest mit RegExp .* haben möchte (welches vermutlich durch autocreate eh immer wieder angelegt werden wird))

Hört sich nach viel Forschungsarbeit an. Werde daher vielleicht doch erstmal ein Attribut "clientList" im Unifi-Modul einführen, mit der man die Readings auf bestimmte Clients einschränken kann.

Ausserdem muss ich mir einen Weg überlegen, wie man die Änderungen langsam und schadlos ins Update bringt.

VG,
Dirk

roedert

#17
Ich hatte das irgendwie anders mit dem Regex gemeint.
Das Unifi-Modul erstellt automatisch für jeden einzelnen Client ein Device (genau wie momentan für jeden einzelnen Switch).
Um die Übersicht zu behalten kann man aber zB beim UniFi-Device angeben sowas attr UniFi ignoreclient iPhone.*
Dies verhindert, das für Clients die mit iPhone beginnen kein Device automatisch erstellt wird.
Oder umgekehrt - man muss angeben für welche Clients automatisch ein Device erstellt werden soll.
attr UniFi autocreateclient iPhone.*
In jedem einzelnen Client-Device sind dann die Readings, die es momentan (noch) im UniFi-Device gibt:
state
accesspoint
essid
hostname
last_seen
snr
uptime

Sind natürlich alles nur meine laienhaften Gedanken, inwieweit sich das in der Form technisch umsetzen lassen würde habe ich keine Ahnung.

Wuehler

Das würde für alle mit Gast-WLAN bedeuten, dass sie die Liste andauernd um den nächsten Besucher oder Paketboten der sein Handy auf ,,nutze jedes WLAN" eingestellt hat erweitern müssen. DA die je nach Handytyp einen Hostname haben kann man nichtmal alle Mac-Adressen wegfiltern.

sledge

Für jeden "Netzteilnehmer" hier im Haus mehr oder minder automatisch ein Device in FHEM angelegt zu bekommen - eher ungern.

Der UNIFI-Controller bietet sehr viele Informationen - sowohl zu seinen eigenen Devices (Device, Port, Stromverbrauch usw) als auch zu den Netzteilnehmern. Egal wo man diese Informationen jetzt verwaltet - bei größeren Netzwerken wird das schnell unübersichtlich - entweder durch die schiere Anzahl der Readings in einem Device (aktuelle Implementierung) oder durch eine Unmenge von Devices, die automatisch angelegt werden (der Ansatz von roedert).

Unsere beiden Ansätze stimmen insofern überein, als das ein Eindämmen dieser Informationsflut sinnvoll erscheint.

Mein Ansatz beruht auf folgender Annahme:


  • Fhem soll den UNIFI Controller nicht ersetzen => Viele Informationen werde ich mir nach wie vor im Controller direkt holen - weil ich dort vermutlich auch konfigurierend eingreife, wenn erforderlich
  • Fhem soll auf Ereignisse reagieren, die aus dem UNIFI Controller extrahiert werden können => Anwesenheitserkennung, ggfs Verfügbarkeitsüberwachung allgemein, Verbrauchswerte plotten

Getreu des KISS-Prinzips halte ich die bisherige Implementierung (clientbezogene Readings in einem zentralen Device zusammentragen) für vollkommen ausreichend - Performanceaspekte noch nicht betrachtet. Allein aus Gründen der Übersichtlichkeit fände ich es schön, wenn man die Readings je Netzteilnehmer "konfigurieren" könnte, also aus der vollständigen Liste je Device


  • state
  • accesspoint
  • essid
  • hostname
  • last seen
  • snr
  • uptime

sind doch idR nur wenige Readings interessant. In meinem Fall vermutlich


  • state
  • accesspoint

zum Zwecke der Anwesenheitserkennung.

Könnte ich jetzt die anderen 5 Readings via regexp ausblenden, hätte ich die Datenmenge im zentralen Device bereits um rund 70% reduziert.

Detaillierte Auswertungen / Informationen kann ich ja nachwievor auch in FHEM extrahieren mit "get <unifi> clientdata <clientname", wenn ich die Info in FHEM weiterverarbeiten möchte.

Just my 2 cts.

Gruß,

Tom

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Wuehler

Zitat von: sledge am 16 Mai 2018, 19:55:06Readings je Netzteilnehmer "konfigurieren" könnte
Da wird die Konfiguration aber komplex, wenn man je Netzteilnehmer eine eigene config machen möchte. Wenn dann für alle dieselben Readings.

Komme in der nächsten Zeit eh nicht dazu. Erstmal den UnifiSwitch fertig machen. Oder jemand anders schickt nen patch.

roedert

Zitat von: sledge am 16 Mai 2018, 19:55:06
Unsere beiden Ansätze stimmen insofern überein, als das ein Eindämmen dieser Informationsflut sinnvoll erscheint.

Richtig, und dafür wurden ja schon die beiden Möglichkeiten genannt:
- per Regex ausschliessen was nicht automatisch angelegt werden soll
- per Regex angeben, was automatisch angelegt werden soll

3. Variante wäre Clients gar nicht automatisch anzulegen, sondern nur manuell.

Unabhängig davon, ob nun ein Device pro Netzclient implementiert wird oder nicht, wäre es auch sinnvoll in der jetzigen Implementierung Clients filtern zu können um dort die Anzahl der Readings zu begrenzen.
Bei mir zB sind es so um die 50 Clients, interessant sind jedoch nur die beiden iPhones für die Anwesenheitserkennung.

sledge

Zitat von: Wuehler am 16 Mai 2018, 20:05:50
Da wird die Konfiguration aber komplex, wenn man je Netzteilnehmer eine eigene config machen möchte. Wenn dann für alle dieselben Readings.

Genau das meinte ich auch - unsaubere Formulierung meinerseits.

Und wie gesagt: Ich bin mehr als zufrieden mit der aktuellen Implementierung - meine Vorschläge sind jammern auf hohem Niveau.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

roedert

Zitat von: sledge am 16 Mai 2018, 20:40:27
Und wie gesagt: Ich bin mehr als zufrieden mit der aktuellen Implementierung - meine Vorschläge sind jammern auf hohem Niveau.

Absolute Zustimmung, das ist schon jetzt ein tolles und nützliches Modul. Ganz großen Dank und Respekt dafür!
Ich oder wir "meckern" hier nicht, sondern wollen unterstützen/diskutieren welche sinnvollen Ideen, Änderungen, Optimierungen oder was auch immer wir noch beisteuern können solange du Zeit, Lust und Spaß daran hast das Modul weiter zu entwickeln und zu pflegen.

Wuehler

@roedert: Danke, und habe ich auch so verstanden. Auch wenn es vielleicht anders angekommen ist. Der Dank geht übrigens auch an rapster, der den größten Teil entwickelt hat.

Aktuell ist dieser Thread etwas vom Thema UnifiSwitch weggekommen. Vorschlag daher: Erstmal den UnifiSwitch fertigstellen und dann in einem neuen Thread das Thema UnifiClients nochmal neu aufgreifen. Ich habe durch die Diskussion einige Ideen mitbekommen und muss bei manchen erstmal schauen, wie sie umsetzbar sind. Ggf. dann auch erstmal nur mit einem einfachen Readings-Attribut am Controller-Device.

der-Lolo

Ich bin nicht sicher ob es bei den Switches auch so ist - aber bei den APs gibt es noch den Zustand Isolated, scheint mir der fall zusein wenn ein AP per Kabel nicht erreichbar ist - aber noch eine Funkverbindung zu einem anderen AP hat.

Christian Uhlmann

Zitat von: der-Lolo am 17 Mai 2018, 06:06:55
Ich bin nicht sicher ob es bei den Switches auch so ist - aber bei den APs gibt es noch den Zustand Isolated, scheint mir der fall zusein wenn ein AP per Kabel nicht erreichbar ist - aber noch eine Funkverbindung zu einem anderen AP hat.
Ja, das sollte im JSON der Status 11 sein
Die anderen habe ich aber bisher noch nicht ermitteln können
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

roedert

Dass das generelle Anlegen eines Devices pro Switchport "Unsinn" bzw. Overkill wäre, waren wir uns ja eigentlich ziemlich einig.
Ist aber die Frage ob es nicht optional sinnvoll wäre, ein "(PoE-)Switchport-Device" manuell anlegen zu können, welches dann auf die set-Befehle on und off versteht.
Beispiel: Ein Kamera hängt an Port 7 eines Switches.
So könnte ich ein Device Kamera definieren unter Angabe des Switches und des Ports und dieses dann direkt mit "set Kamera off" ausschalten.
Geht natürlich mit "set Switch 7 poeMode off" genauso - "set Kamera off" ist aber natürlich übersichtlicher. Und wenn sich der Switch/Port an dem die Kamera angeschlossen ist mal ändert muss ich das nur im Kamera-Device anpassen und nicht über all wo evtl "set switchname portnummer....." steht.
Vielleicht geht dies aber auch anders mit bestehenden FHEM-Mitteln umzusetzen, mit struct oder anderen Helferlein - das habe ich mir noch nicht angeschaut.
Ein dummy und dazu passendes notify ginge natürlich, sind aber auch schon wieder 2 Objekte.

Wie gesagt ... nur ein Denkanstoß. Ob und mit wieviel Aufwand dies realisierbar ist, kann ich nicht einschätzen.

Wuehler

#28
Moin,

Versuch dazu mal einen cmdAlias anzulegen:
https://wiki.fhem.de/wiki/Cmdalias

Ist denke ich eine bessere Lösung als ein eigenes port-device.
Inetwa so:
define setkam cmdalias .* AS set MySwitch 7 $EVTPART1
Müsste dann mit
setkam on
Bzw.
setkam off
bzw.
setkam auto

aufrufbar sein.
Dann musst du beim Umzug der Kamera auch nur den cmdAlias anpassen.

VG,
Dirk

Wuehler

Hallo zusammen,

Im Anhang des ersten Posts eine neue Version 0.90 des UnifiSwitch-Moduls (und Unifi-Moduls).
Meiner Meinung nach wäre das Modul für den UnifiSwitch jetzt erstmal soweit fertig, dass es offiziell bereitgestellt werden könnte.

Bitte nochmal testen. Da ich immer noch nicht der perl-Experte bin fänd ich es Klasse, wenn jemand mal ein Review des neuen Moduls sowie der Anpassungen im Unifi-Moduls durchführen könnte, bevor es dann offiziell wird.

Aktuell funktioniert das Modul nur für USWs. Für den NanoSwitch weiß ich nicht, ob der als Model ebenfalls usw sendet. Für alle anderen Geräte wäre denke ich ein weiteres Submodul/physisches Device richtig, oder es bleibt im Controller-Device.

Danke und viele Grüße,
Dirk