wichtiges UPDATE für controller 7.2.2 im stable

[crunchip]

@Homoran sagte:

kommt aber nicht an die protocoll ID ran, weil er wohl 3 Parameter nicht hab.

eben, soweit ich nachgelesen habe

Der Fehler Cannot parse protocolId bedeutet exakt: Der MQTT-Broker hat eine TCP-Verbindung erhalten, konnte aber das erste Byte-Feld des CONNECT-Pakets nicht als gültige MQTT-Protocol-ID lesen. Der Shelly ist also netzwerkseitig erreichbar (TCP klappt), aber das, was er danach schickt, ist kein valides MQTT-Paket

übrigens tls darf nicht aktiv sein

@Homoran sagte in MQTT und Shelly:

jungfräulichen pm mini g3

mit welcher Firmware?
bei bestimmten Gen3-Firmwareversionen gab es tatsächlich Bugs im MQTT-Stack

[Homoran]

@crunchip danke!

In der Zwischenzeit habe ich den 1miniG3 wieder unter Strom gesetzt, bei dem hatte ich upgedatet, aber tls noch an

Beim pm mini ist es umgekehrt

Stay tuned

[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