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
Ich habe mal die Systemlast in meinem System mit der aktuellen Version verglichen. Ergebnis: die neue Version braucht ca. 30% weniger Systemlast.
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
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]
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
Neue Version wurde eingecheckt.
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
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 DOIFgetestet mit PIR_B als Dummy und
Zitattrigger PIR_B on
Interessant mit
trigger PIR_B onfunktioniert es
Mit
set PIR_B onund 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.
Ich habe das Problem erkannt und bastle an einer Lösung. Es hat mit dem versteckten Status zu tun.
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.
Ich habe das Problem gefixed, es sollte jetzt wieder kompatibel sein. Teste bitte mal die angehängte Version bei dir.
Edit: Version eingecheckt
Ja, jetzt funktioniert es.
Danke.
Ich habe die korrigierte Version eingecheckt.
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.
Mit der Version 98_DOIF.pm 20254 2019-09-26 18:06:30Z Damian gibt es beim Neustart eine Warnung:
Zitat2019.09.27 19:17:39 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_DOIF.pm line 2439.
Zitat von: Ellert am 27 September 2019, 19:31:11
Mit der Version 98_DOIF.pm 20254 2019-09-26 18:06:30Z Damian gibt es beim Neustart eine Warnung:
Wird mit dem nächsten Update korrigiert.
Neue Version eingecheckt. Es wird jetzt im Internal DOIFDEV der DOIF-Filter angezeigt, falls NOTIFYDEV-Filter nicht gesetzt werden konnte.
Ich teste gerade eine neue Version des DOIF mit einer neuen FHEM-API, welche den NOTIFYDEV Filter setzt. Normalerweise scheitert abhängig von der Definition immer wieder das Setzen des Filters, so dass FHEM-Module unnötig von der FHEM-Zentrale benachrichtigt werden und sich selbst um das Filtern der Nachrichten kümmern müssen.
Wenn meine Tests positiv ausfallen, werde ich die neue Version einchecken.
Damit wäre DOIF das erste Modul, welches bei jeder Definition mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst :)
Hier ist die neue DOIF-Version vorab zum Ausprobieren, sie wird nicht durch fremde Events geweckt. DOIF-Devices, die das Attribut disable 1 gesetzt haben (Zustand: deactivated), werden gar nicht mehr geweckt. Da es das erste Modul in FHEM ist, welches die neuen Möglichkeiten performanceschonend zu arbeiten nutzt, wäre gut, wenn der eine oder andere es bei sich vorab testet. Mein umfangreiches System läuft seit ein paar Tagen problemlos mit der neuen Version.
Wichtig: Die neue DOIF-Version funktioniert nur mit der aktuellen fhem.pl Version!
Edit: neue Version wurde eingecheckt
Zitat von: Damian am 22 Januar 2022, 16:41:32
Damit wäre DOIF das erste Modul, welches bei jeder Definition mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst :)
Bei aller (berechtigten!) Freude darüber, dass DOIF demnächst dann auch die schon lange (2014?) bestehenden Möglichkeiten der Optimierung bei der Verteilung von Event-Benachrichtigungen nutzt:
Woher nimmst du die Gewissheit, dass DOIF damit "erster" wäre...? Vielleicht das erste Modul, das die neuen "Pseudo-API-calls" aus fhem.pl nutzt, aber - je nach vorhandenen Modulen - kommen ein paar mehr Treffer mit (performance-technisch betrachtet) korrekten Ergebnissen...:
list .* NOTIFYDEVund
list .* disableNotifyFn(Und nicht alles davon hängt von "korrekten" Einstellungen durch den User ab!)
Zitat von: Beta-User am 28 Januar 2022, 09:00:59
Bei aller (berechtigten!) Freude darüber, dass DOIF demnächst dann auch die schon lange (2014?) bestehenden Möglichkeiten der Optimierung bei der Verteilung von Event-Benachrichtigungen nutzt:
Woher nimmst du die Gewissheit, dass DOIF damit "erster" wäre...? Vielleicht das erste Modul, das die neuen "Pseudo-API-calls" aus fhem.pl nutzt, aber - je nach vorhandenen Modulen - kommen ein paar mehr Treffer mit (performance-technisch betrachtet) korrekten Ergebnissen...:
list .* NOTIFYDEV
und
list .* disableNotifyFn
(Und nicht alles davon hängt von "korrekten" Einstellungen durch den User ab!)
Ich glaube du hast meine Aussage nicht richtig gelesen:
Damit wäre DOIF das erste Modul, welches bei
jeder Definition mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst.
Zitat von: Damian am 28 Januar 2022, 09:30:12
Ich glaube du hast meine Aussage nicht richtig gelesen:
Ich glaube, du hast nur auf "klassische" Eventhandler geschaut, ohne meine Beispielbefehle mal auf deine Installation(en) loszulassen :) .
EDIT: Zumindest, wer CUL_HM im Einsatz hat, wird für jede Instanz dieses Moduls einen der beiden Treffer finden, und es gibt noch eine Reihe weiterer Module, die die alten Funktionen/Möglichkeiten so genutzt haben, dass es IMMER für ALLE Instanzen gesetzt wurde.
Zitat von: Beta-User am 28 Januar 2022, 09:46:43
Ich glaube, du hast nur auf "klassische" Eventhandler geschaut, ohne meine Beispielbefehle mal auf deine Installation(en) loszulassen :) .
EDIT: Zumindest, wer CUL_HM im Einsatz hat, wird für jede Instanz dieses Moduls einen der beiden Treffer finden, und es gibt noch eine Reihe weiterer Module, die die alten Funktionen/Möglichkeiten so genutzt haben, dass es IMMER für ALLE Instanzen gesetzt wurde.
ja, gemeint war natürlich:
Damit wäre DOIF das erste Modul, welches bei jeder Definition mit beliebiger Device-Regex mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst.
Also wer jetzt denkt, sein System würde doppelt so schnell laufen, der irrt. Es handelt sich um ein Feintuning um paar Millisekunden herauszuholen. Dennoch ist es eine zentrale Änderung im Modul, daher hier nochmal der Hinweis, die neue Version vorab zu testen, bevor ich sie einchecke: https://forum.fhem.de/index.php/topic,103401.msg1203851.html#msg1203851
um keine bösen Überraschungen zu erleben :)
Zitat von: Damian am 28 Januar 2022, 10:23:30
ja, gemeint war natürlich:
Ob es "natürlich" gemeint war, sei mal dahingestellt...
Zitat
Damit wäre DOIF das erste Modul, welches bei jeder Definition mit beliebiger Device-Regex mit einem gesetzten NOTIFYDEV-Filter arbeitet und damit keine Performance unnötig frisst.
Je nachdem, auf welchen Aspekt man schielt, würde ich mal (abgesehen vom Sonderfall "auf alles hören") behaupten, dass auch das nicht sachlich 100% stimmt. Du hast vermutlich kein statistics im Einsatz.
Aber ab von solchen Feinheiten: DOIF ist im Unterschied zu notify jetzt an der Stelle so optimiert, dass der User nicht selbst aufpassen muss, was er tut, soweit ist es "natürlich" bald richtig.
ZitatAber ab von solchen Feinheiten: DOIF ist im Unterschied zu notify jetzt an der Stelle so optimiert, dass der User nicht selbst aufpassen muss, was er tut, soweit ist es "natürlich" bald richtig.
Würde ich so nicht behaupten. Egal, ob der User DOIF oder notify benutzt, er sollte sich immer Gedanken machen, was er mit seiner Definition auslöst. Wer z. B. im DOIF [":bla"] definiert, dem wird auch die neue DOIF-Version nicht viel helfen, weil das Modul auch beim gesetzten NOTIFY-Filter bei jedem Event im System geweckt wird.
Hmmm, bin da nicht 100% durch, aber mAn. braucht man NOTIFYDEV nicht setzen, wenn (wirklich!) alle Devices den Eventhandler triggern sollen. Kann sogar sein, dass das (aber nur für diese Ausnahme) einfach nur unnötigerweise die zu durchsuchenden Daten vergrößert und daher die Laufzeit für "den Rest" geringfügig erhöht...
Zitat von: Beta-User am 28 Januar 2022, 11:08:39
Hmmm, bin da nicht 100% durch, aber mAn. braucht man NOTIFYDEV nicht setzen, wenn (wirklich!) alle Devices den Eventhandler triggern sollen. Kann sogar sein, dass das (aber nur für diese Ausnahme) einfach nur unnötigerweise die zu durchsuchenden Daten vergrößert und daher die Laufzeit für "den Rest" geringfügig erhöht...
Wird hier langsam OT, aber, ob man NOTIFYDEV mit .* oder gar nicht setzt, beides führt zur (einmaligen) Bildung der gleichen Benachrichtigungslisten in fhem.pl: für jedes Device im System wird das jeweilige zu benachrichtigende Device eingetragen.
Zitat von: Damian am 27 Januar 2022, 19:25:18Mein umfangreiches System läuft seit ein paar Tagen problemlos mit der neuen Version.
Mein FHEM (NUC mit Proxmox, Debian 11 (bullseye), Perl v5.32.1) läuft seit heute Morgen mit deiner neuen Version. Ohne Fehlermeldungen oder anderen Auffälligkeiten.
Gruss
Enno
Zitat von: enno am 28 Januar 2022, 13:24:29
Mein FHEM (NUC mit Proxmox, Debian 11 (bullseye), Perl v5.32.1) läuft seit heute Morgen mit deiner neuen Version. Ohne Fehlermeldungen oder anderen Auffälligkeiten.
Gruss
Enno
Danke für´s Feedback.
ich schließe mich Enno an und kann berichten: mein Testsystem seit gestern morgen und mein "Haupt"system seit heute morgen laufen mit der eingecheckten Version ohne Probleme. Nix im Log, alles geht soweit. Ein paar DOIFs habe ich mir angesehen, die haben jetzt alle ein Notifydef, so wie es aussieht nur mit den Devices, die triggern sollen. Das war vorher nicht so, oft stand da ein DOIFnotifydef oder so, oder auch gar nix, wenn die Regex nicht gut gewählt war.
Performancemäßig kann ich nicht viel sagen, läuft so wie vorher, was die CPU-Last angeht. Ich habe aber auch schon so ziemlich alles an Events rausgefiltert, was nicht gebraucht wird.
Gruß
Sany
Zitat von: Sany am 29 Januar 2022, 21:05:32
ich schließe mich Enno an und kann berichten: mein Testsystem seit gestern morgen und mein "Haupt"system seit heute morgen laufen mit der eingecheckten Version ohne Probleme. Nix im Log, alles geht soweit. Ein paar DOIFs habe ich mir angesehen, die haben jetzt alle ein Notifydef, so wie es aussieht nur mit den Devices, die triggern sollen. Das war vorher nicht so, oft stand da ein DOIFnotifydef oder so, oder auch gar nix, wenn die Regex nicht gut gewählt war.
Performancemäßig kann ich nicht viel sagen, läuft so wie vorher, was die CPU-Last angeht. Ich habe aber auch schon so ziemlich alles an Events rausgefiltert, was nicht gebraucht wird.
Gut - das hört sich gut an. Die meisten DOIF-Definitionen hatten vorher schon NOTIFYDEV gehabt, wenn es um konkrete Readings ging. Bei bestimmten Ereignistriggern mit einer Regex für Devices der Art ["<Device-Regex>:<Event-Regex>] konnte die bisher genutzt Routine in fhem.pl keinen NOTIFY-Filter setzen. Allerdings habe ich auch für solche Fälle DOIF seinerzeit durch einen eigenen Filter optimiert. FHEM hat dann mit DOIF etwas Ping-Pong gespielt (0,02 Millisekunden pro Ping beim Pi 4). Da jetzt immer der NOTIFY-Filter im DOIF gesetzt werden kann, ist der interne Filter hinfällig. Die Performanceunterschiede werden höchstens in sehr stark belasteten Systemen messbar sein.
Viel effektiver ist es, unnötige Events im System zu eliminieren. :D
Neue DOIF Version ist jetzt offiziell, morgen per Update verfügbar.
Hallo,
ich beobachte seit der Anpassung bei einem meiner DOIF ein unterschiedliches Verhalten - es triggers nicht mehr.
(["Thermo_SZ:^temperature"])
(setreading di_heizen_Schlafzimmer is_temp {("$EVENT" =~ /[^\:]*: (\d*\.\d*)/;$1)})
Das NotifyDev sieht so aus. Hier werden die Devices welche triggers sollen in Klammern gesetzt - dann gilt die Expression nicht mehr.
NOTIFYDEV
.*(Thermo_Bad).*,.*(Thermo_SZ).*,global
Kann man das irgendwie ändern?
Viele Grüße und Dank vorab,
Max
Zitat von: Sirel am 19 Februar 2022, 08:30:58
Hallo,
ich beobachte seit der Anpassung bei einem meiner DOIF ein unterschiedliches Verhalten - es triggers nicht mehr.
(["Thermo_SZ:^temperature"])
(setreading di_heizen_Schlafzimmer is_temp {("$EVENT" =~ /[^\:]*: (\d*\.\d*)/;$1)})
Das NotifyDev sieht so aus. Hier werden die Devices welche triggers sollen in Klammern gesetzt - dann gilt die Expression nicht mehr.
NOTIFYDEV
.*(Thermo_Bad).*,.*(Thermo_SZ).*,global
Kann man das irgendwie ändern?
Viele Grüße und Dank vorab,
Max
Ich kann kein Problem erkennen. Dein einziger gezeigter Trigger ist ["Thermo_SZ:^temperature"], daraus resultiert .*(Thermo_SZ).*, alle anderen Devices dürfen nicht durchkommen.
Hi Damian,
ich sehe grnds. auch keinen Fehler.
Hier mal das gesamte Set an Infos:
Internals:
DEF (["Thermo_SZ:^temperature"])
(setreading di_heizen_Schlafzimmer is_temp {("$EVENT" =~ /[^\:]*: (\d*\.\d*)/;$1)})
DOELSEIF
(["Thermo_Bad:^temperature"])
(setreading Temp_bad is_temp {("$EVENT" =~ /[^\:]*: (\d*\.\d*)/;$1)})
DOELSE
FUUID 5e1f6422-f33f-f340-4cfe-7846b26e7c974b96
MODEL FHEM
NAME di_reading_generator
NOTIFYDEV .*(Thermo_Bad).*,.*(Thermo_SZ).*,global
NR 341
NTFY_ORDER 50-di_reading_generator
STATE cmd_2
TYPE DOIF
VERSION 25663 2022-02-09 17:05:11
READINGS:
2022-02-19 09:27:41 Device Thermo_Bad
2020-01-17 09:45:03 Temperatur T: 20.9 H: 57.1
2022-02-19 09:27:41 cmd 2
2022-02-19 09:27:41 cmd_event Thermo_Bad
2022-02-19 09:27:41 cmd_nr 2
2022-02-19 00:37:59 mode enabled
2022-02-19 09:27:41 state cmd_2
Regex:
accu:
collect:
cond:
:
0:
"Thermo_SZ:^temperature" Thermo_SZ:^temperature
1:
"Thermo_Bad:^temperature" Thermo_Bad:^temperature
attr:
cmdState:
wait:
waitdel:
condition:
0 ::EventDoIf('Thermo_SZ',$hash,'^temperature',0)
1 ::EventDoIf('Thermo_Bad',$hash,'^temperature',0)
do:
0:
0 setreading di_heizen_Schlafzimmer is_temp {("$EVENT" =~ /[^\:]*: (\d*\.\d*)/;$1)}
1:
0 setreading Temp_bad is_temp {("$EVENT" =~ /[^\:]*: (\d*\.\d*)/;$1)}
2:
0
helper:
NOTIFYDEV .*(Thermo_Bad).*,.*(Thermo_SZ).*,global
event temperature: 20.9
globalinit 1
last_timer 0
sleeptimer -1
timerdev Thermo_Bad
timerevent temperature: 20.9
triggerDev Thermo_Bad
timerevents:
temperature: 20.9
timereventsState:
temperature: 20.9
triggerEvents:
temperature: 20.9
triggerEventsState:
temperature: 20.9
internals:
readings:
trigger:
uiState:
uiTable:
Attributes:
do always
room Unsorted
Die Triggernde Instanz ist ein Sensor der via Fhem2Fhem seine Daten ins Hauptsystem liefert. Vor dem Update funktioniert dieses DOIF ohne Probleme, jetzt aber nicht mehr. Es hat sich sonst nichts mehr geändert.
Darüber läuft unsere Heizung :-X
Viele Grüße,
Max
Poste mal die Events vom betroffenen Device.
Hi Damian,
das sind die Events:
19 19:30:07 XiaomiBTLESens Thermo_Bad temperature: 23.0
2022-02-19 19:30:07 XiaomiBTLESens Thermo_Bad humidity: 45.8
2022-02-19 19:30:07 XiaomiBTLESens Thermo_Bad T: 23.0 H: 45.8
Viele Grüße und Dank vorab,
Max
Zitat von: Sirel am 19 Februar 2022, 19:32:15
Hi Damian,
das sind die Events:
19 19:30:07 XiaomiBTLESens Thermo_Bad temperature: 23.0
2022-02-19 19:30:07 XiaomiBTLESens Thermo_Bad humidity: 45.8
2022-02-19 19:30:07 XiaomiBTLESens Thermo_Bad T: 23.0 H: 45.8
Viele Grüße und Dank vorab,
Max
Ich habe mal eine Anfrage dazu im Developer-Board gestellt. Meine Vermutung ist, dass es daran liegt, dass du im FHEM-System, wo dein DOIF definiert ist, kein Device namens Thermo_Bad hast.
Zum testen könntest du einen Dummy namens Thermo_Bad definieren und schauen, ob es dann geht, ggf. danach noch defmod auf das DOIF ausführen.
Dank Dir für Deine schnelle Einschätzung.
Ich teste es morgen mit dem Dummy. Ist diese Bedingung neu? Vorher hat es alles problemlos funktioniert.
Hab ein schönen Samstagabend!
Max
Zitat von: Sirel am 19 Februar 2022, 20:30:39
Dank Dir für Deine schnelle Einschätzung.
Ich teste es morgen mit dem Dummy. Ist diese Bedingung neu? Vorher hat es alles problemlos funktioniert.
Hab ein schönen Samstagabend!
Max
Ich hoffe, dass es keine neue Bedingung sein wird :) Ich warte noch auf Feedback vom Master, ansonsten werde ich mir schon etwas einfallen lassen ;)
Perfekt👌
Bis morgen !
Guten Morgen Damian,
nachdem ich im Host-System die Dummys erstellt habe funktioniert es. Das hat gleichzeitig das DOIF als solches überflüssig gemacht.
Ist so ok, ich fand meine andere Lösung nur etwas kompakter, ist aber vllt auch nur Geschmacksache.
Hab vielen Dank und einen schönen Sonntag,
Max
Zitat von: Sirel am 20 Februar 2022, 10:39:14
Guten Morgen Damian,
nachdem ich im Host-System die Dummys erstellt habe funktioniert es. Das hat gleichzeitig das DOIF als solches überflüssig gemacht.
Ist so ok, ich fand meine andere Lösung nur etwas kompakter, ist aber vllt auch nur Geschmacksache.
Hab vielen Dank und einen schönen Sonntag,
Max
Dadurch arbeitet dein System effizienter. Wenn kein Device existiert, kann der NOTIFY-Filter nicht sinnvoll gesetzt werden, was dazu führt, dass ein DOIF sich mit allen Events des Systems unnötig beschäftigen müsste. Die aktuelle DOIF-Version setzt nun immer den NOTIFY-Filter, um eben solche Dinge zu vermeiden, dafür müssen aber die entsprechenden Devices im Host-System existieren.
Dann weiß ich für das nächste Mal Bescheid.
Wie immer, besten Dank!
Max
Nur am Rande:
Wenn es ein DOIF mit dem Namen Thermo_Bad im Host gibt, werden die Readings durch FHEM2FHEM dort erzeugt. state ist dabei allerdings problematisch, wenn model FHEM ist.
Zitat von: Ellert am 20 Februar 2022, 17:45:26
Nur am Rande:
Wenn es ein DOIF mit dem Namen Thermo_Bad im Host gibt, werden die Readings durch FHEM2FHEM dort erzeugt. state ist dabei allerdings problematisch, wenn model FHEM ist.
Wenn ein DOIF auf verschiedene Devices des fremden Systems reagieren soll, dann reicht das auch nicht mehr.
Die Probleme häufen sich allerdings: https://forum.fhem.de/index.php/topic,126321.0.html
Womöglich werde ich gezwungen sein, das grundsätzliche Setzen des NOTIFYDEV-Filters wieder auszubauen und den alten Mechanismus wieder reaktivieren - das wäre aus Sicht der gewonnen Performance schade.