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

justme1968

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

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

Wuehler

Oha, das ist mir in der commandref durchgerutscht. War glaube ich kurz vor meiner Zeit, dass V5 unterstützt wurde.
Würde am liebsten V3 so langsam mal ausbauen  ;)

sledge

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

Moin,

morgen im Update ein Modul ohne v3-Support. Hoffe nicht, dass jemand von euch noch auf dieser 3 Jahre alten Version hängen geblieben ist. Aber ab und an muss auch mal aufgeräumt werden.

Als nächstes bereite ich dann mal eine Version mit "customClientReadings" vor. Darin wird dann auch das Attribut deprecatedClientNames entfallen.

Viele Grüße,
Dirk

f-zappa

Zitat von: Wuehler am 16 März 2019, 14:20:49
Als nächstes bereite ich dann mal eine Version mit "customClientReadings" vor. Darin wird dann auch das Attribut deprecatedClientNames entfallen.
Hi, schön! Mir sind (wie du ja weißt) die customClientNames wichtiger - wird es die auch geben?
Gruß, Uli

Wuehler

hi,

bin dabei wie vorhin geschrieben. Aber eins nach dem anderen. Das Thema customClientReadings muss etwas mehr durchdacht werden.

Wuehler

Hallo zusammen,

So, im Anhang mal ein Testmodul mit neuem Attribut customClientReadings.

Für jeden client wird der "state" (connected|disconnected) angezeigt.

Um zusätzlich nur die mac als client-Reading zu bekommen müsste man
attr customClientReadings .:^mac$
setzen.

Für einzelne Clients könnte man sich so auch mehr Readings anzeigen lassen. Je nachdem welche Namenskonventionen man bei den Clients hat wird es dann auch ein einfacheres RegEx um zB die Familie zu addressieren. Alle MAC-Adressen und die uptime für die Familie:
attr customClientReadings myFam.*:^mac$|^uptime$

Alle Readings zu allen Clients würde so aussehen:
attr customClientReadings .:.

Welche Readings ist zur Auswahl gibt kann man auch sehen mittels:
get clientDate all

Bitte einmal ausgiebig testen und Feedback geben!
- Z.B. auch, ob sich bei der Installation etwas an eurem bisherigen Readings geändert hat.


PS: das Attribut deprecatedClientNames ist aus der Version auch entfernt worden.

Viele Grüße,
Dirk

Gisbert

Hallo Dirk,

vielen Dank für das update.
Ich habe das angehängte Modul auf einem Testsystem (welches bald mein Hauptsystem sein wird) aufgespielt.

Offtopic: Ich dachte, dass ich mittlerweile soweit fit wäre, einen neuen Fhem-Server aufzusetzen und loszulegen - aber Fhem macht es einem nicht einfach, ich frage mich ernsthaft, wie Anfänger (ich meine Linux und Fhem) bei dem Thema Verschlüsselung durchblicken können. Offtopic Ende

Das Attribut customClientReadings funktioniert soweit.
Bei dem Ausdruck "myFam.*" nehme ich an, dass deine Clients dann wohl vorneweg alle so heißen, die in dieser Gruppe enthalten sind.

Bei dem lastseen bekommt eine 10-stelliges ganzahliges Ergebnis, was möglicherweise mit dem neu aufgesetzten Testsystem zu tun hat.
Auf meinem laufenden System mit dem unverändetem Unifi-Modul bekommt man verständliche Formate: z.B: 2019-03-16 20:40:23.
Das müsste überprüft werden.
Falls das Modul aus deiner Sicht lesbare lastseen readings liefern müsste, dann wäre ein Hinweis für den User wünschenswert, was er ggf. an anderer Stelle ändern müsste, damit ein lesebares Datumsformat herauskommt, im Moment wüsste ich nicht, wo ich suchen sollte.

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

Wuehler

Hi Gisbert,

Danke für das schnelle Feedback.

Bei mir heißen die Clients leider (noch) nicht einheitlich, aber könnte man ja ändern.  ;)
Das schien mir ein leicht verständliches Beispiel zu sein.

Mit dem Attribut customClientReadings leite ich die Werte des UC momentan einfach durch. Es gibt dadurch bei einigen Werten Abweichungen. Lastseen und hostname gehören dazu.
Nehme das Feedback aber so auf, dass lesbarere Werte gewünscht sind. Das wäre dann nicht mehr generisch und könnte abwärtskompatible Updates schwieriger machen. Mal schauen, ob mir zu der Problematik noch etwas schlaues einfällt.

Und ja, wenn man sich nur ab und zu um Verschlüsselung kümmern muss, ist das kein einfaches Thema.

Viele Grüße,
Dirk

Gisbert

Hallo Dirk,

bei dem Format des lastseen bin mir nicht sicher, was besser wäre. Derzeit wird ein lesbares Datum-Uhrzeit-Format ausgegeben.
In deiner neuen Variante dürfte es vermutlich eine Unix-Zeit sein. Damit ließe sich im Zweifelsfall einfacher rechnen und eine Überwachung von IoT-Devices realsieren, d.h. ob die Teile noch brav senden oder sich aufgehängt haben und nichts mehr senden. Dann müsste aber auch der state disconneted sein, den man ebenfalls einfach auswerten könnte.
Readings liest man jetzt ja nicht so oft, natürlich wenn man sich damit beschäftigt schon.
Mit einem lastseen in der jetzigen Form könnte man überwachen, ob ein Modul 5 Minuten, 1 Stunde, 1 Tag z.B. offline ist und je nach Dringlichkeit dann handeln.
Vielleicht kannst du beide Readings zur Verfügung stellen und dem Anwender überlassen, was er bevorzugt.
Nimm es aber nur als Anregung, letzenendes programmierst Du es und es ist deine Zeit, die du investierst.

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

Gisbert

Hallo Dirk,

mir ist auf dem Testsystem noch folgendes im logfile aufgefallen:
2019.03.16 21:50:02 2: myUniFi (Unifi_ProcessUpdate) - finished after 0.0000 seconds.
2019.03.16 21:50:32 2: myUniFi (Unifi_ProcessUpdate) - finished after 0.0000 seconds.
2019.03.16 21:51:02 2: myUniFi (Unifi_ProcessUpdate) - finished after 1.0000 seconds.
2019.03.16 21:51:32 2: myUniFi (Unifi_ProcessUpdate) - finished after 0.0000 seconds.
2019.03.16 21:52:02 2: myUniFi (Unifi_ProcessUpdate) - finished after 1.0000 seconds.

Auch hier weiß ich leider nicht, ob es am Testsystem oder an dem neuen Unifi-Modul liegt.

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

justme1968

ich habe gerade ein verständnis problem: wenn man die mac adressen braucht weil die client namen zu variabel sind kommt es mit komisch vor die client namen zu verwenden um die mac adressen zu aktivieren. wo ist mein denkfehler?

zu den sich ändernden client namen: wenn man im controller einen alias vergibt bleibt der doch konstant.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Wuehler

Moin, das waren zwei verschiedene Anforderungen. Das Attribut customClientNames habe ich noch nicht umgesetzt. Mit dem Alias im UC war auch mein Vorschlag, passte aber anscheinend nicht zur Infrastruktur von zappa.

@gisbert: die zusätzliche Logausgabe war nur zur Testerleichterung. Kommt später wieder raus.

Maui

Moin Wuehler,

hab die Test-Version mal aufgespielt und bin bisher positiv angetan. Konnte keine Fehler fest stellen. Hab aber gleich ein clear Readings gemacht.
Jetzt mit mac und ip neben connect-state ist es echt übersichtlicher.
Danke.

Bzgl. log ausgabe mit processUpdate: Ist das blocking? Ich hab bei mir immer so 6-7 Sekunden.

Wuehler

Hi Maui,

Danke für den Test. Ich denke ich werde für einige Daten noch zusätzlich formatierte Daten bereitstellen und es dann ins offizielle Update übernehmen.

Zum ProcessUpdate: nein. Ist alles non-Blocking. Es wird die Dauer des Updatezyklus gemessen, nicht die Prozessorzeit.