Gelöst: MQTT / Sonoff Geräte mit Eigenleben

[slor]

Hallo Zusammen,

in den letzen Tagen ist mir aufgefallen, dass meine Sonoff Geräte sich häufig von selbst ein und aus schalten. Manchmal blinken sie nur kurz auf, manchmal brennt das Licht für Stunden.
Ich habe noch nicht viel geforscht. Ich bin mir ziemlich sicher, dass es mit Wlan Abbrüchen, bzw. Netzwerkaussetzern zu tun hat.

Kann man bei MQTT / Tasmota etwas konfigurieren, dass die Geräte nichts tun, wenn die Verbindung zum MQTT unterbrochen, bzw. wieder hergestellt wird?

Sebastian

[fstefan1960]

Also prinzipiell gibt es ja die "retained" und "last will"- Optionen.

"Retained" heißt, dass der letzte übergebene Wert solange gültig sein soll, bis ein neuer kommt.
"Last Will" ist ein Wert, der dann greift, wenn der Publisher "gestorben" ist.

Damit sollten Verbindungsabbrüche eben genau überbrückbar sein.

[slor]

Lwt ist auf den Sonoffs vordefiniert. Da wird der Status offline gesendet.
Retained habe ich jetzt Mal auf meinen Sonoffs definiert. War vorher nur auf Fhem Seite gesetzt.  Sieht schon stabiler aus.

[slor]

So, hab das verifiziert. Sobald ich das WLAN abschalte schalten die Relais. Der Basic an aus innerhalb einer Sekunde. Der s20 an oder aus relativ willkürlich.
Im Fhem Log sehe ich auch zu dem Zeitpunkt eingehende publishing's. Da die Geräte sich selbst auch via Mqtt schalten passt das.
Gibts Optionen in der Firmware die das Verhalten beeinflussen?

[slor]

Ich habe noch eine Vermutung... Ich schalte die Sonoffs mit einem Toggle. In Fhem ist das retain flag gesetzt. Nun vermute ich, dass der Sonnoff beim reconnect einfach das Toggle noch mal ausführt. Hab retain mal abgestellt.

[slor]

so, Lösung gefunden. Auf dem Mosquitto MQTT Broker war persistence auf true gesetzt.

Auf fals gesetzt und seit zwei Tagen keine Probleme mehr.

[Rince]

Schön, dass es läuft.
Das Thema Persistence habe ich nicht im Wiki dokumentiert, auch in den FAQs nicht. Folgende Gründe:

Persistence bewirkt zweierlei:

1. Die Subscriptions bleiben erhalten
Wenn der Client sich wieder anmeldet (merkt der Broker an der ClientID), werden die früheren Subscritions wieder aktiv (ein erneutes subscriben ist nicht nötig)
2. Alles was mit QoS 1 oder 2 übertragen worden ist, wird ausgeliefert

Beide Fälle sind für uns nur bedingt sinnvoll:
zu 1.
PubSubClient kennt persistence nicht. Daher muss ein Client der darauf aufbaut, auf jeden Fall die Topics neu subscriben.
zu 2.
Bei Schaltbefehlen ist es eine nicht gute Idee, da sonst alle Schaltbefehle (jedenfalls bei QoS 1 und 2) übertragen werden, wenn die Verbindung wieder hergestellt wird.
Bei z.B. einem Sensor könnte es anders sein, wenn man Werte haben will, die fhem verpasst hat weil der Broker lief aber fhem nicht. Wobei dann zu prüfen ist, welche Timestamps fhem für diese Werte setzt.

Wo soll das hin?
Ins Wiki? In die FAQs? Und was schreibe ich dazu?

[slor]

Das war mir so nicht klar. Habe QOS 1 aktiviert. Zumindest in Fhem um sicherzustellen dass Schaltbefehle ankommen.

Wie spielt retrain da mit rein?

Ich würde es in die FAQ und Wiki packen. Design Überlegungen

[Rince]

Retained und Persistence sind zwei verschiedene Dinge:

Retained:
du meldest dich an und bekommst den letzten aktuellen Wert

Persistence:
du meldest dich an und bekommst alles "was bisher geschah"


Für einen Schaltaktor (subscriber):
Retained kann prinzipiell Sinn machen
Du setzt ne Lampe auf "on", der Schaltaktor ist grade nicht erreichbar
=> sobald er wieder kommt, geht die Lampe an

Das birgt einige Probleme, die hier aber zu weit führen

Persistence für einen Schaltaktor:
Macht prinzipiell eher wenig Sinn. Die ganzen gesendeten Schaltbefehle werden der Reihe nach übertragen. Das ist dein beobachtetes Blinklicht. Letzteres sollte aber nur bei QoS 1 oder 2 passieren.
Ich würde aber darin keinen Vorteil sehen.


Für einen Sensor (publisher):
Retained
Macht hochgradig Sinn; sobald ein Subscriber die Daten am Broker abonnieren will, bekommt er den letzten Sensorwert übermittelt

Persistence
Ja und nein
PubSubClient kann das nicht. Ergo muss das ggfs. der Broker speichern.
Praktisch wäre es natürlich, wenn man einen Temperaturplot will und alle Daten möchte. Zu prüfen ist, welche Timestamps die Werte bekommen! Evtl. müsste man dann eine Uhrzeit mit senden...

[slor]

Wieder was gelernt 
Evtl kann man ja noch eine Best practice dazu entwickeln welche Einstellungen am Sonoff, am Broker und in Fhem vorzunehmen sind. (Retained, QOS, persistence)

Das dann in die FAQ / wiki

[Kuzl]

Ui das hab ich noch gar nicht gekannt

Wie kann man Persistence z.b. bei Mosquitto einschalten?

Das macht z.b. bei Batteriebetriebenen Sensoren sinn, wenn man über MQTT Einstellungen vornehmen will, die dann im EEPROM gespeichert werden.

Wenn ich z.b. das Sleep-Intervall ändern möchte, soll das ja nur 1x ankommen und nicht bei jedem neuverbinden, da sonst auf dauer der EEPROM kaputt geht...

[slor]

Ich glaube, dafür wäre dann retain und QOS 2 gut.

Persistence Infos findest du hier https://eclipse.org/mosquitto/man/mosquitto-conf-5.php

(Hab ich gern für dich gegoogled 😉)

[Rince]

@Kuzl
Du willst Sensoren oft umkonfigurieren und die Konfiguration abspeichern?

Würde ich nicht mit Persistence lösen, sondern mit Retained:

Du publishest retained die Konfiguration.
So empfängt der Sensor die Konfiguration bei einem Neustart oder einer Änderung.

Die Config speichern kannst du, wenn nicht sicher bist, dass dein Sensor immer einen MQTT Connect hat (ansonsten überflüssig). Um ein andauerndes Überschreiben zu verhindern, lies doch die gespeicherte Config, vergleich sie mit der Neuen und speichere nur dann wenn sich was geändert hat. Klingt imho sauberer.

Persistence ist imho für dein Problem keine Lösung!
Wenn dein Sensor aus ist, du 5x die Config änderst, bekommt dein Sensor 5x neue Config-Werte...

Das ist ja slor mit seinem sonoff passiert.

Noch was zu QoS:
PubSubClient kennt keine QoS 2.
Da kommt dann automatisch ein Fallback auf 1 zum tragen. Das bedeutet, du kannst die Werte auch öfter bekommen...

Daher ist das Vergleichen der alten und der neuen Konfiguration in jedem Fall sinnvoll, bevor man das schreiben auf dem EEPROM anfängt.

[Kuzl]

Ok da muss ich dir recht geben...