MQTT und Shelly

mcm1957

Also die Fehletsituation hatte ich noch nie gesehn.

Bist du mal sicher dass die ip .127 der Shelly ist? Nicht dsss da irgendwas anderes sendet...

Und ja - der Adapter erwartet pure tcp ohne tls

Ansonsten bitte Screenshot der SHELLY TCP Einstellung.

Die undefined steh übrigends deshalb dort weil der Shelly keine Verbindung aifgebaut hat und daher kein vonnect packetäl geschickt hat.

Homoran

@mcm1957 sagte:

Bist du mal sicher dass die ip .127 der Shelly ist?

Ja, und die .126 auch

Beide das selbe, aber ich glaube ich komme der Sache näher

Nach Firmwareupdate

shelly.0
2026-05-06 15:46:29.265	debug	Redis Objects: Use Redis connection: 0.0.0.0:9001

shelly.0
2026-05-06 15:46:29.303	debug	Objects client ready ... initialize now

shelly.0
2026-05-06 15:46:29.304	debug	Objects create System PubSub Client

shelly.0
2026-05-06 15:46:29.305	debug	Objects create User PubSub Client

shelly.0
2026-05-06 15:46:29.409	debug	Objects client initialize lua scripts

shelly.0
2026-05-06 15:46:29.423	debug	Objects connected to redis: 0.0.0.0:9001

shelly.0
2026-05-06 15:46:29.471	debug	Redis States: Use Redis connection: 0.0.0.0:9000

shelly.0
2026-05-06 15:46:29.502	debug	States create System PubSub Client

shelly.0
2026-05-06 15:46:29.503	debug	States create User PubSub Client

shelly.0
2026-05-06 15:46:29.606	debug	States connected to redis: 0.0.0.0:9000

shelly.0
2026-05-06 15:46:29.654	debug	Plugin sentry Initialize Plugin (enabled=true)

shelly.0
2026-05-06 15:46:29.856	info	starting. Version 10.6.1 in /opt/iobroker/node_modules/iobroker.shelly, node: v22.22.2, js-controller: 7.0.7

shelly.0
2026-05-06 15:46:30.082	info	Starting in MQTT mode. Listening on 0.0.0.0:1883 (QoS 0)

shelly.0
2026-05-06 15:46:30.089	debug	[MQTT Server] Started listener on 0.0.0.0:1883

shelly.0
2026-05-06 15:46:32.908	debug	[MQTT Server] New connection from 192.168.138.127

shelly.0
2026-05-06 15:46:32.914	info	[MQTT] Client Error: (undefined / undefined / undefined) (Error: Cannot parse protocolId)

shelly.0
2026-05-06 15:46:32.915	info	[MQTT] Client Close: (undefined / undefined / undefined) (false)

shelly.0
2026-05-06 15:46:32.915	debug	[BaseClient] Destroying (undefined / undefined / undefined)

shelly.0
2026-05-06 15:46:32.915	debug	[MQTT] Destroying

shelly.0
2026-05-06 15:46:32.916	debug	[MQTT Server] Close for 192.168.138.127 ((undefined / undefined / undefined))

shelly.0
2026-05-06 15:46:37.043	debug	[MQTT Server] New connection from 192.168.138.126

shelly.0
2026-05-06 15:46:37.046	debug	[MQTT] Client connected: {"cmd":"connect","retain":false,"qos":0,"dup":false,"length":90,"topic":null,"payload":null,"protocolId":"MQTT","protocolVersion":4,"will":{"retain":true,"qos":0,"topic":"shelly1minig3-34b7dac53ffc/online","payload":{"type":"Buffer","data":[102,97,108,115,101]}},"clean":true,"keepalive":60,"clientId":"shelly1minig3-34b7dac53ffc","username":"iobroker"}

shelly.0
2026-05-06 15:46:37.046	error	[MQTT] Wrong MQTT authentication of client "shelly1minig3-34b7dac53ffc": No password transmitted by client

shelly.0
2026-05-06 15:46:37.083	debug	[MQTT Server] End for 192.168.138.126 ((shelly1minig3 / shelly1minig3-34b7dac53ffc / shelly1minig3#34b7dac53ffc#1))

shelly.0
2026-05-06 15:46:37.085	info	[MQTT] Client Close: (shelly1minig3 / shelly1minig3-34b7dac53ffc / shelly1minig3#34b7dac53ffc#1) (false)

shelly.0
2026-05-06 15:46:37.085	debug	[BaseClient] Destroying (shelly1minig3 / shelly1minig3-34b7dac53ffc / shelly1minig3#34b7dac53ffc#1)

shelly.0
2026-05-06 15:46:37.085	debug	[deviceStatusUpdate] shelly1minig3#34b7dac53ffc#1: false

shelly.0
2026-05-06 15:46:37.085	debug	[MQTT] Destroying

shelly.0
2026-05-06 15:46:37.085	debug	[MQTT Server] Close for 192.168.138.126 ((undefined / undefined / undefined))

shelly.0
2026-05-06 15:46:40.082	debug	[firmwareNotify] Starting firmware check on every device

shelly.0
2026-05-06 15:46:41.530	debug	[MQTT Server] New connection from 192.168.138.127

shelly.0
2026-05-06 15:46:41.531	info	[MQTT] Client Error: (undefined / undefined / undefined) (Error: Cannot parse protocolId)

shelly.0
2026-05-06 15:46:41.532	info	[MQTT] Client Close: (undefined / undefined / undefined) (false)

shelly.0
2026-05-06 15:46:41.532	debug	[BaseClient] Destroying (undefined / undefined / undefined)

shelly.0
2026-05-06 15:46:41.532	debug	[MQTT] Destroying

shelly.0
2026-05-06 15:46:41.532	debug	[MQTT Server] Close for 192.168.138.127 ((undefined / undefined / undefined))

shelly.0
2026-05-06 15:46:45.173	info	Got terminate signal TERMINATE_YOURSELF

shelly.0
2026-05-06 15:46:45.486	debug	[onUnload] Closing adapter

shelly.0
2026-05-06 15:46:45.486	debug	[onUnload] Stopping MQTT server

shelly.0
2026-05-06 15:46:45.487	debug	[BaseServer] Destroying

shelly.0
2026-05-06 15:46:45.487	debug	[MQTT Server] Destroying

shelly.0
2026-05-06 15:46:45.487	info	terminating

shelly.0
2026-05-06 15:46:45.488	debug	Plugin sentry destroyed

shelly.0
2026-05-06 15:46:45.488	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

shelly.0
2026-05-06 15:46:45.488	debug	[MQTT Server] Closing listener

shelly.0
2026-05-06 15:46:45.674	info	terminating

erscheint zusätzliches!

Aber ich hatte vergessen das Passwort im shelly neu einzugeben.

Danach das alte Bild.

Gibt es verbotene ze7chen für das Passwort?

Homoran

Homoran sagte:

Gibt es verbotene ze7chen für das Passwort?

BINGO!!

shelly.0
2026-05-06 16:01:34.122	info	[MQTT] Device with client id "shellypmminig3-dcda0ce81e7c" initialized.

shelly.0
2026-05-06 16:01:34.109	info	[MQTT] Device with client id "shelly1minig3-34b7dac53ffc" initialized.

Nach Änderung des Passworts ohne Sonderzeichen!

@axel hätte uns doch mal das debug-log zeigen sollen

mcm1957

Verbotene Zeichen sind mir nicht bekannt. Da das aber offensichtlich ein Problem ist erstell bitte ein issue und gib bekannt welches Passwort Probleme macht. Natülich nicht deins aber ein Muster.

Dann kann ichcschaun ob da ein Fehler im Adapter vorluegt oder ein Bug im Shelly.

Danke

crunchip

@Homoran sagte:

Gibt es verbotene ze7chen für das Passwort?

haben wir doch eigentlich überall, sprich ist doch überall das generelle Problem rund um iobroker

edit
das # im Passwort: Das Hash-Zeichen ist in MQTT-URLs ein Sonderzeichen (URL-Fragment-Trenner) und wird von manchen Clients abgeschnitten – alles nach dem # geht verloren, was dazu führt, dass ein falsches oder gar kein Passwort übermittelt wird

@, :, / und ähnliche URL-Sonderzeichen: Werden in MQTT-Verbindungs-URLs (z. B. mqtt://user:pass@host) als Trennzeichen interpretiert und zerschießen die Credentials

Umlaute und ß: Können je nach Firmware-Implementierung des Geräts zu Encoding-Problemen führen, da manche Firmware-Stacks keine UTF-8-Credentials erwarten

Homoran

@crunchip sagte:

haben wir doch eigentlich überall, sprich ist doch überall das generelle Problem rund um iobroker

Nöö, ich hab bisher überall Sonderzeichen in Passwörtern.
Wird ja auch eigentlich immer empfohlen, wenn nicht sogar als Bedingung gesetzt.

Wäre jetzt nur noch interessant ob das bei @axel auch zutrifft.

Homoran

@crunchip sagte:

möglichwerweise das #

Editeur 😉

Nö, diesmal der Dollar

crunchip

@Homoran war noch nicht fertig, aber jetzt :-)

crunchip

@Homoran sagte:

Wäre jetzt nur noch interessant ob das bei @axel auch zutrifft.

möglich, ans Passwort hatte ich schon gedacht, da aber @mcm1957 meinte

@mcm1957 sagte:

Das Erkennen des Shellies ist erst Step 2. Zuerst muss sich der Shelly zum ioBroker connecten. Und da spielt mal nur IP und Port mit - und das Netzwerk. Selbst wenn User / Passwort falsch sind steht das im ioBroker Log. Und ebenso wenn der Typ manipuliert sein sollte.

hab ichs dann verworfen

Homoran

@crunchip sagte:

Selbst wenn User / Passwort falsch sind steht das im ioBroker Log

Das hat mich auch ausgebremst.
Da wusste ich noch nicht, dass der Loglevel per default auf WARN steht.

mcm1957

Sorry wenn ich mich via Handy nicht an Grundsatzdiskussionen beteilige.

Ich möchte drumm bitten konkret bekannte Sonderzeichen im mqtt Passwort die ein Problem machen via Issue zu melden.

Ich sehe es als Bug wenn ein Passwort das eingebbar ist nicht funktioniert. Ob das ein Bug im Adapter od im Shelly oder sonstwo ist muss man klären.

mcm1957

@crunchip sagte:

@Homoran sagte:

Gibt es verbotene ze7chen für das Passwort?

haben wir doch eigentlich überall, sprich ist doch überall das generelle Problem rund um iobroker

Das ist m.E. so nicht richtug. Wenn dir bei einem Adapter sowas auffällt bitte ein Issue erstellen.

mcm1957

@Homoran sagte:

@crunchip sagte:

Selbst wenn User / Passwort falsch sind steht das im ioBroker Log

Das hat mich auch ausgebremst.
Da wusste ich noch nicht, dass der Loglevel per default auf WARN steht.

Der Defaultwert des Adapters ist INFO. Wenn ein User den umstellt lann der Adapter nichts machen ...

Homoran

@mcm1957 sagte:

Der Defaultwert des Adapters ist INFO. Wenn ein User den umstellt lann der Adapter nichts machen

Sorry da muss ich widersprechen, ich hab den Adapter heute erstmalig installiert, um für diesen Thread helfen zu können, die dann angelegte Instanz stand auf WARN

axel

Also, habe den Shelly auf Werkseinstellungen zurückgesetzt und neu verbunden. Nun tatsächlich Verbindung. Läuft wie erwartet. Ich denke, war ein Bug im Shelly. Habe den neu ausgepackt, Strom abgeschaltet, eingebaut, Strom eingeschaltet, über 192.168.33.1 verbunden, Verbindung mit WLAN hergestellt. Gerät wollte Update machen, habe ich ausgeführt. Ich kann mich nicht mehr daran erinnern, an welcher Stelle das vorkam. Auf jeden Fall läuft das jetzt.

Auf jeden Fall, Dank an Euch alle!

Gibt das häufiger derartige Problematiken mit Shelly? Ich überlege tatsächlich, weitere Geräte in Shelly auszuführen, statt in HM.

Nochmal vielen Dank.

Liebe Grüße

Axel

crunchip

@axel soweit mir bekannt, kann es hin und wieder vorkommen, das bei Ersteinrichtung mal irgendwas "verschluckt" wird, daher dann nochmal das Gerät zurücksetzen und neu einbinden, sollte aber in der Regel die Ausnahme sein

Homoran

@axel sagte:

Ich überlege tatsächlich, weitere Geräte in Shelly auszuführen, statt in HM.

Abgesehen von dem hier behandelten Problem hat @crunchip das richtig geradegeückt.

Zu dem zweiten, impliziten, Teil deiner Frage möchte ich auch etwas sagen:
Ich selber habe seit 15 Jahren Homematic und bin sehr zufrieden.

Heute habe ich erstmalig einen shelly installiert, den ich mal geschenkt bekommen hatte.

Shelly kam für mich nicht in Frage, weil das WLAN Netz eh überfüllt ist. Außerdem hat 2.4GHz eine geringere Reichweite und Durchdringung bei massiven Baustoffen als die 868MHz von Homematic.

Was mich an Shelly interessiert ist die extrem kleine Bauform, die es hoffentlich ermöglicht, diese Aktoren oder Sensoren (PM) direkt in die Dose zu setzen, so dass die Zwischenstecker entfallen können.

crunchip

@Homoran sagte:

direkt in die Dose zu setzen

aber auch nur, sofern du eine tiefe Dose und keine extra Kabel darin hast, sonst wird es wirklich eng

Samson71

@axel
Mit Shelly generell gibt es keine Probleme und man kann sie mittels CUxD sogar in Homematic integrieren.

Ich habe mich damals bewusst und gewollt der HMiP-Schiene verweigert, weil mir das Key-Handling mit den Servern von EQ3 nicht gefallen hat und weil ich aus baulichen Gegebenheiten ohnehin schon mehrere HM-LAN-Gateways im Einsatz habe. Da wollte ich für IP nicht nochmal die gleiche Infrastruktur daneben stellen.

Auch ein Tausch der CCU/Raspimatic ist so mit einfachem Einspielen eines Backups sofort erledigt.

Ich mit Unifi und insgesamt 5 großen AP's ein extrem gut ausgebautes WLAN und habe daher neben Sonoff/Tasmota nur weiter mit Shelly ergänzt.

Samson71

@crunchip sagte:
aber auch nur, sofern du eine tiefe Dose und keine extra Kabel darin hast, sonst wird es wirklich eng

Sofern der Eli nicht zu sehr beim Eingipsen gegeizt hat, helfen ein Hammer und ein nicht zu großer "scharfer" Schraubendreher. Damit lässt sich der Dosenboden sauber raustrennen und der dahinter liegende Gips vorsichtig entfernen. Meist kann man so nochmal gut 2cm in der Tiefe gewinnen.

Community Forum

NEWS

MQTT und Shelly

Support us

265

33.0k

83.2k

1.3m