Lebenszeichen überwachen, actiondetector

[martinp876]

define alarm notify .*:Activity.* dosomethingwith $NAME

klappt das nicht?

[Mr. P]

verstehe ich da was falsch, oder sollte das nicht zb so zu ermitteln sein (eine zeile für die fhem.cfg  ):

Code Auswählen Erweitern

my $dev = $1 if($EVTPART0 =~ m/^status_(.*):$/);;\

Nein, verstehst du vollkommen richtig und würde ich, wenn ich Regex nutze, genauso machen.
Mein Problem ist nur, dass es jemand bedienen soll, der sich freut, wenn er erfolgreich ein Notify schreibt, welches einen Aktor auslöst, nachdem die Temperatur von einem RT einen bestimmten Wert überschritten hat. Regex lässt sich mit gut Glück noch buchstabieren. Aber warten und verstehen ist eine andere Sache. Zu guter Letzt kommt dann noch ein lustiger Linux-/Windows-Dateihandling-Mischmasch zusammen und das Chaos ist perfekt. :-/

define alarm notify .*:Activity.* dosomethingwith $NAME

klappt das nicht?

Leider nicht. Habe alle möglichen Konstellationen durchprobiert. Div. event-on-*-readings hinzugefügt bzw. entfernt, habe es aber mit keiner einzigen geschafft, Activity für ein Notify zu nutzen. Aber vielleicht hast du noch einen alles entscheidenden Tipp für mich. Wäre auch nicht das erste Mal.

[martinp876]

kann ich nicht nachvollziehen. Ich haben meinen test-VD genommen. dann - weil ich ungeduldig bin habe ich:

Code Auswählen Erweitern

attr vd actCycle 000:03
gesetzt. Macht die Sache schneller - von VD wird alle 3 min eine Message erwartet (kann man auch auf 1 min setzen).
mit

Code Auswählen Erweitern

{CUL_HM_ActCheck("")}
kann man den Check erzwingen - der Action detector check also die Action - und die notifies werden getriggert.
selstverständlich ist wie überall auch hier

Code Auswählen Erweitern

attr vd event-on-change-reading .*
gesetzt - bei mir IMMER
nicht zu vergessen, das notify

Code Auswählen Erweitern

define alarm notify .*:Activity.* {Log 1,"we got an Activity:$NAME - $EVENT"}

wenn ich nun die Batterie einlege kommt im Logfile

Code Auswählen Erweitern

2015.04.06 12:26:55.348 1: we got an Activity:vd - Activity: alive
und wenn ich die Batterie rausnehme

Code Auswählen Erweitern

2015.04.06 12:29:47.813 1: we got an Activity:vd - Activity: dead
natürlich 3 min später und erst, wenn der Actiondetector startet - siehe Kommando oben.

nicht funktionieren kann:

Code Auswählen Erweitern

define alarm notify .*:Activity.* {my $d = fhem "get ActionDetector listDevice dead";;Log 1,"we got an Activity:$NAME - $EVENT:dead - $d"}
Grund ist, dass die Devices "Activity" erst geschrieben werden und danach die Readings des ActionDetector. Wenn man also hier auswerten will muss man einen Trigger aus ActionDetector wählen.

Noch ein zaghafter Hinweis zu HMInfo. Hier sollten u.a. Alarme konsolidiert gesammelt werden. Auch der ActionDetector wird ausgewertet. Es soll erlauben, alle kritischen Events anzuzeigen. Was kritisch ist, kann man einstellen. Die Auswertung ist nicht unbedingt zielgerichtet... es sollte aber für eine Email reichen.

[Mr. P]

Hej Martin,

vielen Dank für deine ausführliche Antwort.
War ein klarer Fall von Layer 8 Problem, wie mein Professor gerne dazu sagt. Funktioniert jetzt!

[frank]

hallo martin,

wenn ich davon ausgehe, dass die folgende beschreibung zum status "unknown" des actiondetectors gilt, gibt es ein problem des actiondetectors mit der energiemesssteckdose HM-ES-PMSw1-Pl.

unknown kommt, wenn FHEM seit Start kein lebenszeichen von device gesehen hat, die zeit seit start aber noch in der toleranz ist.
Es wird versucht, beim neustart die werte von vorher zu übernehmen. Daher gibt es nicht nach jedem neustart zu einem unknown. wohl aber, wenn man das statefile löscht.

Ein device, das sich erst nach 24h oder 3 Tagen melden muss kann schon einige Zeit auf unknown stehen. macht man ein getConfig (so das device darauf reagieren kann) wird der state auf alive gesetzt (wenn es sich meldet). Nicht aber auf dead, wenn es sich nicht meldet.

bei schlechtem empfang, bekomme ich natürlich meldungen vom actiondetector. aber anstatt dead zu melden, gibt es immer unknown meldungen. anbei der event-log und die zugehörigen rawmessages, während dieser zeitspanne. actionCycle ist auf 10 min eingestellt.

fhem versucht wohl durch set getSerial den zustand zu ermitteln, was 2x unbeantwortet bleibt. das dead kommt dann sozusagen nach 3x 10min. soll das so sein, oder gibt es hier ein problem?

Code Auswählen Erweitern

2015-07-24_02:47:02 SwitchES01_Pwr eState: E: 240.7 P: 0 I: 0 U: 238.6 f: 50.01
2015-07-24_02:47:02 SwitchES01_Pwr voltage: 238.6
2015-07-24_02:47:02 SwitchES01_SenU 238.6

2015-07-24_03:00:46 SwitchES01 CMDs_pending
2015-07-24_03:00:46 SwitchES01 Activity: unknown
2015-07-24_03:01:05 SwitchES01 ResndFail
2015-07-24_03:01:05 SwitchES01 CMDs_done_Errors:1
2015-07-24_03:01:05 SwitchES01 RESPONSE TIMEOUT:SerialRead

2015-07-24_03:10:46 SwitchES01 CMDs_pending
2015-07-24_03:11:06 SwitchES01 ResndFail
2015-07-24_03:11:07 SwitchES01 CMDs_done_Errors:1
2015-07-24_03:11:07 SwitchES01 RESPONSE TIMEOUT:SerialRead

2015-07-24_03:20:46 SwitchES01 Activity: dead

2015-07-24_03:25:30 SwitchES01_Pwr eState: E: 240.7 P: 0 I: 0 U: 238.4 f: 50.01
2015-07-24_03:25:30 SwitchES01_Pwr voltage: 238.4
2015-07-24_03:25:30 SwitchES01_SenU 238.4

2015-07-24_03:30:47 SwitchES01 Activity: alive

Code Auswählen Erweitern

2015.07.24 02:47:02.373 0: HMLAN_Parse: hmlan1 R:E24AF1D   stat:0000 t:0310E4EA d:FF r:FF9C     m:7F 845E 24AF1D 000000 8009670000000000095201

2015.07.24 03:00:46.270 0: HMLAN_Send:  hmlan1 S:SBD93A48A stat:  00 t:00000000 d:01 r:BD93A48A m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:46.587 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:032054E3 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:46.603 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:032055AB d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:46.743 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03205673 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:46.880 0: HMLAN_Parse: hmlan1 R:RBD93A48A stat:0008 t:00000000 d:FF r:7FFF     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:46.882 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.24 03:00:50.684 0: HMLAN_Send:  hmlan1 S:SBD93B5C7 stat:  00 t:00000000 d:01 r:BD93B5C7 m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:50.747 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03206620 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:50.946 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:032066E8 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:51.136 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:032067B0 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:51.300 0: HMLAN_Parse: hmlan1 R:RBD93B5C7 stat:0008 t:00000000 d:FF r:7FFF     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:51.303 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.24 03:00:54.907 0: HMLAN_Send:  hmlan1 S:SBD93C646 stat:  00 t:00000000 d:01 r:BD93C646 m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:54.967 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:032076A0 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:55.159 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03207768 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:55.351 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03207830 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:55.517 0: HMLAN_Parse: hmlan1 R:RBD93C646 stat:0008 t:00000000 d:FF r:7FFF     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:00:55.519 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.24 03:01:00.016 0: HMLAN_Send:  hmlan1 S:SBD93DA3B stat:  00 t:00000000 d:01 r:BD93DA3B m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:01:00.055 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03208A94 d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:01:00.279 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03208B5C d:FF r:FFCE     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:01:00.471 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03208C24 d:FF r:FFCF     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:01:00.626 0: HMLAN_Parse: hmlan1 R:RBD93DA3B stat:0008 t:00000000 d:FF r:7FFF     m:80 A001 1ACE1F 24AF1D 0009
2015.07.24 03:01:00.628 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D

2015.07.24 03:10:46.754 0: HMLAN_Send:  hmlan1 S:SBD9CCE2D stat:  00 t:00000000 d:01 r:BD9CCE2D m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:46.802 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03297E7B d:FF r:FFCF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:47.021 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03297F43 d:FF r:FFCF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:47.213 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329800B d:FF r:FFCF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:47.364 0: HMLAN_Parse: hmlan1 R:RBD9CCE2D stat:0008 t:00000000 d:FF r:7FFF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:47.366 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.24 03:10:51.324 0: HMLAN_Send:  hmlan1 S:SBD9CE008 stat:  00 t:00000000 d:01 r:BD9CE008 m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:51.374 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03299059 d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:51.598 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:03299121 d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:51.789 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:032991E9 d:FF r:FFCF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:51.938 0: HMLAN_Parse: hmlan1 R:RBD9CE008 stat:0008 t:00000000 d:FF r:7FFF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:51.940 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.24 03:10:56.176 0: HMLAN_Send:  hmlan1 S:SBD9CF2FC stat:  00 t:00000000 d:01 r:BD9CF2FC m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:56.237 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329A34A d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:56.429 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329A412 d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:56.621 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329A4DA d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:56.787 0: HMLAN_Parse: hmlan1 R:RBD9CF2FC stat:0008 t:00000000 d:FF r:7FFF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:10:56.789 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D
2015.07.24 03:11:01.229 0: HMLAN_Send:  hmlan1 S:SBD9D06B8 stat:  00 t:00000000 d:01 r:BD9D06B8 m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:11:01.293 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329B705 d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:11:01.485 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329B7CE d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:11:01.677 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:0329B896 d:FF r:FFCE     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:11:01.839 0: HMLAN_Parse: hmlan1 R:RBD9D06B8 stat:0008 t:00000000 d:FF r:7FFF     m:81 A001 1ACE1F 24AF1D 0009
2015.07.24 03:11:01.841 0: HMLAN_Parse: hmlan1 no ACK from 24AF1D

2015.07.24 03:25:30.127 0: HMLAN_Parse: hmlan1 R:E24AF1D   stat:0000 t:03341CC6 d:FF r:FF99     m:8E 845E 24AF1D 000000 8009670000000000095001

gruss frank

[frank]

hallo martin,
hast du schon mal einen blick auf den letzten post geworfen?

gruss frank

[martinp876]

der Ablauf ist soweit ok...das Device anwortet nicht
Funktioniert das Kommando getSerial bei deinem Device? Bei meinem geht es. Könnte ein Problem sein, da es nicht dokumentiert ist

[frank]

getserial funktioniert schon. das er nachts einige zeit schlechte verbindung hat ist auch ok.

es geht um die meldungen des actiondetectors. ich habe verstanden, dass unknown nur bei restart kommt. ist bei allen anderen devices auch so.

wie oben beschrieben kommt bei diesem device nach ablauf des actioncyclus (10 min) jedesmal unknown. erst nach einem weiteren cyclus (20 min) ohne meldungen kommt dead.

[martinp876]

alles klar-

unknown wurde bei devices mit attr actAutoTry gesetzt wenn sie das Kommando getSerial oder statusRequest unterstützen. Wenn die Zeit abgelaufen war und der Versuch gestartet wurde wurde auch hier unknown gemeldet. nach dem Versuch wird entweder alive oder dead gesetzt.

Ich lasse nun den Status wie vor während dieser Phase.