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
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.
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.
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?
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.
so, Lösung gefunden. Auf dem Mosquitto MQTT Broker war persistence auf true gesetzt.
Auf fals gesetzt und seit zwei Tagen keine Probleme mehr.
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?
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
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...
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
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...
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 😉)
@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.
Ok da muss ich dir recht geben... ::)
Moin, moin!
Hoffe ich hab den richtigen Beitrag erwischt ::)
Ich bin absoluter MQTT Neuling und dachte mir so schwer kann das ja nicht sein, mit der Folge das bis auf einen alle erstmal wieder nur blind nebenher laufen.
Zum Anfang hatte ich Probleme mit dem Empfang von Befehlen aus FHEM heraus (mal schalten die Sonoffs ohne Probleme und mal garnicht, bzw. erst Ewigkeiten später).
Jetzt habe ich FHEM seitig mit QoS und Retain rumgespielt... das Schaltverhalten hat sich verbessert, dafür schaltet ein Sonoff jetzt nach einigen Minuten wie er will ohne Befehl von außen.
Im Log sind keine Reconnects zu sehen, nur die periodische Übermittlung der Teledaten.
Die Sonoffs sind alle mit Tasmota bespielt und GPIO14 herausgeführt um die normalen Wechselschalter weiter nutzen zu können.
Hoffe mit eurer Hilfe bekomme ich die Sonoffs zuverlässig in Funktion.
Gruß Karsten
Was sagt denn die console auf den Sonoffs zu der Zeit?
Meine Antwort hat leider etwas gedauert :-\
Gestern Morgen um 8:13 Uhr, bzw. auf dem Sonoff um 7:13 da eine Stunde Versatz. Woran kann das Verhalten liegen?
Hallo,
den Versatz in der Uhrzeit bekommst Du über die Console der Weboberfläche berichtigt:
Timezone 99
Evtl. musst Du auch noch einen NtpServer setzen.
https://github.com/arendst/Sonoff-Tasmota/wiki/Commands (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands)
MfG
Poste das nächste mal bitte keine Screenshots, sondern Text als Code. Kann man besser lesen.
Man sieht auf dem Gerät, dass es geschaltet wird die Frage von wem? Dreh Mal das logging auf dem Sonoff hoch. Oder richte dir ein syslog ein.
Danke euch erstmal! Das mit der Zeit werde ich demnächst versuchen und die Sonoffs wohl doch erstmal in eine Testinstanz hängen, musste des Hausfriedens wegen die Wohnung ersteinmal wieder in die Steinzeit schicken :'( Die Geisterlichter im Flur und Küche waren meiner besseren Hälfte dann doch zu viel.
Hallo zusammen,
ich habe auch ein Problem im Zusammenhang mit dem ungewollten Schalten der Sonoff´s wenn diese sich wieder mit dem WLan verbinden.
Das macht ganz besonders Probleme bei den Computern die über einen Sonoff POW angeschlossen sind. Sobald ich die Fritzbox neustarte schalten diese einmal kurz. (Da bedanken sich meine Kinder dann natürlich wenn deren Computer dadurch abstürzen).
Ich habe bisher bei den betreffenden Geräten mal das PowerRetain auf 1 gesetzt was aber keine Besserung brachte.
Gibt es dazu schon eine Lösung in der FAQ ? (mit MQTT kenne ich mich bisher so gar nicht aus)
Viele Grüße
Volker