Pour rappel la semaine n’est pas terminée, elle ne fait que commencer !!
Encore aujourd’hui, demain et lundi à temps plein sur Gladys 
Salut @pierre-gilles !
« La semaine ne fait que commencer » : ça fait plaisir à lire
Justement, j’en profite pour te remonter un truc qu’on vient de rencontrer en développant l’intégration externe Shelly, parce qu’on pense que ça touche le SDK/core.
Le problème
publishDiscoveredDevices() (donc POST /discovered_device) se prend un PayloadTooLargeError: request entity too large dès qu’on dépasse une petite douzaine d’appareils.
Le souci, c’est que la découverte entière est alors perdue : les appareils ont bien été trouvés, mais rien n’arrive à l’écran et l’utilisateur conclut que l’intégration ne les voit pas.
Les chiffres
Un Shelly Pro 3EM expose 24 fonctionnalités (3 phases × puissance active / apparente / tension / intensité, les totaux, et 8 compteurs d’énergie). Ça fait environ 8,4 Ko par appareil une fois sérialisé.
| Appareils | Fonctionnalités | Taille du corps |
|---|---|---|
| 10 | 240 | 82 Ko |
| 12 | 288 | 99 Ko |
| 13 | 312 | 107 Ko → refusé |
| 17 | 408 | 140 Ko → refusé |
Le seuil tombe donc autour de 12 appareils, ce qui est vite atteint sur une installation de suivi d’énergie. Chez moi : 19 Shelly, dont une dizaine de Pro 3EM.
Ça ne concerne pas que Shelly — n’importe quelle intégration avec des appareils riches en fonctionnalités (Zigbee, Z-Wave, compteurs) tapera dans le même mur.
Pourquoi je ne peux pas contourner proprement
La doc du SDK est explicite :
publishDiscoveredDevices(devices)— Publishes the complete list of discovered devices (replaces the previous one).
Donc je ne peux pas découper en plusieurs envois : le deuxième lot effacerait le premier et l’utilisateur verrait moins d’appareils qu’avant. En attendant, j’ai mis un repli qui publie le plus gros sous-ensemble acceptable et journalise nommément ce qui a été écarté — ça évite l’échec silencieux, mais ça reste un pansement.
À noter aussi : publishStates et publishTransports documentent chacun un maximum de 100 éléments par requête. publishDiscoveredDevices n’annonce aucune limite, d’où la surprise.
Deux propositions
Option A — le minimum vital
Relever la limite de taille du corps sur cette route (1 Mo par exemple). Une ligne côté core, ça débloque tout de suite, mais ça reste non borné.
Option B — cohérent avec le reste du SDK (ma préférence)
Aligner cette route sur le modèle publishStates : une limite documentée par requête, et le SDK découpe tout seul, de façon transparente pour l’intégrateur.
Côté core, il suffirait d’un drapeau :
POST /discovered_device { devices: [...], replace: true|false }
replace: true→ comportement actuel (remplace la liste)replace: false→ fusionne parexternal_id
Côté SDK, aucun changement d’API : publishDiscoveredDevices(devices) envoie le premier lot avec replace: true puis les suivants avec replace: false. Les intégrations existantes ne changent pas d’une ligne, et celles qui ont beaucoup d’appareils fonctionnent enfin.
On peut le faire
On a nos forks du core et du SDK — si l’option B te convient (ou l’option A si tu préfères aller au plus simple pour l’instant), dis-nous et on prépare la PR. Autant que tu gardes ta semaine intensive pour le reste 
Merci !
Ah mince c’est critique ça !! Je demande à Claude de corriger
En effet, j’arrive a avoir entre 11 et 13 appareils max sur les 19 ^^ Et ca tourne, mais il y en a 5 qui ne se montre jamais (visiblement les plus lents à répondre - RSSI très bas, ca coincide ^^)
Le correctif est live sur master
J’avais oublié, en lien avec les PR core Semaine ultra intensive sur Gladys - #21 par Terdious, il y aura celles du SDK :
@Terdious pour les PRs sur le SDK JS, je sais pas si c’est nécessaire, en vrai je pense que je vais juste dire au SDK « sync toi avec Gladys » à chaque modification, non ?
Ce serait parfait ^^
Je ferme !!