Neues Modul - 74_Unifi - Für den Ubiquiti Networks (UBNT) - Unifi Controller

Begonnen von rapster, 23 August 2015, 02:12:04

Vorheriges Thema - Nächstes Thema

marvin78

Zitat von: hoppel118 am 22 Januar 2022, 20:44:50
By the way... Am OS der UDM-Pro-Se hat sich wohl einiges geändert im Vergleich zur UDM-Pro-SE.

• UDM-Pro: v1.11.0
• UDM-Pro-SE: v2.3.11

Keine Ahnung, wie die API zur Firmwareversion in Beziehung steht. Aber Versionssprung ist ja schon etwas größer.

Anscheinend ist das Root filesystem nur persistent:

https://github.com/boostchicken-dev/udm-utilities/issues/214

Gruß Hoppel

Ich rede nur von der API.

hoppel118

Ich steck da nicht so drin. Also sorry, wenn ich hier Sachen durcheinander werfe.

Ich probiere deinen Vorschlag nachher aus und dann schauen wir weiter. ;)

Ich melde mich. Bis dann
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

hoppel118

@marvin78

Perfekt, meine Geräte sind alle wieder da. Die API Fehler sind weg.

Jetzt habe ich noch das Problem mit den komischen Namen. Ich habe gerade mal versucht herauszufinden, was da los ist.

Dabei ist mir relativ schnell aufgefallen, dass jedes Client Device, dass in der FHEM Unifi Definition keinen "hostname" hat, eine Nummer erhält. Das ist erstmal irgendwie logisch. Hier ein paar Beispiele:

2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7: connected
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_hostname:
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_uptime: 168933
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_snr: 67
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork 5f0b658b0c0abe9ea13fdea7_accesspoint: u6-pro-living
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903: connected
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_hostname: zhimi-fan-za5_mibtC903
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_uptime: 171268
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_snr: 44
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za5_mibtC903_accesspoint: u6-pro-living
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE: connected
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_hostname: zhimi-fan-za4_mibt3ABE
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_uptime: 171275
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_snr: 52
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork zhimi-fan-za4_mibt3ABE_accesspoint: u6-pro-gallery
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV: connected
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_hostname: AppleTV
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_uptime: 171264
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_essid: UNDEFINED
2022-01-22 22:53:03 Unifi UnifiNetwork AppleTV_accesspoint: usw-lite-living
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3: connected
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_hostname:
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_uptime: 168943
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_snr: 40
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork 5ddd365d0c0ab41a9dfb98a3_accesspoint: u6-pro-gallery
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40: connected
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_hostname: Galaxy-A40
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_last_seen: 2022-01-22 22:53:02
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_uptime: 33687
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_snr: 29
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_essid: xxx
2022-01-22 22:53:03 Unifi UnifiNetwork Galaxy-A40_accesspoint: u6-pro-basement


War das schon immer so?

Bei manchen Devices (insbesondere bei diesem IoT Zeugs) kann man ja gar keinen Hostname definieren.

Wenn ich mir jetzt so das verbose 5 bspw. für das Device 5ddd365d0c0ab41a9dfb98a3 (ohne Hostname) anschaue, dann gibt es da durchaus verwertbare Informationen. Ich habe bspw. für alle meine Geräte manuell einen name im WebInterface der Unifi Network Application angelegt.

"name":"Sonos Galerie"

FHEM macht dann das daraus: "fhem_clientName":"5ddd365d0c0ab41a9dfb98a3"

Das "name" Feld zu nehmen, würde sicherlich zu den gleichen Herausforderungen führen, da nicht jeder an jedem Gerät in der Unifi Network Application einen eigenen Namen vergibt.

Jetzt bleibt bei mir einfach die Frage, ob das bei euch auch so ist?

Wie dem auch sei, hauptsächlich benötige ich diese Client Informationen, um den Presence Status zu ermitteln. Für die beiden relevanten iPhones ist das erstmal kein Problem.

Super, vielen Dank und einen schönen Abend noch!

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

hoppel118

OK, habe den Fehler gefunden. Neulich dachte ich irgendwann, dass es in der App schöner aussieht, wenn ich im Namen auf Bindestriche verzichte. Also habe ich bspw. aus

Hoppels-iPhone-13-Pro-Max

folgendes gemacht

Hoppels iPhone 13 Pro Max

Dies habe ich gerade testweise bei zwei Clients rückgängig gemacht und schon werden im FHEM Unifi Device neue Client Devices angelegt, die den "name" verwenden.

Anscheinend prüft das Modul den "name" auf Leerzeichen oder ähnliches. Sobald da Leerzeichen im "name" enthalten sind, wird der Hostname genommen. Schade. Schöner wäre es, wenn das Unifi FHEM Modul die Leerzeichen einfach durch bspw. Bindestriche ersetzen würde (und außerdem Umlaute wie folgt übersetzt ä=ae, ü=ue, ö=oe, ß=ss).

Oder gibt es da irgendeinen Trick, den ich nicht kenne?

Ich habe das Modul also jetzt erstmal wieder so mit meiner UDM-Pro-SE laufen, wie vorher mit der UDM-Pro. Habe gerade nochmal in allen Namen den Bindestrich ergänzt und anschließend am FHEM Unifi Device ein clear all ausgeführt. ;)

Das ist wirklich sehr, sehr schön! :D

Danke euch und Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Ralli

Zitat von: marvin78 am 22 Januar 2022, 20:06:05
Zeile 1450 (bei mir) auskommentieren (wie oben) hat bei mir den gewünschten Erfolg gebracht. Es könnte aber sein, dass das auf schwachbrüstigen Systemen Auswirkungen auf die Gesamtperformance hat.

Super, herzlichen Dank - und schon sind meine Switche mit ihren Werten auch wieder da und grafisch auswertbar  :)
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

Gisbert

Zitat von: marvin78 am 22 Januar 2022, 20:06:05
sub Unifi_GetAccesspoints_Send($) { # TODO Umbenennen in Unifi_GetDevices_Send. Dann muss man auch an Get_ApNames() ran, da dort nicht nur APs sondern auch usg und switch drin sind.
# Waren wohl früher in Version 1 des Moduls nur APs unter devices
    my ($hash) = @_;
    my ($name,$self) = ($hash->{NAME},Unifi_Whoami());
    Log3 $name, 5, "$name ($self) - executed.";
   
    HttpUtils_NonblockingGet( {
                 %{$hash->{httpParams}},
        url      => $hash->{unifi}->{url}."stat/device",
        callback => $hash->{updateDispatch}->{$self}[2],
        method   => "GET",
        #data     => "{\"_depth\":2, \"test\":0}",
    } );
    return undef;
}


Zeile 1450 (bei mir) auskommentieren (wie oben) hat bei mir den gewünschten Erfolg gebracht. Es könnte aber sein, dass das auf schwachbrüstigen Systemen Auswirkungen auf die Gesamtperformance hat.

Guten Morgen Marvin,

betrifft diese Änderung nur den UDM-Pro oder auch den USG-3 Router, und evtl. Access Points?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

marvin78

Zitat von: Gisbert am 23 Januar 2022, 07:06:22
Guten Morgen Marvin,

betrifft diese Änderung nur den UDM-Pro oder auch den USG-3 Router, und evtl. Access Points?

Viele​ Grüße​ Gisbert​

Das weiß ich leider nicht. Nur mit UDMPro getestet.

kl@us

Hallo Marvin. Ich habe einen CloudKey-Gen2-Plus. Nach dem Patch werden die Switches wieder sauber erkannt und ich kann auch wieder die POE-Ports ein-/ausschalten. Vielen Dank für die schnelle Hilfe.

Gruß Klaus
Produktiv: FHEM (aktuell) auf NUC; diverse HM-Sensoren und Aktoren; Z-Wave, HUE

MrStonedfire

Guten Abend,
seit einigen Tagen wird bei mir Accesspoint nicht mehr übertragen mit welchen sich mein Handy verbunden hat.
Hat noch jemand so ein verhalten beobachten können oder gar eine Lösung?
Im post #1569 von hoppel118 stand auch als accesspoint = unknown.

Edit:
Beim Schreiben merke ich gerade das die Mac des AP´s mit welchen ich verbunden bin erkannt wird (blauer Kreiß).

Jemand eine Idee ?



LG
Dennis

hoppel118

Hi @MrStonedfire

folgenden Beitrag hast du gesehen?

https://forum.fhem.de/index.php/topic,40287.msg1202774.html#msg1202774

Seit ich diese Änderung umgesetzt habe, läuft das Modul bei mir.

Gruß Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

MrStonedfire

Zitat von: hoppel118 am 04 Februar 2022, 01:53:39
Hi @MrStonedfire

folgenden Beitrag hast du gesehen?

https://forum.fhem.de/index.php/topic,40287.msg1202774.html#msg1202774

Seit ich diese Änderung umgesetzt habe, läuft das Modul bei mir.

Gruß Hoppel

Danke für die schnelle antwort.

Ich hatte die falsche Zeile auskommentiert....

Jetzt sollte meine Heizung auch wieder das tuen was sie soll.

Vielen Dank.

M@d

Hallöchen,

bin ich eigentlich der einzige der eine Dream Machine einsetzt und keine Voucher über FHEM erzeugen kann?

Das Log schreibt mir folgendes dazu:

2022.02.04 11:47:31 4: UDMPro Info: vouchers without note or containing comma(,) in note or with empty note are ignored in drop-downs.
2022.02.04 11:47:31 5: UDMPro (Unifi_CreateVoucher_Receive) - executed.
2022.02.04 11:47:31 5: UDMPro (Unifi_CreateVoucher_Receive) - Failed! - state:'403' - msg:'Failed with HTTP Code 403.'


Der Aufruf erfolgte mit:
set UDMPro createVoucher 6600 1 1 fhem

Attribut isUDM ist korrekt auf 1 gesetzt.

Danke & Gruß

Martin

choenig

Hi,

Zitat von: M@d am 04 Februar 2022, 11:52:40
bin ich eigentlich der einzige der eine Dream Machine einsetzt und keine Voucher über FHEM erzeugen kann?

Ich verfolge das hier nicht im Detail. Benutzt du die originale Version oder meine gepatchte aus diesem Thread? Ich denke, dass es mit der gepatchten (noch) funktioniert.

LG
Christian

M@d

Danke für den Hinweis, das kann ich mal ausprobieren, bisher verwende ich die originale Version.

justme1968

hallo zusammen,

da ich mich gerade mit der erweiterung des unifi protect moduls beschäftige (siehe: https://forum.fhem.de/index.php/topic,126024.msg1206184.html#msg1206184) sind mir ein paar dinge aufgefallen die im netzwerk vorhandene unifi komponenten und deren zusammenspiel betreffen.

mit der umstellung auf unifi os ist es möglich aus jeder unifi console (d.h. udm, cloud key, unvr, ...) auszulesen welche controller (network/protect/...) jeweils installiert sind, welche unifi os systeme es noch im netz gibt, welche controller eventuell dort installiert sind und welche netzwerk und protect endgeräte es im netz gibt.

ausserdem unterstütz scheinbar jeder console und jeder controller push events für alle möglichen dinge.

mit diesen informationen könnte man die unifi module deutlich erweitern, besser zusammen arbeiten lassen und durch das auswerten der events das regelmäßige pollen und damit die fhem systemlast reduzieren.

gibt es interesse an einer solchen globalen umstellung?

das ganze könnte in etwa so aussehen: statt jeweils zweistufigen modulen für unifi und unifi protect gibt es ein drei- oder vierstufiges vorgehen:
- unifi als oberste ebene, für jede console gibt es ein solches fhem device.
  hier landet information über cpu, health, platten, eventuell firmware updates, ...
- das unifi modul müsste ein mal für irgend eine console (d.h. mit deren ip) in fhem angelegt werden
- wenn es im netz weitere unifi consolen gibt werden deren fhem devices automatisch angelegt
- für alle installierten und unterstützten controller (network, protect, ...?) wird jeweils automatisch
  ein fhem device angelegt
- dieses kümmert sich um die jeweiligen events und daten für die es zuständig ist und erzeugt jeweils
  die fhem devices für die endgeräte (kameras, switche, wlan router, ...)
- diese kümmern sich um die jeweils verbunden endgeräte und plan nutzer. diese vierte ebene vermutlich
  optional und nicht mehr automatisch sondern von hand angelegt.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968