hallo,
Ich möchte die Lebenszeichen von meinen devices überwachen. Immer wenn eine gewisse Zeit kein Signal kommt, soll fhem mir eine Mail schicken. Das funktioniert inzwischen ganz gut.
Jetzt kommt immer mal wieder ein "unknown" State. Den würde ich gerne ignorieren und
...eine Mail schicken, wenn der State im actiondetector für ein Device auf dead springt
...eine Mail schicken, wenn der State im actiondetector für ein Device von dead auf alive springt.
Wenn der State z. B. von unknown auf alive springt, will ich keine Mail versenden.
Wie bekomme ich das hin? Kann man auf den vorherigen Wert einer Variablen (%EVTPART1) zugreifen? Oder erst bei einer bestimmten Änderung von/auf triggern?
Mein aktueller notify code:
ActionDetector:status_.* {
if ("%EVTPART1" eq "dead") {
system("/volume1/addons/fhem/bin/sendmail.sh", "Dead device (%EVTPART0)", "Ein Device meldet sich nicht mehr: %EVENT");
} else {
if ("%EVTPART1" eq "alive") {
system("/volume1/addons/fhem/bin/sendmail.sh", "Alive device (%EVTPART0)", "Ein Device hat sich zurueckgemeldet: %EVENT");
} else {
system("/volume1/addons/fhem/bin/sendmail.sh", "Unexpected device state (%EVTPART0)", "Ein Device hat einen unerwarteten state gemeldet: %EVENT");
}
}
}
attr Actiondetector event-on-change-reading .*
Danach werden Events nur noch für Zustandsänderungen generiert, das müsste wenn ich Dich richtig verstanden habe das sein was Du willst.
EDIT: das hilft natürlich nicht, ich hab überlesen dass du unknown->alive ignorieren willst, sorry.
Ich würde das einfach über HMinfo lösen, da gibt es einen event, sobald ein Device als "dead" erkannt wird. Und man kann einfach auslesen, um welches Gerät es sich handelt.
(Dass ich mal HMinfo empfehlen würde, hätte ich auch nie gedacht...)
Ja genau, ich möchte genau bei diesen beiden events eine mail bekommen.
Zu HMInfo: ich habe dieses virtuelle device schon mal angelegt. Bietet das denn auch wirklich für beides eine Lösung?:
Zitat...eine Mail schicken, wenn der State im actiondetector für ein Device auf dead springt
...eine Mail schicken, wenn der State im actiondetector für ein Device von dead auf alive springt.
Ich müsste mich da neu einlesen, daher würde ich gerne vorher wissen, wenn die zweite mail damit nicht machbar ist.
ZitatIch müsste mich da neu einlesen, daher würde ich gerne vorher wissen, wenn die zweite mail damit nicht machbar ist.
lesen bildet, kann somit nie unnötig sein. hminfo bietet sehr viel mehr.
grundsätzlich brauchst du einen speicher, der dir den letzten zustand speichert, da dich gewisse übergänge nicht interessieren. die mail musst du dann in abhängigkeit vom letzten und aktuellen zustand senden. so wie du das möchtest. einen speicher kannst du mit einem dummy oder über ein zusätzliches reading mit setreading realisieren. eventuell kann man das auch über hminfo oder doif. alle möglichkeiten sind aufwändig, da man sich bei so einem speziellen fall genau einlesen muss. probieren geht über studieren.
Ich mache das der Einfachheit halber auch über den ActionDetector, da dich ja nur die Änderungen interessieren, und HMInfo event-on-change-reading nicht sauber unterstützt (es generiert Events, die man für den folgenden Ansatz zusätzlich unterdrücken müsste, wie schon erwähnt über einen DUMMY, das war mir zu aufwendig - ich hatte dazu auch eine längere Diskussion dazu ...)
Aber mit dem Actiondetector geht das prima:
system.actiondetector.*status_.* {
my $device;
my $ev;
my $headline = "Systemwarnung";
my $priority = "0";
if($EVENT =~ m/.*status_(.*):\s(.*)/) {
$device = AttrVal($1,"alias",$1);
$ev = $2;
if ($ev eq "unknown") {$ev = "Seit kurzem kein Kontakt zu $device!";$priority = "-1";}
elsif ($ev eq "dead") {$ev = "Sensor $device länger ausgefallen!";}
elsif ($ev eq "alive") {$ev = "Sensor $device online.";$priority = "-1";$headline = "Systemmeldung";}
fhem("set system.pushover.default msg '$headline' '$ev' 'iPhone_Peter' $priority 'mechanical' ");
fhem("set system.pushover.default msg '$headline' '$ev' 'iPad' $priority 'mechanical' ");
}
}
Den Namen vom Actiondetector (Hier: system.actiondetector) und den Aufruf für die Notifizierung musst du dir natürlich noch entsprechend anpassen. Das Notify ersetzt auch den Devicenamen durch sein Alias, falls vorhanden.
Edit: Hups ich sehe gerade du willst den Übergang unknown -> alive ausfiltern, das tut das natürlich nicht. Ich habe aber die Erfahrung, dass wenn der status "unknown" ist, das Gerät i.d.R. genauso tot ist wie bei "dead", es kommt nur früher ne Meldung. Daher stört mich das nicht so.
Hallo,
Anfangs bekam ich für einige Fensterkontakte den State "unknown", daher dachte ich, das käme häufiger vor. Aber inzwischen geht mein Testkontakt immer direkt von alive auf dead und umgekehrt. Daher hat sich mein Problem erledigt. Ein Zugriff auf den vorherigen Wert einer Variable/readings usw. fände ich trotzdem cool.
Danke für den Support!
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.
Hej folks,
habe gerade ein kleines Verständnisproblem und hoffe, ihr könnt mir weiterhelfen. :-)
Wenn ich über ein Notify am ActionDetector ein Event auslösen möchte, komme ich sichtlich nicht ohne weiters an den eigentlichen Gerätenamen, da dieser ja Teil von EventPart0 ist. Also: status_<DEVICENAME>:
Dadurch gelingt es mir auch nicht wirklich, den Alias des Geräts auszulesen oder weitere Tests mit Werten von dem Gerät durchzuführen.
Gibt es eine Möglichkeit, die sich mir gerade nicht erschließt, oder muss ich zwangsläufig mit Regex arbeiten und alle Zeichen nach dem ersten Unterstrich und vor dem letzte Zeichen herausfiltern, um an das gewünschte Ergebnis zu kommen?
Vielen Dank für eure Antworten! :-)
Wie waers mit get actionDetector listDevice dead
Zitat von: martinp876 am 03 April 2015, 20:49:56
Wie waers mit get actionDetector listDevice dead
Hej Martin,
danke für deine Antwort.
Womöglich hab ich gerade auch nur ein Brett vorm Kopf, aber inwiefern hilft mir das, um mir ein Notify zu bauen?
Oder hast du gemeint, sobald der ActionDetector ein Device als dead meldet, kann ich unter zu Hilfenahme des 'get' die entsprechende Liste ausgeben lassen?
Was ich gerne konkret machen möchte, wäre eine Benachrichtigung von dem entsprechenden Gerät zu versenden, sofern dieses die Spannung mitüberträgt und diese unter den Wert xy gesunken ist. Insofern ist die Liste nur bedingt brauchbar, als das nur ein Gerät drinnen stehen dürfte (oder ich müsste die Liste zerpflücken und durchiterieren).
Der actiondetector meldet zyklisch. Du kannst bei change die liste der toten durch das get bekommen, dafuer ist es gedacht.
Du kannst aber auch auf das event triggern, das beim device kommt, welches tot ist.
Kann man auch bauen.
Zitat von: martinp876 am 03 April 2015, 21:05:27
Der actiondetector meldet zyklisch. Du kannst bei change die liste der toten durch das get bekommen, dafuer ist es gedacht.
Einfach zum Ausgeben einer Liste perfekt. Zum einfachen Weiterverarbeiten der einzelnen Geräte nicht soooo gut geeignet. :-)
Zitat von: martinp876 am 03 April 2015, 21:05:27
Du kannst aber auch auf das event triggern, das beim device kommt, welches tot ist.
Kann man auch bauen.
Wäre mein nächster Ansatz gewesen.
Wollte mir nur das Eintragen bei allen in Frage kommenden Geräten ersparen. Schließlich gibt es den Trigger vom ActionDetector ja schon.
Ich würd' mir den ActionDetector ja umbauen, aber ist ohne deine Unterstützung gerade einmal bis zum nächsten Update sinnvoll.
Du würdest nicht vielleicht ein paar ähnliche Änderungen wie diese in Erwägung ziehen (ist hier natürlich nur ein User-Attribut)?
--- /tmp/10_CUL_HM.pm 2015-03-25 12:26:25.178528707 +0100
+++ /usr/lib/fhem/FHEM/10_CUL_HM.pm 2015-04-04 01:52:05.328492889 +0200
@@ -6947,13 +6947,15 @@
my @event;
my ($cntUnkn,$cntAliv,$cntDead,$cnt_Off) =(0,0,0,0);
my $autoTry = CUL_HM_getAttrInt($actName,"actAutoTry",0);
+ my $useDeviceNameOnly = AttrVal("ActionDetector","use-devicename-only",0);
foreach my $devId (split(",",$peerIDs)){
next if (!$devId);
my $devName = CUL_HM_id2Name($devId);
if(AttrVal($devName,"ignore",0)){
- delete $actHash->{READINGS}{"status_".$devName};
+ if($useDeviceNameOnly eq 1) { delete $actHash->{READINGS}{$devName}; }
+ else { delete $actHash->{READINGS}{"status_".$devName}; }
next;
}
@@ -7013,7 +7015,8 @@
$attr{$devName}{actStatus} = $state;
Log3 $actHash,4,"Device ".$devName." is ".$state;
}
- push @event, "status_".$devName.":".$state;
+ if ($useDeviceNameOnly eq 1) { push @event, $devName." :".$state; }
+ else { push @event, "status_".$devName.":".$state; }
}
push @event, "state:"."alive:".$cntAliv
." dead:".$cntDead
Du musst es nicht an jedem device eintragen, du kannst ein entity-unabhaengiges notify bauen. Einfach nur activity auswerten.
Deinen vorschlag sehe ich mir an
Zitat von: Mr. P am 03 April 2015, 19:15:38
Hej folks,
habe gerade ein kleines Verständnisproblem und hoffe, ihr könnt mir weiterhelfen. :-)
Wenn ich über ein Notify am ActionDetector ein Event auslösen möchte, komme ich sichtlich nicht ohne weiters an den eigentlichen Gerätenamen, da dieser ja Teil von EventPart0 ist. Also: status_<DEVICENAME>:
Dadurch gelingt es mir auch nicht wirklich, den Alias des Geräts auszulesen oder weitere Tests mit Werten von dem Gerät durchzuführen.
Gibt es eine Möglichkeit, die sich mir gerade nicht erschließt, oder muss ich zwangsläufig mit Regex arbeiten und alle Zeichen nach dem ersten Unterstrich und vor dem letzte Zeichen herausfiltern, um an das gewünschte Ergebnis zu kommen?
Vielen Dank für eure Antworten! :-)
verstehe ich da was falsch, oder sollte das nicht zb so zu ermitteln sein (eine zeile für die fhem.cfg :) ):
my $dev = $1 if($EVTPART0 =~ m/^status_(.*):$/);;\
define alarm notify .*:Activity.* dosomethingwith $NAME
klappt das nicht?
Zitat von: frank am 04 April 2015, 19:40:09
verstehe ich da was falsch, oder sollte das nicht zb so zu ermitteln sein (eine zeile für die fhem.cfg :) ):
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. :-/
Zitat von: martinp876 am 04 April 2015, 20:34:52
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. :-)
kann ich nicht nachvollziehen. Ich haben meinen test-VD genommen. dann - weil ich ungeduldig bin habe ich:
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
{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
attr vd event-on-change-reading .*
gesetzt - bei mir IMMER
nicht zu vergessen, das notify
define alarm notify .*:Activity.* {Log 1,"we got an Activity:$NAME - $EVENT"}
wenn ich nun die Batterie einlege kommt im Logfile
2015.04.06 12:26:55.348 1: we got an Activity:vd - Activity: alive
und wenn ich die Batterie rausnehme
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:
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.
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!
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.
Zitat von: martinp876 am 24 Januar 2015, 12:29:41
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?
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: alive2015.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 8009670000000000095001gruss frank
hallo martin,
hast du schon mal einen blick auf den letzten post geworfen?
gruss frank
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
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.
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.