Zur Erinnerung: Die Woche ist noch nicht vorbei, sie hat gerade erst begonnen!!
Heute, morgen und Montag wieder voll durch auf Gladys 
Hallo @pierre-gilles!
« Die Woche hat gerade erst begonnen »: Das freut einen zu lesen
Genau genommen nutze ich die Gelegenheit, um dir etwas zu melden, das wir gerade bei der Entwicklung der externen Shelly-Integration festgestellt haben, weil wir denken, dass es den SDK/core betrifft.
Das Problem
publishDiscoveredDevices() (also POST /discovered_device) erhält einen PayloadTooLargeError: request entity too large, sobald man eine kleine Dutzend Geräte überschreitet.
Das Problem ist, dass die gesamte Entdeckung dann verloren geht: Die Geräte wurden zwar gefunden, aber nichts erscheint auf dem Bildschirm und der Benutzer schließt daraus, dass die Integration sie nicht sieht.
Die Zahlen
Ein Shelly Pro 3EM bietet 24 Funktionen (3 Phasen × Wirkleistung / Scheinleistung / Spannung / Stromstärke, die Summen und 8 Energiezähler). Das ergibt etwa 8,4 KB pro Gerät nach der Serialisierung.
| Geräte | Funktionen | Größe des Körpers |
|---|---|---|
| 10 | 240 | 82 KB |
| 12 | 288 | 99 KB |
| 13 | 312 | 107 KB → abgelehnt |
| 17 | 408 | 140 KB → abgelehnt |
Die Grenze liegt also bei etwa 12 Geräten, was bei einer Energieüberwachungsinstallation schnell erreicht ist. Bei mir: 19 Shelly, davon etwa zehn Pro 3EM.
Das betrifft nicht nur Shelly — jede Integration mit funktionsreichen Geräten (Zigbee, Z-Wave, Zähler) stößt an dieselbe Grenze.
Warum ich nicht sauber umgehen kann
Die SDK-Dokumentation ist eindeutig:
publishDiscoveredDevices(devices)— Veröffentlicht die vollständige Liste der entdeckten Geräte (ersetzt die vorherige).
Ich kann also nicht in mehrere Sendungen aufteilen: Die zweite Charge würde die erste löschen und der Benutzer würde weniger Geräte sehen als zuvor. Vorerst habe ich eine Notlösung implementiert, die die größte akzeptable Teilmenge veröffentlicht und explizit aufzeichnet, was ausgelassen wurde — das verhindert das stille Scheitern, ist aber nur ein Pflaster.
Auch zu beachten: publishStates und publishTransports dokumentieren jeweils ein Maximum von 100 Elementen pro Anfrage. publishDiscoveredDevices gibt keine Grenze an, daher die Überraschung.
Zwei Vorschläge
Option A — das Minimum
Die Größengrenze für diese Route erhöhen (z. B. 1 MB). Eine Zeile auf der Core-Seite, das löst das Problem sofort, aber es bleibt unbeschränkt.
Option B — konsistent mit dem Rest des SDK (meine Präferenz)
Diese Route an das Modell publishStates anpassen: eine dokumentierte Grenze pro Anfrage, und das SDK teilt automatisch auf, transparent für den Integrator.
Auf der Core-Seite würde ein Flaggen genügen:
POST /discovered_device { devices: [...], replace: true|false }
replace: true→ aktuelles Verhalten (ersetzt die Liste)replace: false→ fusioniert nachexternal_id
Auf der SDK-Seite keine API-Änderung: publishDiscoveredDevices(devices) sendet die erste Charge mit replace: true und die folgenden mit replace: false. Bestehende Integrationen ändern sich nicht, und diejenigen mit vielen Geräten funktionieren endlich.
Wir können das machen
Wir haben unsere Forks des Cores und des SDK — wenn dir Option B gefällt (oder Option A, wenn du lieber zum Einfachsten greifen möchtest), lass es uns wissen und wir bereiten den PR vor. Du kannst deine intensive Woche für den Rest behalten 
Danke!
Ach Mist, das ist kritisch!! Ich bitte Claude, das zu korrigieren
Tatsächlich schaffe ich es, zwischen 11 und 13 Geräte von den 19 zu verbinden ^^ Es läuft, aber 5 zeigen sich nie (offensichtlich die langsamsten beim Antworten - sehr niedriger RSSI, das passt zusammen ^^)
Der Fix ist live auf master
Ich hatte vergessen, in Bezug auf die PRs core Semaine ultra intensive sur Gladys - #21 par Terdious, es wird auch die des SDK geben:
@Terdious für die PRs zum JS-SDK, ich weiß nicht, ob das nötig ist, eigentlich denke ich, ich werde dem SDK einfach nur « sync dich mit Gladys » sagen, wenn sich etwas ändert, oder?
Das wäre perfekt ^^
Ich schließe!!