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

Begonnen von slor, 13 April 2017, 21:02:59

Vorheriges Thema - Nächstes Thema

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
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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.
FHEM auf PC: CUL868, CUL 443, HM_LAN, JeeLink
FHEM auf Raspi: CUL868
div. LaCrosse Temp/Hum-Sensoren, HM-Heizkörperventile, Schaltaktoren, etc.

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.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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?
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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?
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

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
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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...
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

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
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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 😉)
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect

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.
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Kuzl


Bastel Bastel

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
FHEM auf Mac Mini mit i7, Unifi APAC und Controller, 2 Siemens Logo 8er, 1 Wago 830er, diverse Ufos über Wifilight, diverse Homematicdevices, Harmony Hub, Sonos