Shelly Multi Device Suite

Release 8.15 – 26.10.2026

Controller 5.3.5 (enthält 5.3.0 bis 5.3.4)

• Weniger Speicherbedarf beim Geräte-Abruf: Die Antwort von /properties/report wird nicht mehr mit JSON.parse zerlegt, die benötigten Werte werden direkt aus dem Text gelesen. Das spart pro Abfrage rund 2,4 kB Heap
  • Eine abgeschnittene Antwort oder ein fehlender SoC (electricLevel) zählt jetzt als „Fehler beim Parsen der Antwort“. Bisher lief ein fehlender SoC unbemerkt durch
  • Die Start-Synchronisierung der SoC-Grenzen nutzt den normalen Geräte-Abruf und hat keinen eigenen mehr
• Speicherspitze gesenkt: Abläufe, die gleichzeitig größere Antworten im Speicher hielten, laufen jetzt nacheinander (SoC-Grenzen beim Start, Netzmessung nach dem letzten Gerät, KVS-Werte beim Start einzeln). Bei zwei Geräten liegt peak bei etwa 18,8–19,1 kB statt 20,5 kB, auch beim manuellen Laden (vorher über 21 kB)
• KVS-Änderungen von außen (z. B. manuelles Laden aus dem Dashboard) werden nur zwischen zwei Regelzyklen übernommen: mehrere Änderungen kurz hintereinander werden zusammengefasst und mit einem KVS.GetMany gelesen. Vorher konnte der Shelly so langsam werden, dass das Dashboard „konnte nicht beendet werden“ meldete und ein Zyklus bis zum Watchdog hängen blieb
• Geräte-Writes nach einer KVS-Änderung (minSoc, inputLimit) gehen nacheinander raus
• Log: Laufzeiten in ganzen Millisekunden, neue Meldung KVS-Aenderung erkannt (Rev: N) - vorgemerkt, mit debug Speicher-Messpunkte (DEBUG MEM …)
• Regelverhalten unverändert (in der Simulation identische Stellbefehle wie 5.2.6)
• Keine Änderung am CONFIG-Block nötig

Dashboard 3.5.12 (Nachtrag) / Home-Assistant-App Dashboard-Proxy 3.5.12.2

• Manuelles Laden: Schon beim Klick auf Start oder Ende erscheint oben eine Leiste („… wird gestartet/beendet …“, „warte auf Bestätigung“), und die Bedienung ist gesperrt. Danach zeigt die Leiste das Ergebnis und die Restzeit; 10 s lang bleibt die gesamte Bedienung gesperrt, dann lädt das Dashboard den echten KVS-Stand
• Bleibt die Bestätigung aus, erscheint nicht mehr sofort „konnte nicht beendet werden“. Nach der Haltezeit vergleicht das Dashboard den echten Stand und meldet erst dann Erfolg oder Fehler
• Proxy (zendure_proxy.py, auch in der Home-Assistant-App und im local_helper): kvs_set_api darf bis 25 s dauern (bisher 5 s). Das Script schreibt drei Keys nacheinander, und der Proxy brach vorher mit 502 ab, obwohl alle Werte geschrieben waren

Multi-Configurator 2.9.2 (Nachtrag) / Home-Assistant-App Installer 2.9.2.1

• Helfer: Upload robuster, gleiches Verfahren wie upload_shelly.py. Schlägt ein Block fehl, beginnt die ganze Übertragung neu (höchstens dreimal), statt nur den Block zu wiederholen – ein wiederholter Block konnte sonst doppelt im Script landen. Auch ein Verbindungsabbruch wird jetzt wiederholt und nach drei Versuchen als „Upload unvollständig“ gemeldet
• Fortschrittsanzeige beim Direkt-Upload: Balken und Text zeigen die Phase (prüfen, stoppen/entfernen/anlegen, „Übertrage Block 23 von 46 …“, starten), auch einen Neustart der Übertragung
  • Neuer Endpunkt GET /api/upload_status?id=…, Feature upload_progress in /api/health. Mit einem älteren Helfer erscheint wie bisher nur „Übertrage an …“

Statistische Auswertung 1.3.0

• Regelgüte misst gegen den jeweils gültigen Sollwert statt gegen 0 W. Der Sollwert kommt aus dem Startblock und aus jeder Änderung KVS zdmc_setpoint
• Neue Spalten in tage.csv: sollwert_min_w, sollwert_max_w, regel_versatz_w; weicht der Versatz an einem Tag um mehr als BAND_W/2 ab, meldet das Skript einen Hinweis
• Neustarts werden am ganzen Startblock erkannt (vorher nur an „gestartet“)
• Neue Einstellungen SOLLWERT_START_W und NEUSTART_ABSTAND_S

Dokumentation

• Controller-Doku: Geräte-Abruf ohne JSON.parse, KVS-Ablauf seit 5.3.x, Fehlerkennung kvs, Anleitung zum Lesen der Stundenzeile Zyklen 1h
• Speichermodell: Abschnitt zum Regler-Script mit Formel, Tabelle und Messpunkten
• Auswertungs-Readme: Sollwert, Versatz und Neustart-Erkennung