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?

[tobi73]

Hi,
versucht hab ich das Ganze mit einem Notify pro Devicetyp zu realisieren. Setzt aber voraus, dass eine konsequente und eindeutige Namensgebung vorliegt, bei der du per regex eindeutig alle zu überwachenden Devices herausfindest. Ich bin zwar kein Fan davon, über Devicenamen irgendwelche Aktionen zu steuern, bei den Notifies hab ich aber keine andre Lösung gefunden... Wenn ich richtig sehe, hast Du das mit den Namen aber schon mal ähnlich gelöst wie ich:

Bsp: Fensterkontakte sind bei mir so zu identifizieren:
Ein Kürzel für den Raum mit mindestens 2 Buchstaben, danach ,,_FK" für Fensterkontakt und dann eine laufende Nummer. Ergibt folgendes Notify

Code Auswählen Erweitern

\D{2,}_FK\d{1,}.?(battery:.low|Activity:alive|Activity:dead) {health("@","%")}
Der reagiert also, wenn einer der FKs eine kritische Meldung abgibt und ruft dann die Funktion health($$) in 99_myUtils.pm  auf, die den Auslöser und die Meldung übergeben bekommt. Sorry, hab gerade festgestellt daß der Code ziemlich doof aussieht, aber als ich das geschrieben hab wars recht spät und nicht mehr das erste Bier ;-) Wahrscheinlich könnte man das ganze sogar inline in den Notify reinbringen - ich hab eigene Funktionen aber lieber, die lassen sich wiederverwenden und sind übersichtlicher.

Code Auswählen Erweitern

sub health ($$) {
my ($obj, $ts) = @_;
my ($bat) = ReadingsVal ($obj, "battery", "");
#Log 1, "Debug: $ts von $obj - Batterie: $bat";

if ($ts eq "Activity:dead") {
fhem ("set ".$obj."_Health missing");
return 1;
      # -> Gerät tot, das wars
}

if ($ts eq "battery: low") {
fhem ("set ".$obj."_Health lowbat");
return 1;
                # -> Gerät da, aber Batterie leer, das wars nun auch.
}

if ($ts eq "Activity:alive") {
              # Gerät wieder am Leben, also wird geprüft, ob die Batterie OK ist...
     if ($bat eq "low") {
                 fhem ("set ".$obj."_Health lowbat");
                 return 1;
     } else {
                 fhem ("set ".$obj."_Health alive");
                 return 1;
              }
}
        return 0;
}
Für jedes Device gibt's wie gesagt einen Dummy, der den ,,Gesundheitsstatus" speichert und im Webfrontend anzeigt. Dieser Dummy heisst genau wie das device selber mit angehängtem ,,_Health".
Auf Sicherheitsabfragen, ob der Dummy existiert oder die Funktion richtig aufgerufen wurde, hab ich hier verzichtet. Wenn man es anständig programmiert, sollte man das eigentlich tun ;-)

Hoffe das hilft etwas!

Gruß,
Tobi

[Dennis D.]

Ok, vielen Dank! Ich denke damit komme ich zurecht. Damit werde ich am WE mal basteln. Nur noch ein paar kurze Fragen zum Syntax:

1. "\D{2,}_FK\d{1,}": Was bedeutet das \D{2,} und was das \d{1,0} ???

2. Bezüglich der Funktion "sub health ($$)": Was bedeutet das ($$)? In manchen Funktionen sieht man mal drei Dollarzeichen und mal zwei. Wieso?

[tobi73]

Hi,

"\D{2,}_FK\d{1,}": Was bedeutet das \D{2,} und was das \d{1,0}

Regex - Syntax:
\d steht für eine Ziffer, ist eine Abkürzung für [0-9]
\D ist die Negierung davon - also [^0-9] -> Heisst ein beliebiges Zeichen, dass keine Ziffer ist.
\D{2,} heisst, dass \D(also eine nicht-Ziffer) mindestens 2xvorkommen muss
\d{1,} analog: eine Ziffer mindestens einmal

Was bedeutet das ($$)

Perl-Syntax: Anzahl der Dollars = Anzahl der Parameter, ganz grob ausgedrückt...

Gruß Tobi

[justme1968]

gibt es eine möglichkeit das peerList reading im ActionDetector zu unterdrücken oder zumindest auf mehrere zeilen aufzuteilen? bei 7 fenstern und eimem bewegungsmelder ist die zeile jetzt schon so lang das sie noch mehr auf den monitor passt. und es werden noch sensoren dazu kommen.

gruss
  andre

[martinp876]

Hallo Andre,

in mehrere Zeilen austeilen kann ich nicht, das macht das Front-end. Habe noch keinen Weg gefunden, dies zu bewerkstelligen - aus CUL_HM heraus...
Unterdrücken ... hm, ich koennte es in den expert-level schieben.

Gruss
Martin

[justme1968]

hallo martin,

ich habe gestern das peerList reading einfach mal gelöscht. nach einem neustart ist es zwar wieder da, die liste ist aber nicht gefüllt.

das peerIDs attribut ist richtig gefüllt und die überwachung scheint zu gehen. wenn es sonst keine negativen seiteneffekte hat  kann ich damit auch leben :)

gruss
  andre

[martinp876]

funktional aendert dies nichts, das ist korrekt. Es dient nur der Lesbarkeit - und die hat sich deiner Ansicht nach verschlechtert :-(

[justme1968]

hallo martin,

die neue zusammenfassung im state ist wunderbar und mit einem reading pro aktor meiner ansicht nach perfekt. das die eine lange zeile nicht da ist verschlechtert meiner ansicht nach nichts :)

gruss
  andre

[martinp876]

ok - dann werden ich es so festmachen. Es gibt ja eh pro peer ein reading

[Billy]

Hallo,
habe da noch ein paar Fragen zu den Readings? (Auszug vom ActionDetector)

(siehe Anhang / see attachement)

Warum wird im state unkn:0 gezeigt, obwohl ein Device mit unknown gekennzeichnet ist?
Was bedeutet status_1 ? Ist das ein device?

Danke für Antworten Billy.

[martinp876]

kannst du zeigen, was im attribut peerIDs steht?

[Billy]

Da steht:
peerIDs    1D8E62,1DAB08,1CE600,1CEDA1,1A7985,1A88B3,19E3E7,19B431,19D70E,1D94AE,1D9ECB,1A7D0F,1A8526,1A7AC1,1A89AD,1B7C13,1B7C1B,1D9085,1D9EC2,1D8D69,1DA3DD,1D8BA9,

[martinp876]

die _1 ist sicher ein "rest" - hier muss ich noch aufraeumen - also nicht (mehr) relevante states loeschen.

Du hast 22 eintraege.
sind alle auf "alive" (also 21) ausser der eine Unknown?
Den _1 nicht mitgerechnet

Das Zaehlen schaue ich mir noch einmal an

[Billy]

Danke Martin.

werde jetzt mal bei meinem Test-VD die Batterien herausnehmen und schauen was passiert.

Gruss Billy

[Billy]

Hallo Martin,
Der Test-VD ging wie zu erwarten auf dead nach Rausnahme der Batterien!

Nach einem shutdown restart wird die peerIDs komplett gelöscht und alle 22 Einträge gehen auf Unknown!
Ist das so richtig?
Muss ich die peerIDs von Hand eintragen oder füllen die sich mit der Zeit wieder automatisch?
Ohne Eintrag in den peerIDs scheint ja nichts zu passieren. Bin ich da richtig?

Gruss Billy

[kossmann]

Nach einem shutdown restart [...] alle 22 Einträge gehen auf Unknown! Ist das so richtig?

Karneval ist vorbei, ich mach mal wieder mit :-)

Das ist zumindest bei mir auch so. Ich würde auch erwarten, dass der letzte Status in der fhem.save gespeichert und beim Neustart ausgewertet wird. Es hat aber vielleicht auch einen Grund, den müsste man uns wohl nur erklären ;-)

[martinp876]

nach restart geht der Zustand auf "unknown". Das ist beabsichtigt. Es koennten Daten fehlen,... zeitstempel usw. Je nach Device wird bei der ersten Nachricht auf 'alive gesetzt oder nach Ablauf der Max-time auf dead.

Wenn man haeufig neu startet koennte man Problem bekommen...
wenn man nur auf "dead" triggert sollte es trotzdem i.O. gehen. Es sei den man restarted mehrfach am Tag....

Das Befuellen der peerIDs des actionDetectors baue ich gerade um. Nach Restart wird die liste aus den attributen der Devices gefuellt. Muss ich noch einmal testen.
Eine aufraeum-procedur wird 5s nach dem letzten define ausgefuehrt - dann habe ich alle attribute zum pruefen. Danach sollte alles mit den Kommandos funktionieren

[tobi73]

Hi Martin,

nach restart geht der Zustand auf "unknown". Das ist beabsichtigt. Es koennten Daten fehlen,... zeitstempel usw. Je nach Device wird bei der ersten Nachricht auf 'alive gesetzt oder nach Ablauf der Max-time auf dead.

Ok, leuchtet ein. Allerdings habe ich beobachtet, dass auch nach einem rereadcfg die Werte auf unknown gehen. Ist das auch beabsichtigt / sinnvoll? Gruß Tobi

[justme1968]

hallo martin,

könnte man nicht zumindest nach einem neustart den status auf alive setzen wenn das letzte reading nicht länger her ist als actCycle ?

gruss
  andre

[Billy]

nach restart geht der Zustand auf "unknown". Das ist beabsichtigt.

Ok das ist so!

Je nach Device wird bei der ersten Nachricht auf 'alive gesetzt oder nach Ablauf der Max-time auf dead.

Das ging bei mir nicht! Habe um 10:57:43 einen restart gemacht, seitdem peerIDs komplett gelöscht und alle 22 Einträge gingen und bleiben auf Unknown! Auch bei den Devices bleibt seitdem der Staus auf "actStatus unknown"

Das Befuellen der peerIDs des actionDetectors baue ich gerade um. Nach Restart wird die liste aus den attributen der Devices gefuellt.

Löst das dann dieses Problem?
Gruss Billy

[martinp876]

@Billy
das Fehlzaehlen kommt daher, dass ein device nach dem ersten Zaehlem addiert wurde. Der state wird erst nach Ablauf des Timers neu gesetzt. Devices werden aber sofort addiert und mit dem Status unknown versehen

Kannst du einmal nachsehen, ob der ActionDetector laeuft? Der Zeitstempel des Status sollte sich mir jedem Ablauf erneuern...

@Andre
Nach dem restart sind die Zeitstempel rar. Fast alle sind weg, ausser die an den readings (es sei den, das Device sendet etwas).
Und an den readings muss man unterscheiden, ob es ein wirkliches reading oder ein set-kommando war.
Hast du einen Zeitstempel, der immer da ist?

Gruss
Martin

[justme1968]

hallo martin,

ich habe beim bewegungsmelder und den fenstergriffen jewels ein battery reading. da eine hauptanwendug die batterie betriebenen geräte sind könnte man zumindest da wo es ein battery ok reading im zeitfenster actCycle gibt den status nach neustart auf alive setzen. wer genau das mutwillig von hand setzt hätte dann wirklich pech gehabt.

ich gebe aber zu ich bin nicht ganz objektiv. ich starte mein system zur zeit mehrfach am tag weil es auch das system ist auf dem ich entwickle.

gruss
  andre

[kossmann]

da wo es ein battery ok reading im zeitfenster actCycle gibt den status nach neustart auf alive setzen. wer genau das mutwillig von hand setzt hätte dann wirklich pech gehabt.

Da würde ich Andre voll zustimmen. Es gibt doch auch wesentlich relevantere Daten, die sich FHEM aus der fhem.save beim Starten holt. Fenster open/tilted/closed z.B. - dies ist in meinen Augen sicherheitsrelevanter als eine Batterie, wird aber aus der fhem.save genommen. Genau so könnte es man doch auch beim ActionDetector machen, oder?

[martinp876]

Ich denke, ihr habt nich ueberredet. Ich habe da sowieso noch ein paar umbauten vor, mit den Kommandos.

- ActionDetect wird ueber "attr actCycle" ein und ausgeschaltet
- das Kommando actiondetect abgeschafft
- beim start werden die readings nach den neusten Eintrag durchsucht und der Status gesetzt.

Gruss
Martin

[Billy]

@ Martin zur Info!
Mit der 10_CUL_HM.pm.2711 läuft der ActionDetector jetzt wieder an, die peerIDs sind nach restart vorhanden.

Billy

[martinp876]

hoffentlich läuft er immer noch
habe den actionDetector teilweise um-designed.
Das Kommando actiondetect ist geschichte, jetzt einfach das Attribut actCycle setzen.
Ausserdem werden bei einem Restart und beim Eintragen eines Device die Readings als referenz hergenommen - mit Filter natürlich.

Zu tun ist nichts, sollte (hoffentlich) einfach laufen.

Gruss
Martin

[Billy]

Ja er läuft immer noch, habe jetzt die 10_CUL_HM.pm.2719 geladen.

Werde morgen mal berichten.

Gruss und gute Nacht Billy

[Billy]

Hallo Martin, zur Info

Nach dem Einspielen der 10_CUL_HM.pm.2719 hat es mir die
fhem.cfg
komplett verspult! Bin jetzt wieder auf die alte Version 10_CUL_HM.pm.2711 zurück.
Hatte Gottseidank ein backup der Konfig.

Billy

[kossmann]

hoffentlich läuft er immer noch
habe den actionDetector teilweise um-designed.
Das Kommando actiondetect ist geschichte, jetzt einfach das Attribut actCycle setzen.
Ausserdem werden bei einem Restart und beim Eintragen eines Device die Readings als referenz hergenommen - mit Filter natürlich.

Zu tun ist nichts, sollte (hoffentlich) einfach laufen.

Hallo Martin,

kommt der ActionDetector jetzt über ein autocreate und dies dann im "room CUL_HM"? Mir flog meine Konfiguration eben um die Ohren. Was darf ich von folgender Konfiguration nun nicht mehr verwenden und was muss ich ggf. an anderer Stelle ergänzen?

Code Auswählen Erweitern

define ActionDetector CUL_HM 000000
  attr ActionDetector actCycle 600
  attr ActionDetector peerIDs 1CC...,1C2...,1C2...,1C2...,1DC... # 3x Rauchmelder, 1x Fenstergriff, 1x KeyMatic
  attr ActionDetector room System

define ActionDetector_FileLog FileLog ./log/ActionDetector.log ActionDetector
  attr ActionDetector_FileLog logtype text
  attr ActionDetector_FileLog room Logfiles

[Billy]

Mir flog meine Konfiguration eben um die Ohren.

Mir auch siehe oben, also ein Bug?

Gruss Billy

[martinp876]

Hi,

was in der Version kaputt ich habe ich noch nicht verstanden.

Der ActionDetector wird erzeugt wenn ein device mit dem Attribut "actCycle" gefunden wird oder das Attribut gesetzt wird. Vom Grundsatz kein Unterschied zu vorher, nur dass vorher das Kommando actiondetect zum setzen benutzt werden sollte.
Bei Room hat sich hier nichts getan, das geht automatisch.

Die peerIDs des Action Detectors werden nicht mehr benoetigt, da ich beim reboot die Attribute der Devices screene und mich dabei nach actCycle halte. Aber Probleme sollte es nicht machen, wenn es noch drin ist.

Was heisst 'um die Ohren geflogen'?
Wenn peerIDs weg ist - im ActionDetector - ist das keine Problem.
Gruss
Martin

[Billy]

Hallo Martin'
Bei mir war es so, dass nach Einspielen der neuen 10_CUL_HM und reload die fhem.cfg
Von 93 auf 15 entities gekürzt war. Damit war mein fhem natürlich nicht mehr lauffähig.

Gruss Billy

[kossmann]

Guten Morgen zusammen,

ich habe meine fhem.cfg auf ein Minimum reduziert und dort über diverse include-Zeilen einzelne separate Konfigurationen eingelesen, auf die FHEM nur Leserechte hat - so kann ich mir sicher sein, dass nichts durcheinander gerät und ich die Hoheit über die Konfiguration behalte. Die fhem.cfg sieht es wie folgt aus:

Code Auswählen Erweitern

attr global autoload_undefined_devices 1
attr global logfile ./log/fhem.log
attr global modpath .
attr global statefile ./fhem.save
attr global mseclog 1
attr global verbose 3

attr global uniqueID ./FHEM/FhemUtils/uniqueID
attr global sendStatistics onUpdate

define autocreate autocreate
  attr autocreate autosave 1
  attr autocreate device_room %TYPE
  attr autocreate filelog ./log/%NAME.log
  attr autocreate weblink 1
  attr autocreate weblink_room Plots

# TelnetPort, FHEMWEB
include user_zugriff.cfg

# MyCUL, MyHMLAN
include user_cul.cfg

# Standort (Koordinaten, Wetter, Ferien, ...), Anwesenheits-Dummies, FB_CALLMONITOR
include user_standort.cfg
include user_anwesenheit.cfg
include user_fritzbox.cfg

# Aktoren und Sensoren in den jeweiligen Räumen und deren AT- und NOTIFY-Jobs
include user_badezimmer.cfg
include user_kinderzimmer.cfg
include user_kueche.cfg
include user_schlafzimmer.cfg
include user_wohnzimmer.cfg

# KeyMatic und Rauchmelder
include user_keymatic.cfg
include user_rauchmelder.cfg

# InterTechno Funksteckdosen und deren Schaltung (Beleuchtung)
include user_funksteckdosen.cfg
include user_beleuchtung.cfg

# ActionDetector und Batterieüberwachung
include user_actiondetector.cfg
include user_batterie.cfg

# FLOORPLAN
include user_grundriss.cfg
Hier muss ich i.d.R. nur nach dem Anlegen neuer Devices (per autocreate oder hmPairForSec) eingreifen. Gestern wurde die fhem.cfg sofort nach Neustart (nach dem update) durcheinander gebracht, so wie ich es ansonsten nur von einem save gewohnt bin (dafür ist jedoch immer ein Backup des ursprünglichen Files vorhanden).

Was mich jedoch gewundert hat:

- user_actiondetector.cfg ist mir natürlich "um die Ohren" geflogen, da der ActionDetector ja schon automatisch angelegt wurde
- Es fehlten diverse (!) include-Zeilen, u.a. auch die user_grundriss.cfg (mein Floorplan) - dies kann ich gar nicht verstehen und der Floorplan war danach natürlich weg
- Nach dem Neustart standen alle Sensoren/Aktoren/Dummies auf dem Status "???" - FHEM wusste nichts mehr

Ob ich den room des automatisch angelegten ActionDetectors nachträglich noch auf "System" statt "CUL_HM" ändern kann, muss ich mir mal ansehen. Dies wird aber wohl möglich sein, genauso wie auch der room des zugehörigen FileLog.

Aber warum sind diverse include-Zeilen verschwunden, u.a. auch die Beleuchtung oder die FunkSteckdosen.

Das Problem mit Status "???" nach Neustart ist weiterhin vorhanden - dies ist untragbar! Bin ich damit der Einzige?

Das meine KeyMatic nicht im automatischen ActionDetector auftaucht, liegt wohl an einem fehlenden actCycle, den habe ich aber bis jetzt auch sonst nirgendwo (3x HM-Sec-SD, 1x HM-Sec-RHS) gesetzt und die anderen Geräte tauchen auf, wenn auch mit "unknown". Gibt es eigentlich irgendwo eine Liste, wie die Standard-actCycle-Werte zu setzen wären?

[martinp876]

hmm

das mit dem automatischen save muss ich mir ansehen - das mache ich eigentlich nicht. koennte von update kommen? evtl werden da checks gemacht?

Ich habe keinen update gemacht sondern einen restart.
=> tritt das Problem nur bei update auf?
Wenn du nach dem update dein altes config-file einspielst und einen restart machst, klappt es dann?

Den ActionDetector kann ich erklaeren (sollte ich koennen ;-) )
- einige devices haben nach XML einen regelmaessigen 'I-AM-ALIVE' event. Wenn dem so ist habe ich den eingetragen. Diese devices werden beim Anlernen automatisch nach ActionDetect eingebaut.
- alle anderen devices konnte man durch das Kommando 'actiondetect' manuell hinzufuegen

- alle devices, die im ActionDetector bearbeitet werden hatten ein attribut actCycle - wenn nicht werden die entfernt.

- Keymatic devices melden sich nicht regelmaessig. Die muss man also manuell 'addieren'

- das kommando 'actiondetect' funktioniert nicht mehr, da jetzt alles ueber actCycle laeuft. Einfach das Attribut setzen - im Device!, nicht channel.

Gruss
Martin

[martinp876]

Hi,

ich habe diverse restarts gemacht, jetzt auch einen Update. Mein fhem.cfg ist immer ok.

Habt ihr alle CUL oder HMLAN im Einsatz? Es hat jemand einen Verdacht geaeussert, dass es im Zusammenhang mit CUL stehen koennte

Gruss
Martin

[Dennis D.]

Hallo,

also ich habe ausschließlich HMLAN im Einsatz und eben noch ein Update gemacht - ohne Probleme.

Lööpt alles wie geschmiert. :)

Gruß,
Dennis

[Billy]

Hi,

ich habe diverse restarts gemacht, jetzt auch einen Update. Mein fhem.cfg ist immer ok.

Habt ihr alle CUL oder HMLAN im Einsatz?

Also ich habe nur HMLAN im Einsatz und hatte diese Probleme nicht nach einem Update sondern nur nach
Einspielen der 10_CUL_HM.pm.2719. Habe den backup der fhem.config zurückkopiert und wieder auf die alte Version 10_CUL_HM.pm.2711 zurück.

Gruss Billy

[Billy]

Martin,

kennst du eigentlich den Beitrag ? --> FHEM --> Frontends
 Aw: seit letztem Update wird FHEM.cfg abgeschnitten [Beitrag #64444 ist eine Antwort auf Beitrag #64259]

Zitat:

Nabernd,
bei mir hat gestern auch noch alles super funktioniert. Kurz vorm schlafen gehn hab ich dann nochmal geupdated.
Jetzt wunder ich mich, dass die fhem.cfg nurnoch minimal ist.

Gut, dass ich gestern noch gesichert hab. Aber egal ob ich die minimale .cfg speichere oder meine
Sicherung reinkopiere meckert er immer wegen irgendwelcher Actiondetector klamotten
MFG Lars

Billy

[Rohan]

Hallo Billy,

... kennst du eigentlich den Beitrag ? --> FHEM --> Frontends
 Aw: seit letztem Update wird FHEM.cfg abgeschnitten [Beitrag #64444 ist eine Antwort auf Beitrag #64259] ...

solche "Links" sind für mich sehr hinderlich. Im Antwort-Editor gibt es ein kleines Planetensymbol mit 2 "Kettengliedern" rechts unten. Damit fügt man einen *klickbaren* Link in ein Posting ein. Zu jedem Beitrag gibt es eine URL, die man sich mit Maus-Rechtsklick auf die (hier linke) Nummer in der Überschrift (hier z.B.: [Beitrag #64447 ist eine Antwort auf Beitrag #59316] in die Zwischenablage kopieren und dann beliebig einfügen kann.

Das ganze sieht dann z.B. so aus: Link

Code Auswählen Erweitern

Das ganze sieht dann z.B. so aus: [url=http://forum.fhem.de/index.php?t=msg&th=10465&goto=64447&rid=417#msg_64447]Link[/url]

Wäre nett, wenn du mir (und evtl. dem ein oder anderen hier) das Auffinden deiner Hinweise etwas erleichtern würdest. Danke!

Nix für ungut.

Gruß
Thomas

[Billy]

Besser Hinweise als keine!

Wäre nett, wenn du mir (und evtl. dem ein oder anderen hier) das Auffinden deiner Hinweise etwas erleichtern würdest. Danke!

Billy

[martinp876]

Hi,

danke fuer den Hinweis.

Hat irgendjemand mitgeloggt, was passiert ist? Kann ich ein Logfile bekommen?
Da es bei mir sauber Funktioniert brauche ich einen Tip. Das configfile wird von mir nicht geschrieben...

Gruss
Martin

[Billy]

Hi,
danke fuer den Hinweis.
Hat irgendjemand mitgeloggt, was passiert ist? Kann ich ein Logfile bekommen?
Da es bei mir sauber Funktioniert brauche ich einen Tip. Das configfile wird von mir nicht geschrieben...

Gern geschehen, werde dir per PM die originale fhem.cfg (782 Zeilen) und die verspulte fhem.cfg (78 Zeilen)
zukommen lassen. Log gibt es nicht!

Gruss Billy

[martinp876]

Das Problem ist das automatische creieren den ActionDetector.
Werde es in der nächsten Version beheben.
workaround:
Wenn ihr erst den ActionDetector definiert - vor dem ersten actCycle im fhem.cfg sollte es keine Probleme geben

Gruss
Martin

[Billy]

workaround:
Wenn ihr erst den ActionDetector definiert - vor dem ersten actCycle im fhem.cfg sollte es keine Probleme geben

Stimmt, so gehts!!!

Danke Billy

[martinp876]

und jetzt auch wieder wie vorher

[justme1968]

hallo martin,

noch eine frage zum actiondetector. was wäre denn zu tun um ihn auch mit nicht homematic devices zu nutzen. z.b. mit den s300ht.

gruss
  andre

[martinp876]

das ist (leider) nicht vorgesehen  - und muesste umdesigned werden, ausserdem aus HM entfernt werden.

Es gibt wohl eine andere Funktion die kurz nach dem ActionDetector geschrieben wurde. Die ueberwacht devices - auf einer komplett anderen Basis, anderen Hintergrund, Implementierung, Ziel und Performance Gedanken. Musst du einmal suchen, habe ich aus den Auge verloren.

[brmpfl]

Moin,

trotz Suche nix gefunden:
Wirft der ActionDetector irgendein Ereignis, auf dass ich per notify reagieren kann?

[martinp876]

ah - da fehlt wohl noch doku...
bei jedem Device solltest du "Activity" abfragen koennen. Die kann dead, alive, unknown oder switchedoff sein.

In actiondetectorselbst gibt es
status_<devname>:<state>
und
state: alive:<cnt> dead:<cnt> unkn:<cnt> off:<cnt>

Im Prinzip sollte man alle readings mit notify abfangen koennen.

Gruss
Martin

[brmpfl]

Hallo Martin,

vielen Dank für die Antwort.

Bei mir funktioniert das nicht:

Code Auswählen Erweitern


define NotifyActionDetector notify ActionDetector.* { \
  Log 1, '@:%';; \
}

Im Log taucht nix auf.
Mache ich was falsch?

[martinp876]

sorry, liegt an mir. Die events des ActionDetectors habe ich von notify abgeklemmt. Idee war performance zu sparen, da die events der devices sowieso kommen.
Ich sehe aber ein, dass ich es aendern sollte. Ich werde es 'freigeben'. Da dies ein regelmassiges ereigniss ist und das suchen der notifies nicht unerheblich Performance kostet, werde beim actionDetector als default ein attribut event-on-change-reading .* vorsehen.


Gruss
Martin

[gki]

hallo martin,

noch eine frage zum actiondetector. was wäre denn zu tun um ihn auch mit nicht homematic devices zu nutzen. z.b. mit den s300ht.

gruss
andre

Hi André,

eventuell den DeviceMonitor nutzen ... https://groups.google.com/forum/?fromgroups=#!msg/fhem-users/A4dgFwZdtOs/5Wu5Qotm9NMJ

Gruß,
Ines

[justme1968]

danke!

irgendwie ist mir der beim suchen immer durch die lappen gegangen.

gruss
  andre

edit: ich hab eben hier Linkeinen kleinen patch gepostet um den zusätzlichen weblink zu sparen.

[Michi240281]

Hallo,

ich habe seit 2 Tagen den HM-SCI-3-FM im Einsatz.

Bislang sendet er alle paar Stunden ein "alive", jedoch habe ich (noch) kein reading zum Batteriestatus. Wird dieses irgendwann erstmal erzeugt oder muss ich das manuell anstoßen? Bei meinem HM-SEC-CS-2 war das "battery" reading direkt da.

Danke und Gruß

[martinp876]

sollte automatisch kommen.
hast du ein list und ein paar rohmessages zum vorlegen?

[Michi240281]

Code Auswählen Erweitern



Internals:
   DEF        23CD9A
   IODev      HMLAN1
   NAME       Funkschnittstelle_Sicherungskasten
   NR         313
   STATE      Info_Cleared
   TYPE       CUL_HM
   channel_01 Klingeltaster
   channel_02 CUL_HM_HM_SCI_3_FM_23CD9A_Sw_02
   channel_03 CUL_HM_HM_SCI_3_FM_23CD9A_Sw_03
   protState  Info_Cleared
   Readings:
     2014-02-21 17:50:12   Activity        alive
     2014-02-19 19:51:23   CommandAccepted yes
     2014-02-19 19:51:21   D-firmware      1.1
     2014-02-19 19:51:21   D-serialNr      KEQ0767306
     2014-02-19 19:51:23   PairedTo        0x23A6D7
     2014-02-19 19:51:23   R-cyclicInfoMsg on
     2014-02-19 19:51:23   R-pairCentral   0x23A6D7
     2014-02-19 19:51:23   R-transmDevTryMax 6
     2014-02-19 19:51:23   RegL_00:        02:01 09:01 0A:23 0B:A6 0C:D7 14:06 00:00
     2014-02-19 19:51:23   aesKeyNbr       FF
     2014-02-21 22:49:43   state           Info_Cleared
   Helper:
     mId        005F
     rxType     12
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
Attributes:
   IODev      HMLAN1
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.1
   model      HM-SCI-3-FM
   peerIDs   
   room       Wohnzimmer
   serialNr   KEQ0767306
   subType    threeStateSensor
   webCmd     getConfig:clear msgEvents



Wie bekomme ich Rohmessages? Weiß garnicht was das ist *schäm*

[martinp876]

siehe
http://forum.fhem.de/index.php/topic,16563.0.html

[Michi240281]

siehe
http://forum.fhem.de/index.php/topic,16563.0.html

Werd ich mir mal zu Gemüte führen. Danke!

Inzwischen wurde das Reading "battery" eingetragen. Alles prima!

[Zrrronggg!]

Nach einem soeben durchgeführten FHEM Update erhalte ich den Fehler:

actCycle must be higher then 30, 001:00 not allowed

ich habe auch tatsächlich

attr ActionDetector actCycle 001:00

konfiguriert, gab bisher nie Probleme.. Ich ging auch davon aus, dass das Format HHH:MM ist

Was bedeutet die Meldung? (der AktionDetector funktioniert trotzdem wie gewohnt)

[martinp876]

beim ActionDetector ist das HH:MM Format nicht implementiert, es sind einfach Sekunden.
Ich werden die Doku nachzeihen

1:00 sollte also
3600
sein

[Zrrronggg!]

Roger, danke.