NOTIFYDEV explizit setzen

[PatrickR]

Hallo zusammen,

ich nutze eine dreistellige Zahl von Homematic-IP-Geräten. Nahezu sämtliche meiner Geräte (d. h. auch Nicht-HmIP-Geräte) verwenden Namen der Art

Code Auswählen Erweitern

UG.AZ.Lampe

Hierbei ist UG das Geschoss und AZ der Raum. Zum Tracken von Fehlerzuständen aller HmIP-Geräte verwende ich ein DOIF mit DOIF_Readings wie

Code Auswählen Erweitern

problem_count:[#"^..\...\..*$":"^0.(UNREACH|ERROR_CODE|ERROR_OVERHEAT|DUTY_CYCLE)$":"^[1-9].*$"],

Hieraus generiert DOIF das folgende NOTIFDEV:

Code Auswählen Erweitern

.*(^..\...\..*).*,global,.*(^..\...\..*$).*,D_S_HM_HMIP_Problems
Das matcht leider auch auf Nicht-HmIP-Geräte, was man bspw. mit apptime total sehr eindrucksvoll sehen kann.

NOTIFYDEV würde laut DevelopmentModuleIntro aber auch ein NOTIFYDEV der Art

Code Auswählen Erweitern

$hash->{NOTIFYDEV} = "global,D_S_HM_HMIP_Problems,TYPE=HMCCUDEV";
unterstützen, was in meinem Fall die Zahl der unerwünschten Treffer massiv einschränken würde.

Meine Frage: Da sich mein Anwendungsfall durch den Automatismus in DOIF_Set_Filter() vermutlich nur schwer abbilden lässt, besteht eine Möglichkeit/ein Workaround, NOTIFYDEV eines DOIF-Geräts manuell zu setzen?

Patrick

[Damian]

Notifydev selber setzen ist nicht vorgesehen.

Es ist zwar nicht besonders elegant wenn das DOIF-Modul ständig getriggert wird, aber das DOIF-Modul ist auch für diesen Fall optimiert.

Ich muss mal schauen, ob ich eine TYPE-Option beim DEVICE-Filter im DOIF einbauen kann.

[PatrickR]

Hi!

In Ermangelung einer Lösung habe ich mal selbst nach einem Workaround geschaut. Folgendes scheint zu funktionieren:

Code Auswählen Erweitern

init {
  set_Exec("set_notify_dev", 0.1, '$hash->{helper}{NOTIFYDEV} = "global,D_notifydevtest,TYPE=HMCCUDEV";::setNotifyDev($hash, $hash->{helper}{NOTIFYDEV});');
}

Und es bringt (neben der Erhaltung der bisherigen Funktion) die gewünschten Ergebnisse:

Code Auswählen Erweitern

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
D_S_HM_HMIP_Problems                     DOIF_Notify                             99     1237   74040.12    59.85     0.00     0.00 19.08. 01:25:16 HASH(D_S_HM_HMIP_Problems);
[...]
D_notifydevtest                          DOIF_Notify                             66      129    6241.66    48.38     0.00     0.00 19.08. 01:24:18 HASH(D_notifydevtest);
D_S_HM_HMIP_Problems ist das alte DOIF mit Original-NOTIFDEV, D_notifydevtest ist das DOIF mit der obigen init-Funktion. Ich glaube, die Reduktion sowohl bei total als auch bei count ist durchaus lohnenswert.

Patrick

[Damian]

Ich habe mir die Sache genauer angeschaut.

Ich werde für die Deviceangaben bei reinen Ereignistriggern die Option mit TYPE=... einbauen.

Bsp.:

["TYPE=HMCCUDEV,dummy:on"]

NOTIFYDEV wird dann ebenfalls entsprechend gesetzt. Die Syntax will ich mit den FHEM-NOTIFYDEV-Vorgaben gleich halten, damit es keine Verwirrung gibt.

D. h. Kommagetrennte Angaben für mehrere Devices und Regex sind möglich, allerdings wird ohne spezifische Regex nach genauen Devices gesucht und nicht nach einem Teilstring, wie sonst bei DOIF-Ereignisangaben.

Bsp.

Alle Devices deren TYPE mit "HM" anfängt wäre dann:

["TYPE=HM.*"]

und nicht

["TYPE=^HM"]

Ich denke bei TYPE ist das zu vertreten. Weil man auf die Benennung der TYPE-Angaben keinen Einfluss hat, wird man eher konkrete Devicetypen angeben (ggf. mehrere kommagetrennt) statt mit Regex zu filtern.

[PatrickR]

Hallo Damian,

danke, dass Du Dir das Thema angesehen hast. Nur TYPE zu unterstützen halte ich aber für problematisch, da NOTIFYDEV mit devspecs deutlich mehr unterstützt. Somit sollte man konsequenterweise devspecs unterstützen, was aber teilweise bereits vorhandene Funktionalität doppeln und ggf. sogar mit der vorhandenen Syntax kollidieren würde.

Einfacher und mit weniger Nebenwirkungen wäre folgende Implementierung:

• Ein Attribut der Art overrideNotifydev, das die NOTIFYDEV überschreibt. Nutzung auf eigenes Risiko
• Ein Internal, in dem DOIF weiterhin das automatisch ermittelte NOTIFYDEV als Inspirationsquelle vorhält.

Patrick

[Damian]

Hallo Damian,

danke, dass Du Dir das Thema angesehen hast. Nur TYPE zu unterstützen halte ich aber für problematisch, da NOTIFYDEV mit devspecs deutlich mehr unterstützt. Somit sollte man konsequenterweise devspecs unterstützen, was aber teilweise bereits vorhandene Funktionalität doppeln und ggf. sogar mit der vorhandenen Syntax kollidieren würde.

Einfacher und mit weniger Nebenwirkungen wäre folgende Implementierung:

• Ein Attribut der Art overrideNotifydev, das die NOTIFYDEV überschreibt. Nutzung auf eigenes Risiko
• Ein Internal, in dem DOIF weiterhin das automatisch ermittelte NOTIFYDEV als Inspirationsquelle vorhält.

Patrick

Also ich sehe da kein Problem, da ich ja ohnehin eine eigene Auswertung der Events vornehme. Wichtig ist nur, dass die Triggerangaben im DOIF zu NOTIVDEV passt und dafür muss ich Sorge tragen.

Die TYPE-Angabe ist ja keine zusätzliche Einschränkung mit "UND" sondern eine ODER Verknüpfung, daher reicht es nicht ein Attribut zu setzen.

Am Ende macht DOIF eine Perlfunktion daraus, die ja zum Triggerzeitpunkt wahr ist und sonst nicht - das muss so bleiben.

Wenn ich also einen Trigger mit if-Abfrage z. B. ["^Fenster"] dann kann NOTIFYDEV "Fenster..." nur erweitern aber nicht einschränken.

Wenn man TYPE mit eine konventionellen DEVICE-Regex-Kombinieren will, dann kann man es mit or kombinieren if (["^Fenster...] or ["TYPE=HM.*"])...

Ich bin mir nicht sicher ob z.B. NOTIFY selbst TYPE-Angaben unterstützt. In der Doku steht nichts dazu.

[PatrickR]

Hi!

Die TYPE-Angabe ist ja keine zusätzliche Einschränkung mit "UND" sondern eine ODER Verknüpfung, daher reicht es nicht ein Attribut zu setzen.

Ein Attribut löst genau das Problem, um das es hier geht, das UND-Problem. Mein Wunsch ist schlichtweg, meinen perfekt funktionierenden Workaround (s. o.) von einem Hack in ein Attribut zu gießen. Wenn das nicht gewünscht ist, muss ich das akzeptieren.

Überlegen könnte man noch, ob ein derartiges Attribut sogar global, d. h. modulübergreifend Sinn ergibt. Schließlich ist DOIF nicht das einzige Modul, das von einer fallspezifisch handoptimierten NOTIFYDEV profitieren kann.

Patrick

[Damian]

Dann zeige mir bitte ein konkretes DOIF-Beispiel mit dem Attribut.