Shelly 2.0.0: Auto-Update und Web-GUI kommen nicht auf 2.0.1

Freitag, 2. Oktober 2026

Shelly 2.0.0: Auto-Update und Web-GUI kommen nicht auf 2.0.110/02/2026

Mehrere Shelly-Geräte der Generation 3 und ein Pro 4PM standen auf Firmware 2.0.0. Die stabile Version 2.0.1 vom 23. September 2026 war sichtbar, aber weder der automatische Job noch die Weboberfläche haben sie installiert. Drei Ursachen. Danach liefen die Geräte auf 2.0.1.

Das Auto-Update um Mitternacht

Shelly legt für Geräte ab Generation 2 einen täglichen Job an, Methode Shelly.Update, Stufe stable, um 00:00 Uhr. Unter Version 2.0.0 installiert genau diese Uhrzeit das Update nicht. Jede andere Uhrzeit funktioniert. Das ist im Shelly-Forum beschrieben. Die Jobs hier liegen jetzt nach 04:00 Uhr, jedes Gerät ein paar Minuten versetzt, Zeitzone Europe/Vienna. Ein Neustart ist für die neue Uhrzeit nicht nötig.

Die Weboberfläche bricht das Archiv ab

Der manuelle Weg über die Geräteoberfläche endet bei diesem Sprung oft mit Update failed: DATA_LOSS: ZIP flush error : premature end of data. Dieselbe Meldung kommt, wenn man die ZIP-Datei selbst hochlädt. Das Archiv ist dann abgeschnitten. Ein Neustart vor dem Versuch hat das hier nicht geheilt. Dieser Abbruch hängt nicht am BLE-Scanner: der Upload aus dem Browser läuft ohne das Skript.

Der BLE-Scanner nimmt den Speicher

Das Shelly-Plugin in Home Assistant kann auf dem Gerät das Skript aioshelly_ble_integration anlegen, solange der BLE-Scanner auf Auto steht. Das Skript startet wieder, auch wenn man es auf dem Gerät abschaltet. Die Scan-Ereignisse drücken den freien Speicher zusammen. Beim ersten Update-Versuch fiel er auf rund 27 KB, der Lauf blieb bei drei bis fünf Prozent stehen. Bluetooth-Zubehör hängt hier keines. Zuerst den Scanner im Plugin auf disabled stellen, danach das Skript stoppen und löschen. Steht der Scanner beim Neustart noch auf Auto, legt das Plugin das Skript wieder an. Unter Version 2.0.0 kann das Löschen eines Skripts das Gerät neu starten. Die Ausgänge sollten dabei aus sein.

So ist das Update hier durchgelaufen

Den BLE-Scanner im Shelly-Plugin von Home Assistant abschalten, das Skript auf dem Gerät stoppen und löschen.
Den täglichen Shelly.Update-Job von Mitternacht auf eine Zeit nach 04:00 Uhr legen, die Geräte versetzt, Stufe stable.
Die stabile Datei für genau dieses Modell laden und die Prüfsumme prüfen. Die Liste steht unter https://updates.shelly.cloud/update/ plus dem Firmware-Typ. Für den 23. September 2026, Version 2.0.1, sind das diese drei Dateien. fwcdn.shelly.cloud zeigt ein Zertifikat der eigenen Stelle Allterco, kein öffentliches. curl braucht deshalb --insecure. Die Prüfung ist der SHA-256 im letzten Pfadbestandteil, nicht die TLS-Kette. Die Prüfzeile ist das Format von sha256sum. Unter macOS heißt derselbe Aufruf shasum -a 256 -c.

curl --fail --location --insecure --output S1PMG3.zip \
  "https://fwcdn.shelly.cloud/gen2-ntest/S1PMG3/fe946f8c11e95cc43fa529a2350aeade32ad51229a75150926fd4a103e83b4ba"
printf '%s  S1PMG3.zip\n' \
  fe946f8c11e95cc43fa529a2350aeade32ad51229a75150926fd4a103e83b4ba | sha256sum -c

curl --fail --location --insecure --output S2PMG3.zip \
  "https://fwcdn.shelly.cloud/gen2-ntest/S2PMG3/db13df263b6aaf8f8b6ea00d9bfa426750af9345143d89275b6dce0ab1dd9a11"
printf '%s  S2PMG3.zip\n' \
  db13df263b6aaf8f8b6ea00d9bfa426750af9345143d89275b6dce0ab1dd9a11 | sha256sum -c

curl --fail --location --insecure --output Pro4PM.zip \
  "https://fwcdn.shelly.cloud/gen2-ntest/Pro4PM/541dac8d9dd53fd702413f8364527cfdd22d71148aa7e343bac14576a2e7cf64"
printf '%s  Pro4PM.zip\n' \
  541dac8d9dd53fd702413f8364527cfdd22d71148aa7e343bac14576a2e7cf64 | sha256sum -c

Die Dateien sind 3610278, 3496390 und 2553623 Byte. Eine Datei eines anderen Modells gehört nicht auf das Gerät.

Shelly.Update nimmt entweder stage oder url, nicht beides. Mit der CDN-Adresse in url reißt der Download auf Version 2.0.0 ab. Die geprüfte Datei liefert deshalb ein Rechner im selben Netz per HTTP aus. Im Beispiel ist das 192.168.1.10, Port 8765. Das Shelly-Gerät ist 192.168.1.33. Der Aufruf gilt für ein Gerät ohne RPC-Passwort. Die Weboberfläche wurde nach dem Abschalten des BLE-Scanners nicht noch einmal benutzt. Ob sie dann durchgelaufen wäre, ist offen.

python3 -m http.server 8765 --bind 192.168.1.10 --directory .

curl --fail --silent --show-error --request POST \
  --header "Content-Type: application/json" \
  --data '{"id":1,"method":"Shelly.Update","params":{"url":"http://192.168.1.10:8765/S1PMG3.zip"}}' \
  "http://192.168.1.33/rpc"

curl --fail --silent --show-error --request POST \
  --header "Content-Type: application/json" \
  --data '{"id":1,"method":"Shelly.Update","params":{"url":"http://192.168.1.10:8765/S2PMG3.zip"}}' \
  "http://192.168.1.33/rpc"

curl --fail --silent --show-error --request POST \
  --header "Content-Type: application/json" \
  --data '{"id":1,"method":"Shelly.Update","params":{"url":"http://192.168.1.10:8765/Pro4PM.zip"}}' \
  "http://192.168.1.33/rpc"

Der Eco-Modus blieb an. Der Download wurde dadurch langsamer, er lief aber durch. Am verkabelten Pro 4PM bleibt WLAN aus. Unter Version 2.0.1 verliert Ethernet sonst die Adresse, wenn WLAN zusätzlich aktiv ist. WLAN abzuschalten braucht keinen Neustart.

Quellen

7 Aufrufe

Hinweis

Das Weblog gibt meine persönlichen Ansichten und Kommentare wieder und entspricht nicht den Positionen meiner aktuellen oder früheren Arbeitgeber oder Kunden.