Notify wenn mqtt device nicht erreichbar ist

[Init]

Hallo zusammen,

ich habe jetzt einige Zeit im Forum gesucht, aber irgendwie nichts passendes gefunden. Vielleicht habe ich die falschen Suchbegriffe genutzt 

Ich habe das Problem, dass mein sonoff-pow, welcher die Poolpumpe schaltet, recht ungünstig von der WLAN Erreichbarkeit positioniert ist. Geht leider nicht anders.

Zu 90% klappt der Schaltvorgang, aber die übrigen 10% möchte ich gerne sicherstellen, dass der Schaltvorgang wiederholt wird und ich notfalls informiert werde.

Leider habe ich noch nichts gefunden, um einen nicht stattgefundenen Schaltvorgang zu identifizieren.

Ich nutze mqtt mit folgender Definition:

Code Auswählen Erweitern

defmod mqttBroker MQTT mqtt:1883
attr mqttBroker DbLogExclude .*
attr mqttBroker event-on-change-reading .*

Und den sonoff-pow mit folgender Definition:

Code Auswählen Erweitern


defmod SONOFF_POWR2_1 MQTT_DEVICE
attr SONOFF_POWR2_1 userattr subscribeReading_state subscribeReading_status
attr SONOFF_POWR2_1 DbLogExclude .*
attr SONOFF_POWR2_1 IODev mqttBroker
attr SONOFF_POWR2_1 alias Filterpumpe
attr SONOFF_POWR2_1 event-on-change-reading .*
attr SONOFF_POWR2_1 eventMap ON:on OFF:off
attr SONOFF_POWR2_1 group Pool
attr SONOFF_POWR2_1 icon black_Steckdose.on
attr SONOFF_POWR2_1 publishSet ON OFF toggle /SmartHome/Service/SONOFF_POWR2_1/cmnd/POWER
attr SONOFF_POWR2_1 qos 1
attr SONOFF_POWR2_1 retain 1
attr SONOFF_POWR2_1 room mqtt
attr SONOFF_POWR2_1 stateFormat state\
Aktuell: ENERGY_Current\
| Heute: ENERGY_Today\
| Gestern: ENERGY_Yesterday\
| Gesamt: ENERGY_Total
attr SONOFF_POWR2_1 subscribeReading_sensor /SmartHome/Service/SONOFF_POWR2_1/tele/SENSOR
attr SONOFF_POWR2_1 subscribeReading_state /SmartHome/Service/SONOFF_POWR2_1/stat/POWER
attr SONOFF_POWR2_1 webCmd on:off:toggle

Ich würde mich freuen, wenn mich jemand in die richtige Richtung schubsen könnte.

Viele Grüße
Marc

[Beta-User]

Für MQTT_DEVICE ist das auch gar nicht so einfach, und eigentlich sollte das mit retain auch ankommen, wenn der sich wieder verbindet... (ohne damit eine Aussage getroffen zu haben, ob das eine sinnvolle Einstellung ist).

Abboniere doch mal den LWT-Topic, dann siehst du wenigstens, wenn das Ding länger vom Netz geht und kannst ggf. darauf reagieren.

[Init]

Vielen Dank für die Antwort.

Schaue dir das mal mit LWT und retain an.

mqtt2 oder mqtt_server statt tasmota würde wahrscheinlein auch keine Abhilfe schaffen oder?

[Beta-User]

mqtt2 oder mqtt_server statt tasmota würde wahrscheinlein auch keine Abhilfe schaffen oder?

sorry, da verstehe ich die Frage nicht so richtig:
Tasmota ist eine firmware für den Microcontroller (typischerweise: ESP8266). Die ist drauf, und "an sich" funktioniert die auch; "lediglich" der Empfang ist grenzwertig. Ergo würde ich persönlich einen ganz anderen Übertragungsweg als grade WLAN nehmen. Das ist aber eine andere Story...

MQTT ist der Übertragungsweg, der für diese Firmware in der Regel genutzt wird.

In FHEM ist die Behandlung etwas unterschiedlich, je nachdem, ob man die "klassische Einbindung" mit externem Server (aka Broker, häufig "Mosquitto") und den "alten Modulen" (00_MQTT, MQTT_DEVICE oder Derivate davon) hat, oder eben die neueren MQTT2_.* (entweder mit  internem MQTT2_SERVER oder (MQTT2_CLIENT + externem Server (wie gehabt)) und (in beiden Fällen) MQTT2_DEVICE.

MQTT2_DEVICE generiert aber auch keine Info, die vorher nicht da war, und LWT-Informationen kann man auch mit MQTT_DEVICE nutzen...
MQTT2_DEVICE generiert aber - unter bestimmten Umständen - _keine Events_, wenn ein Sendebefehl nicht ankommt; dann bleibt der state auf "set_on" stehen, und wechselt nicht auf "on". Auf sowas kann man dann z.B. einen watchdog ansetzen, um sich informieren zu lassen.

MQTT (als Technik) sieht aber z.B. auch vor, dass Nachrichten gepuffert werden können (Stichwort: retain). _Ausnahmsweise_ könnte das ein Ansatzpunkt sein, um auf Verbindungsabbrüche zu reagieren, falls kein Austausch der Hardware möglich ist (was weiter mAn. die bessere Lösung wäre).

[Gisbert]

Hallo Init,
hallo Beta-User,

an einem guten Empfang führt mittel- bis langfristig kein weg vorbei. In einem Fall hatte ich sehr bescheidene Empfangsverhältnisse. Da ich ich bereits auf halbem Weg einen ESP8266 mit lediglich einem Relais verbaut hatte, habe ich diesem die Software von martin-ger (https://github.com/martin-ger/esp_wifi_repeater) verpasst. Diese hat auch die freundliche Eigenschaft GPIOs zu schalten, so dass ich das angeschlossene Relais bedienen kann, und gleichzeitig einen Wlan-Repeater für den weit entfernten ESP8266 habe. Es ist ein Projekt für mehr als einen Samstagnachmittag (oder man kennt sich ansonsten sehr gut mit ES8266, Arduino, etc. aus), aber ich ich möchte dieses Teil nicht mehr missen.

In anderen Fällen habe ich gute Verbindungen, eigentlich, aber es kommt immer wieder vor, dass ein Teil aus der Reihe tanzt.

Aus diesem Grund erzeuge ich bei den infrage kommenden Fhem-Devices ein userReading mit dem Namen Zeitstempel, basierend auf irgendeinem Reading, welches wiederkehrend erneuert wird, z.B. uptime oder WiFi RSSI, oder dem Messwert/Sensor, den ich gerne überwachen möchte. Mit dem Modul monitoring überwache ich, ob bei einem Device das wiederkehrende Erneuern der Readings ausbleibt.
Meine Definition sieht wie folgt aus (neben Zeitstempel überwache ich auch noch Readings mit dem Namen Illuminance), der Code funktioniert nachgewiesenermaßen, so wie er hier steht:

Code Auswählen Erweitern

defmod mymonitoring monitoring .*:(Zeitstempel.*|.*Illuminance.*)
attr mymonitoring alias monitor
attr mymonitoring errorReturn {return unless(@errors);;\
$_ = AttrVal($_, "alias", $_) foreach(@errors);;\
return("Das Gerät \"$errors[0]\" hat sich seit mehr als 2 Stunden nicht mehr gemeldet.") if(int(@errors) == 1);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", "Die folgenden ".@errors." Geräte haben sich seit mehr als 2 Stunden nicht mehr gemeldet:", @errors))\
}
attr mymonitoring errorWait 7200
attr mymonitoring stateFormat {if (ReadingsVal($name,'warningCount','') > 0 and ReadingsVal($name,'errorCount','') > 0)\
{"<i>Warnung</i>:<br><span style='color:#2e5e87'>".(ReadingsVal($name,'mywarning',''))."</span><br>\
<i>Fehler</i>:<br><span style='color:#FF0000'>".(ReadingsVal($name,'myerror',''))."</span>"} \
elsif (ReadingsVal($name,'warningCount','') > 0)\
{"<i>Warnung</i>:<br><span style='color:#2e5e87'>".(ReadingsVal($name,'mywarning',''))."</span>"} \
elsif (ReadingsVal($name,'errorCount','') > 0)\
{"<i>Fehler</i>:<br><span style='color:#FF0000'>".(ReadingsVal($name,'myerror',''))."</span>"}}
attr mymonitoring userReadings myerror {my $ret = ReadingsVal($name,'error','');; $ret =~ s/,/<br>/g;; return $ret}, \
mywarning {my $ret = ReadingsVal($name,'warning','');; $ret =~ s/,/<br>/g;; return $ret}
attr mymonitoring warningReturn {return unless(@warnings);;\
$_ = AttrVal($_, "alias", $_) foreach(@warnings);;\
return("Das Gerät \"$warnings[0]\" hat sich seit mehr als 1 Stunde nicht mehr gemeldet.") if(int(@warnings) == 1);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", "Die folgenden ".@warnings." Geräte haben sich seit mehr als 1 Stunde nicht mehr gemeldet:", @warnings))\
}
attr mymonitoring warningWait 3600

Das Ganze ist auch behliflich, wenn der ESP8266 an sich läuft, aber der zu überwachende Sensor keine Daten mehr liefert, weil er defekt ist, oder was auch immer der Grund ist, - ich glaube ich habe schon alle möglichen Arten von Fehlern gehabt.

Viele Grüße Gisbert

Edit: kleine Einschränkung zum Code, "hat sich seit mehr als 2 Stunden nicht mehr gemeldet" steht so oder so ähnlich bei den Attributen insgesamt viermal drin, allerdings sehe ich davon nirgends etwas bei den Readings oder sonstigen Meldungen/Nachrichten. Vielleicht ist jemand so nett und erkärt mir, ob der Code an diesen Stellen sinnvoll und richtig ist, bzw. kann einen Vorschlag machen, wie ich es entfernen kann.

[Benni]

Ich habe bei mir so was ähnliches laufen!

Mein Handy meldet seine An-/Abwesenheit "Zuhause" per MQTT an mein FHEM. Allerdings hatte der MQTT-Client auf meinem Handy auch schon mal das Problem, dass er sich nicht mehr mit dem MQTT-Broker verbinden konnte und somit keine Meldungen mehr in FHEM ankamen.
Ich lasse seither von meinem Handy alle 15 Minuten einen Ping-Wert über ein bestimmtes Topic an mein FHEM senden, das im entsprechenden MQTT2_DEVICE als Reading umgesetzt wird. Also auch das Prinzip Totmannschaltung.

Ich haben nun einen einfachen Watchdog auf das entsprechende Ping-Reading in meinem MQTT2_DEVICE der, wenn 60 Minuten keine Aktualisierung kommt, dann löst der aus:

Code Auswählen Erweitern


defmod wdPresenceHandy_Ping watchdog mqPresenceHandy:ping:.* 01:00 SAME {\
Log3 'global',3,'wdPresenceHandy_Ping: Ping not recieved!';;\
}
attr wdPresenceHandy_Ping autoRestart 1


gb#

[Init]

Hallo zusammen,

vielen Dank für die zahlreichen Antworten.

Demnach werde ich wohl erstmal den Weg gehen und retain im Zusammenhang mit einem watchdog oder monitoring einsetzen.

Da es sich um einen sonoff-pow handelt, bekomme ich regelmäßig das /tele/SENSOR rein, auf das ich abfragen kann.
Zusätliche werde ich wohl auf lwt=offline reagieren.

Als Notaus habe ich im Sicherungskasten einen Schütz vor den beiden POW's (Filter- und Wärmepumpe), welchen ich über HM-Wired ausschalten kann.

Mal schauen, ob ich eine robuste Lösung hinbekommen.

@Beta-User: Sorry für die Verwirrung mit Tasmota. War mir "natürlich" klar und hatte es mit Mosquitto gedanklich verwechselt. Hab momentan wenig Zeit

Mit monitoring und watchdog habe ich mich bislang noch nicht beschäftigt und kann daher noch nicht bewerten, welcher Ansatz hier welchen Vorteil hat.
Watchdog sieht jedenfalls "einfacher" aus.

Viele Grüße
Marc

[Init]

Hallo zusammen,

ich habe nun alle Devices auf mqtt2 (MQTT2_DEVICE mit MQTT2_SERVER) umgestellt und habe festgestellt, dass es hier kein retain und qos im MQTT2_DEVICE gibt.

Ich möchte aber weiter sicherstellen, dass der letzte Befehl beim reconnect vom Device gesendet wird.

Mit mqtt hat das mit den beiden Attributen ganz gut geklappt.

Gibt es dir Einstellmöglichkeit in mqtt2 nicht mehr?

Viele Grüße
Marc

[Beta-User]

Retain geht schon:

Code Auswählen Erweitern

if the topic name ends with :r, then the retain flag is set
Ob es allerdings sinnvoll ist, ist eine andere Frage; in den attrTemplate's wird es nicht gesetzt, und vermißt hat es da bisher keiner... (die unbeabsichtigten Nebenwirkungen scheinen mir auch größer zu sein wie der Nutzen, in der Regel ist es sinnvoller, sich um eine stabile Verbindung zu den Zielgeräten Gedanken zu machen, aber das hatten wir hier ja schon diskutiert).

Und M2S unterstützt (wie M2C) auch QoS 0 und 1, allerdings habe ich im Moment keine Ahnung, wie man das in MQTT2_DEVICE umsetzen müßte...

Aus vergangenen Diskussionen rund um das Thema hatte ich mitgenommen, dass es eigentlich in TCP/IP-Netzen nicht erforderlich sein sollte, QoS zu setzen.

[Init]

Vielen Dank für die Antwort.

Werde mich mal im nächsten Jahr um die Erweiterung meines WLANs kümmern. Pool-Saison ist eh vorbei

Wie wäre denn das :r für retain um Topic richt?
off:r    /SmartHome/Service/SONOFF_SM20_2/cmnd/POWER1 0
oder
off:noArg    /SmartHome/Service/SONOFF_SM20_2/cmnd/POWER1:r 0

Viele Grüße
Marc

[Beta-User]

Code Auswählen Erweitern

off:noArg    /SmartHome/Service/SONOFF_SM20_2/cmnd/POWER1:r 0

[Init]

Vielen Dank - Werde is mal sicherheitshalbe so eintragen