Shelly Firmware Download: manuelles Update, wenn OTA im Timeout hängt

Ein Shelly hängt in der hintersten Ecke der Wohnung, funktioniert seit Monaten klaglos — und lässt sich trotzdem nicht aktualisieren. Das Update startet, läuft eine Weile und bricht mit einem Timeout ab. Immer wieder, an derselben Stelle.

Die naheliegende Idee: Firmware selbst herunterladen und die Datei manuell einspielen. Nur gibt Shelly die Firmware nicht einfach zum Download frei, sondern verweist auf denselben OTA-Updater, der ja gerade nicht funktioniert. Es gibt trotzdem einen Weg — er führt über zwei JSON-Abfragen und zwei Zertifikatswarnungen, die man beherzt wegklicken muss.

Das Wichtigste in Kürze

• Erst diagnostizieren: Das RPC-Logging in der Geräte-Weboberfläche zeigt im Klartext, woran es liegt. Bei mir stand da Avg RSSI -90, will scan for a better AP — der Shelly hing am Rand seiner Funkreichweite.
• Modell ermitteln: http://<GERÄTE-IP>/rpc/Shelly.GetDeviceInfo im Browser aufrufen und den Wert von app notieren, bei mir PlugSG3.
• Firmware-Adresse holen: https://updates.shelly.cloud/update/<APP> liefert ein JSON mit Version und Download-URL.
• ZIP herunterladen — die Datei liegt auf einem Server mit ungültigem Zertifikat, die Browserwarnung muss man bestätigen.
• Manuell einspielen über Settings → Firmware file image → Update from file in der Weboberfläche des Shelly.
• Kein Bastelweg: Es ist die offizielle Firmware aus Shellys eigener Update-Infrastruktur — nur eben von Hand geholt statt vom Gerät.

Schritt 0: Herausfinden, woran es wirklich liegt

Bevor man irgendetwas herunterlädt, lohnt sich ein Blick in das Log des Geräts. Shelly-Geräte der zweiten und dritten Generation bringen dafür eine Diagnoseseite mit, die im Alltag niemand ansieht.

Die Log-Ausgabe ist ab Werk abgeschaltet und muss erst eingeschaltet werden — in der Weboberfläche über die Debug-Einstellungen des Geräts. Danach zeigt der Menüpunkt Diagnostics eine mitlaufende Konsole. Wer lieber ohne Oberfläche arbeitet, schaltet dasselbe per RPC-Methode Sys.SetConfig über debug.websocket.enable ein; das Log liegt dann auch unter ws://<GERÄTE-IP>/debug/log an. Dort steht, was das Gerät gerade tut — und was ihm fehlt:

RSSI -90 dBm ist die Grenze zum Nichts. Für einen Sensor, der alle paar Minuten ein paar Byte sendet, reicht das noch — deshalb fällt es im Alltag nicht auf. Ein Firmware-Image von dreieinhalb Megabyte ist etwas anderes: Das Gerät muss es am Stück und innerhalb eines festen Zeitfensters laden. Bricht die Verbindung mittendrin weg oder wird sie zu langsam, läuft das Update in den Timeout.

Wer solche Ausfälle auch an anderen Geräten sieht, sollte ohnehin einmal grundsätzlich prüfen, warum das WLAN an dieser Stelle schwächelt — der Shelly ist dann nur der Bote.

Warum Shelly die Firmware nicht einfach anbietet

Der logische nächste Schritt wäre, sich die Firmware-Datei von der Shelly-Website zu holen. Genau das ist nicht vorgesehen: Es gibt keine öffentliche Download-Seite mit Firmware-Dateien, die Dokumentation verweist stattdessen auf den eingebauten Updater.

Aus Herstellersicht ist das nachvollziehbar — es verhindert, dass Leute die falsche Firmware auf das falsche Gerät spielen. Nur hilft es nicht weiter, wenn der Updater das Problem ist. Die Update-Server sind aber öffentlich erreichbar, man muss nur wissen, wie man sie fragt.

Schritt 1: Das Modell des Geräts ermitteln

Shelly identifiziert seine Geräte intern über einen kurzen Bezeichner, nicht über den Produktnamen. Den bekommst du direkt vom Gerät, indem du diese Adresse im Browser aufrufst:

http://<GERÄTE-IP>/rpc/Shelly.GetDeviceInfo

Kopiere dir den Wert von app. Nur der zählt für den nächsten Schritt. Die Schreibweise mit Groß- und Kleinbuchstaben musst du exakt übernehmen.

Schritt 2: Die Firmware-Adresse abfragen

Jetzt rufst du Shellys Update-Verzeichnis für genau dieses Modell auf:

https://updates.shelly.cloud/update/<APP>

In meinem Fall also https://updates.shelly.cloud/update/PlugSG3. Die Antwort ist wieder ein JSON:

Unter stable stehen die aktuelle Versionsnummer, die Build-ID und die URL zur Firmware-Datei. Manche Modelle führen zusätzlich einen beta-Zweig — für ein Gerät, das einfach nur laufen soll, ist stable der richtige.

Schritt 3: Die Zertifikatswarnungen

Sowohl beim Update-Verzeichnis als auch beim eigentlichen Download meldet sich der Browser mit einer Sicherheitswarnung. Der Fehlercode lautet SEC_ERROR_UNKNOWN_ISSUER: Das Zertifikat stammt nicht von einer Stelle, der der Browser vertraut.

Das ist ärgerlich und bei einem Hersteller dieser Größe schwer zu entschuldigen — es ist aber keine Falle, sondern ein Versäumnis auf Shellys Seite. Bevor du klickst, prüfe trotzdem zwei Dinge:

• Die Domain in der Adresszeile muss auf shelly.cloud enden, bei mir fwcdn.shelly.cloud. Alles andere schließt du besser.
• Die URL musst du aus dem JSON in Schritt 2 haben, nicht aus einer Suchmaschine oder einem Forenbeitrag.

Danach lädt eine ZIP-Datei herunter, benannt nach dem langen Hash aus der URL. Entpacken musst du sie nicht — das Gerät erwartet genau dieses Archiv.

Schritt 4: Manuell einspielen

Zurück in der Weboberfläche des Shelly, unter Settings → Firmware information. Dort gibt es unterhalb der offiziellen Update-Schaltfläche einen zweiten Bereich: Firmware file image.

Die ZIP-Datei per Drag-and-drop ablegen oder über browse files auswählen, dann Update from file. Der Fortschrittsbalken läuft oben am Fensterrand, das Gerät startet anschließend neu.

Direkt darunter sitzt übrigens noch Firmware file image link. Dort kannst du die URL aus Schritt 2 auch direkt eintragen, statt die Datei herunterzuladen. Das spart einen Schritt — in meinem Fall hätte es aber wenig gebracht, weil dabei wieder das Gerät selbst über die schwache Funkstrecke laden muss.

Schritt 5: Kontrolle

Nach dem Neustart zeigt die Oberfläche oben den Hinweis, dass die Firmware aktualisiert wurde und die angezeigte Web-Oberfläche noch die alte ist. Nach einem Neuladen stimmt die Firmware ID mit der Build-ID aus Schritt 2 überein, und bei den offiziellen Updates steht No updates. Bei mir war damit die Version 2.0.1 installiert — die, an der der OTA-Updater vorher dreimal gescheitert war.

Warum der Umweg funktioniert, das Update aber nicht

Shelly dokumentiert den Unterschied nicht, die Mechanik ist aber nachvollziehbar. Beim normalen Update baut das Gerät selbst eine verschlüsselte Verbindung nach außen auf und zieht das Image über seine eigene, hier sehr schwache WLAN-Strecke — mit einem festen Zeitlimit im Rücken. Reißt die Verbindung, war alles umsonst.

Beim Upload aus dem Browser kommt die Datei dagegen aus dem lokalen Netz, und der Browser bestimmt das Tempo. Die Funkstrecke zum Shelly ist zwar dieselbe, aber der Transfer hängt nicht mehr an einem Timeout in der Cloud. Das reicht in der Praxis offenbar aus.

Was das nicht ist: eine Lösung für das eigentliche Problem. Ein Gerät mit -90 dBm ist und bleibt schlecht angebunden. Wenn du den Shelly dauerhaft nutzen willst, gehört an diese Stelle ein zusätzlicher Access Point oder ein Repeater — sonst wiederholt sich das Spiel beim nächsten Update.

Sicherheit: Was man hier eigentlich tut

Zertifikatswarnungen wegzuklicken ist eine schlechte Gewohnheit, und man sollte sich bewusst machen, warum es hier vertretbar ist: Die Adresse stammt aus einer Abfrage bei Shellys eigenem Update-Dienst, nicht aus einer fremden Quelle. Die heruntergeladene Datei ist dieselbe, die das Gerät bei einem normalen Update selbst holen würde.

Was du nicht tun solltest: Firmware-ZIPs aus Foren, Filehostern oder von Drittseiten einspielen. Der Weg über updates.shelly.cloud ist genau deshalb der richtige — er ist nachprüfbar.

Fazit

Der Weg ist umständlicher, als er sein müsste. Zwei JSON-Abfragen und zwei Zertifikatswarnungen für etwas, das ein Download-Link auf der Produktseite erledigen würde. Dafür funktioniert er zuverlässig, und er kommt ohne zusätzliche Software aus — Browser genügt.

Die eigentliche Lektion steckt aber in Schritt 0: Das RPC-Log hätte mir den Grund sofort verraten, wenn ich früher hineingesehen hätte. Avg RSSI -90 ist eine klarere Ansage als jede Timeout-Meldung im Update-Dialog. Wer bei einem hakeligen Shelly zuerst die Diagnoseseite öffnet, spart sich einiges an Raten.

Bei den batteriebetriebenen Bluetooth-Geräten von Shelly sieht die Sache übrigens völlig anders aus — dort gibt es diese Weboberfläche gar nicht. Wie man ein BLU-Gerät nach einem abgebrochenen Update rettet, habe ich separat aufgeschrieben.

Häufige Fragen

Woher bekomme ich die IP-Adresse meines Shelly?

Aus der Shelly-App unter den Geräteeinstellungen oder aus der Liste der DHCP-Leases im Router. Sinnvollerweise vergibst du dort gleich eine feste Adresse für das Gerät.

Muss ich die ZIP-Datei entpacken?

Nein. Das Gerät erwartet das Archiv so, wie es geladen wurde.

Funktioniert das auch für Gen-1-Geräte?

Die hier beschriebene RPC-Schnittstelle gibt es erst ab Generation 2. Ältere Shellys haben eine andere Oberfläche und eine andere API — dort führt der Weg über /status und /settings. Den Bezeichner findest du bei ihnen unter device.type.

Kann ich damit auch eine ältere Version aufspielen?

Das Update-Verzeichnis liefert nur die jeweils aktuelle stabile und gegebenenfalls eine Beta-Version. Ein Downgrade ist damit nicht vorgesehen, und bei Shelly auch nicht ohne Weiteres möglich.

Ist das ein Garantieproblem?

Nein. Es ist die offizielle Firmware des Herstellers, eingespielt über eine Funktion, die der Hersteller selbst in die Oberfläche eingebaut hat. Etwas anderes wäre eine Fremdfirmware wie Tasmota — die kostet die Garantie.

Was ist ein guter RSSI-Wert?

Als Faustregel: bis etwa -60 dBm sehr gut, bis -70 dBm brauchbar, ab -80 dBm wird es dünn, und bei -90 dBm funktioniert nur noch das Nötigste. Der Wert steht im Log und in der Weboberfläche unter den WLAN-Einstellungen.

Der beschriebene Weg wurde am 24.09.2026 mit einem Shelly Plug S Gen 3 (Modell S3PL-00112EU) durchgeführt, Update von Version 1.2.3 auf 2.0.1. Geräte-ID und MAC-Adresse sind in den Screenshots unkenntlich gemacht. Die Amazon-Links sind Affiliate-Links: Wenn du darüber kaufst, bekomme ich eine kleine Provision, für dich ändert sich nichts.