Neues YouTube-Video: Visualisierung im Devices-Adapter

[schweiger2]

@Scrounger

ist erledigt

[Dragon]

@schweiger2 Könntest du uns teilhaben lassen woran es gelegen hat, wenn es jetzt erledigt ist.

[schweiger2]

erledigt ist das Anlegen eines Issue, alles Weitere ist im Fluss und Scrounger arbeitet hart daran. Ich melde mich, wenn und wie erledigt.

[Scrounger]

@Dragon
https://github.com/Scrounger/ioBroker.unifi-network/issues/65

[Dragon]

Achsooo. Das hatte ich falsch verstanden. Dachte das Problem wär erledigt

[schweiger2]

@dragon

JETZT ist das Problem Dank der schnellen Bearbeitung durch @scrounger gelöst. Danke nochmal dafür.

Bei der Anbindung des Unifi OS Server (aktuell v5.06) an den unifi-network Adapter ist Folgendes zu beachten:

• Der im Unifi OS Server erkennbare bzw. angelegte site name ist nicht der Name, der in der Adapter-Instanz unter Controller-Site eingetragen werden muss. Da scheint es wohl einen internen System-Namen zu geben. Ich hatte nicht den default genommen, sondern eine neue Site angelegt, mit der ich arbeite. Der einzutragende Name wurde bei mir so herausgefunden:

1. Login auf den Unifi OS Server über die Web-GUI
2. Neuen Tab öffnen und https://192.168.x.x:11443/proxy/network/api/self/sites eingeben
3. In der Ausgabe hinter "name" findet sich der Name für die Controller-Site, in meinem Fall z.B. "name":"rag584vc" .

• Die Rechte im Unifi OS Server für den angelegten User müssen auf Super Admin gesetzt werden; die Rechte in der Anleitung reichten nicht.

• In der aktuellen Version 1.3.1 (stable) hat das noch nicht funktioniert. Ich habe die von Scrounger aktualisierte Version 1.3.4 über github geladen.

Danach ging der Adapter auf grün und die Clients wurden eingelesen und werden auch aktualisiert.

[Scrounger]

Ich hab jetzt auch mal diesen Unifi OS Server in ner Test VM installiert:

@schweiger2 sagte in Test Adapter Unifi Network:

• Der im Unifi OS Server erkennbare bzw. angelegte site name ist nicht der Name, der in der Adapter-Instanz unter Controller-Site eingetragen werden muss. Da scheint es wohl einen internen System-Namen zu geben. Ich hatte nicht den default genommen, sondern eine neue Site angelegt, mit der ich arbeite. Der einzutragende Name wurde bei mir so herausgefunden:

Ja das ist schon immer so, der angezeigt Name in der Übersicht ist nicht die ID. Diese findet man auch in der browser url zeile: https://xx.xx.xx.xx:11443/network/${siteId}/dashboard.
Oder man liest das log file, das gibt es ne error meldung wenn die site nicht existiert und welche wirklich existieren.

@schweiger2 sagte in Test Adapter Unifi Network:

• Die Rechte im Unifi OS Server für den angelegten User müssen auf Super Admin gesetzt werden; die Rechte in der Anleitung reichten nicht.

also bei meinem Test System geht es genauso wie es in der Anleitung beschrieben ist, keine notwendigkeit als admin da rum zu hampeln.

[quinti]

Hallo #zsmmn,
Habe seit ein paar Tagen folgenden Fehler. Habe an der config nicht geändert. Lief immer stabil:

[updateUnifiData-login site undefined] error: Request failed with status code 400, stack: AxiosError: Request failed with status code 400 at settle (/opt/iobroker/node_modules/node-unifi/node_modules/axios/lib/core/settle.js:19:12) at IncomingMessage.handleStreamEnd (/opt/iobroker/node_modules/node-unifi/node_modules/axios/lib/adapters/http.js:585:11) at IncomingMessage.emit (node:events:519:35) at endReadableNT (node:internal/streams/readable:1701:12) at processTicksAndRejections (node:internal/process/task_queues:90:21)

[Scrounger]

@quinti sagte in Test Adapter Unifi Network:

[updateUnifiData-login site undefined] error: Request failed with status code 400, stack: AxiosError: Request failed with status code 400 at settle (/opt/iobroker/node_modules/node-unifi/node_modules/axios/lib/core/settle.js:19:12) at IncomingMessage.handleStreamEnd (/opt/iobroker/node_modules/node-unifi/node_modules/axios/lib/adapters/http.js:585:11) at IncomingMessage.emit (node:events:519:35) at endReadableNT (node:internal/streams/readable:1701:12) at processTicksAndRejections (node:internal/process/task_queues:90:21)

Falscher Adapter, die Meldung gehört zum unifi Adapter, nicht zum unifi-network adapter

[quinti]

ooops, sry !!!

[warp735]

Das VPN Thema gabs zwar letztes Jahr schonmal... ist da inzwischen was passiert? Brauch die Verbindung jetzt wieder und das Log ist randvoll damit...

[Scrounger]

@warp735
Nö hab ich noch nicht gemacht.
Stell den Adapter auf Error Level, dann siehst die Meldung nicht mehr

[klee]

Ich habe heute versucht von dem alten auf den neuen Adapter umzustellen.
Ich habe 2 Probleme:

1. Die Clients haben nicht mehr alle Datenpunkte. Hostname, essid und first_seen (und einige weitere) fehlen.
2. Die Clients sind nun in verschiedene Ordner aufgeteilt. clients, guest und vpn. So wird es schwierig, alle clients gemeinsam zu durchsuchen bzw macht alles was darauf aufbaut unnötig komplex. Im Adapter früher war das so gelöst das es den Datenpunkt isguest gab. Das war deutlich flexibler.

Hier ein Screenshot aus den Datenpunkten des alten Adapter V0.7.0

Hier die Daten mit dem neuem Adapter mit 1.3.1

Ich nutze eine UDM Pro mit Network App Version 10.3.55

[Meister Mopper]

Dann zeig doch mal die Konfiguration der Instanz. Da geht nämlich viel mehr.

Spoiler

[klee]

Das war meine Vermutung, das man es noch irgendwo konfigurieren kann wie bei dem altem Adapter... bei dem neuem hab ich es aber nicht gefunden.
Wo muss ich klicken?

[klee]

Ahh ich habs, Datenpunkte Black/List Whitelist.....
Das war Standardmäßig auf Blacklist und recht viel ausgeschlossen.
Hatte auf den ersten Blick nicht erkannt wofür das gut sein soll.

[megamacy]

Seit dem letzten Gateway Update rappelt diese Nachricht im sekundentakt als Warnung durch das log. Ich finde aktuell keinen weg das zu deaktivieren ausser das logging ganz zu deaktivieren.

Es bezieht sich in dem Fall auf eine VPN Verbindung. Wenn ich VPN clients raus nehme hört es aber nicht auf.

Die IDs und andere Werte habe ich leicht abgeändert da ich nicht weiß ob es sensible Daten enthält... falls es seltsam aussieht, das ist der Grund

unifi-network.0
	2026-05-28 21:35:17.639	warn	[onNetworkMessage]: meta: {"message":"vpn-users:sync","rc":"ok"} not implemented! version: 10.4.57, data: [{"id":"wgsrv1:gW+YGRFfC6cxxxxxxxxxxxxxxxxxxxxxxxxx3Uy1Y=:32311111,"ip":"192.168.1.1","name":"gW+YGRFxxxxxxxxxxxxxxxxxxoKhQy3Uy1Y=","status":"online","type":"VPN","uptime":260,"assoc_time":1779938395,"country_code":"ZZ","display_name":"Handy VPN","last_seen":1779996917,"network_id":"6633df4gd5fb6a53433253ba","remote_ip":"192.168.1.100","remote_port":47159,"rx_bytes":135527066,"rx_bytes-r":139,"tx_bytes":1585551830,"tx_bytes-r":0,"usage_bytes":1721078896,"vpn_type":"wireguard-server"}]
W+YGRFfC6cBuevQAKvX5IsvE+ahXE6oKhQy3Uy1Y=","status":"online","type":"VPN","uptime":250,"assoc_time":1779938395,"country_code":"ZZ","display_name

MOD-EDIT
Bitte Code-Tags benutzen!

[Frank579]

Hi @megamacy , der Fehler ist schon ein. Paar Wochen bei GitHub gemeldet, jetzt heißt es warten wann/ob der Fehler behoben wird. Was bei mir erstmal geholfen hat ist den Adapter Log auf Error zu stellen. Behebt den Fehler nicht aber spamt den Log nicht voll.

[Scrounger]

@megamacy
@Frank579

Das ist kein Fehler, die Funktionalität des Adapters ist dadurch in keiner Weise beeinflusst.

Es zeigt nur auf was noch nicht implementiert ist. Ich könnte das als debug Meldung machen, aber da es soviel unterschiedlich Hardware gibt, hab ich mich bewusst dazu entschlossen das als warn zu machen, damit man es implementieren kann, bzw. ausschließen kann, je nachdem ob es sinnvoll wäre es zu implementieren.

Temporäre den Adapter auf Error stellen bis ich eine neue Version öffentliche.

[Snopy_16]

Könnte man, wie beim alten adapter auch wieder "name" mit einpflegen?