Just a reminder, the week isn’t over, it’s just beginning!!
Still today, tomorrow, and Monday full-time on Gladys 
Hi @pierre-gilles!
« The week has only just begun »: it’s nice to read
I’m taking this opportunity to bring up an issue we just encountered while developing the Shelly external integration, because we think it affects the SDK/core.
The Problem
publishDiscoveredDevices() (i.e., POST /discovered_device) gets a PayloadTooLargeError: request entity too large as soon as we exceed a little over a dozen devices.
The issue is that the entire discovery is then lost: the devices were found, but nothing appears on the screen, and the user concludes that the integration doesn’t see them.
The Numbers
A Shelly Pro 3EM exposes 24 features (3 phases × active/reactive power, voltage, current, totals, and 8 energy meters). This results in approximately 8.4 KB per device once serialized.
| Devices | Features | Body Size |
|---|---|---|
| 10 | 240 | 82 KB |
| 12 | 288 | 99 KB |
| 13 | 312 | 107 KB → rejected |
| 17 | 408 | 140 KB → rejected |
The threshold is therefore around 12 devices, which is quickly reached in an energy monitoring installation. At my place: 19 Shelly devices, including about ten Pro 3EM.
This isn’t just about Shelly — any integration with feature-rich devices (Zigbee, Z-Wave, meters) will hit the same wall.
Why I Can’t Properly Work Around It
The SDK documentation is clear:
publishDiscoveredDevices(devices)— Publishes the complete list of discovered devices (replaces the previous one).
So I can’t split it into multiple sends: the second batch would erase the first, and the user would see fewer devices than before. For now, I’ve implemented a fallback that publishes the largest acceptable subset and logs what was excluded — this prevents silent failure, but it’s still a band-aid.
Also note: publishStates and publishTransports each document a maximum of 100 items per request. publishDiscoveredDevices doesn’t announce any limit, hence the surprise.
Two Proposals
Option A — the bare minimum
Increase the body size limit on this route (e.g., 1 MB). One line on the core side, and it’s immediately resolved, but it remains unbounded.
Option B — consistent with the rest of the SDK (my preference)
Align this route with the publishStates model: a documented limit per request, and the SDK splits it automatically, transparently for the integrator.
On the core side, it would just need a flag:
POST /discovered_device { devices: [...], replace: true|false }
replace: true→ current behavior (replaces the list)replace: false→ merges byexternal_id
On the SDK side, no API change: publishDiscoveredDevices(devices) sends the first batch with replace: true and the following ones with replace: false. Existing integrations don’t change a line, and those with many devices finally work.
We Can Do It
We have our forks of the core and SDK — if Option B suits you (or Option A if you prefer to keep it simple for now), let us know, and we’ll prepare the PR. You can keep your intensive week for the rest 
Thanks!
Oh shoot that’s critical!! I’m asking Claude to fix it
Indeed, I can get between 11 and 13 devices max out of the 19 ^^ It works, but there are 5 that never show up (apparently the slowest to respond - very low RSSI, it matches ^^)
The fix is live on master
I had forgotten, in relation to the core PRs Semaine ultra intensive sur Gladys - #21 par Terdious, there will also be those of the SDK:
@Terdious about PRs on the JS SDK, I don’t know if it’s necessary, honestly I think I’ll just tell the SDK « sync with Gladys » every time there’s a change, right?
That would be perfect ^^
I’m closing!!