Aquí tienes:
ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2-arm64
@Will_71 ¿La integración de Free Mobile no se convertiría en una integración externa? 
Sí, por supuesto. Después tengo que ver cómo funciona todo esto. Me di cuenta el fin de semana, pero no tuve tiempo de mirarlo más.
Lance Claude sobre el tema, es realmente una historia de 5 minutos a mi parecer 
Integración externa TP Link en desarrollo/pruebas (tengo que ocuparme de la parte de descubrimiento de red)
Para el escaneo de red, ¡está en el SDK! Es Gladys quien realiza el escaneo y proporciona los resultados a la integración.
Solo dale el SDK a Claude y él hará el trabajo 
Ese lado es demasiado fácil con Claude ^^
Hola @pierre-gilles,
Retroalimentación de experiencia de usuario después de poner en servicio el modelo de transportes +
acciones en gladys-tuya (por cierto: los macarons local/nube, el interruptor
GLADYS_PREFER_LOCAL, la actualización de parámetros y la acción detect_protocol
funcionan perfectamente en la práctica — enhorabuena, eso lo cambia todo).
El punto difícil que queda es la LEGIBILIDAD DEL LADO DEL DISPOSITIVO. Escenario vivido por un
usuario lambda: dos dispositivos muestran un macaron « Nube » cuando el
modo local está activado. ¿Por qué? Uno no fue encontrado por el escaneo UDP
(no hay IP), el otro rechaza las sesiones locales. Imposible saberlo
desde la ficha del dispositivo: solo muestra Nombre / Habitación / Funcionalidades
(DeviceBox.jsx no renderiza ningún parámetro fuera de la insignia GLADYS_TRANSPORT).
Tres solicitudes, por orden de prioridad:
-
Mostrar parámetros « útiles » en la ficha del dispositivo de una integración externa — como mínimo en lectura (IP_ADDRESS, PROTOCOL_VERSION), idealmente con la IP editable. Sin esto, el usuario no puede ni diagnosticar ni actuar. Pista: una lista de claves de parámetros a exponer, declarada en el manifiesto (ej. « device_params_display »: [« IP_ADDRESS », « PROTOCOL_VERSION »]), con un flag « editable » por clave — la edición pasa por la actualización de parámetros existentes.
-
Acciones POR DISPOSITIVO: hoy las acciones del manifiesto solo se renderizan en la pantalla de Configuración (ActionsCard.jsx), a nivel de integración.
Para « detectar el protocolo local », el lugar adecuado es la ficha del dispositivo en cuestión: un flag « scope »: « device » en la acción, renderizada como botón en cada tarjeta, con el external_id del dispositivo inyectado en los campos transmitidos a la integración. Esto evitaría pedir al usuario que copie un identificador. -
A falta de (o como complemento), una FUENTE DINÁMICA para los campos select de las acciones: hoy ConfigSchemaForm.jsx solo renderiza opciones estáticas del manifiesto. Un campo
{ "type": "select", "source": "devices" }que liste los dispositivos creados de la integración (label = nombre, value = external_id) resolvería el 90 % de la necesidad con un cambio mínimo en el front.
Mientras tanto, hemos puesto un parche del lado de la integración: el campo de la acción acepta el NOMBRE del dispositivo tal como se muestra en Gladys (o el ID Tuya). Es un apaño, pero sigue siendo entrada libre con los riesgos de homónimos.
Complemento sobre los macarons de transporte — un estado « degradado » (naranja)
Al usar los macarons local/nube en la práctica, nos encontramos con un caso que los tres estados actuales (local / nube / inalcanzable) no saben expresar: el dispositivo FUNCIONA, pero no como debería.
Caso concreto vivido: un dispositivo es bien identificado por el escaneo UDP local (IP y versión de protocolo conocidas, modo local activado), pero devuelve errores o timeouts en las lecturas locales. Nuestra integración entonces cambia al modo de respaldo nube: el usuario ve un macaron « Nube » azul, perfectamente normal en apariencia… cuando en realidad algo falla (dispositivo que rechaza sesiones locales, clave local rotada, otro cliente local que mantiene la conexión, etc.). Nada le invita a investigar.
La solicitud: un estado « degradado » (macaron NARANJA), ortogonal al transporte efectivo. Dos pistas de modelado, a tu preferencia:
- Un campo de salud separado en publishTransports, para no contaminar la semántica del transporte:
[{ "external_id": "...",
"transport": "cloud",
"health": "degraded",
"reason": {
"en": "LAN found but local polls fail — using cloud",
"fr": "Vu en LAN mais échecs de lecture locale — bascule cloud",
"de": "Im LAN beobachtet, aber lokale Lesefehler – Cloud-Umschaltung"
}
}]
→ el macaron muestra el transporte, el naranja señala la degradación, el
reason se muestra en tooltip / al hacer clic. Es mi favorita: « degraded »
sigue siendo cierto independientemente del transporte (una nube lenta o un local que
pierde tramas también son degradados).
- A falta de eso, un valor « degraded » añadido al enum del transporte — menos rico (se pierde la info del transporte realmente utilizado), pero trivial de añadir.
Del lado de la integración, ya tenemos todo para subirlo limpiamente: nuestro interruptor de circuito local sabe exactamente cuándo un dispositivo LAN-capable es aparcado en la nube después de N fallos, con la razón. Solo nos falta el canal para expresarlo al usuario.
Y más allá de este caso concreto, esto da un vocabulario genérico para todos los « funciona pero mal »: token de nube que expira pronto, dispositivo que responde una vez de cada dos, subcontenedor en bucle de fallos pero respaldo activo, etc.
¡Gracias!
¡Increíble, gracias por tus comentarios y estas 2 integraciones! Para implementar tus comentarios será probablemente el jueves (hoy y mañana estoy freelance 
)
¡Sí, sí, lo sé muy bien, por eso hemos solucionado el problema de otra manera mientras tanto, sigue siendo funcional de todos modos 
!!
Gracias por todo 
, esta evolución mayor es un punto de inflexión para Gladys, creo. Aunque, pero no me hago muchas ilusiones, conociéndote ahora sobre la calidad, como mencionaba muy bien @cicoub13, la siguiente etapa no será necesariamente fácil para mantener una calidad e imagen alta de Gladys !!
¡Vamos! ¡A trabajar yo también ^^
Sí, eso es lo que hice, pero la propuesta debe revisarse (IP a ingresar por el usuario y retroceso al escaneo de red). Me gustaría que fuera más simple y, por lo tanto, entender qué es realmente posible con el escaneo (voy a releer la documentación).
¿No ganaría la parte de Supervisión estar en una sección aparte (fuera de la configuración)?
Si generas un ejemplo con Fable, puedo revisarlo.
Te expuse la idea de un servidor de validación del SDK. No necesitarás validar si el SDK pasa todas las pruebas del servidor de validación. El desarrollador puede hacerlo localmente además. Esto también permitirá multiplicar los SDK externos. Creo que JS y Python soportados oficialmente cubren el 90% de las necesidades y desarrolladores. Además, Python es utilizado por HA y, por extensión, tenemos muchas integraciones que podemos portar más fácilmente. Pero hay que esperar a la versión estable de la versión JS primero. No vayamos demasiado rápido
¡Por qué no, buena idea!
Sí, estoy de acuerdo. Me gustaría tener primero una primera versión en producción en full JS, así como un SDK JS lo suficientemente maduro, antes de proponer un SDK Python.
En cambio, una vez que el SDK JS esté estabilizado y requiera menos evolución y mantenimiento por mi parte, estaré encantado de llevarlo a Python.
Y bien, parece que todo funciona bien ^^ OAuth perfecto desde el primer intento.
¡Imagen y flujo de vídeo perfectos!
Pero no tengo sonido en los flujos de vídeo y el flujo se retrasa 10/15s => Búsqueda mañana
Y bien, creo que podremos dedicarnos a eso pronto ^^ ¡Probablemente un proyecto para el fin de semana! ^^
Increíble, ¡realmente son la leche estas integraciones externas
Vale, ¡avísame para lo de la latencia!
Después de discutir con Fable:
Los tres comentarios abordan necesidades reales, pero no los tomaría todos tal cual. Mi opinión punto por punto:
1. Acciones por dispositivo (scope: "device") — lo pospondría. La necesidad es legítima (no hacer que el usuario copie un external_id), pero la solución propuesta abre una caja de Pandora en la UI: botones declarados por el manifiesto que se inyectan en las tarjetas de los dispositivos, exactamente el tipo de superficie que queríamos evitar (requisito n°3 del marco: UI coherente, sin renderizado controlado por las integraciones más allá de formularios generados). Y plantea preguntas sin buena respuesta en la v1: ¿en qué tarjeta? ¿Solo en la pantalla de Dispositivos de la integración, o en el panel de control? ¿Qué hacer cuando una integración declara 5 acciones de dispositivo × 40 dispositivos? El desarrollador lo dice él mismo: la fuente dinámica cubre el 90% de la necesidad. Los 10% restantes (un clic ahorrado en comparación con un select) no justifican esta complejidad ahora. Candidato para la fase 2 si el uso lo exige, no para la v1.
2. Fuente dinámica para los selects ("source": "devices") — sí, francamente. Es la solución correcta al mismo problema: pequeña, genérica, coherente con el config_schema existente, y el renderizado sigue siendo 100% controlado por el núcleo (label = nombre del dispositivo, value = external_id, filtrado por el service_id de la integración — cero fuga entre inquilinos). Dos salvaguardias a poner en la especificación: source es un enum reservado definido por el núcleo (v1: solo devices), no una URL ni una expresión — no abrimos un mecanismo de inyección de datos arbitrarios; y source es exclusivo con options estáticos. Funciona para los campos de actions[] y, gratuitamente, también para el config_schema de instalación.
3. Estado « degradado » — la necesidad es real, pero no como 4º valor del enum. El caso descrito (el dispositivo funciona en la nube cuando debería estar en local) es genérico, no específico de tuya, y el macaron azul « todo va bien » que oculta un problema es un verdadero agujero de observabilidad. Sin embargo, agregar degraded a GLADYS_TRANSPORT mezcla dos ejes ortogonales: qué transporte se está utilizando y ¿es el estado nominal? Con un enum de 4 valores, el usuario que ve « Degradado » pierde la información « está en la nube en este momento » — que es justamente lo que le permite entender. Mi propuesta: mantener local|cloud|unreachable como valor del transporte, y enriquecer el mismo endpoint POST /device/transport con dos campos opcionales por entrada: degraded: true y un message multilingüe (ej. « Local detectado pero sesiones rechazadas, cambio a la nube »). Renderizado: el macaron mantiene su color/etiqueta de transporte con un borde o punto naranja, tooltip = el mensaje; el contador global de la pantalla de Dispositivos gana una línea « n degradado(s) ». Mantener las dos informaciones en lugar de sobrescribir una.
En resumen: tomo el 2 tal cual (con enum reservado), el 3 remodelado en una bandera ortogonal degraded + mensaje en lugar de un 4º estado, y pospongo el 1 en la fase 2 ya que el 2 cubre la mayor parte de la necesidad. Si te parece bien, escribo estos dos añadidos en la especificación.
¡Estoy bastante de acuerdo con él!
Estoy totalmente de acuerdo con esto, y como se mencionó en el punto 1, funciona sin ello, es solo una mejora posible, hay que consultarlo y tomarse el tiempo 
¡Es mucho mejor! 
Nueva versión del SDK, la v0.7.0 con nuevas funcionalidades para @Terdious y @cicoub13:
- feat: estado de transporte degradado y selección dinámica de la fuente « dispositivos » (actualización de la especificación) por @Pierre-Gilles en #11
- feat: escaneo de red de difusión activa
udp-active-broadcast(actualización de la especificación B.16) por @Pierre-Gilles en #12