"Alive" Meldung via Pushover zu bestimmter Zeit HM-Sec-SC-2

[schnun]

Hallo zusammen,

ich habe u.a. bei meinem HM-Sec-SC-2 eine battery:low Meldung via Pushover eingerichtet.

Die bessere Lösung wäre, wie ich das so rauslesen konnte, der ActionDetector. Ich spiele damit gerade ein wenig rum. Ich habe die .cfg dahingehend erweitert,
aber wenn ich das mit actCycle testweise auf 000:01 stelle, die Batterien entnehme und einen restart mache bleibt der HM-Sec-SC-2 auf alive.
Reading sagt aus Activity:unknown und Alive:yes.Auch nach 10 min ändert sich das nicht.
Ich denke ich habe den ActionDetector noch nicht verstanden.

Gibt es eine Möglichkeit das mir der HM-Sec-SC-2 um z.B. 22 Uhr eine Pushover-Meldung mit seinem aktuellen Status (alive, dead oder unknown) oder evtl. dem
Batteriestatus sendet ? Nur damit ich sicher gehen kann das zumindest zu diesem Zeitpunkt die Alarmanlage zuverlässig funktioniert ?

Habe bislang nur diesen und zwei HM-Thermostate im Einsatz, bin deshalb noch nicht so fit in Sachen Homematic.

Danke für evtl. Vorschläge.

Gruss
Patrick

[martinp876]

Hi Partick,

der Action detector ist (wie der name suggerieren soll) gebaut um Aktion eines Device zu erkennen. Action ist, wenn das Device irgend eine Message sendet. In welchen Zeitraum das zu passieren hat, kann man festlegen.
Der ActionDetector selbst "tastet die Devices ab". Er wird also nur alle zeit aufgerufen und prüft den Zustand aller seiner Klienten.

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

der ActionDetector prüft alle 600sec seine Klienten ab. Kann man bis auf 30sec reduzieren, falls gewünscht.

define HM-Sec-SC-2 CUL_HM 111111
attr HM-Sec-SC-2 actCycle 00:01

Es wird in diesem Fall alle 10 min nachgesehen, ob der SC in den "verfangenen 1min" eine Message sendete.
Sinn macht es keinen. Bei den (default) 144 Prüfungen eines Tages ist gesichert (wenn cyclicInfoMessage Aktiv ist) dass der SC sich einmal melden wird - plus die Betätigungen.

Den SC kann man auch nicht abfragen...

Wenn du also den default belässt kannst du erkennen ob der SC sich in den letzten 24h wie gefordert gemeldet hat.

Wenn man nun battery UND actionState beobachtet sollte man relativ sicher sein. Denkbar ist (immer) dass jemand das device klaut oder zerstört, die Batterien entfernt,... und dann den Einbruch innerhalb der verbleibenden zeit (max 24h) begeht. dazu muss er allerdings an das Device ran kommen, also das Fenster auf machen? Ist das allerdings möglich ist der sc als einbruchsicherung eh nicht brauchbar.

Würde mich interessieren, welches Scenarion du im Kopf hast, dass durch den default nicht abgedeckt ist.

Übrigens - HMInfo sammelt und generiert eine sammelmeldung, wenn du willst. Da ist dann noch drin, ob es einen sabotage-kontakt evetn gibt oder ein "cover-open". Da sollte auch ein batterie-klau gemeldet werden.

[schnun]

Hi Martin,

danke für die Erläuterungen.

Den ActionDetector hatte ich wie Du geschrieben hast "aktiviert". CyclicInfoMessage ist aktiv.

Zusätzlich habe ich HMinfo noch definiert. Habe ich so aus einem anderen Beitrag kopiert, hoffe ich habe damit
den größten Teil abgesichert, siehe hier...

Code Auswählen Erweitern

define hm HMinfo
attr hm autoUpdate 0:30
attr hm event-on-change-reading .*
attr hm sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed,
attr hm sumStatus battery,sabotageError,powerError,motor
attr hm webCmd update:protoEvents short:rssi:peerXref:configCheck:models




Ich habe es so eingerichtet das von 23 Uhr bis 6 Uhr morgens im Falle das die Haustüre geöffnet wird alle Telefone klingeln und mir zusätzlich
eine Pushover-Meldung reinflattert damit ich weiss welcher Aktor überhaupt "angeschlagen" hat.
Mein Ziel war es einfach das ich täglich um z.B. 22 Uhr eine Meldung des HM-Sec-SC-2 per Pushover bekomme damit ich kurz vor dem schlafen gehen weiss das
dieser noch lebt.

Wenn er sich allerdings einmal am Tag von sich aus  meldet wäre das dann auch okay, aber wie bekomme ich diese Meldung per Pushover   ?
Und meldet er sich sporadisch oder immer zur selben Zeit (nach 24 oder 28 Stunden?).
Da konnte ich leider keinen passenden Beitrag finden, nur diesen der "dead" meldet...

Code Auswählen Erweitern

####START######### DeadDeviceIndicator on "dead" if ActionDetector shows at least 1 dead device ###############START####
define DeadDeviceIndicatorNotify notify ActionDetector:.*alive:.* {\
if (Value("ActionDetector") !~ m/dead:0 /) {\
my $InActiveDeviceList = fhem "get ActionDetector listDevice notAlive";;\
my $InActiveDeviceString = "Dead device(s) detected: " . $InActiveDeviceList;;\
fhem "set PushoverWarning msg 'Deeke Home-ActionDetector' '$InActiveDeviceString' '' 1 ''";;\
Log 3, "Dead Device warning sent via Pushover for " . $InActiveDeviceList;;\
}
#####END########## DeadDeviceIndicator on "dead" if ActionDetector shows at least 1 dead device ################END#####

Gruss
Patrick

[martinp876]

Hi,
Hminfo sollte die aufgefuehrten attribute bei definition ( nach restart, wenn definiert ) selbst setzen. Du musst also nicht suchen, fuer diese einstellungen.
Du kannst einmal loggen - z.b. attr hmprotocolevents auf 3 setzen ( emfehle ich generell nicht, nur in speziellen faellen. Kann zu preformanceproblemen kommen ). Der trigger sollte etwa um die gleiche zeit jeden tag kommen. Da das device die uhr nicht kennt ist es zufall. Ich wuerde auch einen jitter erwarten - hm will so eine streuung erziehlen.

[kvo1]

Hallo Martin,
ich habe 3 Stück HM-Sec-SC-2 die zwar den Status melden (normal immer closed) aber im
ActionDetector immer "unknown"  sind.
Wenn ich diesen dann öffne und wieder schließe dann werden diese wieder "alive".

Der ActionDetector ist definiert

define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector
attr ActionDetector room OG_Arbeitszimmer

Der HM-SEC-SC-2 sieht so aus

define WG_Fenster_li CUL_HM YYYYY
attr WG_Fenster_li IODev CUL_HM
attr WG_Fenster_li actCycle 028:00
attr WG_Fenster_li actStatus unknown
attr WG_Fenster_li autoReadReg 4_reqStatus
attr WG_Fenster_li devStateIcon open:tuer_offen closed:tuer_geschlossen
attr WG_Fenster_li expert 2_full
attr WG_Fenster_li firmware 2.4
attr WG_Fenster_li icon Kontakt2
attr WG_Fenster_li model HM-SEC-SC-2
attr WG_Fenster_li peerIDs 00000000,
attr WG_Fenster_li room EG_Wintergarten
attr WG_Fenster_li serialNr LEQxxxxxxx
attr WG_Fenster_li subType threeStateSensor

Also müßten sich diese doch alle 28 Minuten (wohl default) melden (attr WG_Fenster_li actCycle 028:00)?

Warum hier "attr WG_Fenster_li actStatus unknown" ist mir leider nicht klar ! wird das gesetzt !?

Wie kann ich hier vorgehen um heraus zu finden, HM-SEC-SC-2 nicht melden ?

danke
klaus

[justme1968]

das sind 28 stunden. nicht minuten.

ist cyclicInfoMesssge gesetzt? nur wenn das register gesetzt ist meldet sich der sensor auch dann ein mal am tag wenn er nicht betätigt wurde.

gruß
  andre

[kvo1]

das sind 28 stunden. nicht minuten.

ist cyclicInfoMesssge gesetzt? nur wenn das register gesetzt ist meldet sich der sensor auch dann ein mal am tag wenn er nicht betätigt wurde.

gruß
  andre

Hallo Andre,
(Du bist ja überall  danke dafür)

Ich meinte natürlich auch Stunden , nicht Minuten !

wann wird den ein ...

Code Auswählen Erweitern

set <Device> regSet cyclicInfoMsg on

übernommen ?

grusss
klaus

[justme1968]

das hängt vom device ab. bei den devices die fhem nicht aufwecken kann musst du kurz auf den knopf zum anlernen drücken.

gruß
  andre

[kvo1]

das hängt vom device ab. bei den devices die fhem nicht aufwecken kann musst du kurz auf den knopf zum anlernen drücken.

gruß
  andre

....kurz auf den knopf zum anlernen drücken ......

Funktioniert ! Danke

gruss
klaus