nach FW Update Shelly 1 Probleme

[mcm1957]

@andibr
hast du den Shelly 1 (GEN1 ) wirklich bewußt via MQTT eingebunden?

Wenn ja, welche MQTT QOS hast du eingestellt. Versuch QOS 0 oder 1, bei 2 sind Probleme bekannt da der Shelly QOS 2 nicht unterstützt.

Ansonsten verwend die Shelly GEN1 mit COAP Anbindung

[andibr]

@mcm1957
Grundsätzlich habe ich alle Shelly via den Shelly-Adapter eingebunden, und dort ist folgendes eingestellt:

auf dem Shelly 1 ist folgendes:

ja ist bei mir der Port 1882, weil ich auf dem 1883 noch den Iobroker MQTT Adapter am drehen habe für meine Nuki. Es ist mir bewusst, das es halt wirklich "alte" Shelly sind.

Ich verstehe den Log-Eintrag so, dass der Shelly irgend was sendet, womit der Iobroker nichts anfangen oder kein Datenpunkt dazu hat. Ich habe nur noch nicht begriffen was das sein könnte.

Edit:
Habe da gerade einen sehr merkwürdigen Eintrag im Log gefunden:

2025-05-10 13:12:39.564  - warn: shelly.1 (76499) [MQTT] Unable to publish message to 192.168.130.216 (shelly1 / shelly1-3494547256D9 / SHSW-1#3494547256D9#1) - mqtt prefix was not set but is required for this message: shellies/<mqttprefix>/relay/0/command = off
2025-05-10 13:12:39.564  - warn: shelly.1 (76499) [MQTT] Unable to publish message to 192.168.130.216 (shelly1 / shelly1-3494547256D9 / SHSW-1#3494547256D9#1) - mqtt prefix was not set but is required for this message: shellies/<mqttprefix>/relay/0/command = off

Irgendwie scheint es da ein Begriff "shellies" zu geben? Woher der kommt und was das ist, da habe ich keine Ahnung, ich wüsste nicht das ich das geschrieben hätte.

Wenn ich im Adapter auf "QoS = 0" umstelle bleiben die Einträge aus, aber die Relais reagieren auch nicht mehr immer.

[haselchen]

@andibr

Warum so kompliziert ?
Im Adapter COAP einstellen , in der WebGui des Shelly die IP des Iobrokers eintragen (Unicast).
Fertig.
Ich verstehe das rumgeeier mit MQTT nicht.
Ab GEN2 gehts nur noch so, aber bei GEN1 ist das quasi PlugandPlay.

[andibr]

@haselchen
Das ist weder kompliziert noch rumgeeier sondern schlicht und einfach "alles im gleichen Adapter". Das ganze tritt auch erst seit kurzem auf, ich habe viele Shelly hier mit Einsatz, quer durchs ganze Programm und bei keinem dieser anderen trat je ein Problem auf.

Das du nicht geschrieben hast, ich solle es via Shelly Cloud machen verwundert mich noch ein wenig. Aber was soll's MQTT gehört die Zukunft, darum mache ich es damit.

[haselchen]

@andibr

Wenn es für Dich weder kompliziert noch sonst was ist, warum postet Du dann bei Einsteigerfragen
Aber mach wie Du denkst.
@mcm1957 hat Dir das Gleiche geraten wie ich.
Du kriegst das schon hin .

[andibr]

@haselchen
weil ich weitere Shelly 1 (Gen 1) habe mit genau den gleichen Einstellungen und die machen das nicht.
Wo soll ich den sonst fragen?

[mcm1957]

@andibr

Also jetzt mal zur Klarstellung:

a) Es ist voll OK und sinnvoll alles mit dem Shelly Adapter zu machen.
b) Ich kenne keinen Adapter der via Shelly Cloud operiert. Insofern kann dir das auch niemand sinnvoll empfehlen (und hat auch niemand empfohlen)
c) Der Shelly Adapter kann GEN1 Devices via COAP und via MQTT einbinden. Wird ein Shelly GEN 1 via MQTT eingebunden dann kann dieser Shelly nicht mit der Shelly Cloud kommunizieren. (Hier nicht relevant). 90% der User verwenden für Shellioes GEN1 COAP. Das soll aber nicht heißen, dass die an sich supportete MQTT Verbindung nicht funktionioert. Auch COAP ist lokal ohne Cloud.
d) Shellies GEN 2 oder neuer müssen MQTT verwenden
e) Um COAP für GEN1 und MQTT für GEN2 zu verwenden musst du 2 Instanzen des Shelly Adapters aufsetzen.

Ergo:
Ich und haselchen wollten eigentlich nur drauf hinweisen, dass für Shellies GEN 1 typisch COAP verwendet wird.

Und nun zu deinem Problem:
Welche Shellies (GEN1) funktionieren mit MQTT bei dir und welche Firmware haben die.
Haben die Shellies die jetzt nicht funktionieren vor dem FW Update mit denselben Einstellungen funktioniert?
Welche Version des Adapters läuft bei dir?
Welche Version des js-controllers und welche Node.js Version?

EDIT:
You did not show the QOS setting of your ioBroker instance. According to log it seems to be set to 1

[MQTT] Send state to 192.168.130.216 (shelly1 / shelly1-3494547256D9 / SHSW-1#3494547256D9#1) with QoS 1: shellies/shelly1-3494547256D9/relay/0/command = off (3)

But your screenshot of the shelly shows max QOS 0

Please check / compare with working shellies.

[andibr]

@mcm1957
Danke für die klärenden Worte, ob ich mit der Wahl "Einsteigerfragen" richtig bin, weiss ich nicht, vieleicht nützt jemandem diese Diskussion ja mit dem gleichen Problem. Denke nicht, dass ich der einzige mit diesen Problemen bin.
Das die wenigsten Shelly mit MQTT und der Shelly Cloud zusammen funktionieren ist mir auch klar, dass war eigentlich auch eher die Aussage die ich schon vernommen habe, weil viele Leute ein lokales System vermeiden wollen.

Ich habe gestern für die Shelly 1 eine 2.Instanz eingerichtet, und die GEN 1 mit COAP dort angemeldet, was aber zu dieser Meldung hier führt:

2025-05-11 11:07:29.721	error	[http controlFunction] Error in function state.coap.http_cmd of state SHSW-1#34945470F361#1.Relay0.Switch for 192.168.130.215 (shelly1 / shelly1-34945470F361 / SHSW-1#34945470F361#1): AxiosError: timeout of 8000ms exceeded

Aber die Meldungen mit dem "unbekannten Eintrag" sind seither ausgeblieben.

Ich habe rasch bei einem Shelly1 (GEN1) nachgeschaut der hat die ID 116CBC (1141948) und die FW: 20230913-112003/v1.14.0-gcb84623. Dieser ist noch älter als diese welche mir Probleme bereiten, den dieser ist seit Jahren bei einem Lichtschalter für die Deckenlampe eingebaut und funktioniert einwandfrei via MQTT.

In der Instanz mit dem Shelly-MQTT ist "QoS 1" eingestellt.

Aus allen diesen Gründen gehe ich davon aus, dass ich da irgendwelche Shelly1 (GEN1) habe die irgendwie nicht richtig funktionieren oder sich nicht mit dem Iobroker verständigen möchten. Ich habe sowohl den "default Reset" wie auch den "Hardware Reset" schon mehrmals gemacht, es sind aber keine Veränderungen aufgetreten.

Somit werde ich diese mit dem merkwürdigen Verhalten durch neue ersetzen (Sind leider nicht die ersten 230V-Typen die sich bei mir verabschiedet haben).

Edit: Shelly-Adapterversion v9.2.0, Node.js v20.19.1, NPM 11.3.0
Edit2: beim Shelly der funktioniert ist "Max. QoS-0", habe ich aber auch bei den merkwürdigen so übernommen.

[Homoran]

@andibr sagte in nach FW Update Shelly 1 Probleme:

Denke nicht, dass ich der einzige mit diesen Problemen bin.

das ist aber nicht Sinn der Einsteigerseiten!

siehe
https://forum.iobroker.net/topic/59411/hinweise-zu-dem-unterforum-einsteigerfragen/1

und
https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1

[Homoran]

@andibr sagte in nach FW Update Shelly 1 Probleme:

NPM 11.3.0

selbst installiert?
das ist nicht die passende Version.

Wird aber nicht unbedingt der Grund für dein Problem sein

[wendy2702]

@andibr sagte in [nach FW Update Shelly 1 Probleme]

Edit: Shelly-Adapterversion v9.2.0, Node.js v20.19.1, NPM 11.3.0

Unabhängig von deinem Shelly Problem solltest du deine Node und NPM Installation korrigieren.

Ungerade NPM Versionen sind nicht offiziell freigegeben und Entwickler Versionen die verschiedene ungewünschte Nebenwirkungen haben können.

[Thomas Braun]

@wendy2702 sagte in nach FW Update Shelly 1 Probleme:

Ungerade NPM Versionen sind nicht offiziell freigegeben und Entwickler Versionen die verschiedene ungewünschte Nebenwirkungen haben können.

Nein, gilt nicht für npm sondern für nodejs.
Ein zu nodejs beigepacktes npm kann auch ungerade sein. Allerdings kommt nodejs=20.19.1 nicht mit npm=11.x sondern mit einem npm=10.x daher. Da ist also irgendwas irgendwie händisch gemacht worden.

Ich würde nodejs sauber neuinstallieren:

iob stop
sudo apt update
sudo apt install --reinstall nodejs
iob start

[da_Woody]

@andibr

die ID 116CBC (1141948)

noch 6 stellig. da gibts inzwischen oft probs.
http://<ip vom shelly>updentifyid
musst nur nachher wieder neu einrichten.

[wendy2702]

@thomas-braun dann so rum. Hatte mir noch was mit ungerade im Kopf

[mcm1957]

@Homoran
schieb das Thema gern in allgemein damis Nebenthema Einsteiger erledigt ist.

@w00dy
ja die kurzen ids machen öftwr Probleme. Meines Wissens nach aber nur bei der cloud da es schlicht so viele shellies gibt dass die kurze id icht mehr eindeutig war. sollte aber fürlokales mqtt irrelevant sein.

[andibr]

@mcm1957
Danke, bin gerade unterwegs, werde es aber probieren.
Zur installation: ich habe da eigentlich nichts von "von hand" dem Iob zu gefügt. Ausser immer mal das Debian Update gemacht, kann das von dort kommen?
Das mit der Shelly ID ist mir ganz neu, werde ich aber sicher bei diesen 3 stk probieren bevor ich sie definitiv wegwerfe.
Danke, schönen Abend

[Homoran]

@andibr sagte in nach FW Update Shelly 1 Probleme:

ich habe da eigentlich nichts von "von hand" dem Iob zu gefügt

npm ist ja auch kein Bestandteil von iob, sondern der node package manager

@andibr sagte in nach FW Update Shelly 1 Probleme:

immer mal das Debian Update gemacht, kann das von dort kommen?

nicht von alleine, da muss schon was händisch eingegeben worden sein.

[Thomas Braun]

@andibr sagte in nach FW Update Shelly 1 Probleme:

ich habe da eigentlich nichts von "von hand" dem Iob zu gefügt. Ausser immer mal das Debian Update gemacht, kann das von dort kommen?

Bei sauberer Konfiguration nicht.

[da_Woody]

@mcm1957 sagte in nach FW Update Shelly 1 Probleme:

ja die kurzen ids machen öftwr Probleme. Meines Wissens nach aber nur bei der cloud da es schlicht so viele shellies gibt dass die kurze id icht mehr eindeutig war. sollte aber fürlokales mqtt irrelevant sein.

da hast du natürlich recht. hatte gestern massive netzwerkprobleme und hab nicht genug nachgedacht.
schaden kanns trotzdem nicht.

@andibr sorry, duch das chaos gestern hab ich den falschen code gepostet!
richtig ist: IP/longifyid

[andibr]

Hallo zusammen
kurze Rückmeldung zur ganzen Thematik: Ich habe jetzt alle meine Shelly 1 (GEN1), dem "longifyid"-Prozess unterzogen (habe da noch ein paar RGBW2 die auch noch zu machen wären), und auch gleich geschaut das alle die gleiche Firmeware drauf haben:

Current version: 20230913-112003/v1.14.0-gcb84623

Das merkwürdige an der ganze Sache ist folgendes:

• ich habe ein paar (zb. den oben erwähnten fürs Licht), welcher sowohl mit der kurzen und nun auch mit der langen ID einwandfrei mit dem Iob-Shelly Adapter mit MQTT funktionieren. Da hat die lange ID gar nicht geändert ausser das ich die ganzen Alias neu machen musste

• die Shelly1 welche ich für den Heizstab im Pufferspeicher verwende kommen auch mit der langen ID nicht mit MQTT zurecht. Die haben aber auch mit dem COAP/CoIoT ihre Mühe, d.h. manchmal schaltet das Relais auf Befehl und manchmal auch nicht.

• bei den einen musste ich alle Daten neu eingeben, bei einigen wurden diese Daten übernommen. Das interessante ist, dass 2stk der ganz alten die EInstellungen verloren haben und bei einem sind sie erhalten geblieben. Auch bei einem der beiden die MQTT können blieben sie erhalten. Kann es sein, dass da andere Chip oder andere Bootloader verbaut sind?

Da ich nicht ganz verstehe warum die einen gehen und die anderen nicht frage ich mich, was da anderes noch sein könnte?
Ich habe im gleichen Raum auch noch einen ESP8266 (Wemos D1 mini) mit etlichen 1-Wire ds18B20 Temperaturfühler an mehreren GPIO dran und somit rein theoretisch den gleichen Chip im Einsatz. Die Shelly geben beim rssi einen Wert von ca. -72dBm raus, der ESP einen Wert von -66dBm. Die Shelly in der Waschküche nebenan einen Wert von -70dBm, also sind alle in etwa auf dem gleich Niveau. Auch der von dem Deckenlicht im 2.OG (welcher seit Einrichten mit MQTT läuft) liegt beim Wert von -67dBm.

Aus den ganzen Werte schliesse ich, dass es kaum direkt am WiFi Signal liegen sollte. Ich weiss nun auch das man die GEN1 mit COAP verwenden sollte, aber wenn es trotzdem nicht zuverlässig ist bleibt wohl wirklich nur der Ersatz dern GEN1 durch neue?

Edit:
Ich habe gerade festgestellt: wenn ich den Shelly via seiner eigenen Webseite schalte bekomme ich in den Datenpunkte diese Änderung angepasst, aber eine Statusänderung in den Datenpunkten wird nicht an den Shelly weitergegeben.