NEWS
Shelly Adapter - genereller Support
-
@Peter-c sagte in Integration von shelly1minigen3:
Hi Peter,
alle Shelly Geräte mit dem selben MQTT User Name "shelly_Plugs"und Passwort definiert
Das passt ja. Jedoch brauchen alle Shellies in den Settings - Authentication auch ein gleichlautendes Passwort:

@fuzzy1955 Das hab ich mal probiert, bringt aber keine Änderung. Ist bei den anderen Shellys die ich habe nicht eingetragen.
-
@mcm1957 Habe nun das PW im Adapter geprüft und beim shelly 1mini gen3 erneut eingegeben, neu gebootet. Dann die Shelly Instanz neu gestartet. Und dass ist dann protokolliert worden.
2025-12-02 13:53:50.335 - error: shelly.0 (28807) [MQTT] Wrong MQTT authentication of client "shelly1minig3-e4b32328d3c8": Incorrect username (expected "shelly_Plugs") 2025-12-02 13:53:50.357 - info: shelly.0 (28807) [MQTT] Client Close: (shelly1minig3 / shelly1minig3-e4b32328d3c8 / shelly1minig3#e4b32328d3c8#1) (false) 2025-12-02 13:54:15.176 - info: host.iobroker stopInstance system.adapter.shelly.0 (force=false, process=true) 2025-12-02 13:54:15.186 - info: shelly.0 (28807) Got terminate signal TERMINATE_YOURSELF 2025-12-02 13:54:15.193 - info: shelly.0 (28807) terminating 2025-12-02 13:54:15.195 - info: shelly.0 (28807) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2025-12-02 13:54:15.236 - info: host.iobroker stopInstance system.adapter.shelly.0 send kill signal 2025-12-02 13:54:15.697 - info: shelly.0 (28807) terminating 2025-12-02 13:54:15.796 - info: host.iobroker instance system.adapter.shelly.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2025-12-02 13:54:19.382 - info: host.iobroker instance system.adapter.shelly.0 in version "10.4.1" started with pid 29166 2025-12-02 13:54:23.291 - info: shelly.0 (29166) starting. Version 10.4.1 in /opt/iobroker/node_modules/iobroker.shelly, node: v20.19.1, js-controller: 7.0.7 2025-12-02 13:54:23.889 - info: shelly.0 (29166) [firmwareUpdate] Auto-Update enabled - devices will be updated automatically 2025-12-02 13:54:23.890 - info: shelly.0 (29166) Starting in MQTT mode. Listening on 0.0.0.0:1882 (QoS 0) 2025-12-02 13:54:29.587 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-80646fe770c4" connected from 192.168.178.126! 2025-12-02 13:54:29.598 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-a0a3b3e84258" connected from 192.168.178.199! 2025-12-02 13:54:29.603 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-d4d4da7c3fdc" connected from 192.168.178.98! 2025-12-02 13:54:29.968 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-d48afc56889c" connected from 192.168.178.105! 2025-12-02 13:54:30.194 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-a0a3b3e82c7c" connected from 192.168.178.106! 2025-12-02 13:54:30.524 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-e465b843483c" connected from 192.168.178.130! 2025-12-02 13:54:32.182 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-d48afc560ac0" connected from 192.168.178.116! 2025-12-02 13:54:45.190 - error: shelly.0 (29166) [MQTT] Wrong MQTT authentication of client "shelly1minig3-e4b32328d3c8": Incorrect username (expected "shelly_Plugs") 2025-12-02 13:54:45.219 - info: shelly.0 (29166) [MQTT] Client Close: (shelly1minig3 / shelly1minig3-e4b32328d3c8 / shelly1minig3#e4b32328d3c8#1) (false)@Peter-c sagte in Shelly Adapter - genereller Support:
Incorrect username (expected "shelly_Plugs"
...und nicht shelly_PlugS
-
@Peter-c sagte in Shelly Adapter - genereller Support:
Incorrect username (expected "shelly_Plugs"
...und nicht shelly_PlugS
-
@mcm1957 Habe nun das PW im Adapter geprüft und beim shelly 1mini gen3 erneut eingegeben, neu gebootet. Dann die Shelly Instanz neu gestartet. Und dass ist dann protokolliert worden.
2025-12-02 13:53:50.335 - error: shelly.0 (28807) [MQTT] Wrong MQTT authentication of client "shelly1minig3-e4b32328d3c8": Incorrect username (expected "shelly_Plugs") 2025-12-02 13:53:50.357 - info: shelly.0 (28807) [MQTT] Client Close: (shelly1minig3 / shelly1minig3-e4b32328d3c8 / shelly1minig3#e4b32328d3c8#1) (false) 2025-12-02 13:54:15.176 - info: host.iobroker stopInstance system.adapter.shelly.0 (force=false, process=true) 2025-12-02 13:54:15.186 - info: shelly.0 (28807) Got terminate signal TERMINATE_YOURSELF 2025-12-02 13:54:15.193 - info: shelly.0 (28807) terminating 2025-12-02 13:54:15.195 - info: shelly.0 (28807) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2025-12-02 13:54:15.236 - info: host.iobroker stopInstance system.adapter.shelly.0 send kill signal 2025-12-02 13:54:15.697 - info: shelly.0 (28807) terminating 2025-12-02 13:54:15.796 - info: host.iobroker instance system.adapter.shelly.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2025-12-02 13:54:19.382 - info: host.iobroker instance system.adapter.shelly.0 in version "10.4.1" started with pid 29166 2025-12-02 13:54:23.291 - info: shelly.0 (29166) starting. Version 10.4.1 in /opt/iobroker/node_modules/iobroker.shelly, node: v20.19.1, js-controller: 7.0.7 2025-12-02 13:54:23.889 - info: shelly.0 (29166) [firmwareUpdate] Auto-Update enabled - devices will be updated automatically 2025-12-02 13:54:23.890 - info: shelly.0 (29166) Starting in MQTT mode. Listening on 0.0.0.0:1882 (QoS 0) 2025-12-02 13:54:29.587 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-80646fe770c4" connected from 192.168.178.126! 2025-12-02 13:54:29.598 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-a0a3b3e84258" connected from 192.168.178.199! 2025-12-02 13:54:29.603 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-d4d4da7c3fdc" connected from 192.168.178.98! 2025-12-02 13:54:29.968 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-d48afc56889c" connected from 192.168.178.105! 2025-12-02 13:54:30.194 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-a0a3b3e82c7c" connected from 192.168.178.106! 2025-12-02 13:54:30.524 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-e465b843483c" connected from 192.168.178.130! 2025-12-02 13:54:32.182 - info: shelly.0 (29166) [MQTT] Device with client id "shellyplusplugs-d48afc560ac0" connected from 192.168.178.116! 2025-12-02 13:54:45.190 - error: shelly.0 (29166) [MQTT] Wrong MQTT authentication of client "shelly1minig3-e4b32328d3c8": Incorrect username (expected "shelly_Plugs") 2025-12-02 13:54:45.219 - info: shelly.0 (29166) [MQTT] Client Close: (shelly1minig3 / shelly1minig3-e4b32328d3c8 / shelly1minig3#e4b32328d3c8#1) (false)@Peter-c sagte in Shelly Adapter - genereller Support:
@mcm1957 Habe nun das PW im Adapter geprüft und beim shelly 1mini gen3 erneut eingegeben, neu gebootet. Dann die Shelly Instanz neu gestartet. Und dass ist dann protokolliert worden.
2025-12-02 13:53:50.335 - error: shelly.0 (28807) [MQTT] Wrong MQTT authentication of client "shelly1minig3-e4b32328d3c8": **Incorrect username** (expected "shelly_Plugs")Auch wenns schon gelöst ist - als Info für die Zukunft:
Die Fehlermeldung sagt EINDEUTIG dass der Username nicht passt. Bei falschem Passwort würde die Meldung anders lauten und auf das falsche Kennwort hindeuten. Allerdinsg wird weder das falsche noch das erwartetet Passwort in diesem Fall gelogged :-) -
ich habe ein problem mit einem shelly Dimmer2 gen1 der im adapter nicht auftaucht. iobroker auf raspi alle adapter und js aktuell.
Das Problem: ich habe den iobroker in netzwerk1 . shelly1/GEN1 Shelly Dimmer2/Gen1 in netzwerk2 Verbindung der Netzwerke über VPN. Shellys in Netzwerk2 coap/http aktiviert und in shelly cloud aktiviert.
Der shelly1 taucht im Netzwerk1 im Adapter auf der Dimmer nicht. beide Shellys von Netzwerk 1 über ip erreichbar. Wie kann ich den Adapter überreden den Dimmer anzunehmen? Alles mehrfach neu gestartet.
Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt. -
Shelly cloud spielt mal nicht mit. Der Adapter benutzt die Cloud nicht.
Sofern die beiden Netzte via vpn OHNE NAT verbunden sind sollte es prinzipiell gehen.
Hast du beim Dimmer COAP UNICAST eingestellt? Siehe Doku https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/protocol-coap.md
Falls eine Firmware-Version größer als 1.9.4 verwendet wird, musst ein CoIoT-Server auf den Shelly-Geräten konfiguriert werden (unicast).
-
Hallo,
ich habe einen Shelly H&T G3 in iobroker mittels MQTT eingebunden. Das funktioniert auch soweit, das entsprechende Objekt wird unter "Shelly" aufgelistet. Nur sehe ich das Problem, dass das Gerät, um Energie zu sparen, ja immer nur kurz sendet und dann wieder in den Deep-sleep-mode fällt. Entsprechend dieses Verhaltens sehe ich in dem entsprechenden Shelly-Objekt im iobroker auch, dass eben keine Verbindung zum Gerät in diesen deep-sleep-Phasen existiert. Das wäre ja nicht tragisch, jedoch sehe ich auch nach längerem Zeitraum, in der das Gerät jetzt im iobroker existiert, keine entsprechenden sich ändernden Messwerte im Verlaufsdiagramm z.b. der Temperatur. Kriegt iobroker die kurzen "Wachphasen" einfach nicht mit?
Hat einer einen Lösungsvorschlag? -
Sobald der H&T sendet bekommt das ioBroker mit.
Welche Adapterversion verwendest du?
Was steht im Log? Schalt ggF das DEBUG Log ein . dann solltest du sehen ob bzw. was der H&T sendet.
In den Stateattributen siehst du auch wann sie zuletzt aktualisisiert wurden.Sieht eigentlich eher so aus als würde der H&T gar keine Verbindung mit ioBroker aufnehmen. Check mal die MQTT Einstellung, insbesondere ob die IP Addressen des Hosts passen und ob die MQTT Optionen alle angehakt sind. (Sihe Dokumentation)
-
Hallo,
ich habe einen Shelly H&T G3 in iobroker mittels MQTT eingebunden. Das funktioniert auch soweit, das entsprechende Objekt wird unter "Shelly" aufgelistet. Nur sehe ich das Problem, dass das Gerät, um Energie zu sparen, ja immer nur kurz sendet und dann wieder in den Deep-sleep-mode fällt. Entsprechend dieses Verhaltens sehe ich in dem entsprechenden Shelly-Objekt im iobroker auch, dass eben keine Verbindung zum Gerät in diesen deep-sleep-Phasen existiert. Das wäre ja nicht tragisch, jedoch sehe ich auch nach längerem Zeitraum, in der das Gerät jetzt im iobroker existiert, keine entsprechenden sich ändernden Messwerte im Verlaufsdiagramm z.b. der Temperatur. Kriegt iobroker die kurzen "Wachphasen" einfach nicht mit?
Hat einer einen Lösungsvorschlag?@musicnrw sagte in Shelly Adapter - genereller Support:
Kriegt iobroker die kurzen "Wachphasen" einfach nicht mit?
...ja, das bekommt er mit und funktioniert einwandfrei. Ich habe über zehn der HT eingebunden.
Da könnte bei dir evtl. was falsch eingestellt sein.
Grüße
Fabio -
Hallo,
ich habe einen Shelly H&T G3 in iobroker mittels MQTT eingebunden. Das funktioniert auch soweit, das entsprechende Objekt wird unter "Shelly" aufgelistet. Nur sehe ich das Problem, dass das Gerät, um Energie zu sparen, ja immer nur kurz sendet und dann wieder in den Deep-sleep-mode fällt. Entsprechend dieses Verhaltens sehe ich in dem entsprechenden Shelly-Objekt im iobroker auch, dass eben keine Verbindung zum Gerät in diesen deep-sleep-Phasen existiert. Das wäre ja nicht tragisch, jedoch sehe ich auch nach längerem Zeitraum, in der das Gerät jetzt im iobroker existiert, keine entsprechenden sich ändernden Messwerte im Verlaufsdiagramm z.b. der Temperatur. Kriegt iobroker die kurzen "Wachphasen" einfach nicht mit?
Hat einer einen Lösungsvorschlag?@musicnrw sagte in Shelly Adapter - genereller Support:
Hat einer einen Lösungsvorschlag?
Check das mal (https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/protocol-mqtt.md)
Vor allem die RPC Einstellungen und die IP incl. Port

-
@musicnrw sagte in Shelly Adapter - genereller Support:
Hat einer einen Lösungsvorschlag?
Check das mal (https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/master/docs/de/protocol-mqtt.md)
Vor allem die RPC Einstellungen und die IP incl. Port

@mcm1957, genau die Einstellungen habe ich umgesetzt. Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht. Es kommen in der "wachen" Zeit leider auch keine Messwerte rein.
-
@mcm1957, genau die Einstellungen habe ich umgesetzt. Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht. Es kommen in der "wachen" Zeit leider auch keine Messwerte rein.
@musicnrw sagte in Shelly Adapter - genereller Support:
Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht
Hi, @mcm1957
dasselbe Problem habe ich mit dem batteriebetriebenen Shelly Smoke auch. Gibt es da eine Lösung?
Gruß,
Fuzzy -
@mcm1957, genau die Einstellungen habe ich umgesetzt. Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht. Es kommen in der "wachen" Zeit leider auch keine Messwerte rein.
@musicnrw sagte in Shelly Adapter - genereller Support:
Es kommen in der "wachen" Zeit leider auch keine Messwerte rein.
es kommen nur Messwerte rein wenn sie sich auch geändert haben ansonsten nicht auch wenn du ihn aufweckst falls der Wert sich nicht verändert hat wirst du auch nichts im Iobroker sehen. So ist das jedefalls bei mir.
du kannst ihn an ein Netzteil hängen dann kommen Daten öfters rein.
Bitte lesen https://kb.shelly.cloud/knowledge-base/shelly-h-t-gen3
hier ein Beispiel von mir

letzte Änderung war um 7.07 jetzt haben wir fast 9.00 Uhr. -
@musicnrw sagte in Shelly Adapter - genereller Support:
Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht
Hi, @mcm1957
dasselbe Problem habe ich mit dem batteriebetriebenen Shelly Smoke auch. Gibt es da eine Lösung?
Gruß,
Fuzzy@fuzzy1955 sagte in Shelly Adapter - genereller Support:
@musicnrw sagte in Shelly Adapter - genereller Support:
Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht
Hi, @mcm1957
dasselbe Problem habe ich mit dem batteriebetriebenen Shelly Smoke auch. Gibt es da eine Lösung?
Gruß,
FuzzyWelches Problem hast du auch?
Die batteriebetriebenen Geräte wachen nur kurzzeitig auf und gehen dann wieder in den seep sleep. Im deep-sleep Zustand trennen die Shellies die WLAN Verbindung um Energie zu sparen. Dies ist von Shelly so implementiert und aus Gründen der Batterielebensdauer auch so sinnvoll. Diese Trennung der WLAN Verbindung ist kein Problem sondern "per Design" so vorgesehen.
-
@mcm1957, genau die Einstellungen habe ich umgesetzt. Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht. Es kommen in der "wachen" Zeit leider auch keine Messwerte rein.
@musicnrw sagte in Shelly Adapter - genereller Support:
@mcm1957, genau die Einstellungen habe ich umgesetzt. Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht. Es kommen in der "wachen" Zeit leider auch keine Messwerte rein.
Also der shelly sollte wie folgt lt. Doku senden:
Measuring and reporting
On batteries
When running on batteries the Device behaves as follows:Wakes up every minute to do a measurement. If there is a 0.2 °C temperature or 3% humidity difference the screen updates. The default threshold for reporting is a change of 0.5 °C or 5%. If the change is less there will be no report sent.
If for two hours there is no report based on threshold values, the Device unconditionally (disregarding threshold values) reports its status to Shelly Cloud and other connected channels.
Due to self-heating a cool down period of 5 minutes is imposed. During this period the Device would not wake up at all.
On USB power supply
If powered via its USB port the Device will wake up every 5 minutes, perform a measurement, update its screen, unconditionally report to all connected channels, and sleep for 5 minutes.User initiated report
If the user presses the Reset button (behind the cover) the Device will wake up, perform a measurement, update its screen, unconditionally report to all connected channels, and sleep for 5 minutes.Wenn du auch beim Drücken des Reset Buttons keine geänderten Werte siehst dann stimmt was nicht - wobei du beachten musst dass die 5 Minuten jeden Update in der Zeit blockt. Sinnvoller Weise würde ich daher die Teperatur vor dem Drücken merkbar ändern (kurz warm anblasen od in den Kühlschrank legen).
Wenn da nichst kommt bitte
- gib mal die Adpater Version an die du benutzt
- aktiveiere das Log mit LEVEL DEBUG
Im Log muss der Connect des Shellies auftauchen. Weiters wird gelogged was er sendet. Prüf mal ob das ankommt oder ob der Shelly den ioBroker Host gar nicht erreicht. Und NEIN das Online Symbol sagt nichts darüber aus ob die MQTT Verbindung richtig eingestellt ist. Online / offline wird via ping / http geprüft. Also schau sicherheitshalber nochmal die IP und vor allem den Port den du im Shelly eingetragen hast genau an.
-
@fuzzy1955 sagte in Shelly Adapter - genereller Support:
@musicnrw sagte in Shelly Adapter - genereller Support:
Wenn ich am Shelly den Knopf (Reset-Button) kurz drücke, dmit er aufwacht, sehe ich das Gerät mit aktivem WLAN im iobroker. Aber das bleibt eben nur für die kurze Zeit, bis er wieder in den deep-sleep-Modus geht
Hi, @mcm1957
dasselbe Problem habe ich mit dem batteriebetriebenen Shelly Smoke auch. Gibt es da eine Lösung?
Gruß,
FuzzyWelches Problem hast du auch?
Die batteriebetriebenen Geräte wachen nur kurzzeitig auf und gehen dann wieder in den seep sleep. Im deep-sleep Zustand trennen die Shellies die WLAN Verbindung um Energie zu sparen. Dies ist von Shelly so implementiert und aus Gründen der Batterielebensdauer auch so sinnvoll. Diese Trennung der WLAN Verbindung ist kein Problem sondern "per Design" so vorgesehen.
@mcm1957 sagte in Shelly Adapter - genereller Support:
Dies ist von Shelly so implementiert und aus Gründen der Batterielebensdauer auch so sinnvoll
Ja, das ist mir klar. Das Problem ist: Ich bringe den batteriebetriebenen Shelly Smoke bei Rauchalarm nicht zum Reagieren.
-
@mcm1957 sagte in Shelly Adapter - genereller Support:
Dies ist von Shelly so implementiert und aus Gründen der Batterielebensdauer auch so sinnvoll
Ja, das ist mir klar. Das Problem ist: Ich bringe den batteriebetriebenen Shelly Smoke bei Rauchalarm nicht zum Reagieren.
@fuzzy1955 sagte in Shelly Adapter - genereller Support:
Ich bringe den batteriebetriebenen Shelly Smoke bei Rauchalarm nicht zum Reagieren.
... was heißt das denn genau. Gibt er von sich aus keinen Alarm bei Rauch?
-
@mcm1957 sagte in Shelly Adapter - genereller Support:
Dies ist von Shelly so implementiert und aus Gründen der Batterielebensdauer auch so sinnvoll
Ja, das ist mir klar. Das Problem ist: Ich bringe den batteriebetriebenen Shelly Smoke bei Rauchalarm nicht zum Reagieren.
@fuzzy1955 sagte in Shelly Adapter - genereller Support:
@mcm1957 sagte in Shelly Adapter - genereller Support:
Dies ist von Shelly so implementiert und aus Gründen der Batterielebensdauer auch so sinnvoll
Ja, das ist mir klar. Das Problem ist: Ich bringe den batteriebetriebenen Shelly Smoke bei Rauchalarm nicht zum Reagieren.
Damit wir alle vom selben Gerät reden:
Geht es um einen Shelly Smoke (GEN1) oder einen Shelly Smoke Plus (GEN2) ?An sich sollten beide supported sein.
Beim Gen 2 gilt dasseleb wie eben erst geschrieben - also bitte nochmals explizit die MQTT Daten prüfen.
Beim Gen 1 hängts davon ab ob du COAP oder MQTT benutzt. Bei COAP bitte sicherstellen dass unicast ausgewählt ist.Wenn da Daten nicht ankommen gilt auch hier:
Bitte ein DEBUG LOG erstellen und den Shelly aktivieren - ich weiß leider nicht wie man beim Smoke einen Testalarm auslösen kann (abgesehen von anrauchen oder Testspray). -
H Homoran hat dieses Thema am aufgespalten
