He revisado tus registros y creo que en realidad hay dos problemas diferentes que se acumulan, lo que explica por qué el streaming funciona pero no la recuperación de imágenes.
El primero es el flujo de Netatmo en sí. El token en la URL (el a859f78… en /live/index.m3u8) es una sesión local que no es permanente: gira, y el flujo solo está disponible cuando una sesión de streaming está activa. Se ve claramente en tus registros: a veces ffmpeg abre el flujo, recupera algunos segmentos, luego recibe 404 en bucle en las listas de reproducción medium y low con « Packet corrupt », y finalmente es asesinado por timeout. En otros momentos es directamente un 404 en el m3u8 principal, allí el token ya no es válido. Por lo tanto, cuando abres la cámara manualmente, se inicia un flujo fresco y funciona, pero el poll de fondo golpea una URL ya caducada.
El segundo, y creo que es el que bloquea tu entrada, es esta línea:
PayloadTooLargeError: request entity too large
expected: 103788, length: 103788, limit: 102400
En resumen, ffmpeg logra extraer la imagen, pero pesa 103 KB y Gladys rechaza todo lo que supere los 100 KB. La imagen se captura, pero nunca se guarda. Y coincide con tu problema: tu entrada está en el exterior, la escena es más detallada, por lo que el JPEG es más pesado y siempre supera el límite. Tus cámaras interiores producen imágenes más ligeras, pasan cuando el flujo quiere responder. Probablemente por eso la entrada falla cada vez mientras que las otras funcionan intermitentemente.
Los dos parecen más problemas de integración que un problema de configuración de tu parte. El PayloadTooLargeError sobre todo: el límite de 100 KB es un poco justo para una captura de 1280px en exteriores, habría que aumentarlo, o bajar un poco la resolución o la calidad del snapshot.
¡Vaya, el flujo funciona después de todo! Solo que el re-encodificación causa un retraso de 10/15 segundos. ¡Y sin sonido! Pero parece que esto se tratará por separado en el núcleo.
Al parecer, para poder probar mejor, y con toda lógica, debería poder mostrar uno de los parámetros del dispositivo, para poder seleccionar la calidad del flujo « camera_quality »:
Ya tengo una solicitud en este sentido para Tuya para permitir ingresar los campos de IP y versión del protocolo en las fichas de Dispositivos. Va en la misma dirección.
Por el momento, hemos sorteado esto con un parámetro global en la configuración para todas las cámaras de la integración.
Aún no he encontrado una solución para el flujo de audio.
Y, por otro lado, realmente necesitamos poder crear una documentación con acceso a los enlaces de las plataformas de desarrollo, ya que en este caso no tenemos ninguna información para crear cuentas, etc., como la teníamos en las integraciones principales (¿o encontrar una manera de definir capítulos de inicio en las configuraciones que puedan incluir enlaces externos?)
EDIT:
Para el sonido, al parecer es mi cámara de prueba la que está rota y ya no da sonido… lo siento
En cuanto al retraso en vivo, Claude hace una propuesta:
1. Tipo de campo section — bloques de inicio en el formulario de configuración (se necesita el portado de Netatmo)
Validación manifiesta: nuevo tipo section en el config_schema (y los fields de las acciones, mismo motor) — label (título del capítulo, multilingüe), description en texto sin formato ≤ 1000 caracteres/idioma, links opcional (1–5 entradas {url, label}, urlhttps obligatorio, campos desconocidos rechazados). Puramente presentacional: required, default y placeholder en una sección → manifiesto rechazado en 422. El esquema vendored refleja todo (enum + links + reglas allOf).
Sin valor: validateConfigValue rechaza una clave de sección en cualquier carga útil de configuración (front y integración → 422 « los campos de sección no tienen valor »), nada se escribe nunca en t_variable, y getConfigForFront no expone la clave.
Renderizado front (declarativo, cero markdown/HTML): título + texto + enlaces abiertos en una nueva pestaña con el dominio objetivo mostrado entre paréntesis junto al label. Como el config_schema está ordenado, las secciones dividen naturalmente los formularios grandes — incluyendo los mini-formularios de acciones.
2. Enlace « Documentación » permanente en la pantalla de Configuración
Nuevo getDocsUrls en el lado del servidor: el detalle GET /api/v1/external_integration/:selector ahora expone docs (URLs rehuéspedadas por idioma, desde la caché del índice de la tienda, vinculadas por store_slug — null para una instalación de desarrollo, que no tiene documentación rehuéspedada).
El front muestra un botón « Documentación » en el encabezado de la tarjeta Configuración (idioma del usuario, fallback en), para las integraciones « dispositivo » como « comunicación » (componente compartido).
De paso, corrección de un agujero existente: getCatalog no transmitía el campo docs del índice — el enlace de documentación de la pantalla de instalación leía un campo siempre ausente. Ahora lo hace (docs: entry.docs || null), con aserción en las pruebas de la tienda.
estaba previsto ^^
