ActionDetector

[kossmann]

Hallo zusammen,

bei batteriebetriebenen Sensoren wird mittels autocreate immer ein ActionDetector (und zugehöriges FileLog) angelegt. Dazu habe ich ein paar Fragen:

- einer pro Sensor oder einer für alle
Der ActionDetector wird immer mit der HMID 000000 angelegt. Darf diese mehrmals existieren, wenn beispielsweise für 3 Rauchmelder 3 Detektoren mit dieser HMID definiert werden? Die Definition sieht ja für alle Rauchmelder identisch aus, mit Ausnahme der peerIDs - macht es in diesem Fall Sinn, einen ActionDetector anzulegen und die IDs der Rauchmelder in einer kommaseparierten Liste als peerIDs anzugeben?

- actiondetect und actCycle - Sendefrequenz der Sensoren erkennen
Wenn ich es richtig verstanden habe, setzt man für jeden Sensor mittels actiondetect die Zeit, in der ein Sensor sich mit einem Status melden muss, bevor er als "dead" gilt. Dieser Wert wird nur in FHEM gesetzt und nicht in den Sensor geschrieben, oder? Ausgewertet wird er von dem zugehörigen ActionDetector, nehme ich an.
Woher weiß ich, in welchen Abständen (Frequenz) sich ein Sensor normalerweise meldet? Ein autocreate setzt hier nämlich verschiedene Werte im ActionDetector für Rauchmelder und Türgriff-Sensoren.
Was macht im Gegensatz dazu der actCycle? Aus der ComandRef werde ich nicht ganz schlau. Prüft er das ganze nur alle x Sekunden? Sind 600 Sekunden (10 Minuten) für einen Rauchmelder nicht etwas übertrieben? Wie soll dieser in der Praxis "sterben"?

- Funktionsweise und Sinn
Hat der Detektor nur den Sinn, ein Gerät "dead" zu setzen oder was macht er alles? Die Alive-Meldungen eines Sensors bekommt FHEM doch auch so mit (wenn der Sensor diese sendet), oder? Für den Batteriestatus müsste gleiches gelten (FHEM bekommt es auch so mit), oder?

Ich danke schon mal für Aufklärung ;-)

[martinp876]

bei batteriebetriebenen Sensoren wird mittels autocreate immer ein ActionDetector (und zugehöriges FileLog) angelegt.
- einer pro Sensor oder einer für alle
Der ActionDetector wird immer mit der HMID 000000 angelegt. Darf diese mehrmals existieren, wenn beispielsweise für 3 Rauchmelder 3 Detektoren mit dieser HMID definiert werden?

das logfile ist je nach geschmack. Logfiles kosten Zeit und jeden muss entscheiden wieviele und welche er braucht.
Man braucht nur einen actionDetector fuer beliegig viele devices. Dies soll performance sparen.
Die peerList des ActionDetectors ist die Liste aller devices, die dieser ueberwacht.
Konkret: der -eine- actiondetector ueberwach ALLE devices, bei denen dies gewünscht ist, egal ob Rauchmelder oder sonstiges.

- actiondetect und actCycle - Sendefrequenz der Sensoren erkennen
Wenn ich es richtig verstanden habe, setzt man für jeden Sensor mittels actiondetect die Zeit, in der ein Sensor sich mit einem Status melden muss, bevor er als "dead" gilt. Dieser Wert wird nur in FHEM gesetzt und nicht in den Sensor geschrieben, oder? Ausgewertet wird er von dem zugehörigen ActionDetector, nehme ich an.

der actionDetector dient dazu verstorbene Devices zu alarmieren. einige HM devices liefern einen batteriestatus "low". Das ist eine Warnung. Aber der Ernstfall ist, wenn die Batterie leer ist. Dann kann das device nicht mehr senden. Somit HM liefert bei einigen devices zyklisch messages und unterstuetzt somit eine 'externe' ueberwachtung. Der ActionDetector ist nun die logische konsequenz - also der Alarm zum Ausbleiben dieser Messages. Die überwachung findet also ausschliesslich in FHEM statt.
Das Verfahren soll performance-sparend sein da es nur eine Hintergrund-aktivitaet ist. Ferner ist es 'allgemein' gehalten um Usern die Möglichkeit zu geben auch sonstige Devices auf 'leben' zu ueberwachen. Soll heissen wenn ein device defekt ist, nicht mehr sendet, gestohlen ist,... . Eben wenn es in der angegebenen Mindestzeit keine message von sich gegeben hat.

Das Verfahren ist: Der ActionDetector wird regelmaessig geweckt - die Abstände kann der User mittels actCycle im action detector einstellen.
Immer wenn er wach ist prüft er ALLE devices in seiner peerList auf eine Zeitüberscheitung. Jegliche message vom device wird als 'action' gewertet und wuerde ihn als 'alive' markieren.
Die maximale 'no-action-dauer' wird im device in actCycle eingestellt. Beachte: Bedeutung von actCycle eines device unterscheidet sich von dem des ActionDetector selbst.

Der ActionDetector wird fuer Devices mit regelmaessigen Messages automatisch eingeschaltet. Er macht nur Sinn bei Devices, nicht bei Kanaelen. Die Cycle-werte sind den XML Daten von HM entnommen.

Der User kann andere Devices auch beliebig selbst eintragen wenn er dies für nötig haelt - sollte dies aber mit dem Funktionen wie im Commandref beschrieben machen.

Woher weiß ich, in welchen Abständen (Frequenz) sich ein Sensor normalerweise meldet? Ein autocreate setzt hier nämlich verschiedene Werte im ActionDetector für Rauchmelder und Türgriff-Sensoren.

aus dem commandref

Was macht im Gegensatz dazu der actCycle? Aus der ComandRef werde ich nicht ganz schlau. Prüft er das ganze nur alle x Sekunden? Sind 600 Sekunden (10 Minuten) für einen Rauchmelder nicht etwas übertrieben? Wie soll dieser in der Praxis "sterben"?

actDetect ist der aktuelle Zustand, actCycle die Zykluszeit.
Du kannst gerne den Wert hoch setzen, das ist kein Problem. Merke, dass hier keine messages zum Device gesendet werden. Der Aufwand und die Performance gehen also nicht zu Lasten der besoderns kritischen 'luft-schnittstelle' es wird ausschliesslich die CPU belastst....
Du hast recht damit, dass der wert recht schnell ist, ich denke aber vertretbar. Einige wollte es noch viel schneller haben. Du kannst es bis 30sec runterdrehen - oder bis über 100h hoch.

- Funktionsweise und Sinn
Hat der Detektor nur den Sinn, ein Gerät "dead" zu setzen oder was macht er alles? Die Alive-Meldungen eines Sensors bekommt FHEM doch auch so mit (wenn der Sensor diese sendet), oder? Für den Batteriestatus müsste gleiches gelten (FHEM bekommt es auch so mit), oder?

hmm - also alive bekommst du, wenn der Sensor wieder erwacht. Das sagt die, dass das device einen Stromausfall hatte. Evtl interessiert dich dies weil jemand an deinen devices spielt. Es sagt nichts ueder empfangsprobleme aus. Es gibt auch keine Meldung, wenn die Batterie leer ist, erst wenn du sie erneuert hast.
Batterie-low ist eine Meldung des Device. Wenn du auf sie korrekt reagierst sollte die Batterie nicht ausfallen. Es gibt keine Meldung wenn die Erkennung fehlschlaegt (batterie verstirbt schlagartig, low-bat wird nicht erkannt weil der Empfang zu schlecht ist - evtl weil die Batterie low ist und die entfernung zu gross. Oder: de Aktor ist einfach defekt.

Aus meiner Sicht hat du eine Lücke - die einige kritische details beinhaltet - eigentlich die kritischsten überhaupt. Dein SD - den du nicht taeglich überprüfen willst - meldet sich nicht.
Vorteil der überwachung ist, dass diese komplett unabhaengig von allen denkbaren Fehlern deines Devices einen Alarm auslöst - ganz egal warum er sich nicht meldet.

Es bietet auch die Möglichkeit - wer will - sämtliche devices zu überwachen (falls man eine grosse installation hat) und einen Alarm zu bekommen wenn devices tagelang nicht 'gesehen' wurden. (bis zu 999h). dann kann man beispeilsweise einfach einen statusrequest losschicken und bekommt Klarheit, der Alarm verschwindet nach dem nächsten ActionDetector cycle. Dies ist optional, wer es braucht.

Ich hoffe dies erläutert die Hintergründe

[kossmann]

Hallo Martin,

vielen Dank für die Erklärung (du hast mittlerweile einige Bier gut). Das Thema scheint nicht ganz einfach zu sein.

Ich gehe mal davon aus, dass du dich nicht verschrieben hast... ein actCycle wird im ActionDetector gesetzt und kann zusätzlich individuell pro Device gesetzt werden? In der ComandRef set unterhalb von CUL_HM jedoch ein actiondetect. Ist dies etwas anderes?

Kurzum:

Kann ich (bzw. sollte man) einen ActionDetector definieren, mit allen batteriebetriebenen Devices in der peer-Liste und muss in den Devices selbst nichts machen? ... oder muss dort (in den Devices) etwas gesetzt werden (z.B. actCycle oder actiondetect)?

[jhohn]

Mit set ActionDetector actiondetect hhh:mm setzt Du die Zeit für den Actiondetector.
Mit set <device> actiondetect hhh:mm setzt Du actStatus auf unknown und actCycle für das Device auf die angegebene Zeit.

Ich habe bei mit actCycle des Actiondetector auf der Standardzeit (10min.) stehen und für Thermostate auf 000:30. So sollte der Status auf dead wechseln wenn die Thermostate nach 3 Durchläufen des ActionDetector keine Meldung abgegeben haben.

Jedenfalls habe ich das so verstanden.

[martinp876]

@jhohn - absolut korrekt

@kossmann:
bei einigen Devices wird der Actiondetector automatisch initialisiert. Denn du eigenen devices addieren willst kannst du
set <dev> actiondetect <hhh:mm>
benutzen - er wird alles andere fuer dich erledigt. Schau ins commandref.

Du kannst damit auch die Zeiten verstellen.
Alternativ kannst du das attribut im device (nachdem es von actiondetect angelegt wurde) veraendern.

Wenn du alles mit dem Kommando machst werden ein paar checks durchgeführt - ist also sicherer. Manuell anlegen empfehle ich daher nicht.

Gruss
Martin

[jhohn]

Was mir eben noch aufgefallen ist: Wenn ich die Fenstersensoren HM-SEC-RHS zum ActionDetector hinzufüge, wird deren Status auf "actiondetect hhh:mm" gesetzt und bleibt so bis sich der Status mal ändert, also das Fenster auf oder zu gemacht wird. Muss das so sein oder lässt sich das abstellen? Ich habe das bei einem Kontakt übersehen und dadurch ist in diesem Raum die Heizung nicht mehr angegenagen, wil ich auf "closed" prüfe.

[martinp876]

schaue ich mir an. ActionDetect hat eigentlich nichts im status zu suchen. ist aber eigentlich unterdrückt...

[Dennis D.]

Das mit dem "actiondetect hhh:mm" im status kann ich ebenfalls bei den Fensterkontakten bestätigen. Habe dadurch aus versehen meine alarmanlage ausgelöst :-).

Habe aber auch noch ein paar Fragen zum ActionDetector, da ich das aus dem Commandref und dem Thread hier nit so ganz schlau werde.

1. Ich habe meinen ActionDetector auf dem Standart-actCycle "600" stehen und es werden 11 Devices (Fensterkontakte) überwacht.
Die Fensterkontakte haben in ihren Readings bei alive "yes" stehen und bei den attibuten einen actCycle von "027:00". Ab und zu habe ich in der Auflistung vom ActionDetector mal bei einzelnen Geräten für kurze Zeit ein "alive" stehen. Meistens steht jedoch "unknown" oder "dead" dort. Was muss ich machen, damit der richtige Status auch im ActionDetector erscheint?

2. Wenn ich das richtig verstanden habe, dient der ActionDetector lediglich für diese "Dead/Alive"-Geschichte, um ggf. über ein Notify eine Benachrichtigung zu erhalten, wenn ein Gerät nicht mehr als "alive" gelistet ist. Benötigt man diesen ActionDetector eigentlich zwingend? Habe den bisher drin gelassen, weil er halt automatisch angelegt wurde und ich dachte "dat g'hört so."

3. Bei Fernbedinungen und den AP-Tastschaltern habe ich im Status immer stehen ... (to ActionDetector), obwohl die Fernbedienung/ der Schalter nicht vom ActionDetector überwacht wird. So nimmt z.B. mein AP-Schalter folgenden Status an: "ANLAGE_SCHARF_intern_off Short (to ActionDetector)". Hat das seine Richtigkeit?

Viele Grüße,
Dennis

[tobi73]

Hallo zusammen!

Bei Fernbedinungen und den AP-Tastschaltern habe ich im Status immer stehen ... (to ActionDetector)

-> ist mir auch aufgefallen. Ich schätze, es liegt daran, dass diese Meldungen der Fernbedienungen und Schalter Broadcast Meldungen sind. BC Adresse ist 000000. Genau diese Adresse hat aber auch das "Device" ActionDetector. Wenn kein ActionDetector existiere würde, wäre im Log gestanden "... to broadcast", da es aber den ActionDetector mit der Adresse 000000 gibt, steht da halt "to ActionDetector".

Martin, kann das sein, kannst du Dir das auch mal ansehen?

Ansonsten: Finde die Idee mit dem Actiondetector klasse und bin auch gerade dabei, die Batteriedevices ständig zu überwachen, was absolut Sinn macht - sonst steigen die ganzen Türkontakte aus, niemand merkt's und der Einbrecher freut sich ;-)

Gruß Tobias

[martinp876]

unknown kommt immer nach einem restart von FHEM. Der letzte Zustand wird nicht gespeichert und somit nach jedem restart neu errechnet. Bis zur "feststellung" bleibt er "unknown".

"dead" kommt immer wenn die eingestellte Zeit überschritten wurde seit der letzten Nachricht von device (oder Kanal- falls jemand es an einem Kanal einrichtet).

Wenn du es an einem Fensterkontakt hast und 27:00 einstellst sollte "dead" kommen wenn der kontakt 27h nichts gemeldet hat, auch kein ack.

Zwingend benötigt man ihn nicht. Wichtig ist er nach meinem Dafürhalten für rauchmelder, also batteriebetriebene Sicherheitsdevices.
Automatisch eingerichtet wird er nur bei devices die sich automatisch melden sollten.
Abschalten kann man ihn für diese devices indem man sie 'off' setzt.

das mit 'to ActionDetector' werde ich überarbeiten. Leider habe ich mir beim ActionDetector die HMID "000000" einreden lassen. War eine Fehlentscheidung da dies auch "Broardcast" ist. Deshalb muss ich hier nacharbeiten und dies in diesem Fall umschreiben...

Gruss
Martin

[Dennis D.]

Danke für die Erklärung. Glaube jetzt hab auch ich es kapiert.

Das mit der Batterieüberwachung habe ich bisher so gelöst:

define Batterie_TuerKontakt_WZ_pruef at *17:00:00 {if (ReadingsVal("WZ_TuerKontakt","battery","ok") ne "ok") {fhem ("trigger Batterie_TuerKontakt_WZ")}}

Die halt für jedes Device. Ist das zu kompliziert gedacht von mir? Ist es besser das über den ActionDetector laufen zu lassen?

Das komisch ist, dass innerhalb dieser 27 Stunden die Sensoren schon mal geöffnet werden und somit doch ein Signal senden. Zudem dachte ich, die Fensterkontakte würden generell alle 20 Minuten oder so nen Status senden. Das die bei mir aus dead gehen müsste doch bedeuten, dass sie über 27 Stunden keinen Status melden.

Gruß,
Dennis

[martinp876]

Das mit der Batterieüberwachung habe ich bisher so gelöst:

define Batterie_TuerKontakt_WZ_pruef at *17:00:00 {if (ReadingsVal("WZ_TuerKontakt","battery","ok") ne "ok") {fhem ("trigger Batterie_TuerKontakt_WZ")}}

Die halt für jedes Device. Ist das zu kompliziert gedacht von mir? Ist es besser das über den ActionDetector laufen zu lassen?

ich denken schon. Der fängt auch ab, wenn die Batterie leer ist, ohne "low" gemeldet zu haben. Wenn du sicher bist, dass HM immer erst low sendet und dass diese message nicht verloren gehen kann sollte es genügen. Mir waere dies nicht sicher genug. Es gibt verschiedene Batterien, die sterben verschieden schnell... und wenn sie versterben - reicht die power noch aus größerer Entfernung (schwacher Empfang) die Nachricht sauber zu übertragen? Bis du hier sicher bist kannst du sehr viel ausprobieren.
Dem ActionDetector ist dies alles egal. Wer nicht liefert hat ein Problem und muss geprüft werden.
Performanceschonender sollte er in jeden Fall sein
Ob du ihn für zu kompliziert hältst weiss ich nicht. Ich denke er ist auch übersichtlich - du hast immer eine Liste aller eingetragenen devices sowie den Zustand an jeden Device selbst.

Das komisch ist, dass innerhalb dieser 27 Stunden die Sensoren schon mal geöffnet werden und somit doch ein Signal senden. Zudem dachte ich, die Fensterkontakte würden generell alle 20 Minuten oder so nen Status senden. Das die bei mir aus dead gehen müsste doch bedeuten, dass sie über 27 Stunden keinen Status melden.

Der ActionDetector prüft den "protLastRcv" zeitstempel, das ist alles. Den kannst du auch selbst nachsehen - wenn sich dein schalter alle 20min meldet gib noch einmal beschied - dann wäre ein bug im code. Ansonsten prüfe deinen Schalter.

Gruss
Martin

[Dennis D.]

...Ob du ihn für zu kompliziert hältst weiss ich nicht. Ich denke er ist auch übersichtlich...

Ne, da haste mich missverstanden. Fragte ob ich mit meiner Batterierüfung zu komliziert denke und ich das mit dem ActionDetector einfacher lösen kann.

... wenn sich dein schalter alle 20min meldet gib noch einmal beschied - dann wäre ein bug im code. Ansonsten prüfe deinen Schalter.

Keine Ahnung ob der alle 20 Minuten sendet. Ich DACHTE die Fensterkontakte würden das machen (meine das mal gelsen zu haben).

Senden die Fensterkontakte AUSSCHLIEßLICH, wenn der Kontakt geöffnet oder geschlossen wird, oder geben die auch so ab und zu mal ne Statusmeldung ab?? Wenn ja, in welchem Abstand?

Wenn die Fensterkontakte NUR senden, wenn sie geöffnet oder geschlossen werden, dann würde dies bedeuten, dass nach 27 Stunden das Gerät auf "dead" gesetzt wird? In diesem Fall würde sich die ganzen "dead" Meldungen erklären, da wir die meisten Fenster nicht so oft öffnen (haben ne kontrollierte Wohnraumlüftung). Gibt es in diesem Fall dennoch eine Möglichkeit den ActionDetector zur "Alive"-Prüfung zu verwenden?

Gruß,
Dennis

[tobi73]

Ich seh's wie Martin. Alleine den Batteriealarm zu überwachen ist nicht unbedingt sicher. Mir ,,stirbt" regelmäßig mein HM-SCI-3-FM wegen leerer Knopfzelle, ohne dass er sich je mit einem Low-Battery verabschiedet hätte (ungezogenes Ding ;-)  zum Glück ist der stationär, der bekommt demnächst mal eine 3V Festspannung angelötet).

Einem HM-Bewegungsmelder versuch seit Tagen verzweifelt einen Batteriealarm mit leergelutschten AA Zellen zu entlocken - ohne Erfolgt. Keine Ahnung, ob die Spannungserkennung im Device nicht tut, die Batterie zu schnell absinkt oder gar fhem den Bat-Alarm doch nicht richtig auswertet (das glaub ich aber am wenigsten). Muss mal in Ruhe messen und ein Labornetzgerät dranhängen...

Zum Verständnis: Grundsätzlich sind Batteriealarm und Action Detection zwei paar Stiefel. Ersteres ist eine Meldung, die das Gerät senden sollte, wenn die Batterie leer ist. Wie gesagt, das ist unsicher.  Zweiteres ist ein Geräte-Attribut (!), das vom Action Detector gesetzt wird, wenn er merkt dass das Gerät seit einer bestimmten Zeit nichts mehr ,,sagt". Auf beide Ereignisse kannst Du per Notify reagieren.  

Ich hab daher auch beides (Action Detection und Batteriealarm) ausgewertet: pro batteriebetriebenem Device hab ich einen Dummy definiert, der die Werte ,,alive", ,,dead" oder ,,lowbat" annehmen kann. Ein notify wertet die Device Messages aus und setzt in einer Perl Funktion den jeweiligen Dummy auf den entsprechenden Wert. Ein paar Symbole dazu tun ihr Übriges: Ist alles OK, grünes Symbol, meckert das Teil wegen niedrigem Batteriestand (hatte ich wie gesagt noch nie), kommt ein gelbes Batteriesymbol und gibt das Teil keinen Mucks mehr, ein rotes Fragezeichen. So sollten alle Eventualitäten abgefangen sein. Wenns tatsächlich mal einen Batteriealarm gibt, wird ich rechtzeitig gewarnt. Wenn nicht, merke ich es spätestens, wenn das Teil (oder besser Action Detection) ,,dead" sagt.

Zu Deiner letzten Frage: Fensterkontakte senden immer wenn sie ihren Status ändern (Ok, das ist trivial) und spätestens ca. alle 24 Stunden. MWn ist diese zyklische alive Meldung aber konfigurierbar. So wie ich gesehen habe in fhem nicht (regset gibt da nichts aus) aber Du hast ja einen HMLAN, da kannst Du dich mal über die Windows Konfigsoftware verbinden und nachsehen ob sich das einstellen lässt. Das muss dann natürlich angeschaltet sein, ansonsten ist's wie Du schreibst: Irgendwann nach Deinen 27h geht das Device auf ,,dead". Logisch, wie soll der Action Detector auch sehen ob das Ding tut, wenn es  nichts sendet...

Gruß Tobi

[Dennis D.]

Das leuchtet mir ein.

Deine Lösung mit der Kombinierten Abfrage finde ich echt gut. So was schwebt mir auch vor. Würdest Du deine Perl-Funktion und den Rest um das umzusetzen mal zur Verfügung stellen? Den Weg den ich über die tausend Notifys gegangen bin finde ich ziemlich aufgebläht für ne Batterie-Prüfung. Habe halt pro überwachtem Device zwei Notifys angelegt, da ich gerne in meiner Nachricht stehen haben wollte, welches der Devices leer ist.

Habe das bei mir über folgenden Code umgesetzt:

Code Auswählen Erweitern


define Batterie_TuerKontakt_WZ notify Batterie_TuerKontakt_WZ "printf "Subject:ACHTUNG Batterie Tuerkontakt Wohnzimmer leer\nTo:xxx@@xxx.de\nFrom:fhem@@xxx.de\n\nDie Batterie vom Tuerkontakt im Wohnzimmer ist leer. Bitte wechseln." | sendmail -t"
attr Batterie_TuerKontakt_WZ alias bei leerer Batterie vom Türkontakt Wohnzimmer
attr Batterie_TuerKontakt_WZ group E-Mail Benachrichtigungen
attr Batterie_TuerKontakt_WZ room FHEM
define Batterie_TuerKontakt_WZ_pruef at *17:00:00 {if (ReadingsVal("WZ_TuerKontakt","battery","ok") ne "ok") {fhem ("trigger Batterie_TuerKontakt_WZ")}}
attr Batterie_TuerKontakt_WZ_pruef room hidden

Wohlgemerkt ist dies nur für ein Device. Mir kommt das nach ner unsauberen Lösung eines FHEM-Noobs aus *g*. Man kann das bestimmt eleganter lösen, oder?