FHEM Forum

Hallo zusammen,

gibt es für die HMCCU auch sowas wie den ActionDetector?

Ich nutze den für normal eingebundene HM Komponenten zur Überwachung auf Erreichbarkeit.
Wie habt ihr das für HMCCU Geräte und Chanels gelöst? In Fhem oder in der CCU?

Die gleiche Frage stelle ich mir für die Überwachung des Batterie Status.

Über https://fhem.de/commandref_DE.html#readingsWatcher ?

Blöde Frage eines "Nicht-CUL_HM" Users: Was macht der ActionDetector?

Zitat von: zap am 10 Januar 2020, 07:53:21
Blöde Frage eines "Nicht-CUL_HM" Users: Was macht der ActionDetector?

Das ist ein Pseudo-Device, das prüft, ob der Status sich innerhalb actCycle nicht gemeldet hat, und ggf. das Device auf "dead" setzt

Ok, das bekommt man bei HMCCU von der CCU automatisch geliefert.

ActionDetector prüft ob sich Devices welche sich regelmäßig melden sollte dies auch tun. Das sollte die HMCCU auch schaffen.
Zusätzlich kann man dies auch für devices einrichten, welche sich nicht regelmäßig melden. Also bspw ein Lichtschalter.
Hierzu habe ich einen "ping" service implementiert. Man trägt ein Device ein und gibt vor, in welchen Abständen man eine Reaktion erwartet (wenn möglich wird es automatisch gesetzt). Beim Lichtschalter bswp alle 24h.
Meldet sich das Device nicht (also das Licht wurde nicht geschaltet,...) dann wird, wenn möglich, ein Status-request abgesetzt (das Ping). Wird dies nicht beantwort ist das Device tot.
Ich hatte solche Fälle bei Devices welche am Netz hängen und das Netzteil Probleme hatte.

Ich überwache somit das "vorhanden-sein" aller devices bei denen es möglich ist.
Lücken: Batterie betriebene Taster. Hier kann der Service auch aktiviert werden, allerdings gibt es kein "ping". Damit bekomme ich nur "verdachtsfälle", wenn der Schalter 3 Tage nicht genutzt wurde.

Die Darstellung der Ergebnisse habe ich in HMInfo, also der CUL_HM Sammelstelle (sowie im Action-Detector, sekundär) eingebracht. Bei HMCCU ist es mir noch nicht klar. Die HMCCU ist das übergeordnete Device und damit die 1. Wahl, das Alarm-Interface zusammenzufassen.
Bei Alarmen bin ich gedanklich noch nicht, vorstellen würde ich mir aber eine Zusammenfassung aller entsprechender Alarme.
Ein "device-ping-service" wäre cool - ich werde ihn auf jeden Fall brauchen. Immerhin ist das die wichtigste Info überhaupt: "Sind alle meine Teilchen erreichbar" bestmöglich darzustellen.

Genau, ich überwache damit meine hm Geräte. Damit bekomme ich auch mit wenn mein hm-lan Mal wieder spinnt.
Da ich gerade alles auf ccu umziehe suche ich nach Möglichkeiten die Erreichbarkeit und Batteriezustand zu überwachen und Telegramm Nachrichten mit dem Device im Namen zu versenden.

Hallo slor,

hast du dir im Modul HMCCU schon mal ccuaggregate https://wiki.fhem.de/wiki/HMCCU#Aggregation_von_Ger.C3.A4tezust.C3.A4nden_.28ab_3.6.29 (https://wiki.fhem.de/wiki/HMCCU#Aggregation_von_Ger.C3.A4tezust.C3.A4nden_.28ab_3.6.29) angesehen?

Ich überwache damit den Batteriestatus, Duty-Cycle und Erreichbarkeit der Geräte (HMiP und HM). Dies funktioniert prima seit einigen Jahren. Ich führe den Befehl "get HMCCU aggregation all" einmal stündlich über ein doif aus und versende Nachrichten über Pushover wenn es Abweichungen gibt.

Das entsprechende Attribut in HMCCU:
attr CCU2 ccuaggregate name:HmIP_battery_,filter:group=HmIP-Device,read:(Batterie),if:any=leer,else:ok,prefix=HmIP_battery_,coll:alias;;\
name:HM_battery_,filter:group=HM-Device,read:(Batterie),if:any=leer,else:ok,prefix=HM_battery_,coll:alias;;\
name:DutyCycle_,filter:group=HmIP-Device,read:(0.DUTY_CYCLE),if:any=(1|true),else:(0|false),prefix=DutyCycle_,coll:alias\
name:Unerreichbar_,filter:name=^HM_.*,read:(0.UNREACH),if:any=(1|true|dead),else:(0|false|alive),prefix=Unerreichbar_,coll:alias

Dazu noch mein doif:
{
[06:30-22:30,+[1]:30]; fhem("get CCU2 aggregation all");
my $HmIP_Geraete;
my $HM_Geraete;
my $Duty_Cycle;
my $Unreach;
if ([?CCU2:HmIP_battery_list] ne "no match") {
$HmIP_Geraete = ReadingsVal("CCU2","HmIP_battery_list","keine");
Log 2, "Systemhinweis - HmIP-Warnung, Batterien bei: $HmIP_Geraete schwach!";
if ([?du_Pushover_MSG_unterdruecken] eq "Einschalten") {
fhem_set ("Postmaster msg title=Systemmeldung! sound=bugle HmIP-Warnung, Batterien bei: $HmIP_Geraete schwach!")
}
}
if ([?CCU2:HM_battery_list] ne "no match") {
$HM_Geraete = ReadingsVal("CCU2","HM_battery_list","keine");
Log 2, "Systemhinweis - HM-Warnung, Batterien bei: $HM_Geraete schwach!";
if ([?du_Pushover_MSG_unterdruecken] eq "Einschalten") {
fhem_set ("Postmaster msg title=Systemmeldung! sound=bugle HM-Warnung, Batterien bei: $HM_Geraete schwach!")
}
}
if ([?CCU2:DutyCycle_list] ne "no match") {
$Duty_Cycle = ReadingsVal("CCU2","DutyCycle_list","keine");
Log 2, "Systemhinweis - Duty Cycle bei: $Duty_Cycle Geräten erreicht!";
if ([?du_Pushover_MSG_unterdruecken] eq "Einschalten") {
fhem_set ("Postmaster msg title=Systemmeldung! sound=bugle Duty Cycle bei: $Duty_Cycle Geräten erreicht!");
}
}
if ([?CCU2:Unerreichbar_list] ne "no match") {
$Unreach = ReadingsVal("CCU2","Unerreichbar_list","keine");
Log 2, "Systemhinweis - Folgende Geäte sind nicht erreichbar: $Unreach !";
if ([?du_Pushover_MSG_unterdruecken] eq "Einschalten") {
fhem_set ("Postmaster msg title=Systemmeldung! sound=bugle Folgende Geäte sind nicht erreichbar: $Unreach !")
}
}
}

Vorraussetztungen hierfür sind nur passende Readings bei den Geräten oder du legst wie ich, entsprechende Gruppen an.
Ich habe bis heute den ActionDetector noch nie gebraucht und wenn ich ehrlich bin auch noch nicht verstanden wie der genau funktioniert ;)
Hängt wahrscheinlich auch damit zusammen, dass ich über 80% HMiP Geräte habe.

Guck es dir mal an, wenn es noch Fragen dazu gibt, melde dich einfach.

Gruß Reinhard

Ein regelmäßiges Ausführen von "get aggregation all" sollte eigentlich nicht notwendig sein, da HMCCU das bei jeder Aktualisierung eines Datenpunktes/Readings durch die CCU automatisch ausführt.
Man kann dieses Feature auch verwenden, um immer eine aktuelle Liste der offenen Fenster zu haben usw.

Zitatda HMCCU das bei jeder Aktualisierung eines Datenpunktes/Readings durch die CCU automatisch ausführt.

da ich es entweder nicht verstanden habe bzw für unwahrscheinlich habe ich einmal getestet.

Ein
get <device> datapoint LEVEL
liest den cache in der CCU. Es geht definitiv kein Kommando an das Device. Somit kann sich mit einer Abfrage dieser Art nicht testen, ob das Device schon gestolen ist oder noch erreichbar ist.

Somit sehe ich das Anliegen für mich in keiner der Optionen hinreichend gelöst