Por cierto, la semana no ha terminado, ¡solo acaba de empezar!!
¡Hoy, mañana y el lunes a tiempo completo en Gladys 
!
¡Hola @pierre-gilles!
« La semana apenas comienza »: ¡qué alegría leerlo !
Justamente, aprovecho para subirte algo que acabamos de encontrar al desarrollar la integración externa Shelly, porque creemos que afecta al SDK/core.
El problema
publishDiscoveredDevices() (es decir, POST /discovered_device) recibe un PayloadTooLargeError: request entity too large tan pronto como se supera una docena de dispositivos.
El problema es que todo el proceso de descubrimiento se pierde: los dispositivos se han encontrado, pero nada llega a la pantalla y el usuario concluye que la integración no los ve.
Los números
Un Shelly Pro 3EM expone 24 características (3 fases × potencia activa/aparente/tensión/intensidad, los totales y 8 contadores de energía). Esto representa aproximadamente 8,4 Ko por dispositivo una vez serializado.
| Dispositivos | Características | Tamaño del cuerpo |
|---|---|---|
| 10 | 240 | 82 Ko |
| 12 | 288 | 99 Ko |
| 13 | 312 | 107 Ko → rechazado |
| 17 | 408 | 140 Ko → rechazado |
El límite, por lo tanto, está alrededor de 12 dispositivos, lo cual se alcanza rápidamente en una instalación de seguimiento de energía. En mi caso: 19 Shelly, de los cuales una decena de Pro 3EM.
Esto no solo afecta a Shelly: cualquier integración con dispositivos ricos en características (Zigbee, Z-Wave, contadores) chocará con el mismo muro.
Por qué no puedo solucionarlo adecuadamente
La documentación del SDK es explícita:
publishDiscoveredDevices(devices)— Publica la lista completa de dispositivos descubiertos (reemplaza la anterior).
Por lo tanto, no puedo dividirlo en varios envíos: el segundo lote borraría el primero y el usuario vería menos dispositivos que antes. Mientras tanto, he implementado una solución provisional que publica el subconjunto más grande aceptable y registra explícitamente lo que ha sido descartado: esto evita el fallo silencioso, pero sigue siendo un parche.
También cabe destacar que publishStates y publishTransports documentan cada uno un máximo de 100 elementos por solicitud. publishDiscoveredDevices no anuncia ningún límite, de ahí la sorpresa.
Dos propuestas
Opción A — lo mínimo vital
Aumentar el límite de tamaño del cuerpo en esta ruta (1 Mo, por ejemplo). Una línea en el core lo desbloquea de inmediato, pero sigue sin estar limitado.
Opción B — coherente con el resto del SDK (mi preferencia)
Alinear esta ruta con el modelo publishStates: un límite documentado por solicitud, y el SDK lo divide automáticamente, de forma transparente para el integrador.
En el core, bastaría con una bandera:
POST /discovered_device { devices: [...], replace: true|false }
replace: true→ comportamiento actual (reemplaza la lista)replace: false→ fusiona porexternal_id
En el SDK, ningún cambio de API: publishDiscoveredDevices(devices) envía el primer lote con replace: true y los siguientes con replace: false. Las integraciones existentes no cambian ni una línea, y las que tienen muchos dispositivos finalmente funcionan.
Podemos hacerlo
Tenemos nuestros forks del core y del SDK: si la opción B te conviene (o la opción A si prefieres ir a lo más simple por ahora), dínoslo y prepararemos la PR. Mejor que guardes tu semana intensiva para el resto 
¡Gracias!
¡Ay, esto es crítico! Le pido a Claude que lo corrija
De hecho, logro tener entre 11 y 13 dispositivos como máximo de los 19 ^^ Y funciona, pero hay 5 que nunca aparecen (visiblemente los más lentos para responder - RSSI muy bajo, coincide ^^)
La corrección está en vivo en master
Había olvidado, en relación con las PR principales Semaine ultra intensive sur Gladys - #21 par Terdious, también habrá las del SDK:
@Terdious para las PRs sobre el SDK JS, no sé si es necesario, en realidad creo que simplemente le diré al SDK « sincronízate con Gladys » cada vez que haya una modificación, ¿no?
¡Sería perfecto ^^
¡Lo cierro!!