Hauptmenü

Umstellung auf NOTIFYDEV-Filter

Begonnen von Damian, 31 August 2019, 16:10:46

Vorheriges Thema - Nächstes Thema

Damian

Aufgrund eines Problems musste ich die internen Triggermechanismen im DOIF anpassen, siehe: https://forum.fhem.de/index.php/topic,92296.0.html

In diesem Zusammenhang habe ich DOIF einen Filter verpasst, siehe https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Begrenzung_von_Events

Nun werden, wie beim Notify, nur noch Ereignisse von bestimmten Geräten zum DOIF-Gerät durchgelassen, das sollte sich positiv auf die Gesamtlast des System auswirken, wie stark genau, muss ich noch mit apptime untersuchen.

Als Nebeneffekt werden im DOIF die zu triggernden Devices angezeigt,

z. B.

ZitatInternals:
   DEF        (["bla1:test4"]) () DOELSEIF ([bla5:test2] == 1) () DOELSEIF ([[bla2:state]]) () DOELSE ()
   MODEL      FHEM
   NAME       checkall
   NOTIFYDEV  global,.*bla1.*,bla5,bla2
   NR         662
   NTFY_ORDER 50-checkall
   STATE      initialized
   TYPE       DOIF
   READINGS:
     2019-08-31 16:05:19   cmd             0
     2019-08-31 16:05:19   mode            enabled
     2019-08-31 16:05:19   state           initialized
     2019-08-31 16:05:19   timer_01_c03    01.09.2019 14:00:00

Im Anhang befindet sich die neue Version, sie sollte zur bisherigen kompatibel sein.

Edit: Version wurde eingecheckt
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Ich habe mal die Systemlast in meinem System mit der aktuellen Version verglichen. Ergebnis: die neue Version braucht ca. 30% weniger Systemlast.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

a-p-s

Hallo,

hab die Version jetzt einige Tage im Einsatz und sie reduziert die Systemlast gerade bei vielen DOIFs. Danke!

Eines ist mir aufgefallen: könnte es sein, dass wenn ich ein Device nur in DOIF_Readings verwende, dieses nicht korrekt in die NotifyDev übernommen wird? (Übrigens ist praktisch, direkt zu sehen, auf welche Devices reagiert wird).

Habe zum Testen dieses Device dann als Triggerbedingung im Hauptteil (Perl-Modus) eingebaut. Danach erschien es im NotifyDev, und das entsprechende DOIF-Reading wurde auch aktualisiert.

Grüße,
a-p-s

Damian

Zitat von: a-p-s am 09 September 2019, 17:57:41
Hallo,

hab die Version jetzt einige Tage im Einsatz und sie reduziert die Systemlast gerade bei vielen DOIFs. Danke!

Eines ist mir aufgefallen: könnte es sein, dass wenn ich ein Device nur in DOIF_Readings verwende, dieses nicht korrekt in die NotifyDev übernommen wird? (Übrigens ist praktisch, direkt zu sehen, auf welche Devices reagiert wird).

Habe zum Testen dieses Device dann als Triggerbedingung im Hauptteil (Perl-Modus) eingebaut. Danach erschien es im NotifyDev, und das entsprechende DOIF-Reading wurde auch aktualisiert.

Grüße,
a-p-s

Das Problem kann ich bei mir nicht nachvollziehen:

ZitatInternals:
   CFGFN     
   DEF        ##
   MODEL      FHEM
   NAME       doif_Reading
   NOTIFYDEV  global,FS
   NR         2021
   NTFY_ORDER 50-doif_Reading
   STATE      initialized
   TYPE       DOIF
   CHANGED:
     test: off
   CHANGEDWITHSTATE:
     test: off
   DOIF_Readings:
     test       ::InternalDoIf($hash,'FS','STATE')
   READINGS:
     2019-09-09 19:53:11   cmd             0
     2019-09-09 19:53:11   mode            enabled
     2019-09-09 19:53:11   state           initialized
     2019-09-09 19:54:04   test            off
   Regex:
     DOIF_Readings:
       FS:
         test:
           &STATE     ^FS$
     accu:
   condition:
   do:
     0:
   helper:
     DOIF_Readings_events
     event      off
     globalinit 1
     last_timer 0
     sleeptimer -1
     triggerDev FS
     triggerEvents:
       off
     triggerEventsState:
       state: off
   uiState:
   uiTable:
Attributes:
   DOIF_Readings test:[FS]
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

a-p-s

Hmm.. stimmt, wenn ich das mit einem Test-Device nachvollziehe, dann ist alles korrekt.

Da lag ich mit meiner Erklärung schlicht falsch.

Kann das Problem jetzt auch nicht mehr nachstellen - hatte das bei einem Device, das ich vor der Umstellung auf die neue Modulversion erstellt hatte. Ansonsten melde ich mich nochmals.

Grüße und Danke für die schnelle Antwort.
a-p-s

Damian

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Mit der neuen Version
98_DOIF.pm      20157 2019-09-13 21:08:50Z Damian
funktioniert der Eventtrigger nicht, getestet mit dem nachstehenden Code für Raw definition

set PIR_B on triggert nicht

defmod NDEV_test DOIF (["^PIR_B$:^on$"]) {Log 1, "$SELF:1 set on"}
attr NDEV_test do always
attr NDEV_test group 00_Test
attr NDEV_test room 0_Test

defmod PIR_B dummy
attr PIR_B group 00_Test
attr PIR_B room 0_Test
attr PIR_B setList on off

setstate NDEV_test initialized
setstate NDEV_test 2019-09-15 09:26:58 cmd 0
setstate NDEV_test 2019-09-15 09:26:58 mode enabled
setstate NDEV_test 2019-09-15 09:26:58 state initialized

setstate PIR_B on
setstate PIR_B 2019-09-15 09:27:27 state on

Damian

Bei mir schon:

Internals:
   CFGFN     
   DEF        (["^PIR_B$:^on$"]) {Log 1, "$SELF:1 set on"}
   MODEL      FHEM
   NAME       NDEV_test
   NOTIFYDEV  global,PIR_B
   NR         1784
   NTFY_ORDER 50-NDEV_test
   STATE      cmd_1
   TYPE       DOIF
   READINGS:
     2019-09-15 10:57:54   Device          PIR_B
     2019-09-15 10:57:54   cmd             1
     2019-09-15 10:57:54   cmd_event       PIR_B
     2019-09-15 10:57:54   cmd_nr          1
     2019-09-15 10:55:31   mode            enabled
     2019-09-15 10:57:54   state           cmd_1
   Regex:
     accu:
     cond:
       :
         0:
           "^PIR_B$:^on$" ^PIR_B$:^on$
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          ::EventDoIf('^PIR_B$',$hash,'^on$',0)
   do:
     0:
       0          {Log 1, "NDEV_test:1 set on"}
     1:
   helper:
     event      on
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   PIR_B
     timerevent on
     triggerDev PIR_B
     DOIF_eventas:
       cmd_nr: 1
       cmd: 1
       cmd_event: PIR_B
       state: cmd_1
     timerevents:
       on
     timereventsState:
       on
     triggerEvents:
       on
     triggerEventsState:
       on
   internals:
   readings:
   trigger:
   uiState:
   uiTable:
Attributes:
   room       DOIF


getestet mit PIR_B als Dummy und
Zitattrigger PIR_B on
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

#8
Interessant mit
trigger PIR_B on
funktioniert es

Mit
set PIR_B on
und auch bei der Benutzung der on/off Button in der Detailansicht funktioniert es nicht.

Die Events im Eventmonitor sehen so aus

2019-09-15 13:30:37 DOIF NDEV_test cmd_event: PIR_B
2019-09-15 13:30:37 dummy PIR_B on
2019-09-15 13:30:44 dummy PIR_B on
2019-09-15 13:30:47 dummy PIR_B on
2019-09-15 13:30:50 dummy PIR_B on


13:30:37 wurde mit dem Befehl trigger erzeugt, die anderen Events per on-Button im Frontend

Funktioniert bei Dir nur trigger oder auch set und der on-Button?

So sieht das Listing aus, wenn set oder der Button verwendet wird
ZitatInternals:
   CFGFN     
   DEF        (["^PIR_B$:^on$"]) {Log 1, "$SELF:1 set on"}
   FUUID      5d7e226a-f33f-a3dc-30fa-cb694a7a13fb332d
   MODEL      FHEM
   NAME       NDEV_test
   NOTIFYDEV  global,PIR_B
   NR         274
   NTFY_ORDER 50-NDEV_test
   STATE      initialized
   TYPE       DOIF
   VERSION    20157 2019-09-13 21:08:50
   READINGS:
     2019-09-15 13:37:14   cmd             0
     2019-09-15 13:37:14   mode            enabled
     2019-09-15 13:37:14   state           initialized
   Regex:
     accu:
     cond:
       :
         0:
           "^PIR_B$:^on$" ^PIR_B$:^on$
   condition:
     0          ::EventDoIf('^PIR_B$',$hash,'^on$',0)
   do:
     0:
       0          {Log 1, "NDEV_test:1 set on"}
     1:
   helper:
     globalinit 1
     last_timer 0
     sleeptimer -1
   uiState:
   uiTable:
Attributes:
   do         always
   group      00_Test
   room       0_Test

Das Verhalten ist auf 3 verschiedenen FHEM-Instanzen gleich, der Fehler tritt bei mir in jeder Instanz auf, auf verschiedenen Rechnern.

FHEM habe ich gestern komplett aktualisiert und neu gestartet.

Damian

Ich habe das Problem erkannt und bastle an einer Lösung. Es hat mit dem versteckten Status zu tun.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Ja, ich habe auch etwas experimentiert, folgendes funktioniert

["^PIR_B$:on$"], also weglassen des Beginnzeichen ^ bei Reading/Value Regex oder
["^PIR_B$:^state: on$"] und setzen von AddStateEvent.


Damian

#11
Ich habe das Problem gefixed, es sollte jetzt wieder kompatibel sein. Teste bitte mal die angehängte Version bei dir.

Edit: Version eingecheckt
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert


Damian

Ich habe die korrigierte Version eingecheckt.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Die neueste Version arbeitet mit einem zweistufigen Filter: Sollte der NOTIFYDEV-Filter aufgrund der Regex-Definition für Geräte nicht greifen (Internal NOTIFYDEV nicht sichtbar), so wird ein eigener Filter im DOIF zur Systemlastminimierung verwendet.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF