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

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

Vorheriges Thema - Nächstes Thema

Wuehler

Nabend,

habe ein wenig nachgelesen, wie das mit dem zweistufigen Modulen funktioniert und habe eine erste Beta für den UnifiSwitch gebaut. Als IODev wird ein funktionierende Unifi-Modul verwendet. Um dort die Anzahl Readings nicht explodieren zu lassen ein Kind-Modul -> UnifiSwitch.

Es muss sowohl das Unifi als auch das UnifiSwitch-Modul aus dem Anhang in den FHEM-Ordner kopiert werden. Bis es das per offiziellem Update gibt wird es noch etwas dauern.

Bitte mal ausprobieren und Fehler sowie Wünsche posten.

TODOs:
- state des USW korrekt setzen (aktuell nur connected und provisioning)

V 0.1:
  - Initiale Version mit ein paar Readings zum poe-state je port
V 0.11:
- state des USW wird gesetzt (noch nicht immer korrekt, da ich die state-Nr. für z.B. upgrading noch nicht kenne)
- Port-Nummern < 9 mit führender 0
- Model als Internal
- port-state als reading hinzugefügt
- fixed encode_json-Fehler
V 0.90:
- setter für poe-Mode aus dem Unifi-Modul entfernen und hier einfügen
- commandref

Edit: 10.06.2018:
Modul ist ab 11.06.2018 eingecheckt. Anhänge hier entfernt.

roedert

#1
...das ging ja schnell mit der Umsetzung :-)
Hab die beiden Module mal in mein Testsystem eingepflegt, bekomme aber leider direkt nen Komplettabsturz:
Undefined subroutine &main::encode_json called at ./FHEM/74_Unifi.pm line 1145.

Kann aber auch sein dass irgendein Paket fehlt, das Unifizierend-Modul hatte ich vorher auf dem Testsystem noch nicht im Einsatz.

sledge

Hi,

gerade eingespielt, shutdown restart und go. Derzeit betreibe ich 2 * US8 Switche (die via PoE am Hauptswitch hängen) und einen US16P150, der hier alles zentral mit PoE versorgt (4 APs, 2 US8)

Was passiert nach dem restart:


  • Raum "UnifiSwitch" wird angelegt (nice)
  • Alle Switches werden via "autocreate" angelegt und in den Raum gepackt (nice2)

Generell enthalten die Readings die In formationen, die man erwartet, je Switchport gibt es folgende Einträge:


port_8_name
Wohnzimmer
2018-05-13 11:47:27
port_8_poe_current
175.53
2018-05-13 11:47:27
port_8_poe_mode
auto
2018-05-13 11:47:27
port_8_poe_power
9.33
2018-05-13 11:47:27
port_8_poe_voltage
53.14
2018-05-13 11:47:27


Als Reading liest Du das "model" des Switches aus, in diesem Fall usw_model  US16P150. Da es mE unveränderlich (je Device) ist, hätte ich das bei Internals gesehen. Naja - und einen sinnvollen State gibt es noch nicht, aber das wusstest Du vermutlich.

Aber das wichtigste: Das Modul macht was es soll, alle meine Switches wurden angelegt, zu jedem Switchport gibt es die PoE-relevante Info. Alles Switches werden mit dem richtigen Model erkannt - also bestens. Und die Verlagerung der PoE-Infos in die abhängigen Devices gefällt mir gut.

Darüberhinaus stellt sich mir generell die Frage, wie man bei umfangreichen Unifi-Installationen die Explosion von Readings im Hauptdevice verhindern kann... Zu jedem Gerät gibt es ~6 Readings - bei meiner Installation sind das dann schon geschmeidige 60 Geräte * 6 Readings ;-) Tut erstmal nicht weh - nur halt so ein Gedanke.

Also Danke erstmal für die Mühe, jetzt auf ein 2-stufiges Modulkonzept umzusteigen.

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, ...

sledge

Zitat von: roedert am 13 Mai 2018, 12:00:52
...das ging ja schnell mit der Umsetzung :-)
Hab die beiden Module mal in mein Testsystem eingepflegt, bekomme aber leider direkt nen Komplettabsturz:
Undefined subroutine &main::encode_json called at ./FHEM/74_Unifi.pm line 1145.

Kann aber auch sein dass irgendein Paket fehlt, das Unifizierend-Modul hatte ich vorher auf dem Testsystem noch nicht im Einsatz.

Yep, da fehlt mE JSON für perl https://packages.debian.org/de/sid/libjson-perl. Installieren, ggfs "shutdown restart" und dann sollte es klappen.
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

Danke euch für den Test.
Ich habe gesehen, dass es auch eine fhem-Funktion tojson() gibt. Werde die mal verwenden. Vielleicht braucht man dann kein zusätzliches Paket.

Ansonsten fänd ich eure Meinungen interessant, wann man in Zukunft ein Kind-Modul nutzen sollte und wenn nicht.
60 eigene client-Devices sind bestimmt auch keine Lösung.
Rein theoretisch müsste auch ein dreistufiges Modul gehen, so dass z.B. jeder Port des Switch auch ein eigenes Devices sein könnte.

Bin auf eure Meinung gespannt.
VG,
Dirk

jochen_f

Hi,

Undefined subroutine &main::encode_json called at ./FHEM/74_Unifi.pm line 1145.

Diesen Fehler bekomme ich auch. libjson-perl ist aber installiert (2.90-1). Auch ein Update auf 2.97001-1 brachte keine Änderung.

Gruß, Jochen

Christian Uhlmann

Hi Wuehler,

dank für die Arbeit, klappt bei mir wunderbar, alle 5 Switch sind angelegt worden und ich kann alle Informationen rauslesen.

Bzgl. Mehrstufigkeit würde ich folgedes Vorschlagen:
Alle Unifi Devices, die im Controller als Unifi Device geführt werden, als Kind-Modul.
In Zukunft also auch die AP's, wenn es Sinn macht.

Damit repräsentiert das Unifi Modul den Controller und das UnifiSwitch Modul die Devices, evtl, sollte das Modul dann auch anders heißen, UnifiDevice.

Pro Port ein weiteres Kinde-Modul halte ich für nicht angebracht, wer das braucht, kann das leicht mit ReadingsProxy bauen.
Wichtiger wäre mir ein
set <UnifiSwitch> port_6_poe_mode off|auto|etc.
am leibsten mit dropDowns :)

ein kleiner Hinweis noch, evtl nennst du die Ports 01, 02 usw. ansonsten sieht das mit den Readings bei einem US8P150 so aus:
   TYPE       UnifiSwitch
   READINGS:
     2018-05-14 11:08:27   port_10_name    SFP 2
     2018-05-14 11:08:27   port_1_name     KG.vr.SW.server.downlink
     2018-05-14 11:08:27   port_1_poe_current 115.23
     2018-05-14 11:08:27   port_1_poe_mode auto
     2018-05-14 11:08:27   port_1_poe_power 6.20
     2018-05-14 11:08:27   port_1_poe_voltage 53.78


nicht sehr schlimm aber evtl. unschön.


Grüße und Danke

Christian
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

jochen_f

Ich habe in 74_Unifi.pm folgendes hinzugefügt:

use JSON qw(encode_json);

Damit funktioniert es. Jetzt bekomme ich das Device angelegt:

define UNDEFINED UnifiSwitch UNDEFINED
attr UNDEFINED room UnifiSwitch

Die Readings sind aber korrekt.

usw_model US16P150 etc.

Was meiner Meinung nach aber fehlt, ist der Port Status selbst.

sledge

Zitat von: Christian Uhlmann am 14 Mai 2018, 11:10:34


Bzgl. Mehrstufigkeit würde ich folgedes Vorschlagen:
Alle Unifi Devices, die im Controller als Unifi Device geführt werden, als Kind-Modul.
In Zukunft also auch die AP's, wenn es Sinn macht.

Damit repräsentiert das Unifi Modul den Controller und das UnifiSwitch Modul die Devices, evtl, sollte das Modul dann auch anders heißen, UnifiDevice.


Um das mal aufzugreifen: Je UNIFI-Gerät ein entsprechendes Device anlegen - sinnvoll und auch handhabbar, denke ich. Insofern +1. Welche Infos dann in dem Device als Reading zur Verfügung gestellt werden - was halt geht und sinnvoll ist.

Entspricht ja auch der Vorgehensweise ähnlicher Module.

Und: Danke!

Gruß und Danke,

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

#9
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)

Offen ist noch der Einbau der setter (und Ausbau aus dem Unifi-Modul).

Ich denke, dass es zukünftig bei Bedarf noch folgende Kind-Module geben könnte. Ein allgemeingültiges UnifiDevice halte ich für nicht so sinnvoll, da darin dann auch immer unnötige Funktionen anderer Devices enthalten sein würden:
- 74_UnifiAP.pm: Readings und getter/setter für Access-Points
- 74_UnifiUSG.pm: Readings und getter/setter für USG
- 74_UnifiClients.pm: Alle Clients in einem extra-Device
- 74_UnifiHotspot.pm: Der Hotspot mit z.B. dem VoucherCache
Aber das muss man sich im Detail dann noch ansehen.

@Jochen_f: Hast du deinem switch keinen Alias gegeben? Ich habe jetzt mal die IP des switch als Fallback genommen, dass da kein UNDEFINED kommt. Bitte nochmal den Switch löschen und wenn weiterhin UNDEFINED kommt nochmal löschen und vom Unifi ein log mit verbose=5 anhängen.

VG,
Dirk

roedert

#10
Zitat von: Wuehler am 14 Mai 2018, 08:59:39
Ansonsten fänd ich eure Meinungen interessant, wann man in Zukunft ein Kind-Modul nutzen sollte und wenn nicht.
60 eigene client-Devices sind bestimmt auch keine Lösung.

Besten Dank erstmal für die schnelle Umsetzung - sieht schonmal prima aus.
Die Idee für jedes Gerät ein UniFi-Gerät (Switch, AP etc) ein eigenes Device zu erstellen klingt eigentlich plausibel. Nochmal ein Device per Switchport halte ich auch für übertrieben.
Konsequenterweise könnte man auch für jeden Netzwerk-Client ein eigenes Device anlegen, dann hat man evtl. zwar deine "60 Client-Devices" - aber momentan hat man "hunderte" Readings im Unifi-Device was ja auch nicht gerade übersichtlicher ist.

Edit: Sorry, ich hatte deinen Beitrag von gestern Abend noch nicht gesehen, da steht's ja ähnlich drin. Diesen Ansatz halte ich für sehr sinnvoll.

jochen_f

Ja, der Switch hatte in der Tat keinen Alias. Die Unifi Software nimmt als Namen dann standardmäßig die MAC Adresse, daher war mir das noch gar nicht aufgefallen.

Funktioniert jetzt einwandfrei, auch Port Status ist jetzt vorhanden.

Vielen Dank!

Gruß, Jochen

Wuehler

Danke für euer Feedback.

@roedert: Sicherheitshalber folgende Klarstellung: ich meinte für die Clients genau ein Device in dem dann alle Clients mit ihren Readings sind. Ich meinte nicht ein Device je Client.

roedert

#13
ok, kann man glaube ich drüber streiten was unübersichtlicher ist:

- ein Device mit "hunderten" unübersichtlichen Readings von allen Clients
oder
- unübersichtliche "60" Devices mit einer Hand voll Readings pro Client

Ich würde Variante 2 bevorzugen, so ist es ja auch in der UniFi-GUI abgebildet.

Evtl. kann man auch dem UniFi-"Elterndevice" auch ein Attribut geben, welche Clients (als Regex) zu ignorieren sind und somit gar nicht erst als Device/Reading erstellt werden.

sledge

Zitat von: roedert am 15 Mai 2018, 14:40:43
ok, kann man glaube ich drüber streiten was unübersichtlicher ist:

- ein Device mit "hunderten" unübersichtlichen Readings von allen Clients
oder
- unübersichtliche "60" Devices mit einer Hand voll Readings pro Client

Ich würde Variante 2 bevorzugen, so ist es ja auch in der UniFi-GUI abgebildet.

Evtl. kann man auch dem UniFi-"Elterndevice" auch ein Attribut geben, welche Clients (als Regex) zu ignorieren sind und somit gar nicht erst als Device/Reading erstellt werden.

Diesen Ansatz hatte ich auch schon im Kopf "hin und her gewälzt".

Folgender Gedanke:

1. Einschränkung der anzuzeigenden Devices regexp (was ja Deinem Vorschlag entspricht)
2. Einschränkung der anzuzeigenden Readings via Regexp - Raumtemperatur, PH-Wert und aktuelle Beschleunigung (you get the picture) interessieren mich je nach Anwendungsfall nicht - aber An/Abwesenheit schon.

Aber eine Einschränkbarkeit der Netzwerkteilnehmer im Hauptdevice (=Controller) fände ich schon charmant.

Gruß - Test folgt später.

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, ...