Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[hotspot_2]

Hallo zusammen,

ich habe einen ioBroker schon länger am laufen und habe auch zahlreiche Shellys in Betrieb. Nachdem der Shelly Adapter nicht allzuhäufig aktualisiert wird, was seine berechtigten Gründe hat, habe ich irgendwann mal auf NodeRed und mosquitto MQTT Server geschwenkt (@mickym hat da sehr geholfen!). Mittlerweile bin ich sehr großer NodeRED Fan und das lief immer alles wunderbar.

Vermutlich seit einem der letzten Shelly Firmwareupdates habe ich das Problem das sich Shellys immer wieder einschalten und ich wusste nicht warum. NodeRED analysiert, History Adapter verwendet und und... Das alles hat nichts aufgezeigt was die Einschaltungen erklärt. Erst als ich jetzt rsyslog verwendet habe bin ich einer Sache auf die Spur gekommen. Wenn ein Shelly sich ein neues WLAN sucht (weil sich der Pegel ändert) oder das WLAN verliert dann frägt er danach vom MQTT Server irgendwas ab das ihm dann mitteilt das er sich wieder einschalten soll. Man kann das auch sauber reproduzieren indem man einfach den Repeater im Haus zeith mit dem der Shelly gerade verbunden ist. Ziehen -> Licht an. Ich habe das bisher aber nur bei einzelnen Shellys festgestellt nicht bei allen.

Als erste Maßnahme habe ich den Shellys mitgegeben sich nicht ständig neue WLANs zu suchen. Das hilft schon mal sehr.

Ich würde aber trotzdem gerne das Problem lösen und zwar so das es nicht mehr vorkommt.

Der Shelly Support hat mir jetzten den Tipp gegeben retain und QOS zu überpüfen beim MQTT Server (denke ich). Bei mir fungiert der MQTT Adapter nur als Client im ioBroker wenn ich das noch richtig in Erinnerung habe.

Jetzt zu meiner Frage, nach der langen Erklärung, wie kann ich das überprüfen und wo?

Danke schon mal für eure Hilfe!

[BananaJoe]

@hotspot_2 In den Einstellungen des MQTT-Adapters:

[mickym]

In den mqtt-out Nodes darfst Du halt keine retain Nachrichten verschicken.

Wenn Du nichts eingibst, dann ist false der Standard. Wenn Du hier true eingetragen hast (also retain eingetragen hast), dann werden diese Nachrichten jedesmal wenn sich ein mqtt-Client verbindet diese Nachricht erneut geschickt. Das würde erklären, wenn sich Dein Shelly ein neues WLAN sucht, muss es sich ja auch erneut wieder mit dem mqtt-Broker verbinden. Wenn Du dann einen Einschaltbefehl als retain geschickt hast, dann wird das beim Wiederverbinden erneut geschickt. Und natürlich auch wie @BananaJoe sagt, auch vom Adapter keine retain Nachrichten schicken.
Wenn alles sauber ist, sollte auch das erneute Verbinden mit dem mqtt-Broker keine Nachrichten erzeugen.

Ich habe nur Gen1 Shellies - aber auch hier kannst Du das retain flag setzen. Das sollte man meiden (wobei man es bei den Geräten ggf. noch vertreten kann, aber ich komm ohne aus) und auch immer mit clean sessions beginnen, nach dem Wiederverbinden:

Du kannst das auch überprüfen, indem Du mqtt-IN Nodes auf topics setzt, die Du sonst selbst über mqtt-Out Node schickst. Wenn Du dann nach wiederverbinden sofort Nachrichten auf diesen Topics erhälst dann ist das ein Grund.

Wenn Du sicher gehen willst, dass Du keine retained Nachrichten in deinem mosquitto Broker hast - würde ich einfach die komplette mosquitto.db löschen oder wegsichern - mache ich auch manchmal, um wieder eine saubere Datenbank zu haben. Vorher natürlich mosquitto stoppen, dann die DB löschen oder wegsichern, dann mosquitto wieder starten.

Die mosquitto Datenbank befindet sich hier:

/var/lib/mosquitto $ ls
mosquitto.db

Wenn Du für ein einzelnes topic eine retain Nachricht löschen willst, musst Du einen leeren String an das topic schicken, aber wie gesagt - ich würde lieber mit einer sauberen DB anfangen.

[hotspot_2]

Super! Vielen Dank.

Ich habe jetzt mal QoS auf 1 gesetzt und Retain-Flag ausgeschalten. In Node Red sind alle MQTT Out Nodes so eingestellt das QoS und Retain einfach leer sind. Die Gen1 Shellys überprüfe ich noch alle und dann die mosquitto DB noch löschen.

Verbunden mit der Einstellungen das die Shellys nicht alle 60 Sekunden nach einem besseren WLAN suchen sollen sondern das nun gar nicht mehr machen sollte es dann klappen, denk ich.

[mickym]

@hotspot_2 wenn du über Node-red steuerst, dann ist der mqtt Adapter eigentlich ein reines Monitoring. Meines Erachtens fährt man mit den Standardeinstellungen ohne retain (da hat der mqtt Adapter meines Erachtens eh einen Bug) und einer frischen mqtt Datenbank am Besten.

[hotspot_2]

@mickym So hatte ich das auch verstanden mit dem MQTT Adapter.

Bedeutet das ich sollte die MQTT Out Nodes dann alle anpassen mir QoS 1 und retain false (ist ja standard). Den die Einstellungen im MQTT Adapter haben ja dann keinen Einfluss auf die MQTT Outs in Node Red.

[mickym]

@hotspot_2 Du brauchst in meinen Augen nicht auf QoS 1 in den mqtt-Out Nodes umstellen - Standard ist OK - wichtig ist nur dass das retain Flag nie gesetzt wird.

[hotspot_2]

@mickym Hi!

Ich habe mal wieder eine Frage. Ich hole mir ja per Node Red einige Werte der Shellys als Objekte in ioBroker rein.

Hast Du mir einen Tipp wie ich in Node.Red diese Berechnung hier umsetzen könnte (Blockly Variante).

Ich würde gerne den täglichen Energieverbrauch von ein paar Shellys, sind alle schon in Node Red drin weil ich den Switch Status oder den momentan Energieverbrauch schon so hole, berechnen.

Danke schon mal.

[mickym]

@hotspot_2 Nun diese Dinge musst Du selbst implementieren - da haben sie dem NodeRed Adapter gegenüber Blockly benachteiligt.

Also einfach selbst Datenpunkte erstellen für vorherigen Wert, letzte Änderungen und vorherige letze Änderung. Getriggert von einer aktualisierung des Leistungspunktes.

Ansonsten kannst Du ja mal schauen, ob Dir dieser Subflow als Basis weiterhilft, da habe ich Zählerstände und Verbräuche in verschiedenen Zeiten ermittelt - allerdings, wenn der Zähler von den Shellies plötzlich auf 0 geht, dann stimmen die Berechnungen nicht - aber vielleicht kannst Du ja den Subflow noch etwas verbessern.

https://forum.iobroker.net/post/1148029