Funktionsüberwachung anhand von aktuellem Reading

Begonnen von Meister_Petz, 12 Februar 2021, 00:56:40

Vorheriges Thema - Nächstes Thema

Meister_Petz

Moin,

ich habe gesucht! wurde aber nicht fündig: Ihr dürft mich gerne auf einen passenden Eintrag verweisen!

Was will ich eigentlich? ;-)

Im Prinzip: wenn sich Reading X für Zeit Y NICHT AKTUALISIERT mach was

Gruß und Dank

Petz

DeeSPe

MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Beta-User

Zitat von: DeeSPe am 12 Februar 2021, 01:13:02
watchdog?
+1.

Falls die Frage in Zusammenhang steht mit deinen anderen Fragen rund um MQTT: sorge dafür, dass dein MQTT-Client (der Code auf dem ESP) den LWT-Mechanismus nutzt... (Du wolltest erst mal ein Stichwort haben).

Ansonsten wäre ggf. noch https://fhem.de/commandref_modular_DE.html#readingsWatcher einen Blick wert.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wzut

#3
ganz klar readingsWatcher :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

enno

DOIF

defmod di_aktivity DOIF  ([05:11] and [?NUKIDevice333550209:rssi:sec] <= 86400 )(setreading NUKIDevice333550209 Activity alive)\
DOELSEIF ([05:11] and [?NUKIDevice333550209:rssi:sec] > 86400 )(setreading NUKIDevice333550209 Activity dead)\


Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC mit Proxmox und Debian

Meister_Petz

readingsWatcher ... genial! Genau das habe ich gebraucht.

Ja, das steht im Zusammenhang mit dem MQTT Gerät. Das Problem ist aber eher, dass der ESP bei -10 Grad draußen hängt und ich noch nicht abschätzen kann wie lang er das durchhält.

Und sobald kein Reading mehr kommt... kann ich reagieren

Danke Euch allen

Beta-User

Ebend. LWT  ;) . (=MQTT-Mechanismus, um zu signalisieren, dass sich ein Gerät nicht mehr wie angekündigt meldet. "Guter" MQTT-Code beinhaltet das...).
(Kann man auch mit den anderen Lösungen kombinieren).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors