Externe Integration - Unify-Netzwerk

Entwicklung
21

Man sollte trotzdem die großen Installationen einplanen, denn es ist ohnehin wahrscheinlicher, dass ein Nutzer, der die Unifi-Integration verwendet, eine große Netzwerkinstallation dahinter hat.

22

Ja !!

Ich schaue in HA, wie das präsentiert wird :wink:
Ich weiß nicht mehr ^^

23

27038
270381080×2340 172 KB

Voilà, das ist schon mal ein Anfang!^^

Eine Option pro Typ, das zeigt bereits die erste Basis der Geräte!

Und dann, wie ich dachte, ein Selektor (den man verbessern muss, das ist für @pierre-gilles ^^, denn man kann es besser machen, da bin ich sicher, zum Beispiel einen Selektor mit Suchfeld)

27043
270431080×2340 246 KB

Könnte man sogar einen Selektor „Verbundene Clients“ und einen „Getrennte Clients“ haben?
(In meinen Logs sind es etwa 400 verbundene Clients)

1 vorangeklicktes Kontrollkästchen für „Infrastruktur(en)“,
1 vorangeklicktes Kontrollkästchen WLAN(s)
1 vorangeklicktes Kontrollkästchen Verbundene Clients mit Selektor
1 vorangeklicktes Kontrollkästchen Getrennte Clients mit Selektor

Ich weiß nicht, was du davon hältst?

An sich ist es auch ohne Core-Entwicklung möglich, den Anfang zu haben, indem man den Selektor durch ein Textfeld ersetzt, in das man die IP-Adressen der Clients, getrennt durch „," oder „;" eingibt.

24

Ich denke, wir bewegen uns in dieselbe Richtung. Auf meiner Seite hat mein Brainstorming mit der KI mir Folgendes vorgeschlagen:

Um den Bedürfnissen der Nutzer gerecht zu werden (von denen, die nur eine Anwesenheitserkennung für die Familie benötigen, bis zu denen, die ihr gesamtes Netzwerk überwachen möchten), können wir die Filterung in 4 Hauptkategorien organisieren:

A. Filterung nach Gerätetyp

  • Ubiquiti-Infrastrukturgeräte (discover_infrastructure) (Boolesch)
    • Standardmäßig aktiviert: Erkennt die Konsole (UDM/UCG), Switches, Wi-Fi-Access-Points und UniFi-Smart-Steckdosen.
    • Ermöglicht die Messung des Status/Durchsatzes/Verfügbarkeit der Netzwerkgeräte selbst.
  • Netzwerk-Clients (discover_clients) (Boolesch)
    • Standardmäßig aktiviert: Aktiviert die Erkennung von Telefonen, Computern, IoT-Geräten usw.

B. Filterung der Clients nach Status und Verbindungsmodus

  • Nur aktive/verbundene Clients (only_active_clients) (Boolesch)
    • Standardmäßig deaktiviert: Wenn aktiviert, importiert die Integration nur die 127 aktuell verbundenen Clients und ignoriert die 462 historischen Clients, die im UniFi-Controller registriert sind (getKnownClients).
    • Sofortiger Vorteil: Reduziert die Anzahl der in Gladys gemeldeten Geräte um das Vierfache!
  • Verbindungsmodus der Clients (client_connection_type) (Auswahl)
    • Optionen: Alle (Standard), Nur Wi-Fi, Nur kabelgebunden.
    • Anwendungsfall: Die Anwesenheitserkennung für Personen (Smartphones/Uhren) erfordert in der Regel nur Wi-Fi, während kabelgebundene Computer oder Fernseher irrelevant sind, um zu wissen, ob jemand zu Hause ist.

C. Filterung nach Netzwerk / SSID / VLAN

  • Filterung nach Wi-Fi-SSIDs (allowed_ssids) (Liste / Kommagetrennte Texte)
    • Beispiel: Maison, IoT
    • Anwendungsfall: Automatisches Ausschließen aller Telefone/Tablets, die sich mit dem Wi-Fi-Netzwerk Invites oder Test verbinden.
  • Filterung nach Netzwerken / VLANs (allowed_networks) (Liste / Kommagetrennte Texte)
    • Beispiel: VLAN_Principal, VLAN_Domotique
    • Anwendungsfall: Ignorieren eines gesamten Subnetzes (z. B. VLAN Sicherheitskameras oder VLAN Gäste).

Mit all dem denke ich, dass wir einen klareren Überblick bekommen würden.

25

Voilà, wir sind uns einig!! Das ist ein super guter Notfallplan :sweat_smile::smiling_face_with_three_hearts:

26

Ich starte eine neue Version :wink:

27

Das ist aktuell, falls du testen möchtest :wink:

28

„Im Bett … greift er zum Handy, um schnell zu testen“…
Wer hätte das vor einem Monat noch für möglich gehalten …:sweat_smile:

Danke @guim31, ich mach mich gleich auf den Weg

29

Et paf!! Wir sind gut für die Infrastruktur!! Und für die Netzwerke!! Aber :sweat_smile: er geht sogar bis zum Port, aber er macht ein Gerät pro Switch-Port… :sweat_smile::zany_face: Hier ist alles total chaotisch ^^
Eine Feature, die pro Port eines Infrastrukturgeräts schaltet, wäre super!!!

Aber ansonsten super.

27045
270451080×2340 150 KB

27047
270471080×2340 153 KB

27049
270491080×2340 141 KB

27051
270511080×2340 130 KB

27053
270531080×2340 137 KB

Gut, aber die Clients funktionieren nicht :sweat_smile:

Die Anzeige der IP-Adressparameter in den Geräteprofilen wäre ein Pluspunkt!

Dashboard für Statusrückmeldungen /cmd:

27055
270551080×2340 179 KB

30

Ich verstehe nicht … Sprichst du von den Statusrückmeldungen „Keine aktuellen Werte“?

31

Neue Version 1.5.2:

  • Ein 24-Port-PoE-Switch erzeugt nun ein einziges Gladys-Gerät (enthält 25 Funktionen: Status + 24 PoE-Ports) anstelle von 25 separaten Gerätekarten.
  • Die lokale IP-Adresse und die MAC-Adresse werden im Einstellungen-Tab jeder Gerätekarte in der Gladys-Oberfläche angezeigt.
  • Wenn das Gerät (z. B. UCG Fiber oder Dream Machine) PoE-Ports besitzt, wird ein einziges dediziertes Gerät mit dem Namen PoE-Switch: Cloud Gateway Fiber (der definierte Gerätename) erzeugt. Es fasst alle PoE-Ports mit ihren aussagekräftigen Namen zusammen: Port 1 (Kamera Eingang), Port 2 (AP Wohnzimmer), usw.
32

Entschuldigung, Fehler in diesem Teststandort, man schläft ein :face_with_peeking_eye: :sweat_smile:

Nein nein, ich sprach von der Liste der 400 verbundenen Kunden im Netzwerk in der Entdeckung ^^
Nach dem erneuten Test verstehe ich deine Frage, du hast die Entdeckungen in Chunks unterteilt, aber das funktioniert nicht, das ist das, was ich dir zuvor gesagt habe ^^ Tatsächlich, wenn du in Chunks unterteilst, sendet dein Container dreimal die Anfrage discovered_device

image
image188×118 2.37 KB

Aber dadurch wird auf Gladys-Seite jede vorherige Liste ersetzt. Daher erhältst du mit dieser Methode nur den letzten Chunk:
image
image504×701 41.1 KB

Kurz gesagt, ich sehe nur die letzten 99 Geräte der vollständigen Liste. Aber das kannst du auf deiner Seite nicht ändern :sweat_smile:

Die einzige derzeit mögliche Lösung, wie ich dir bereits gesagt habe, ist:

Super!! Ich teste das mal ^^

33

Die Magie des Blindvideocodings… Ich hatte das Problem mit den vielen Geräten erwähnt, und er hat den Chunk codiert, dieser Schlingel, und ich habe nichts überprüft (dieser Noob :sweat_smile:).

34

Vielen Dank für dieses 1.5.2 :+1: Ich habe eine vollständige Neuerkennung auf meiner Infrastruktur (UDM Pro, mehrere 8- und 24-Port-Switches, mehrere SSIDs) gestartet. Hier sind meine Rückmeldungen, ich habe ein wenig in deinem Code gestöbert, um dir die Arbeit bei der Standortbestimmung der Punkte zu erleichtern.

1. 8-Port-Switches: Gerätedoppelung und 4 von 8 Ports

Die Netzwerkpräsenz des Geräts und die PoE-Ports erscheinen als zwei separate Gladys-Geräte (unifi-gateway-<mac> und unifi-poe-switch-<mac>, gleiche MAC):

image
image498×318 19.9 KB

image
image332×297 5.64 KB

image
image320×294 6.53 KB

Ich sehe in src/devices/index.js, dass dies absichtlich geschieht: Für jedes Infrastrukturgerät wird gatewayBlueprint.buildDevice() gepusht, dann poeSwitchBlueprint.buildDevice(), wenn hasPoePorts. Ist das eine bewusste Entscheidung?

Aus meiner Sicht als Benutzer ist ein Switch ein Gerät in Gladys, mit Präsenz + Ports als Features. Zwei Karten für dieselbe Hardware belasten die Liste (und bei mir verdoppelt sich schnell die Anzahl der Geräte, ein Thema, das wir bereits im Beitrag 20 mit der Grenze von 200 Geräten hatten). Wenn du die Trennung für diejenigen, die es bevorzugen, beibehalten möchtest, würde eine Konfigurationsoption merge_switch_devices (Standard: zusammengeführt) den Job erledigen. Vorsicht jedoch: Zusammenführen ändert die external_id, es muss eine Migration für diejenigen vorgesehen werden, die ihre Geräte bereits benannt/geordnet haben.

Für die 4 von 8 Ports: Nach dem Lesen von src/devices/poePort.js ist es logisch, du filterst auf
if (port.poe_caps && port.poe_caps > 0 && port.port_idx).
Mein USL8LP8 (UniFi Switch Lite 8 PoE) hat tatsächlich 8 Ports, von denen nur 4 PoE sind — daher ist das Verhalten korrekt, wenn das Ziel die Steuerung von PoE ist. Es ist also kein Bug, sondern zwei Anmerkungen:

  • es ist nicht offensichtlich für den Benutzer: eine kleine Notiz im README (« nur die PoE-Ports werden angezeigt ») würde den Zweifel vermeiden;
  • es wäre toll, alle Ports mit dem auszusetzen, was für jeden Port sinnvoll ist: Zustand der Verbindung (up/down), verhandelte Geschwindigkeit und die Aktivierung/Deaktivierung des Ports, wenn die API es zulässt — die PoE-Steuerung bleibt den PoE-Ports vorbehalten. Dann hätten wir eine echte Switch-Ansicht.

2. 24-Port-Switches: Keine Ports gemeldet

image
image329×259 5.72 KB

Keine Port-Features, nicht einmal das zugehörige « Switch PoE »-Gerät. Aus dem Code geht hervor, dass hasPoePorts falsch ist. Zwei Hypothesen:

  1. meine 24-Port-Modelle sind nicht-PoE-Modelle → erwartetes Verhalten (aber dann verstärkt dies Punkt 1: ohne die nicht-PoE-Ports haben diese Switches streng genommen nichts anzuzeigen);
  2. bestimmte Firmware melden die PoE-Info über port_poe: true statt über poe_caps. Ein permissiverer Filter wie
    const isPoe = Boolean(p.port_poe) || Number(p.poe_caps) > 0;
    würde den Fall absichern.

Sag mir, was du als Trace benötigst (ein logger.debug der port_table auf einem bestimmten Gerät?), und ich mache dir einen Dump meiner 24-Port-Modelle, ich bestätige dir, welcher der beiden Fälle zutrifft.

3. Dream Machine Pro: Öffentliche IP statt Verwaltungs-IP + Multi-WAN

image
image322×272 6.29 KB

Das ist der Punkt, der mich am meisten stört. In src/devices/gateway.js:

const deviceIp = typeof unifiDevice.ip === 'string' ? unifiDevice.ip.trim() : '';
const params = [{ name: 'MAC_ADDRESS', value: mac.toUpperCase() }];
if (deviceIp) {
  params.push({ name: 'IP_ADDRESS', value: deviceIp });
}

Bei einem Gateway entspricht unifiDevice.ip der WAN-IP (öffentlich), nicht der lokalen IP. Ergebnis: IP_ADDRESS enthält meine öffentliche IP. Mein Vorschlag:

  • IP_ADDRESS → lokale Verwaltungs-IP des Gateways (die, die in der Integrationskonfiguration eingegeben wird, oder die IP der LAN-Schnittstelle, die vom Controller gemeldet wird);
  • IP_ADDRESS_PUBLIC_1 → öffentliche IP des Haupt-WAN;
  • IP_ADDRESS_PUBLIC_2 → öffentliche IP des sekundären/Backup-WAN.

Bei mir sind die beiden WANs permanent aktiv: WAN1 auf der Hauptstrecke und WAN2 auf der Backup-Strecke, die tatsächlich mein LAN PRO / WiFi PRO zu jeder Zeit + Backup meiner persönlichen Netzwerke Camping versorgt. Daher sind die beiden öffentlichen IPs gleichzeitig nützlich, es ist nicht nur Failover, sie machen beide. Die Objekte wan1 / wan2 des UniFi-Geräts sollten dir geben, was du brauchst.

Korollar: Es gibt heute nur ein einziges Feature-Paar WAN Upload Speed / WAN Download Speed. Bei Dual-WAN bräuchte man eines pro Verbindung (WAN1 Up/Down, WAN2 Up/Down), sonst weiß man nicht, was gemessen wird. Und der Up/Down-Zustand jedes WANs wäre sehr praktisch, um Umschalt-Szenarien auszulösen.

Schließlich, wie bei den Switches, meldet die DMP (Dream Machine) keine Ports (normal, keine PoE darauf) — aber der Zustand der LAN-Ports wäre ein echter Pluspunkt.

4. Wi-Fi-Netzwerke

Alles in Ordnung, es funktioniert gut: Jeder SSID kommt mit einem Schalter, und er schaltet das gesamte Netzwerk ein/aus, wie erwartet. Einige Ideen, falls du Material suchst:

  • die Anzahl der verbundenen Clients pro SSID (numerische Feature, super für Szenen und Historie);
  • die Darstellung des Gästefunknetzwerks / die Möglichkeit, ein Gästepasswort zu regenerieren;
  • eventuell die Aktivierung pro Access Point statt global.

Vorschlag

Statt dir eine Liste von Beschwerden zu machen, schlage ich vor, das Repository zu forken und dir PRs zu diesen Punkten zu machen, in der Reihenfolge, die du möchtest. Ich dachte, ich würde es so aufteilen:

  1. Zusammenführen von Switch-Präsenz + Ports in ein einziges Gladys-Gerät, mit Konfigurationsoption und Migration der external_id.
  2. Permissivere PoE-Erkennung (port_poe zusätzlich zu poe_caps), um die Fälle von Switches zu entsperren, die nichts melden;
  3. Darstellung aller Ports (Verbindung / Geschwindigkeit), nicht nur der PoE-Ports;
  4. Lokale IP vs. öffentliche IPs auf dem Gateway (IP_ADDRESS, IP_ADDRESS_PUBLIC_1/2) — die einfachste und nützlichste sofort;
  5. Dual-WAN: Durchsatz- und Zustands-Features pro Verbindung;

Sag mir einfach:

  • ob du mit dem Prinzip der PRs einverstanden bist;
  • ob du Konventionen zu beachten hast (Tests, Commit-Format, Zielzweig);
  • und welche Punkte dich am meisten interessieren, damit ich nicht mit einem Projekt beginne, das du bereits in Arbeit hast.

In der Zwischenzeit führe ich die Tests fort und melde dir alles, was ich finde. Nochmals vielen Dank für die Arbeit, die Integration ist bereits gut fortgeschritten :slight_smile:

35

Zuerst einmal ein riesiges DANKESCHÖN!
Es ist nicht einfach, so eine umfassende Rückmeldung zu geben!

Ich nehme alles zur Kenntnis, ich glaube, ich habe alles verstanden :saluting_face:

Aber ich muss dir sagen, dass ich, auch wenn ich weiß, was ein PR ist, absolut KEINE Ahnung habe, was ich damit anfangen soll. In meinem Kopf muss man bei einem PR den Code überprüfen (dazu bin ich nicht in der Lage) und dann mergen, wenn alles in Ordnung ist (das kann ich auch nicht).

Also ich weiß nicht so recht, was ich dir antworten soll… Entschuldigung!

36

Ach was, kein Problem ^^
Keine Sorge ^^!!

Also:

Sie wird in deinem Repo vorgeschlagen. Wenn du direkt mit der KI arbeitest, kannst du sie bitten, die Überprüfung durchzuführen und dann ein Bild von « :dev » zu erstellen (ich glaube, das machst du schon für diese Version, oder?)
Du kannst sie bitten, direkt in der PR zu kommentieren (damit ich Korrekturen vornehmen kann, falls mir etwas entgangen ist)
Und wenn bei deinen Tests alles okay ist, kannst du sie direkt bitten, die PR zu mergen (und wenn nicht, ist es nur ein Klick unten ^^)
Aber kein Problem, wir können das zusammen nochmal durchgehen!!

Ansonsten kannst du ihr den Post teilen und die erste Version auf deiner Seite erstellen => Aber arbeite nicht direkt auf master, wenn du das schon tust? Oder arbeitest du nur mit Branches und mergest in master?

37

Gibt es da etwas zu korrigieren?

38

Derzeit habe ich nur einen Hauptzweig und sonst nichts, kein :dev oder so.

Wir sind auf dem Gipfel der Best Practices :stuck_out_tongue:

39

Ich würde dir trotzdem auf einen Punkt antworten (falls du dich mal an PRs versuchen willst), nämlich zu den doppelten Geräten. Eigentlich ist das beabsichtigt, aber das kommt daher, dass ich in meinen ersten Versuchen, wenn ich die Geräte nicht verdoppelt habe, am Ende etwas wie Folgendes hatte:

  • GERÄT 1
    • Anwesenheit
    • Aufwärtsdurchsatz
    • Abwärtsdurchsatz
    • Schalter
    • Schalter
    • Schalter
    • usw…

Mit der Unmöglichkeit, die Schalter voneinander zu unterscheiden.

Vielleicht liegt es auch daran, dass Gemini weniger begabt ist als Claude und es nicht geschafft hat, mir etwas Funktionales in diesem Bereich zu liefern!

40

Das ist keine Gewichtsgrenze mehr, sondern eine Anzahlgrenze!!
Aber ich finde diese Anzahlgrenze nicht ganz unvernünftig => mehr als 200 Geräte in der Entdeckungsseite, ohne Suchfeld!! Hmmm

@guim31 hat bereits eine Vorsortierung für alle Geräte hinzugefügt, die sich in einem SSID befinden.

Der ergänzende Vorschlag wäre, einen Parameter in der Konfigurationsliste zu haben, der die Geräte anzeigt, die ausgewählt werden können, um nur diejenigen zu « entdecken », wie es HA tut, praktisch für solche Fälle:

image
image230×500 47 KB

Dieses Feld wäre im Gegensatz zu HA ideal mit einem Suchfeld, um die gewünschten Geräte direkt zu finden
=> Das ermöglicht zum Beispiel die Überwachung des Smartphones, das Ausschalten/Abmelden eines überwachten Geräts usw.!