De todos modos, habría que planificar las grandes instalaciones, ya que, de todas formas, hay más « riesgos » de que un usuario que utilice la integración de Unifi tenga una gran instalación de red detrás.
¡Sí !!
Miro en HA cómo se presenta 
No me acuerdo ^^
¡Voilà para empezar!^^
Una opción por tipo, ya permite ver la primera base de dispositivos.
Y después, como pensaba, un selector (que habrá que innovar, eso es para @pierre-gilles ^^, porque se puede hacer mejor, estoy seguro, como por ejemplo un selector con campo de búsqueda).
¿Podríamos tener incluso un selector « Clientes conectados » y uno « Clientes desconectados »?
(En mis registros, hay unos 400 conectados, por ejemplo).
1 casilla de verificación marcada para « Infrastructure(s) »,
1 casilla de verificación marcada para wlan(s)
1 casilla de verificación marcada para Clientes conectados con selector
1 casilla de verificación marcada para Clientes desconectados con selector
No sé qué opinas.
En sí, incluso sin desarrollo central por el momento, es posible tener el inicio reemplazando el selector por un campo de texto donde ingresas tus IPs de clientes separadas por « , » o « ; »
Creo que vamos hacia lo mismo, por mi parte, mi lluvia de ideas con la IA me propuso esto:
Para satisfacer las necesidades de los usuarios (desde quien solo quiere hacer detección de presencia para la familia hasta quien quiere supervisar toda su red), podemos organizar el filtrado en 4 categorías principales:
A. Filtro por tipo de equipo
- Equipos de infraestructura Ubiquiti (
discover_infrastructure) (Booleano)- Activo por defecto : Descubre la consola (UDM/UCG), los switches, los puntos de acceso Wi-Fi y los enchufes inteligentes UniFi.
- Permite medir el estado/ancho de banda/tiempo de actividad de los equipos de red en sí.
- Clientes de la red (
discover_clients) (Booleano)- Activo por defecto : Activa la detección de teléfonos, ordenadores, IoT, etc.
B. Filtro de clientes por estado y modo de conexión
- Solo clientes activos/connectados (
only_active_clients) (Booleano)- Desactivado por defecto : Si se activa, la integración solo importa los 127 clientes actualmente conectados, ignorando los 462 clientes antiguos registrados históricamente en el controlador UniFi (
getKnownClients). - Beneficio inmediato : Reduce a un cuarto el número de dispositivos reportados en Gladys!
- Desactivado por defecto : Si se activa, la integración solo importa los 127 clientes actualmente conectados, ignorando los 462 clientes antiguos registrados históricamente en el controlador UniFi (
- Modo de conexión de los clientes (
client_connection_type) (Selección)- Opciones :
Todos(por defecto),Solo Wi-Fi,Solo cableado. - Casos de uso : La detección de presencia para personas (teléfonos inteligentes/relojes) generalmente solo necesita Wi-Fi, siendo inútiles los ordenadores fijos o televisores cableados para saber si alguien está en casa.
- Opciones :
C. Filtro por Red / SSID / VLAN
- Filtro por SSIDs Wi-Fi (
allowed_ssids) (Lista / Texto separado por comas)- Ejemplo :
Casa, IoT - Casos de uso : Excluir automáticamente todos los teléfonos/tablets que se conectan a la red Wi-Fi
InvitadosoTest.
- Ejemplo :
- Filtro por Redes / VLANs (
allowed_networks) (Lista / Texto separado por comas)- Ejemplo :
VLAN_Principal, VLAN_Domótica - Casos de uso : Ignorar una subred completa (ej: VLAN Cámaras de seguridad o VLAN Invitados).
- Ejemplo :
Con todo esto creo que permitiría ver las cosas más claras
¡Vamos, estamos de acuerdo! ¡Es un muy buen plan de continuidad! 
Me lanzo a una nueva versión
Está actualizado si quieres probar
« En su cama … va a su teléfono para probar rápido »…
¿Quién habría pensado que esto era posible hace un mes?
Gracias @guim31, voy ahora mismo
¡Pum! ¡Estamos listos para la infraestructura! ¡Y para las redes! Incluso llega hasta el puerto, pero hace un dispositivo por puerto de switch… 
Es un desastre aquí ^^
¡Una función de conmutador por puerto de un dispositivo de infraestructura sería genial!!!
Pero bueno, está muy bien.
Bueno, pero los clientes no pasan
Mostrar los parámetros de dirección IP en las fichas de los dispositivos sería un plus.
Panel de control de retorno de estados /cmd:
No entiendo… ¿Te refieres a los estados de retorno « Sin valor reciente »?
Nueva versión 1.5.2 :
- Un interruptor de 24 puertos PoE genera ahora 1 solo dispositivo Gladys (que contiene 25 funcionalidades: Estado + 24 puertos PoE) en lugar de 25 tarjetas de dispositivos separadas.
- La dirección IP local y la dirección MAC aparecen en la pestaña Configuración de cada ficha de dispositivo en la interfaz de Gladys.
- Si el equipo (por ejemplo, UCG fiber o Dream Machine) tiene puertos PoE, se genera un solo dispositivo dedicado llamado
Switch PoE: Cloud Gateway Fiber(el nombre definido del dispositivo). Agrupa todos los puertos PoE con sus nombres explícitos:Puerto 1 (Cámara Entrada),Puerto 2 (AP Salón), etc.
Lo siento, error en esta ubicación de prueba, nos dormimos 
No no, hablaba de la lista de los 400 clientes conectados en la red en el descubrimiento ^^
Después de la re-prueba, entiendo tu pregunta, has dividido los descubrimientos, pero no funciona, es lo que te decía anteriormente ^^ De hecho, si divides, tu contenedor devuelve 3 veces la consulta discovered_device
Pero entonces, para cada uno en Gladys, reemplaza la lista anterior. Por lo tanto, haciendo esto solo recuperas el último fragmento:
en resumen, ahora solo veo los últimos 99 dispositivos de la lista completa. Pero eso no puedes hacer nada de tu lado
La única solución posible en este momento, como te decía, es:
¡Genial! ¡Lo pruebo ^^
La magia del videcoding ciego… Había hablado del problema con los grandes números de dispositivos, él codificó el chunk, ese travieso, y yo no verifiqué nada (este noob ).
Gracias por esta 1.5.2 
He reiniciado un descubrimiento completo en mi infraestructura (UDM Pro, varios switches de 8 y 24 puertos, varios SSID). Aquí están mis comentarios, he estado revisando un poco tu código para facilitarte el trabajo en la localización de los puntos.
1. Switches de 8 puertos: equipo duplicado y 4 puertos de 8
La presencia en red del equipo y los puertos PoE aparecen como dos dispositivos Gladys distintos (unifi-gateway-<mac> y unifi-poe-switch-<mac>, misma MAC):
Veo en src/devices/index.js que es intencional: para cada dispositivo de infraestructura, empujas gatewayBlueprint.buildDevice(), luego poeSwitchBlueprint.buildDevice() si hasPoePorts. ¿Es una elección consciente?
Desde mi punto de vista como usuario, un switch = un equipo en Gladys, con la presencia + los puertos como características. Dos tarjetas para el mismo hardware, pesan la lista (y en mi caso, duplican rápidamente el número de dispositivos, un tema que ya habíamos encontrado en el mensaje 20 con el límite de 200). Si quieres mantener la separación para quienes prefieren, una opción de configuración merge_switch_devices (por defecto: fusionado) haría el trabajo. Ten cuidado: fusionar cambia los external_id, habrá que prever una migración para aquellos que ya han nombrado/organizado sus dispositivos.
Para los 4 puertos de 8: después de leer src/devices/poePort.js, es lógico, filtras sobre
if (port.poe_caps && port.poe_caps > 0 && port.port_idx).
Mi USL8LP8 (UniFi Switch Lite 8 PoE) tiene efectivamente 8 puertos de los cuales solo 4 PoE — por lo tanto, el comportamiento es correcto si el objetivo es el control PoE únicamente. Por lo tanto, no es un error, sino dos comentarios:
- no es evidente para el usuario: una pequeña nota en el README («solo los puertos PoE están expuestos») evitaría la duda;
- sería genial exponer todos los puertos con lo que tiene sentido por puerto: estado del enlace (arriba/abajo), velocidad negociada, y la activación/desactivación del puerto si la API lo permite — el control PoE permaneciendo reservado para los puertos PoE. Allí tendríamos una verdadera visión del switch.
2. Switches de 24 puertos: ningún puerto reportado
Ninguna característica de puerto, ni siquiera el dispositivo « Switch PoE » asociado. Según el código, esto significa que hasPoePorts es falso. Dos hipótesis:
- mis 24 puertos son modelos no-PoE → comportamiento esperado (pero entonces refuerza el punto 1: sin los puertos no-PoE, estos switches no tienen absolutamente nada que mostrar);
- algunos firmware reportan la información PoE a través de
port_poe: trueen lugar de a través depoe_caps. Un filtro más permisivo del tipo
const isPoe = Boolean(p.port_poe) || Number(p.poe_caps) > 0;
aseguraría el caso.
Dime qué necesitas como rastro (un logger.debug de la port_table en un dispositivo dado?) y te hago un volcado de mis modelos de 24 puertos, te confirmo cuál de los dos casos es.
3. Dream Machine Pro: IP pública en lugar de la IP de administración + multi-WAN
Este es el punto que más me molesta. En 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 });
}
En una gateway, unifiDevice.ip corresponde a la IP WAN (pública), no a la IP local. Resultado: IP_ADDRESS contiene mi IP pública. Mi propuesta:
IP_ADDRESS→ IP local de administración de la gateway (aquella que se ingresa en la configuración de la integración, o la IP de la interfaz LAN reportada por el controlador);IP_ADDRESS_PUBLIC_1→ IP pública del WAN principal;IP_ADDRESS_PUBLIC_2→ IP pública del WAN secundario / de respaldo.
En mi caso, los dos WAN están activos permanentemente: el WAN1 en la vía principal y el WAN2 en la vía de respaldo, que en realidad sirve mi LAN PRO / WiFi PRO en todo momento + respaldo de mis redes locales Personales / Camping. Por lo tanto, las dos IP públicas son útiles simultáneamente, no es solo un failover, hacen las dos. Los objetos wan1 / wan2 del dispositivo UniFi deberían darte lo que necesitas.
Consecuencia: hoy solo hay un par de características WAN Upload Speed / WAN Download Speed. En dual-WAN se necesitaría uno por enlace (WAN1 Up/Down, WAN2 Up/Down), de lo contrario no sabemos qué estamos midiendo. Y el estado up/down de cada WAN sería muy práctico para desencadenar escenas de conmutación.
Finalmente, como para los switches, la DMP (Dream Machine) no reporta ningún puerto (normal, no hay PoE en ellos) — pero el estado de los puertos LAN sería un verdadero plus.
4. Redes Wi-Fi
RAS, funciona bien: cada SSID llega con un interruptor, y corta/activa la red completa como se espera. Algunas ideas si buscas material:
- el número de clientes conectados por SSID (característica numérica, genial para escenas e historial);
- la exposición de la red invitada / la posibilidad de regenerar una contraseña invitada;
- eventualmente la activación por punto de acceso en lugar de global.
Propuesta
En lugar de hacerte una lista de quejas, te propongo forkear el repositorio y hacerte PR sobre estos puntos, en el orden que quieras. Pensé dividirlo así:
- fusión de switch presencia + puertos en un solo dispositivo Gladys, con opción de configuración y migración de los
external_id. - detección PoE más permisiva (
port_poeademás depoe_caps) para desbloquear los casos de switches que no reportan nada; - exposición de todos los puertos (enlace / velocidad), no solo los PoE;
- IP local vs IP públicas en la gateway (
IP_ADDRESS,IP_ADDRESS_PUBLIC_1/2) — la más simple y útil de inmediato; - dual-WAN: características de velocidad y estado por enlace;
Dime solo:
- si estás de acuerdo con el principio de los PR;
- si tienes convenciones que respetar (pruebas, formato de los commits, rama objetivo);
- y qué punto(s) te interesan en prioridad, para que no me ponga a trabajar en un proyecto que ya tengas en curso.
Mientras tanto, sigo con las pruebas y te subo todo lo que encuentro. Gracias de nuevo por el trabajo, la integración ya está bastante avanzada 
¡Primero que nada, un GRAN gracias!
¡Es complicado hacer una devolución tan completa!
Tomo nota de todo esto, creo que lo he entendido todo 
Pero debo decirte que aunque sé lo que es una PR, no tengo NI IDEA de qué voy a tener que hacer con ella. En mi cabeza, cuando hay una PR, hay que revisar el código (no soy capaz) y hacer merge si todo está bien (tampoco sé hacerlo).
Así que no sé muy bien qué responderte… ¡Lo siento!
Mais non aucun soucis ^^ T’inquiète ^^!!
Déjà :
Se te propondrá en tu repositorio. Si trabajas directamente con la IA, podrás pedirle que revise y luego que genere una imagen de « :dev » (creo que ya lo haces para esta versión, ¿no?)
Puedes pedirle que comente directamente en la PR (para que yo pueda corregir si se me ha escapado algo)
Y si todo está bien en tus pruebas, podrás pedirle directamente que la fusione (y si no, solo es un clic abajo ^^)
Pero sin problema, ¡podemos repasarlo juntos!!
Por otro lado, puedes compartirle el post y hacer la primera versión por tu lado => Pero evita trabajar directamente en master si ya lo haces. ¿O trabajas solo con ramas y las fusionas en master?
¿Hay algo que corregir?
Actualmente solo tengo una rama main, y nada más, ni :dev ni nada.
Estamos en la cima de las buenas prácticas 
Me gustaría responderte sobre un punto (por si acaso quieres lanzarte a hacer PR), el de los equipos duplicados. En realidad, es intencional, pero se debe a que en mis primeros intentos, si no duplicaba los aparatos, terminaba con algo así:
- APARATO 1
- Presencia
- Velocidad de subida
- Velocidad de bajada
- Conmutador
- Conmutador
- Conmutador
- etc…
Con la imposibilidad de distinguir los conmutadores entre sí.
Después, quizá sea porque Gemini es menos hábil que Claude, y no ha conseguido darme algo funcional en este aspecto.
¡Ya no es un límite de peso, sino un límite de número!!
Pero no es una tontería esta limitación de número => más de 200 dispositivos en la lista de la página de descubrimiento, sin campo de búsqueda!! Humhum
@guim31 ya ha añadido una preordenación para todos los dispositivos que están en un SSID.
La propuesta complementaria sería tener un parámetro en la lista de configuraciones que muestre los dispositivos permitiendo seleccionar aquellos que se desean « Descubrir » solo de la manera en que lo hace HA, práctico para estos casos:
Este campo, a diferencia de HA, sería ideal con un campo de búsqueda para encontrar directamente los dispositivos que se desean
=> Esto permite, por ejemplo, monitorear tu smartphone, la desconexión/el apagado de un dispositivo monitoreado, etc!