NEWS
MQTT und Shelly
-
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
-
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 terminatingerscheint zusätzliches!
Aber ich hatte vergessen das Passwort im shelly neu einzugeben.
Danach das alte Bild.
Gibt es verbotene ze7chen für das Passwort?
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
-
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
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.
-
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 war noch nicht fertig, aber jetzt :-)
-
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.
Wäre jetzt nur noch interessant ob das bei @axel auch zutrifft.
möglich, ans Passwort hatte ich schon gedacht, da aber @mcm1957 meinte
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
-
Wäre jetzt nur noch interessant ob das bei @axel auch zutrifft.
möglich, ans Passwort hatte ich schon gedacht, da aber @mcm1957 meinte
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
-
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.
-
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
-
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 ...
-
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 ...
-
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
-
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
@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
-
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
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.
-
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.
-
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
@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.
-
@crunchip sagte:
aber auch nur, sofern du eine tiefe Dose und keine extra Kabel darin hast, sonst wird es wirklich engSofern 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.
-
Also, nochmal danke. Ich benutze den 2em nur, weil es bei HM nichts vergleichbares gibt.
Ansonsten ist alles HM-IP und es läuft wirklich stabil. Ein kleiner PI auf dem Dach als Zentrale und alles ist ok.
Dazu einen ioBroker auf einer VM, läuft auch prima. Integiert wird ebenfalls (je auf dedizierten VM's) SQL-Server und Grafana. Alles Bestens.
Einen schönen Abend für alle.
-
Also, nochmal danke. Ich benutze den 2em nur, weil es bei HM nichts vergleichbares gibt.
Ansonsten ist alles HM-IP und es läuft wirklich stabil. Ein kleiner PI auf dem Dach als Zentrale und alles ist ok.
Dazu einen ioBroker auf einer VM, läuft auch prima. Integiert wird ebenfalls (je auf dedizierten VM's) SQL-Server und Grafana. Alles Bestens.
Einen schönen Abend für alle.
-
Mein aktuelles Projekt ist es, eine Haus ki aufzubauen. In einem ersten Schritt entwickle ich ein KPI System für die verschiedenen Bereiche, Heizung, Strom, und so weiter. In einem zweiten Schritt baue ich dann einen eigenen lokalen Chatbot, auf, der in der Lage sein wird, Anfragen über das Haus und seine Zustände zu beantworten beziehungsweise Zustände zu steuern. Ist sehr herausfordernd, mal sehen, wie lange ich dafür brauche. :-)
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden