Auf Alter von Readings im Dummy triggern. Syntax?

Begonnen von Frank_Huber, 11 August 2017, 09:14:19

Vorheriges Thema - Nächstes Thema

Frank_Huber

Moin,

Ich habe einen dummy wo alle Temperaturen vom Gebäude (4 Instanzen) einlaufen.
Jetzt möchte ich wenn eines der Readings älter als 10 Minuten ist eine Benachrichtigung erhalten.

Das ist mein jetzige Stand:
defmod DOIF_Whatchdog_Temp DOIF ([Temperaturen:.*:sec] > 660) ((set TelegramBot message Temperatur $EVENT scheint offline zu sein, bitte prüfen!))
attr DOIF_Whatchdog_Temp do always


Was er jetzt aber macht ist bei jedem Event von jedem Reading triggern. also 14 Auslösungen alle 5 Minuten.
Wo kann denn hier mein Fehler stecken? stehe gerade auf dem schlauch.

Danke & Grüße
Frank

tiwo85

Gibt es dafür nicht das Modul Watchdog?

Gesendet von meinem VKY-L09 mit Tapatalk


Frank_Huber

damit habe ich es nicht geschafft alles in einen unterzubekommen.
und wollte es vermeiden 14 einzelne Whatchdogs anzulegen.

in einem anderen DOIF funktuioniert das:
and [IT_00FF0F0FFF:state:sec] > 120
daher dachte ich ich kann den Weg gehen.

Per

Statt Watchdogs geht auch do resetwait 600, aber auch da bräuchtest du 14 DOIF. Wäre nur interessant, wenn du eh für jeden Sensor eins hättest, welches du erweitern könntest.
Problem ist, dass [xxx:yyy:sec] nur bei "== 0" ein Event erzeugt.
Dass dein
Zitat von: Frank_Huber am 11 August 2017, 09:30:05and [IT_00FF0F0FFF:state:sec] > 120
funktioniert, ist "Zufall", weil eigentlich ist es ein
and [?IT_00FF0F0FFF:state:sec] > 120.
Du könntest einen Timer machen und regelmäßig mit
[#"Temperaturen:.*:sec" > 120]
(#)
eine Liste erzeugen.

amenomade

@Per: da bin ich mir nicht sicher. Wenn das so wäre, hätte das Beispiel im CommandRef kein Sinn:
ZitatAnwendungsbeispiel: Licht soll angehen, wenn der Status des Bewegungsmelders in den letzten fünf Sekunden upgedatet wurde.

define di_lamp DOIF ([BM:state:sec] < 5) (set lamp on-for-timer 300)
attr di_lamp do always

Bei HM-Bewegungsmelder werden periodisch Readings aktualisiert, dadurch wird das Modul getrigger, auch wenn keine Bewegung stattgefunden hat. Der Status bleibt dabei auf "motion". Mit der obigen Abfrage lässt sich feststellen, ob der Status aufgrund einer Bewegung tatsächlich upgedatet wurde.

@Frank_Huber: ein "list Temperaturen" wäre interessant.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

MadMax-FHEM

Hallo Frank,

evtl. statt dem DOIF ein notify und dann eine sub in myUtils aufrufen, wo du dann die Zeiten der Readings prüfst 'ReadingsAge' und dann entsprechend eine Meldung schickst...

Statt dem notify geht auch ein at, welches dann zyklisch die Sub aufruft...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Frank_Huber

Zitat von: MadMax-FHEM am 11 August 2017, 11:55:42
evtl. statt dem DOIF ein notify und dann eine sub in myUtils aufrufen, wo du dann die Zeiten der Readings prüfst 'ReadingsAge' und dann entsprechend eine Meldung schickst...
Statt dem notify geht auch ein at, welches dann zyklisch die Sub aufruft...
Das übersteigt dann meine Möglichkeiten. ;)

Zitat von: amenomade am 11 August 2017, 11:44:40
@Frank_Huber: ein "list Temperaturen" wäre interessant.
Internals:
   NAME       Temperaturen
   NR         236
   STATE      ???
   TYPE       dummy
   Helper:
     DBLOG:
       OG_absFeuchte:
         logdb:
           TIME       1502448120.69115
           VALUE      10.3
   READINGS:
     2017-08-11 12:41:39   DG_Ost          21.9375
     2017-08-11 12:41:42   EG_Bad          19.625
     2017-08-11 12:41:48   EG_Garderobe    20.6875
     2017-08-11 12:41:51   EG_Gast         20.75
     2017-08-11 12:41:56   EG_Kammer       21
     2017-08-11 12:42:01   EG_Kueche       21.9375
     2017-08-11 12:42:05   EG_Ofen         21.6875
     2017-08-11 12:42:09   EG_Wohn         21
     2017-08-11 12:41:32   OG_Bad          21.3125
     2017-08-11 12:41:46   OG_Flur_Ost     21.3125
     2017-08-11 12:41:49   OG_Flur_West    21
     2017-08-11 12:42:04   OG_Johanna      21.6875
     2017-08-11 12:42:11   OG_Luisa        21.8125
     2017-08-11 12:42:23   OG_Schlafzimmer 20.5
     2017-08-11 12:42:00   OG_absFeuchte   10.3
Attributes:
   DbLogExclude EG_Gast,EG_Kammer,EG_Garderobe,EG_Bad,EG_Kueche,EG_Ofen,EG_Wohn,OG_Bad,OG_Flur_Ost,OG_Flur_West,OG_Johanna,OG_Luisa,OG_Schlafzimmer,DG_Ost
   DbLogInclude OG_absFeuchte
   readingList EG_Gast EG_Kammer EG_Garderobe EG_Bad EG_Kueche EG_Ofen EG_Wohn OG_Bad OG_Flur_Ost OG_Flur_West OG_Johanna OG_Luisa OG_Schlafzimmer OG_absFeuchte DG_Ost
   room       Temp / Feucht
   setList    EG_Gast EG_Kammer EG_Garderobe EG_Bad EG_Kueche EG_Ofen EG_Wohn OG_Bad OG_Flur_Ost OG_Flur_West OG_Johanna OG_Luisa OG_Schlafzimmer OG_absFeuchte DG_Ost


Zitat von: Per am 11 August 2017, 11:08:27
Problem ist, dass [xxx:yyy:sec] nur bei "== 0" ein Event erzeugt.
Das erklärt das fehlerbild.

Zitat von: Per am 11 August 2017, 11:08:27
Dass deinfunktioniert, ist "Zufall", weil eigentlich ist es ein
and [?IT_00FF0F0FFF:state:sec] > 120.
Mag sein, in dem Einsatzfall dort würde das so auch reichen.

Zitat von: Per am 11 August 2017, 11:08:27
Du könntest einen Timer machen und regelmäßig mit
[#"Temperaturen:.*:sec" > 120]
(#)
eine Liste erzeugen.
Das werd ich mir mal anschauen! Danke.

Per

Zitat von: Per am 11 August 2017, 11:08:27Problem ist, dass [xxx:yyy:sec] nur bei "== 0" ein Event erzeugt.
Eingentlich stimmt das nicht ganz, in Wirklichkeit ist :sec gleich 0, wenn der passende Event erzeugt wird (und es eine Änderung gab).

Zitat von: amenomade am 11 August 2017, 11:44:40@Per: da bin ich mir nicht sicher. Wenn das so wäre, hätte das Beispiel im CommandRef kein Sinn:
Hier wird ein Event erzeugt, ohne dass es eine Zustandänderung gibt, deshalb wird :sec größer. Sozusagen ein (im Sensor befindlicher) Timer.

Du hast aber dass Problem, dass du das Ausbleiben des Eventes prüfen willst. Also musst du dir einen Timer erstellen und in diesem das Alter der einzelnen (oder halt aggregiert -> #) state abfragen und entsprechend handeln.

Beta-User

Vielleicht hilft Dir das weiter (modifiziert bzw. geklaut von https://forum.fhem.de/index.php/topic,34482.msg268826.html#msg268826, keine Syntaxprüfung):

define Temperaturueberwachung_Melder notify .*Temperaturen:.* { fhem "defmod - temporary $NAME_ReceivedTimer at +00:06:60 { fhem 'set TelegramBot message Temperatur $NAME scheint offline zu sein, bitte prüfen!' } }"
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

amenomade

Hier wird ein Event erzeugt, ohne dass es eine Zustandänderung gibt, deshalb wird :sec größer. Sozusagen ein (im Sensor befindlicher) Timer.

Du hast aber dass Problem, dass du das Ausbleiben des Eventes prüfen willst. Also musst du dir einen Timer erstellen und in diesem das Alter der einzelnen (oder halt aggregiert -> #) state abfragen und entsprechend handeln.
[/quote]
@Per: Stimmt.

@Frank: Warum dann mit :sec arbeiten, und nicht mit wait und do resetwait? Da ist dafür gemeint. Ich würde so probieren:

([Temperaturen:.*])
     (set TelegramBot message Temperatur $EVENT scheint offline zu sein, bitte prüfen!)
attr _Whatchdog_Temp wait 660
attr _Whatchdog_Temp  do resetwait
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Brockmann

Ich bin mir nicht sicher, ob sich dieses Problem mit einem DOIF "elegant" lösen lässt. Und Du willst ja eigentlich auch nicht die Temperaturen überwachen, sondern die Sensoren, welche diese Temperaturen liefern (oder?).
Vielleicht schaust Du Dir mal das monitoring-Modul an, das ist genau für solche Aufgaben gedacht.
https://fhem.de/commandref_DE.html#monitoring

Frank_Huber

Doch, es geht um die Temperaturen. Diese werden per RFHEM von anderen Instanzen da reingeschrieben. Manchmal bleibt dies aber hängen. Das will ich damit erkennen.
Die Hänger passieren z. B. wenn beim Wert schreiben kurz das Netzwerk weg ist. Ab dem Moment hängt dann irgendwas beim sendenden FHEM. Die entsprechenden devices werden dann auch nicht mehr geloggt.

Deswegen ist das erkennen und Handeln können der erste Schritt.
Im zweiten step werd ich meine Testumgebung um einen zweiten RasPi erweitern und die Wurzel des Bösen suchen.

Gesendet von meinem S3_32 mit Tapatalk


Frank_Huber

@amenomade, werde ich ausprobieren, danke!

Gesendet von meinem S3_32 mit Tapatalk


amenomade

ZitatIch bin mir nicht sicher, ob sich dieses Problem mit einem DOIF "elegant" lösen lässt. Und Du willst ja eigentlich auch nicht die Temperaturen überwachen, sondern die Sensoren, welche diese Temperaturen liefern (oder?).

Deswegen ([Temperaturen:.*])
     (set TelegramBot message Temperatur $EVENT scheint offline zu sein, bitte prüfen!)


und nicht
([Temperaturen])
     (set TelegramBot message Temperatur $EVENT scheint offline zu sein, bitte prüfen!)


Hab's aber nicht probiert.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Per

Zitat von: Brockmann am 12 August 2017, 08:50:26Ich bin mir nicht sicher, ob sich dieses Problem mit einem DOIF "elegant" lösen lässt.

Zitat von: Per am 11 August 2017, 11:08:27aber auch da bräuchtest du 14 DOIF
Also nicht wirklich "elegant"...