Hallo zusammen.
Da gelegentlich der ein oder andere CUL ausfällt, würde ich gerne die per DOIF überwachen. Es soll dann eine Telegram Nachricht abgesetzt werden.
Habe mir den folgenden Code zusammen gestellt. Funktioniert jedoch nicht.
Ich habe das TYPE=CUL genommen, da ich 4 Stück davon habe.
([TYPE=CUL:state] ne "Initialized") (set zuhause @Sascha $name ist raus aus dem Rennen)
DOELSE
Jemand eine Idee, was da nicht klappt, bzw warum ?
Danke und Gruß
Sascha
devspec geht in DOIF nicht
Dafür musst Du die Aggregationsfunktionen vom DOIF nutzen und eine passende Regex für die Namen von deinen CULs finden, oder die Variable $TYPE nutzen
Siehe u.a. die Beispiele "Fenster Status/Meldung" oder "Raumtemperatur-Überwachung"
So. Habe mal ein bsichen experimentiert.
Hier das List zum DOIF
Internals:
DEF (["CUL"] ne "Initialized") (set zuhause message @Sascha 1 CUL ist raus aus dem Rennen)
DOELSE ()
MODEL FHEM
NAME receiver.cul
NR 471
NTFY_ORDER 50-receiver.cul
STATE cmd_1
TYPE DOIF
READINGS:
2018-10-10 16:43:25 Device wlanCUL
2018-10-10 16:45:14 cmd 1
2018-10-10 16:45:14 cmd_event wlanCUL
2018-10-10 16:45:14 cmd_nr 1
2018-10-10 16:39:12 mode enabled
2018-10-10 16:45:14 state cmd_1
2018-10-10 16:45:14 wait_timer no timer
Regex:
cond:
:
0:
"CUL" CUL
attr:
cmdState:
wait:
0:
130
1:
30
waitdel:
condition:
0 ::EventDoIf('CUL',$hash,'',0) ne "Initialized"
devices:
do:
0:
0 set zuhause message @Sascha 1 CUL ist raus aus dem Rennen
1:
0
helper:
event UNKNOWNCODE r382ce900033200162039a42
globalinit 1
last_timer 0
sleepdevice wlanCUL
sleepsubtimer -1
sleeptimer -1
timerdev wlanCUL
timerevent UNKNOWNCODE r382ce900033200162039a42
triggerDev wlanCUL
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: wlanCUL
state: cmd_1
timerevents:
UNKNOWNCODE r382ce900033200162039a42
timereventsState:
UNKNOWNCODE r382ce900033200162039a42
triggerEvents:
UNKNOWNCODE r382ce900033200162039a42
triggerEventsState:
UNKNOWNCODE r382ce900033200162039a42
internals:
itimer:
perlblock:
readings:
trigger:
uiState:
uiTable:
Attributes:
do always
room 99_Steuerung
wait 130:30
Habe das Problem, dass der wlanCUL als nicht da registriert wird, obwohl er da ist (Initialized).
Das tritt auch nur auf, bei den CUL´s die über wlan laufen.
jemand eine Idee, was da nicht rund läuft ?
Gruß und Danke
Sascha
Zitat von: sash.sc am 10 Oktober 2018, 16:55:20
So. Habe mal ein bsichen experimentiert.
Hier das List zum DOIF
Internals:
DEF (["CUL"] ne "Initialized") (set zuhause message @Sascha 1 CUL ist raus aus dem Rennen)
DOELSE ()
MODEL FHEM
NAME receiver.cul
NR 471
NTFY_ORDER 50-receiver.cul
STATE cmd_1
TYPE DOIF
READINGS:
2018-10-10 16:43:25 Device wlanCUL
2018-10-10 16:45:14 cmd 1
2018-10-10 16:45:14 cmd_event wlanCUL
2018-10-10 16:45:14 cmd_nr 1
2018-10-10 16:39:12 mode enabled
2018-10-10 16:45:14 state cmd_1
2018-10-10 16:45:14 wait_timer no timer
Regex:
cond:
:
0:
"CUL" CUL
attr:
cmdState:
wait:
0:
130
1:
30
waitdel:
condition:
0 ::EventDoIf('CUL',$hash,'',0) ne "Initialized"
devices:
do:
0:
0 set zuhause message @Sascha 1 CUL ist raus aus dem Rennen
1:
0
helper:
event UNKNOWNCODE r382ce900033200162039a42
globalinit 1
last_timer 0
sleepdevice wlanCUL
sleepsubtimer -1
sleeptimer -1
timerdev wlanCUL
timerevent UNKNOWNCODE r382ce900033200162039a42
triggerDev wlanCUL
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: wlanCUL
state: cmd_1
timerevents:
UNKNOWNCODE r382ce900033200162039a42
timereventsState:
UNKNOWNCODE r382ce900033200162039a42
triggerEvents:
UNKNOWNCODE r382ce900033200162039a42
triggerEventsState:
UNKNOWNCODE r382ce900033200162039a42
internals:
itimer:
perlblock:
readings:
trigger:
uiState:
uiTable:
Attributes:
do always
room 99_Steuerung
wait 130:30
Habe das Problem, dass der wlanCUL als nicht da registriert wird, obwohl er da ist (Initialized).
Das tritt auch nur auf, bei den CUL´s die über wlan laufen.
jemand eine Idee, was da nicht rund läuft ?
Gruß und Danke
Sascha
["CUL"] ist ein Ereignistrigger (wegen Anführungszeichen), der ist nur wahr oder falsch aber nicht "Initialized".
Ich mache das zB. so:
defmod CUL_Monitor DOIF ([CUL433] eq "disconnected") \
(set CUL433 reopen, msg CUL433 ausgefallen!)\
DOELSEIF ([CUL868] eq "disconnected") \
(set CUL868 reopen, msg CUL868 ausgefallen!)\
DOELSEIF ([USB300] !~ /initialized|opened/)\
(set USB300 reset, msg push EnOcean Stick ausgefallen!)\
DOELSEIF ([CUL433] eq "Initialized")\
(msg push CUL433 wieder verbunden.)\
DOELSEIF ([CUL868] eq "Initialized")\
(msg push CUL868 wieder verbunden.)\
DOELSEIF ([USB300] =~ /initialized|opened/) \
(msg push EnOcean Stick wieder verbunden.)
attr CUL_Monitor devStateIcon cmd_(1|2|3):ios-off cmd_(4|5|6):ios-on-blue
attr CUL_Monitor do always
attr CUL_Monitor repeatsame 1:1:1:1:1:1
attr CUL_Monitor wait 5:5:5:0:0:0
VG Sebastian
Zitat von: Damian am 10 Oktober 2018, 16:58:58
["CUL"] ist ein Ereignistrigger (wegen Anführungszeichen), der ist nur wahr oder falsch aber nicht "Initialized".
Wie kann man das ändern, dass auf das initialized reagiert wird? Ich möchte nicht jeden einzelnen cul abfragen, sondern als in einem Rutsch bzw als in einer Definition.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 10 Oktober 2018, 17:39:30
Wie kann man das ändern, dass auf das initialized reagiert wird? Ich möchte nicht jeden einzelnen cul abfragen, sondern als in einem Rutsch bzw als in einer Definition.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
evtl, mit (["CUL",""] eq "Initialized"), wenn Initialized sauber im Event steht. Es wird hier nämlich das Event ausgewertet und nicht der Status.
Was wäre denn mit [.*CUL.*]? Würde das nicht auch gehen?
Es geht nicht um die Namensfindung. Das scheint zu funktionieren.
@damian
Habe es mal mit deinem Vorschlag ausprobiert. Der msg Teil in das DOELSE gepackt. Es is immer einer der cul die über wlan angebunden sind, der Stress macht.
Gesendet von meinem E6653 mit Tapatalk
Und wie kann man dann noch heraus finden, welcher cul ausgesetzt hat?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 10 Oktober 2018, 19:39:27
Und wie kann man dann noch heraus finden, welcher cul ausgesetzt hat?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
z. B. https://fhem.de/commandref_DE.html#DOIF_do_resetwait
Mit resetwait?
Ich meine in einer gemeinschaftlichen Abfrage muss es doch ne variabel geben, die den Namen des auslösenden Gerätes beinhaltet,oder?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 10 Oktober 2018, 19:50:50
Mit resetwait?
Ich meine in einer gemeinschaftlichen Abfrage muss es doch ne variabel geben, die den Namen des auslösenden Gerätes beinhaltet,oder?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
ja, da bietet sich der DOIF-Perl-Modus an, da dieser beliebig viele Timer verwalten kann.
Nachdem was ich gelesen habe kann aber das normal doif nicht mit der Perl Variante nebeneinander existieren, oder?
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 11 Oktober 2018, 06:10:34
Nachdem was ich gelesen habe kann aber das normal doif nicht mit der Perl Variante nebeneinander existieren, oder?
Gesendet von meinem E6653 mit Tapatalk
Du kannst natürlich DOIFs im FHEM-Modus und im Perl-Modus definieren. Jeder DOIF-Definition kann aber immer nur entweder oder sein aber nicht beides.
Heißt, ein doif muss komplett in fhem oder Perl Modus sein!?
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 11 Oktober 2018, 08:19:02
Heißt, ein doif muss komplett in fhem oder Perl Modus sein!?
Gesendet von meinem E6653 mit Tapatalk
Ja.
Kannst du mir bitte mit dem doif Perl über die Arme greifen? Habe von perl absolut keinen Plan.
Würde mich freuen.
Danke
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 11 Oktober 2018, 09:07:24
Kannst du mir bitte mit dem doif Perl über die Arme greifen? Habe von perl absolut keinen Plan.
Würde mich freuen.
Danke
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Du musst dich erst mal hier einlesen: https://fhem.de/commandref_DE.html#DOIF_Perl_Modus
Dort steht auch erklärt wie man Definitionen aus dem FHEM-Modus in den Perl-Modus überführen kann.
Wenn dir das zu kompliziert ist, dann musst du im FHEM-Modus bleiben, ggf. pro CUL ein DOIF definieren.