Aber das ist doch schon der Sinn der Seite „Entdecken“!
Warum also nicht einfach das Limit erhöhen?
Denn schon bei 100 Geräten … ist es unleserlich ^^ Also bei 950 … kannst du dir das vorstellen
Und ohne Suchfeld … humhum ^^ Aber es ist natürlich möglich (die Browser-Suche mit Strg+F funktioniert) aber was die Benutzerfreundlichkeit angeht … ^^
Falls du einen anderen Vorschlag hast, immer her damit 
Ich erhöhe das Limit und füge einen Suchfilter hinzu!
Perfekt ^^ Vielen Dank ^^
Also @Terdious, wir müssen uns über unsere Arbeitsweise einigen. Ich habe absolut nichts dagegen, dass du PRs machst, aber ich habe diese Integration nicht erstellt, um dir mehr Arbeit zu geben!
Ich lasse dich mir Bescheid sagen, ich bin für alles offen!!
Ouioui!! Keine Sorge (und die Arbeit nervt mich nie, das bringt uns allen etwas^^)
Ich brauche nur sehr lange, um dir die Antwortnachricht zu schreiben, damit sie bestmöglich formuliert und verständlich ist, und zwar mit der KI (die Präsentation ist viel besser). Klar, deswegen ist sie lang, aber ich lese alles durch/korrigiere, normalerweise ist alles klar, und am Ende wirst du sehen, dass es gar nicht so kompliziert ist^^
Jede kleine externe Integration wird zu einem unabhängigen Mikroprojekt Gladys^^
Hop :
Verdammt… das lässt Spielraum ^^
Ich habe es getestet, die Suche funktioniert gut!
Es ist gemerged, es wird in der nächsten Gladys-Release (heute) veröffentlicht.
Jaa willkommen !!
Normal, es sind die Anfänge, wir sind alle durch das gegangen!
Aber ja, das sollte man unbedingt vermeiden: main ist der Zweig, den jeder verwendet. Eine Änderung, die kaputt geht, und deine Nutzer bekommen sie direkt ab.
Die einfache Regel
Jede Änderung (außer bei absoluter Sicherheit bei etwas extrem Einfachem) muss in einem separaten Zweig erfolgen, den du als getaggtes Bild :dev hochlädst oder :dev-tartempion für einen spezifischen Test mit jemandem.
Konkrekt wird dein Zyklus:
main ──► Arbeitszweig ──► (Testbild :dev) ──► zurück zu main
Und nicht viel mehr. In der Kommandozeile ist es wörtlich:
git checkout main
git pull
git checkout -b fix-ip-gateway # dein Arbeitszweig
# ... du arbeitest, du commitest ...
git push -u origin fix-ip-gateway
Zwei unmittelbare Vorteile:
- wenn etwas bei jemandem kaputt geht, gehst du zurück, indem du einen Zweig löschst/rückgängig machst, nicht indem du 15 gemischte Commits in
mainentwirrst; - du kannst mehrere Projekte parallel haben, ohne dass sie sich gegenseitig stören.
PRs: nicht obligatorisch, aber sehr praktisch
Zu beachten: PRs sind nicht obligatorisch. Du kannst sehr gut main → Arbeitszweig → main allein machen, ohne jemals eine PR zu öffnen.
Es ist besonders nützlich:
- wenn jemand von außen dir etwas vorschlagen möchte (mein Fall);
- wenn du einen Fortschritt / eine Vorbereitung teilen möchtest, bevor du sie veröffentlichst.
Persönlich arbeite ich viel mit PRs auch in meinen eigenen Repos, weil:
- du hast eine echte Historie, lesbar, mit dem Warum jeder Änderung;
- du kannst direkt im Code kommentieren;
- du kannst langfristige Themen haben, ohne dich erinnern zu müssen, welcher Zweig es war — der gesamte Kontext ist in der PR.
Was du konkret von einer PR tun musst
Also gute Nachricht: du hast schon alles, was du brauchst, in deinem Repo
Zuerst, das Wichtigste: Eine PR ändert NICHTS bei dir, solange du nicht klickst.
Solange du nicht auf den grünen Button gedrückt hast, ist dein main intakt, dein Bild :latest ist intakt, deine Nutzer sehen nichts. Null Risiko. Und du kannst eine PR schließen, ohne sie zu mergen, ohne jede Rechtfertigung. Auch wenn es besser ist, das tue ich dir nicht vor.
Dann, in dieser Reihenfolge:
1. Der CI überprüft den Code für dich — das ist bereits eingerichtet
Dein .github/workflows/ci.yml löst bereits on: pull_request aus. Bei jeder PR startet es automatisch:
npm run format:check(Prettier)npm run lint(ESLint)npm test
Du musst also nichts lesen, um zu wissen, ob es kaputt geht: du schaust unten in der PR, grünes Häkchen = es funktioniert, rotes Kreuz = es funktioniert nicht. Das ist alles.
2. Du kannst die Überprüfung deiner KI anfordern
Du gibst ihr den Link zur PR und bittest sie, sie zu überprüfen und direkt darin zu kommentieren. Ich werde ihre Kommentare sehen und korrigieren. Das ist, wo die Hin- und Her-Gänge stattfinden, ohne dass du eine Zeile schreiben musst.
3. Du baust ein Testbild — das ist auch schon eingerichtet
Dein .github/workflows/build.yml hat bereits einen workflow_dispatch mit einem Feld image-tag, das standardmäßig den Namen des Zweigs übernimmt, und vor allem berührt es :latest nicht. Also:
Registerkarte Actions → Workflow Build → Button Run workflow → du wählst den Zweig → Run
et du erhältst ghcr.io/guim31/gladys-integration-unifi:<nom-de-la-branche> die du in dein Docker für echte Tests ziehst. Deine Nutzer auf :latest sehen nichts davon.
(Kleiner Hinweis: Dein build.yml wird nur automatisch bei Tags v* ausgelöst, also deinen Releases. Der manuelle Auslöser oben ist also der richtige Weg, um eine Branch zu testen.)
4. Du mergest (oder nicht)
Falls deine Tests OK sind: Großer grüner Button « Merge pull request » unten in der PR, dann « Confirm merge ». Zwei Klicks. Du kannst auch deine KI bitten, das zu erledigen.
Falls es dir nicht gefällt: Du kommentierst oder schließt. Kein Problem.
Zusammengefasst: Du musst niemals meinen Code lesen, wenn du nicht willst. Du schaust auf das grüne Häkchen, testest das Bild und klickst.
Ein Punkt zum Fork => Und damit die PRs, die bei dir auftauchen
Wie wir uns konkret organisieren (und du behältst ALLE Rechte)
Ich präzisiere, weil es wichtig ist: Ich verlange keine Rechte auf dein Repo. Ich mache genau das, was ich auf dem Repo von Gladys mache — ich forke, ich arbeite auf meinem Fork, ich schlage dir eine PR vor. Ich kann weder bei dir pushen noch mergen. Du bist der Einzige, der auf den Knopf drücken kann. Das ist die Standardfunktion von Open Source, und so ist es sehr gut.
Und für die Tests: Du musst nichts bauen: Ich liefere dir das Bild zusammen mit der PR.
Der Ablauf
- Ich arbeite auf einer Branch meines Forks.
- Ich starte den Build bei mir — dein
build.ymlfunktioniert so wie es ist in einem Fork, es berechnet das Bild mitghcr.io/${GITHUB_REPOSITORY,,}und überschreibt nielatest. Es gibt mir zum Beispielghcr.io/terdious/gladys-integration-unifi:fix-ip-gateway. - Ich mache dieses Paket bei mir öffentlich.
- Ich öffne die PR bei dir und setze die Adresse des Bildes direkt in die Beschreibung, mit dem Manifest zum Kopieren und Einfügen.
- Du installierst dieses Bild in deinem Gladys, testest es und sagst mir Bescheid.
- Wenn es gut ist: grüner Knopf. Andernfalls: Du kommentierst oder schließt.
Du hast also nichts zu bauen, nichts zu konfigurieren und nichts zu deinstallieren.
Wie du mein Bild installierst (2 Felder auszufüllen)
In Gladys: Integrationen → Installieren von GitHub → « Entwicklermodus: Installieren von einem Docker-Bild »
- Feld Docker-Bild → du fügst die Adresse ein, die ich dir in der PR gebe;
- Feld Manifest (JSON, optional) → du fügst das JSON ein, das ich dir direkt darunter gebe.
Und das war’s. Zwei Kopieren-Einfügen.
Ein paar Dinge, die du wissen solltest
Es wird NEBEN deiner aktuellen Version installiert, du zerstörst nichts.
Gladys baut den Selector unterschiedlich je nach Installationsmodus: ext-guim31-gladys-integration-unifi für deine normale Installation, ext-dev-unifi-network für eine Installation per Bild. Zwei verschiedene Selectoren = die beiden Integrationen koexistieren ruhig. Du behältst deine laufende Produktion, testest daneben und wenn du fertig bist, deinstallierst du einfach die Testversion.
Warum muss ich dir das Manifest zum Einfügen geben?
Normalerweise kann Gladys es selbst aus den Labels des Bildes lesen (das Label io.gladysassistant.manifest). Aber dein Dockerfile setzt keines und dein build.yml überträgt auch keines, also würde die Installation an einem MANIFEST_NOT_FOUND scheitern. Daher das manuelle Kopieren-Einfügen — ohne Bedeutung, genau dafür ist das optionale Feld da.
Deshalb schlage ich dir das als allererste PR vor: Füge dieses Label zum Bild hinzu. Es sind 2 Zeilen, es berührt keinen funktionalen Code, und danach kann jeder (du als Erster) ein Testbild installieren, indem er nur seinen Namen einfügt, ohne Manifest. Das verbessert dein eigenes Dev-Erlebnis für alle folgenden Male — und du siehst den Mechanismus einer PR von Anfang bis Ende ohne das geringste Risiko. Ideal, um sich einzuarbeiten 
Ein Punkt der Aufmerksamkeit für die Tests
Da die beiden Integrationen parallel laufen, entdecken sie dieselben Geräte. In Gladys ist der selector eines Geräts jedoch global einzigartig. Daher:
- um zu überprüfen, was eine PR ändert (die IP-Parameter, die Port-Features, die Namen) → der Entdeckungsschirm der Testinstanz reicht völlig aus, du fügst nichts hinzu, kein Risiko;
- um tatsächlich einen PoE-Port von der Testinstanz aus zu steuern → du musst zuerst die betroffenen Geräte auf der Produktionsseite löschen, sonst erhältst du einen Fehler, wenn du sie hinzufügst. Nichts ist kaputt, nur eine Fehlermeldung in der Karte, aber es ist gut, das zu wissen.
Und langfristig
Wenn du dich wohlfühlst, ist der zusätzliche Komfort, eine Branch dev bei dir zu erstellen:
git checkout main
git checkout -b dev
git push -u origin dev
Dort mergest du die PRs nach und nach (es wird immer noch nichts veröffentlicht, latest bleibt unverändert), du baust dein Bild :dev von Actions → Build → Run workflow → Branch dev, du testest mehrere Änderungen auf einmal und mergest erst nach main, wenn du zufrieden bist. Aber das ist nicht notwendig, um anzufangen.
Zu den verdoppelten Geräten
Dort werde ich dich beruhigen: Das ist nicht die Schuld von Gemini, und dein Code war wahrscheinlich gut.
Was du gesehen hast, ist kein Problem mit der Benennung deiner Features, sondern das Verhalten des Entdeckungsschirms von Gladys: Auf diesen kleinen Karten zeigt Gladys die Kategorie der Feature an, nicht ihren Namen.
Der Beweis ist in meinen eigenen Screenshots des vorherigen Posts:
- auf der Karte Dream Machine Pro liest man
Präsenz/Durchsatz/Durchsatz— obwohl in deinemgateway.jsdiese Features tatsächlichStatus,WAN Upload SpeedundWAN Download Speedheißen. Zwei identischeDurchsatzauf dem Bildschirm, zwei deutlich unterschiedliche Namen im Code; - und vor allem, auf der Karte « Switch PoE: SW-CAMPING-02 », liest man immer noch 4 ×
Switch. Mit anderen Worten: Die Verdopplung hat das Problem, das du lösen wolltest, nicht gelöst — die Ports bleiben auf diesem Bildschirm ununterscheidbar, getrennt oder nicht
Während in dem JSON der entdeckten Geräte (mein erster Screenshot) deine Namen perfekt sind: Port 1 (SW-MAISON-01 / Port 19). Sie sind da, sie sind gut gebaut.
30-Sekunden-Test, wenn du es überprüfen willst: Füge einen Switch zu Gladys hinzu, dann gehe hin und füge die Ports auf dem Dashboard hinzu, du wirst die richtigen Namen haben. Du wirst die echten Namen (Port 1 (…), Port 3 (…), usw.) sehen und sie auch in den Feature-Selektoren finden, wenn du eine Szene baust.
Also, wenn du einverstanden bist, können wir ohne Bedenken zusammenführen: ein Switch = ein Gerät, Präsenz + Ports zusammen, alles bleibt identifizierbar. Der echte Gewinn ist die Anzahl der Geräte und die Kohärenz
Das ist alles, sag mir, was du über Fork vs. Collaborator bevorzugst, und mit welchem Punkt wir anfangen sollen. Ich schlage vor, mit der lokalen IP / öffentlichen IP des Gateways zu beginnen: Es ist am autonomsten, es betrifft nur eine Datei und wird dir eine erste PR « für die Fahrt » geben, um den Mechanismus in der Praxis ohne Risiko zu sehen
Vielen Dank für diese SEHR vollständige Nachricht!
Wie ich bereits erklärt habe: Ich bin kein Entwickler, ich habe keine Ausbildung in dem Bereich. Dieses Projekt existiert, weil mir die KI es heute ermöglicht, Dinge zu bauen, die ich selbst nie hätte schreiben können. Wenn du also sagst, dass ich deinen Code nie lesen muss, wenn ich nicht will… perfekt ^^ ich könnte ihn sowieso nicht beurteilen. Und das ist auch gut so: Ich vertraue dir lieber auf den Inhalt und konzentriere mich darauf, was ich kann, nämlich zu Hause selbst zu testen.
Daher passt das System mit Fork + PR perfekt für mich. So sehe ich jeden
Änderung einzeln, mit einer Erklärung dazu.
Was du mir über „solange du nicht klickst, passiert nichts“ erklärst, beruhigt mich. Ich hatte den Eindruck, dass ein PR bereits ein Fuß in der Tür ist. Jetzt verstehe ich, dass ich die Kontrolle von Anfang bis Ende behalte, und das ändert alles in meiner Herangehensweise.
Bei der Reihenfolge folge ich dir zu 100%:
- der PR des Labels im Dockerfile, damit ich den gesamten Mechanismus
an etwas sehen kann, das absolut risikofrei ist; - dann die lokale IP / die öffentlichen IPs des Gateways.
Zu den doppelt vorhandenen Geräten: Danke für die Details und vor allem dafür, dass du mir gesagt hast, dass das nicht unbedingt mein Fehler war. Ich hatte nicht verstanden, dass der Entdeckungsschirm die Kategorie und nicht den Namen der Funktion anzeigt — daher hatte ich etwas „repariert“, das gar nicht kaputt war. Ich gehe davon aus, dass du recht hast: Wir verschmelzen, ein Switch = ein Gerät. Ich kann versuchen, diesen Teil in einem PR auf meiner Seite zu machen, um mich einzugewöhnen!
Und ich merke mir die Regel „eine Änderung = ein Branch“, ich mache das auch für meine
Eigenen Änderungen, Claude ist wirklich ein super Kumpel für solche Dinge 
Ich werde unterwegs dumme Fragen haben, ich warne dich lieber vorher
Danke, dass du dir all diese Zeit nimmst!!!
Kleine Fortschritte auf meiner Seite: Ich habe die Switches zusammengeführt und meinen ersten Pull Request gemacht! Ich benutze das „ich“, aber wir alle wissen, wer sich dahinter verbirgt
Ein Gerät = eine Ausrüstung jetzt.
Es ist in main gemerged, aber ich habe keine Veröffentlichung gemacht.
Kurz gesagt, ich bin bereit für deine Pull Requests, wann immer du willst
Um meinen Beitrag zu leisten, habe ich die Version 1.5.2 auf meiner Seite getestet und die Wiederherstellung der Elemente funktioniert problemlos