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

[roedert]

ok, danke.
Vielleicht ist das ja noch ein "Denkanstoß" für die Zukunft - die UniFi-Gui gibt diese Infos ja her.

Hintergrund:
Hab eine Aussenkamera die bei Dämmerung auf s/w und IR-Beleuchtung umschaltet wodurch der Stromverbrauch steigt. Darüber könnte ich in FHEM prima erkennen wenns draussen dunkel wird. 

[Christian Uhlmann]

Ja, die Diskussion gab es hier schon mal. Aber da kam als Ergebnis raus, das es dann pro unifi Controller sub-devices geben muss, je Switch eins zum Beispiel. Das ist natürlich mehr Arbeit und bisher gab es da nicht so viel Interesse.
Schau mal Post #353

[Wuehler]

Moin,

@justme:

d.h. alles auf einer zeile, die einzelnen werte mit ; getrennt, nur ein mal das Cookie schlüsselwort am anfang, ohne \r\n dazwischen.

so wie ich die Unifi-Schnittstelle verstanden habe werden insgesamt zwei Cookies gesetzt:
1. unifise: (oder so ähnlich, kann gerade nicht nachsehen) - eine Session-ID
2. csrf: ein Token gegen cross-site-request-forgery

Beim ersten Cookie kommen glaube ich auch noch andere name-Wert-Paare mit, die allerdings ignoriert werden.

Der ganz richtige Output müsste also folgendermaßen lauten:

Code Auswählen Erweitern

Cookie: unifise=<die Session-ID>;
Cookie: csrf=<das csrf-Token>;

In der alten Version fehlte das Wort Cookie sowie das Semikolon nach einem Wert.

VG,
Dirk

[justme1968]

ich meine das Cookie: schlüsselwort sollte nur ein mal am anfang der zeile auftauchen und danach dir name/wert paare mit semikolon getrennt. das wäre dann die syntax wie sie auch für alle anderen header elemente gilt.

das kann man z.b. mit wget auch auf der kommandozeile testen.

schau mal im rfc oder hier: https://de.wikipedia.org/wiki/HTTP-Cookie unter aufbau.

ja. die beiden cookie werte sind zumindest aktuell die einzig relevanten. es gibt zwar scheinbar noch einen dritten, der scheint aber nicht weiter wichtig zu sein.

[Wuehler]

Moin roedert,

Vielleicht ist das ja noch ein "Denkanstoß" für die Zukunft - die UniFi-Gui gibt diese Infos ja her.

Ich hatte eh mal vor mich mit dem Thema zweistufiges Modul auseinanderzusetzen, hatte persönlich zu Hause bisher allerdings keinen case. Mittlerweile habe ich einen Unifi-Switch, da ein altes Billigding nach 13 Jahren den Geist aufgegeben hat (endlich ein Grund  ). Mal schauen wir kompliziert das wird und ob die (auf den ersten Blick gute) Doku im Wiki für mich verständlich ist.

Idee für die erste Stufe wäre, nur die Daten des Switch anzuzeigen, aber nichts schalten zu können. Dann müsste eine Erweiterung um ein paar Kleinigkeiten sowie die dispatch()-Funktion ausreichen (plus neues Modul 74_UnifiSwitch.pm).

Mal sehen wann ich dazu komme. Brauche dann auf jedenfall Tester

VG,
Dirk

@justme: Es werden zwei Cookies gesetzt, nicht einer mit zwei Werten.

[justme1968]

ja. beim setzen. beim zurück geben hat das bei meinen tests aber nicht funktioniert. die beiden gesetzten mussten in der antworte zu einer einzigen antwortet zeile zusammengefasst werden.

[sledge]

Habe ich nur irgendwas übersehen oder ist es nicht möglich den PoE-Verbrauch eines einzelnen Switchports auszulesen? Habe nur den Gesamtverbrauch eines Switches gefunden.

Also ich kann das auslesen, sowohl im Controller als auch in FHEM:

Code Auswählen Erweitern

TK.KG.USW            (mac:78:8a:20:fa:91:29, id:5ae06bae5147cd3be019de77)
  id  name             on mode        class     
   1  Port 1          7 1 auto   good Class 4     3.33W 53.27V 62.49mA
   2  Port 2          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   3  Port 3          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   4  Port 4          7 1 auto   good Class 4     9.06W 53.27V 170.16mA
   5  Port 5          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   6  Port 6          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   7  Port 7          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   8  Wohnzimmer      7 1 auto   good Class 4     9.61W 53.14V 180.78mA
   9  Port 9          7 0 auto        Unknown     0.00W  0.00V  0.00mA

Oder was genau meinst Du?

[Christian Uhlmann]

Also ich kann das auslesen, sowohl im Controller als auch in FHEM:

Code Auswählen Erweitern

TK.KG.USW            (mac:78:8a:20:fa:91:29, id:5ae06bae5147cd3be019de77)
  id  name             on mode        class     
   1  Port 1          7 1 auto   good Class 4     3.33W 53.27V 62.49mA
   2  Port 2          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   3  Port 3          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   4  Port 4          7 1 auto   good Class 4     9.06W 53.27V 170.16mA
   5  Port 5          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   6  Port 6          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   7  Port 7          7 0 auto        Unknown     0.00W  0.00V  0.00mA
   8  Wohnzimmer      7 1 auto   good Class 4     9.61W 53.14V 180.78mA
   9  Port 9          7 0 auto        Unknown     0.00W  0.00V  0.00mA

Oder was genau meinst Du?

Klar, im Controller geht das. Das FHEM Modul liefert diese Info aber nur auf device Ebene, nicht auf Port Ebene.

[sledge]

Yep - wie im Controller eben auch nur auf Device-Ebene.

Und - mir reicht sogar die Gesamtzahl, da ich damit dann bzgl. der USV rechnen kann... Aber generell geht es - den Output müsste man jetzt noch parsen...

Der Output ist ja von FHEM, nicht vom Controller.

[Wuehler]

Nabend,

mich hat der Ehrgeiz dann doch gepackt. Näheres unter https://forum.fhem.de/index.php/topic,87728.0.html.

VG,
Dirk

[Wuehler]

@Sledge und Christian: Habt ihr das Modul hinter dem Link ausprobiert? Funktioniert es bei euch?

[Christian Uhlmann]

@Sledge und Christian: Habt ihr das Modul hinter dem Link ausprobiert? Funktioniert es bei euch?

yep, antwort ist gerade gekommen, zeit ist bei mir momentan leider etwas knapp, aber ich bleibe dran und bin froh über die entwicklungen

[Motivierte linke Hände]

Ich muss nochmal auf das Blocken und Entblocken von Clients zurückkommen. Das funktioniert ja mit dem Modul mittlerweile gut. Was ich immer noch über ein externes Skript mache, das dann per API-Zugriff den Unifi Controller abfragt, ist zu ermitteln, ob ein Client aktuell geblockt ist oder nicht.

Denn ein Reading dafür kann ich in Unifi nicht finden. Das Reading mit dem Namen des Clients wird nur zu "disconnected", wenn der Client geblockt ist. Und interessanterweise gibt ein

Code Auswählen Erweitern

get unifi clientData <client> auch bei einem geblockted Client

Code Auswählen Erweitern

blocked = 0 zurück.

Ist das so nach wie vor beabsichtigt?

Danke, Christian

[Wuehler]

Hi Christian,

das Problem ist (weiterhin?), dass die aktuell verwendete Unifi-API geblockte clients nicht mitsendet. Daher bekommt man nie blocked=true. Erst wenn sich der client wieder connected wird blocked=false mitgesendet.

Man könnte ein Reading einführen, dass ausschließlich beim "set Unifi blockClient <client>" auf true gesetzt wird. Sobald der client per update mitkommt wird es wieder auf false gesetzt.
Dies könnte zu inkonsitenten Zuständen führen, wenn man direkt über die Oberfläche des UnifiController den Client blockt. Daher sollte das Reading evtl. eher "maybe_blocked" heißen.

Gruß,
Dirk

[Motivierte linke Hände]

Danke, Dirk. Das ist schade, aber das zusätzliche Reading würde ich dann tatsächlich nicht umsetzen. Denn mit "maybe" hat ja niemand was gewonnen.