¡Pero eso ya es el principio de la página « Descubrimiento »!
¿Por qué no aumentar simplemente el límite?
Porque ya con 100 dispositivos… es ilegible ^^ Entonces con 950… te dejo imaginar
Y sin un campo de búsqueda… humhum ^^ bueno, es posible (la función CTRL+F del navegador funciona) pero en cuanto a facilidad de uso… ^^
Si tienes otra propuesta, con gusto 
¡Aumento el límite y añado un filtro de búsqueda!
Perfecto ^^
Muchas gracias ^^
Pues @Terdious, tenemos que ponernos de acuerdo sobre cómo vamos a trabajar. Yo no tengo nada en contra de que hagas PR, pero no he creado esta integración para darte más trabajo.
Te dejo que me digas, yo estoy abierto a todo.
¡Sí, sí! ¡Ninguna preocupación (y el trabajo nunca me molesta, nos beneficia a todos ^^
Solo me lleva mucho tiempo redactarte el mensaje de respuesta, para que esté lo mejor posible y sea comprensible, haciéndolo con la IA (presentación mucho mejor). Bueno, por eso es largo, pero lo releo todo/corrijo, normalmente todo está claro, y al final verás que no es tan complicado ^^
Cada pequeña integración externa se convierte en un microproyecto Gladys independiente ^^
Hop :
Mierda… eso deja margen eso ^^
¡Lo he probado, el buscador funciona bien!
Está fusionado, saldrá en el próximo lanzamiento de Gladys (hoy)
¡Sí, bienvenido!
Normal, son los comienzos, todos hemos pasado por ahí.
Pero sí, hay que evitarlo absolutamente: main es la rama que todos usan. Un cambio que rompe, y son tus usuarios los que lo reciben de lleno.
La regla simple
Cada modificación (a menos que tengas la certeza absoluta de algo ultra simple) debe hacerse en una rama aparte, que subes como imagen etiquetada :dev, o :dev-tartempion para una prueba específica con alguien.
Concretamente, tu ciclo se convierte en:
main ──► rama de trabajo ──► (prueba de imagen :dev) ──► regreso a main
Y no mucho más. En la línea de comandos es literalmente:
git checkout main
git pull
git checkout -b fix-ip-gateway # tu rama de trabajo
# ... trabajas, haces commits ...
git push -u origin fix-ip-gateway
Dos ventajas inmediatas:
- si algo se rompe en algún lugar, vuelves atrás eliminando/cancelando una rama, no desenredando 15 commits mezclados en
main; - puedes tener varios proyectos en paralelo sin que se interfieran.
Las PR: no obligatorias, pero muy prácticas
Nota: las PR no son obligatorias. Puedes hacer main → rama de trabajo → main solo, sin abrir nunca una PR.
Es especialmente útil:
- cuando alguien de fuera quiere proponerte algo (mi caso);
- cuando quieres compartir un avance / una preparación antes de lanzarlo.
Yo trabajo mucho con PR incluso en mis propios repos, porque:
- tienes un historial real, legible, con el por qué de cada cambio;
- puedes comentar directamente en el código;
- puedes tener temas a largo plazo sin tener que recordar de qué rama se trataba — todo el contexto está en la PR.
Lo que realmente tendrás que hacer con una PR
Entonces, buena noticia: ya tienes todo lo que necesitas en tu repo
Primero, lo más importante: una PR no cambia NADA en tu repositorio hasta que no haces clic.
Mientras no hayas presionado el botón verde, tu main está intacto, tu imagen :latest está intacta, tus usuarios no ven nada. Cero riesgo. Y puedes cerrar una PR sin hacer merge, sin ninguna justificación. Aunque es mejor, no te lo oculto ^^
Luego, en orden:
1. El CI verifica el código por ti — ya está en marcha
Tu .github/workflows/ci.yml ya se activa on: pull_request. Con cada PR lanza automáticamente:
npm run format:check(Prettier)npm run lint(ESLint)npm test
Por lo tanto, no tienes nada que revisar para saber si está roto: miras abajo en la PR, casilla verde = pasa, cruz roja = no pasa. Es todo.
2. Puedes pedir la revisión a tu IA
Le das el enlace de la PR y le pides que la revise y comente directamente dentro. Yo veré sus comentarios y los corregiré. Es ahí donde se hacen los intercambios, sin que tengas que escribir una línea.
3. Construyes una imagen de prueba — también está en marcha
Tu .github/workflows/build.yml ya tiene un workflow_dispatch con un campo image-tag que toma por defecto el nombre de la rama, y sobre todo no toca :latest. Por lo tanto:
Pestaña Actions → workflow Build → botón Run workflow → eliges la rama → Run
y recuperas ghcr.io/guim31/gladys-integration-unifi:<nom-de-la-branche> que tiras en tu Docker para probar en realidad. Tus usuarios en :latest no ven nada pasar.
(Pequeño detalle: tu build.yml solo se activa automaticamente en los tags v*, es decir, tus releases. El disparo manual de arriba es por lo tanto el buen camino para probar una rama.)
4. Tu merges (o no)
Si tus pruebas son OK: gran boton verde « Merge pull request » abajo de la PR, luego « Confirm merge ». Dos clics. Tambien puedes pedirle a tu IA que lo haga.
Si no te conviene: comentas, o cierras. Ningun problema.
En resumen, nunca tienes que leer mi codigo si no quieres. Miras la marca verde, pruebas la imagen, haces clic.
Un punto sobre el fork => Y por lo tanto las PR que aparecen en tu lado
Como nos organizamos concretamente (y guardas TODOS los derechos)
Especifico, porque es importante: no te pido ningun derecho sobre tu repo. Hago exactamente lo que hago en el repo de Gladys — forkeo, trabajo en mi fork, te propongo una PR. No puedo ni empujar en tu lado, ni merger. Tu eres el unico que puede presionar el boton. Es el funcionamiento estandar de open source, y esta muy bien asi.
Y para las pruebas, no necesitas construir nada: te entrego la imagen al mismo tiempo que la PR.
El desarrollo
- Trabajo en una rama de mi fork.
- Lanzo el build en mi lado — tu
build.ymlfunciona tal cual en un fork, calcula la imagen conghcr.io/${GITHUB_REPOSITORY,,}y nunca sobrescribelatest. Me da por ejemploghcr.io/terdious/gladys-integration-unifi:fix-ip-gateway. - Hago este paquete publico en mi lado.
- Abro la PR en tu lado, y pongo la direccion de la imagen directamente en la descripcion, con el manifiesto para copiar y pegar.
- Tu instalas esta imagen en tu Gladys, pruebas, y me dices.
- Si esta bien: boton verde. Si no: comentas, o cierras.
Por lo tanto no tienes nada que construir, nada que configurar, y nada que desinstalar.
Como instalas mi imagen (2 campos para llenar)
En Gladys: Integrations → Instalar desde GitHub → « Modo desarrollador: instalar desde una imagen Docker »
- campo Imagen Docker → pegas la direccion que te doy en la PR;
- campo Manifiesto (JSON, opcional) → pegas el JSON que te doy justo abajo.
Y eso es todo. Dos copiar-pegar.
Dos o tres cosas a saber
Se instala AL LADO de tu version actual, no rompes nada.
Gladys construye el selector diferente segun el modo de instalacion: ext-guim31-gladys-integration-unifi para tu instalacion normal, ext-dev-unifi-network para una instalacion por imagen. Dos selectors diferentes = las dos integraciones coexisten tranquilamente. Mantienes tu produccion en funcionamiento, pruebas al lado, y cuando terminas solo desinstalas la de prueba.
¿Por que debo darte el manifiesto para pegar?
Normalmente Gladys sabe leerlo solo en los labels de la imagen (el label io.gladysassistant.manifest). Pero tu Dockerfile no pone ninguno y tu build.yml tampoco pasa ninguno, por lo que la instalacion fallaria en un MANIFEST_NOT_FOUND. De ahi el copiar-pegar manual — sin gravedad, es exactamente para eso que sirve el campo opcional.
Por lo tanto, te propongo esto como primera PR: agregar este label a la imagen. Son 2 lineas, no tocan ningun codigo funcional, y despues cualquiera (tu el primero) podra instalar una imagen de prueba pegando solo su nombre, sin manifiesto. Te mejora tu propio confort de desarrollo para todas las veces siguientes — y te hace ver el mecanismo de una PR de principio a fin sin el menor riesgo. Ideal para practicar 
Un punto de atencion para las pruebas
Como las dos integraciones funcionan en paralelo, descubren los mismos equipos. Pero en Gladys el selector de un dispositivo es unico a nivel global. Por lo tanto:
- para verificar lo que cambia una PR (los parametros IP, las caracteristicas de puertos que aparecen o no, los nombres) → la pantalla de descubrimiento de la instancia de prueba es suficiente, no agregas nada, sin riesgo;
- para controlar realmente un puerto PoE desde la instancia de prueba → primero debes eliminar los dispositivos concernidos del lado de produccion, de lo contrario tendras un error al momento de agregarlos. Nada roto, solo un mensaje de error en la tarjeta, pero es bueno saberlo.
Y a largo plazo
Cuando estés cómodo, el confort adicional es crear una rama dev en tu lado:
git checkout main
git checkout -b dev
git push -u origin dev
Alli merges las PR sobre la marcha (nunca publica nada, latest no se mueve), construyes tu imagen :dev desde Actions → Build → Run workflow → rama dev, pruebas varios cambios de una vez, y solo merges hacia main cuando estás contento. Pero no es necesario para empezar.
Sobre los equipos duplicados
Entonces, voy a tranquilizarte: no es culpa de Gemini, y tu codigo probablemente era bueno.
Lo que viste no es un problema de nombramiento de tus caracteristicas, es el comportamiento de la pantalla de descubrimiento de Gladys: en estas pequeñas tarjetas, Gladys muestra la categoria de la caracteristica, no su nombre.
La prueba está en mis propias capturas de la publicación anterior:
- en la tarjeta Dream Machine Pro, se lee
Presencia/Ancho de banda/Ancho de banda— aunque en tugateway.jsestas caracteristicas se llaman en realidadStatus,WAN Upload SpeedyWAN Download Speed. DosAncho de bandaidénticos en la pantalla, dos nombres bien distintos en el codigo; - y sobre todo, en la tarjeta « Switch PoE: SW-CAMPING-02 », se leen cuatro veces
Interruptor. En otras palabras: la duplicación no resolvió el problema que intentabas resolver — los puertos siguen indistinguibles en esta pantalla, separados o no
Mientras que en el JSON de los dispositivos descubiertos (mi primera captura), tus nombres son perfectos: Port 1 (SW-MAISON-01 / Port 19). Están bien ahí, están bien construidos.
Prueba de 30 segundos si quieres verificar: agrega un switch a Gladys, luego ve a agregar los puertos en el dashboard, tendrás los buenos nombres. Verás los nombres reales (Port 1 (…), Port 3 (…), etc.), y los encontrarás también en los selectores de caracteristicas cuando construyas una escena.
Por lo tanto, si estás de acuerdo, podemos fusionar sin miedo: un switch = un dispositivo, presencia + puertos juntos, todo sigue identificable. La verdadera ganancia es el número de dispositivos y la coherencia
Eso es todo, dime lo que prefieres sobre el fork vs colaborador, y por cual punto quieres que empecemos. Te propongo comenzar con la IP local / IP publicas de la gateway: es lo mas autonomo, toca un solo archivo, y te dara una primera PR « para el camino » para ver el mecanismo en realidad sin riesgo
¡Muchas gracias por este mensaje MUY completo!
Como ya he explicado: no soy desarrollador, no tengo ninguna formación en eso. Este proyecto existe porque la IA me permite hoy en día construir cosas que nunca habría podido escribir yo mismo. Así que cuando dices que nunca tengo que leer tu código si no quiero… ¡me viene de perlas! ^^ De todos modos, no sabría juzgarlo de todas formas. Y está muy bien así: prefiero confiar plenamente en ti en cuanto al fondo y concentrarme en lo que sé hacer, probar en casa de verdad.
Por lo tanto, el sistema fork + PR me viene perfecto. Así podré ver pasar cada
cambio uno por uno, con la razón escrita al lado.
Lo que me explicas sobre « mientras no hagas clic, nada se mueve » me tranquiliza. Tenía la impresión de que una PR era ya un pie en la puerta. Ahora entiendo que mantengo el control de principio a fin, y eso cambia todo en mi forma de abordar el tema.
En cuanto al orden, te sigo al 100%:
- la PR de la etiqueta en el Dockerfile, para que vea el mecanismo completo
en algo de riesgo cero; - luego la IP local / las IPs públicas de la gateway.
Sobre los equipos duplicados: gracias por los detalles y sobre todo por decirme que no era necesariamente un error mío. No había entendido en absoluto que la pantalla de descubrimiento mostraba la categoría y no el nombre de la función — así que « reparé » algo que no estaba roto. Parto del principio de que tienes razón: se fusiona, un interruptor = un equipo. ¡Puedo intentar hacer esta parte en una PR por mi cuenta para practicar!
Y tomo nota de la regla « una modificación = una rama », también lo haré para mis
propias modificaciones, Claude es de todos modos un gran amigo para estas cosas 
Tendré preguntas tontas en el camino, prefiero avisarte
¡Gracias por tomarte todo este tiempo!!!
Pequeño avance por mi parte: he fusionado los switches y
he hecho mi primera PR. Uso el « yo » pero todos habréis entendido quién hay detrás
Un material = un equipo ahora.
Está fusionado en main pero no he hecho un lanzamiento.
En resumen, estoy listo para tus PR cuando quieras
Para aportar mi granito de arena, he probado por mi parte la versión 1.5.2 y la recuperación de los elementos funciona sin problemas
UniFi Network 1.6.0 está disponible, con tres widgets de panel de control: Red (ancho de banda WAN en tiempo real, clientes conectados, dispositivos en línea, estado de Internet y curva de tráfico), Presencia (sus dispositivos presentes o ausentes) y Wi-Fi (una red a su elección, con dos botones Activar / Desactivar: perfecto para el Wi-Fi de invitados).
Esta versión requiere Gladys 5.1 como mínimo: actualice Gladys primero, de lo contrario, no se le ofrecerá la actualización de la integración.
La actualización se realiza en Integraciones; sus dispositivos y escenas no cambian. Sus comentarios son bienvenidos 