... hat sich am DOIF irgend was geändert?
Folgendes Konstrukt hat zumindest gestern Abend, und ich meine vorgestern Abend noch funktioniert, heute Abend nicht mehr. Seit Sonnabend oder Sonntag war ich auch nicht mehr am System am Gange, so das auch von der Seite keine Fehler eingebracht werden konnten ...
Es wird "lum" nicht mehr gesetzt resp. wird "lum_set" nicht mehr von Änderungen in "LUM" (Groß-/Kleinschreibung beachten) getriggert, egal ob berechnete oder manuelle Änderungen an "LUM" vorgenommen werden.
Die Abarbeitung von LUM_set funktioniert einwandfrei; der aktuelle Mittelwert wird bei Änderungen nach LUM:state geschrieben.
Änderungen an LUM:state resp. LUM:x scheinen keinen Trigger zu generieren, welcher von "lum_set" aufgefangen werden kann; weder in "lum_set", noch in "lum" passiert irgend etwas...
# Groß-/ Kleinschreibung beachten!
# Bei Änderung der Helligkeit eines Melders Mittelwert in LUM-Dummy schreiben
define LUM_set DOIF (["HM2BB"]) (set LUM {(([HM2BB1:brightness]+[HM2BB2:brightness])/2)})
attr LUM_set do always
define LUM dummy
attr LUM alias Helligkeit
attr LUM group Vorgaben
attr LUM readingList 0 1 2
attr LUM room Vorgaben
attr LUM setList 0:40,45,50,55,60,65,70,75,80,85,90,95,100,105,110 1:80,85,90,95,100,105,110,115,120,125,130,135,140,145,150 2:120,125,130,135,140,145,150,155,160,165,170,175,180,185,190
attr LUM webCmd 0:1:2
# LUM = Schwellwerte in 0, 1, 2 so wie die aktuelle Helligkeit in state
# lum = Luminanz auf 3=sonnenschein, 2=hell, 1=dämmerung, 0=dunkel setzen
define lum_set DOIF ([LUM] < [LUM:0]) (set lum 0) \
DOELSEIF ([LUM] > [LUM:0] and [LUM] < [LUM:1]) (set lum 1) \
DOELSEIF ([LUM] > [LUM:1] and [LUM] < [LUM:2]) (set lum 2) \
DOELSEIF ([LUM] > [LUM:2]) (set lum 3)
attr lum_set do always
define lum dummy
attr lum alias Helligkeit
attr lum devStateIcon 0:scene_night@darkblue:1 1:scene_night@skyblue:2 2:weather_sun@khaki:3 3:weather_sun@khaki:0
attr lum group Umwelt
attr lum room System,EG.Wohnen,EG.Essen,EG.Küche,Umwelt
attr lum setList state:0,1,2,3
attr lum sortby 12
attr lum webCmd :
hier noch die Lists dazu, falls jemand fragt:
Internals:
CFGFN /opt/fhem/_INC/00_Global_Vorgaben.cfg
NAME LUM
NR 869
STATE 12
TYPE dummy
Readings:
2016-08-09 23:29:12 0 75
2016-08-03 13:19:20 1 110
2016-08-04 21:55:32 2 140
2016-08-09 23:39:27 state 12
Attributes:
alias Helligkeit
group Vorgaben
readingList 0 1 2
room Vorgaben
setList 0:40,45,50,55,60,65,70,75,80,85,90,95,100,105,110 1:80,85,90,95,100,105,110,115,120,125,130,135,140,145,150 2:120,125,130,135,140,145,150,155,160,165,170,175,180,185,190
webCmd 0:1:2
nternals:
CFGFN /opt/fhem/_INC/00_Global_Sonne_real.cfg
NAME lum
NR 807
STATE 2
TYPE dummy
Readings:
2016-08-09 23:43:55 state 2
Attributes:
alias Helligkeit
devStateIcon 0:scene_night@darkblue:1 1:scene_night@skyblue:2 2:weather_sun@khaki:3 3:weather_sun@khaki:0
group Umwelt
room System,EG.Wohnen,EG.Essen,EG.Küche,Umwelt
setList state:0,1,2,3
sortby 12
webCmd :
Internals:
CFGFN /opt/fhem/_INC/00_Global_Vorgaben.cfg
DEF (["HM2BB"]) (set LUM {(([HM2BB1:brightness]+[HM2BB2:brightness])/2)})
NAME LUM_set
NR 861
NTFY_ORDER 50-LUM_set
STATE cmd_1
TYPE DOIF
Readings:
2016-08-09 23:39:27 Device HM2BB2
2016-08-09 23:39:27 cmd 1
2016-08-09 23:39:27 cmd_event HM2BB2
2016-08-09 23:39:27 cmd_nr 1
2016-08-03 23:16:41 e_PIRdy_Pav 19
2016-08-09 23:39:27 matched_event_c1_1 brightness: 9
2016-08-09 23:39:27 state cmd_1
Condition:
0 EventDoIf('HM2BB',$hash,'',0)
Devices:
Do:
0:
0 set LUM {(([HM2BB1:brightness]+[HM2BB2:brightness])/2)}
Helper:
event brightness: 9
globalinit 1
last_timer 0
sleeptimer -1
timerdev HM2BB2
timerevent brightness: 9
triggerDev HM2BB2
timerevents:
brightness: 9
timereventsState:
brightness: 9
triggerEvents:
brightness: 9
triggerEventsState:
brightness: 9
Internals:
Itimer:
Readings:
Regexp:
0:
0 HM2BB
All:
0 HM2BB
State:
Trigger:
Attributes:
do always
Internals:
CFGFN /opt/fhem/_INC/00_Global_Sonne_real.cfg
DEF (["HM2BB"] and [LUM] < [LUM:0]) (set lum 0)
DOELSEIF (["HM2BB"] and [LUM] > [LUM:0] and [LUM] < [LUM:1]) (set lum 1)
DOELSEIF (["HM2BB"] and [LUM] > [LUM:1] and [LUM] < [LUM:2]) (set lum 2)
DOELSEIF (["HM2BB"] and [LUM] > [LUM:2]) (set lum 3)
NAME lum_set
NR 794
NTFY_ORDER 50-lum_set
STATE cmd_3
TYPE DOIF
Readings:
2016-08-09 23:39:27 Device HM2BB2
2016-08-09 21:11:20 cmd 3
2016-08-09 21:11:20 cmd_event LUM
2016-08-09 21:11:20 cmd_nr 3
2016-08-09 23:39:27 e_LUM_1 110
2016-08-09 23:39:27 e_LUM_2 140
2016-08-09 23:39:27 e_LUM_STATE 12
2016-08-09 23:24:35 e_LUM_state 19.5
2016-08-03 22:22:45 e_lum_STATE 0
2016-08-09 23:39:27 matched_event_c1_1 brightness: 9
2016-08-09 23:39:27 matched_event_c2_1 brightness: 9
2016-08-09 23:39:27 matched_event_c3_1 brightness: 9
2016-08-09 23:39:27 matched_event_c4_1 brightness: 9
2016-08-09 21:11:20 state cmd_3
Condition:
0 EventDoIf('HM2BB',$hash,'',0) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) < InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef))
1 EventDoIf('HM2BB',$hash,'',0) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) > InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) < ReadingValDoIf($hash,'LUM','1','','',AttrVal($hash->{NAME},'notexist',undef))
2 EventDoIf('HM2BB',$hash,'',0) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) > ReadingValDoIf($hash,'LUM','1','','',AttrVal($hash->{NAME},'notexist',undef)) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) < ReadingValDoIf($hash,'LUM','2','','',AttrVal($hash->{NAME},'notexist',undef))
3 EventDoIf('HM2BB',$hash,'',0) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) > ReadingValDoIf($hash,'LUM','2','','',AttrVal($hash->{NAME},'notexist',undef))
Devices:
0 LUM
1 LUM
2 LUM
3 LUM
all LUM
Do:
0:
0 set lum 0
1:
0 set lum 1
2:
0 set lum 2
3:
0 set lum 3
4:
Helper:
event brightness: 9
globalinit 1
last_timer 0
sleeptimer -1
triggerDev HM2BB2
triggerEvents:
brightness: 9
triggerEventsState:
brightness: 9
Internals:
0 LUM:STATE
1 LUM:STATE
2 LUM:STATE
3 LUM:STATE
all LUM:STATE
Itimer:
Readings:
1 LUM:1
2 LUM:1 LUM:2
3 LUM:2
all LUM:1 LUM:2
Regexp:
0:
0 HM2BB
1:
0 HM2BB
2:
0 HM2BB
3:
0 HM2BB
All:
0 HM2BB
State:
Trigger:
Attributes:
do always
Zitathat sich am DOIF irgend was geändert?
Welche DOIF Version hast Du geladen?
... ist derzeit ...
98_DOIF.pm 11314 2016-04-26 18:29:24Z damian-s
Dann sollte sich nach dem 7. oder 8.08. nichts geändert haben. Es sei denn, Du hattest eine Beta-Version geladen, die beim Update überschrieben wurde.
Zitat von: Ellert am 10 August 2016, 10:59:14Dann sollte sich nach dem 7. oder 8.08. nichts geändert haben. Es sei denn, Du hattest eine Beta-Version geladen, die beim Update überschrieben wurde.
... nene, so was mache ich nicht; dazu fehlen mir die Kenntnisse, um sowas zu handeln ...
Ok, wenn sich nichts geändert hat, muss die Ursache irgend wo anders liegen; ich gehe doch richtig in der Annahme, das nicht nur für Linux/Debian, sondern auch für Perl/FHEM/DOIF "
LUM != lum" ist, oder? Wie gesagt hat das jetzt über Tage und Wochen funktioniert, bis gestern Abend halt. Auch heute Morgen nach einem kompletten System- Neustart ignoriert "lum_set" Events von "LUM"; ich werde nachher mal andere Namen vergeben, nur um ganz sicher zu gehen ...
EDIT:
Ein Umbenennen des DOIF und/oder des Dummys hat keinerlei Änderung ergeben; daran liegt es also nicht. War sowieso sehr unwahrscheinlich, aber man hat ja schon Pferde ...
Dann habe ich heute Morgen als erste Aktion das DOIF mit in jenes gelegt, welches den Mittelwert der Helligkeit in "[LUM]" schreibt und das DOIF mit einem leeren DOELSE abgeschlossen, damit alle Bedingungen geprüft werden... Kein Erfolg.
Dann habe ich als Test mal an Stelle von "[LUM]" direkt die Mittelwertberechnung eingesetzt. der entsprechende Event wird nun also nicht von einer Wertänderung im Dummy "LUM:state" ausgelöst, sondern durch einen der Devices "HM2BBx". Und siehe da, das funktioniert:
define LUM_set DOIF (["HM2BB"]) (set LUM {(([HM2BB1:brightness]+[HM2BB2:brightness])/2)}) \
DOELSEIF ((([HM2BB1:brightness]+[HM2BB2:brightness])/2) < [LUM:0]) (set lum 0) \
DOELSEIF ((([HM2BB1:brightness]+[HM2BB2:brightness])/2) > [LUM:0] and (([HM2BB1:brightness]+[HM2BB2:brightness])/2) < [LUM:1]) (set lum 1) \
DOELSEIF ((([HM2BB1:brightness]+[HM2BB2:brightness])/2) > [LUM:1] and (([HM2BB1:brightness]+[HM2BB2:brightness])/2) < [LUM:2]) (set lum 2) \
DOELSEIF ((([HM2BB1:brightness]+[HM2BB2:brightness])/2) > [LUM:2]) (set lum 3) \
DOELSE
attr LUM_set do alwaysSo habe ich allerdings via Dummy keinen Einfluss mehr auf die ganze Sache; kann also nicht so bleiben ....
Ich verstehe nicht, warum es auf einmal nicht anders geht. Denn wenn ich etwas in einen Dummy schreibe, sollte der doch bei einem darauf zielendem DOIF einen Event auslösen (hat ja auch etliche Tage funktioniert...). Mir ist vollkommen unverständlich, warum das auf einmal nicht mehr geht.
Könnte das ein Timing- Problem sein, das die Events in der "Kette" so kurz hintereinander kommen, das Perl den Zweiten verschluckt?
Die vormals funktionierende Kette sah ja original so aus: Device > DOIF > LUM > DOIF > lum
Nachtrag:
Das hier geht:
define lum_set DOIF ([00:01]) \
DOELSEIF ([LUM] < [LUM:0]) (set lum 0) \
DOELSEIF ([LUM] > [LUM:0] and [LUM] < [LUM:1]) (set lum 1) \
DOELSEIF ([LUM] > [LUM:1] and [LUM] < [LUM:2]) (set lum 2) \
DOELSEIF ([LUM] > [LUM:2]) (set lum 3)
attr lum_set do alwaysDas hier mit einem Event Verzögerung (erster Event > LUM_set, zweiter Event > lum_set):
define lum_set DOIF (["HM2BB"]) \
DOELSEIF ([LUM] < [LUM:0]) (set lum 0) \
DOELSEIF ([LUM] > [LUM:0] and [LUM] < [LUM:1]) (set lum 1) \
DOELSEIF ([LUM] > [LUM:1] and [LUM] < [LUM:2]) (set lum 2) \
DOELSEIF ([LUM] > [LUM:2]) (set lum 3)
attr lum_set do always
... also ich beiße mir hier die Zähne aus und habe bald ne Glatze vom Haare raufen ... :'( :'(
Entweder hat DOIF eine Macke (was ich nicht glaube; wäre bestimmt schon wem aufgefallen), oder ich habe mich total verrannt und bin betriebsblind geworden ...
1. Erkenntnis:
Wenn die zu vergleichenden Werte (siehe unten) aus ein und dem selben Dummy kommen, wird das den Vergleich umgebende DOIF niemals durch das Beschreiben von LUM getriggert. das habe ich bis zum Erbrechen in allen möglichen Varianten ausprobiert ...
2. Erkenntnis:
Splitte ich den Dummy in zwei Dummy's auf, so das ich die Werte aus zwei Dummy's vergleichen kann, wird das den Vergleich umgebende DOIF bei Beschreiben von LUM zwar getriggert, aber das Ergebnis ist falsch.
In "LUM" steht ausschließlich der aktuelle Wert (alle anderen Readings zur Sicherheit gelöscht), in "test:0,1,2" jeweils die per DropDown vorgegebenen Werte. Real also LUM = 20, test:0 = 60, test:1 = 120, test:2 = 140
Hier die Vergleichsabfrage aus zwei Dummy's, damit es überhaupt getriggert wird:
define lum_set DOIF ([LUM] < [test:0]) (set lum 0) \
DOELSEIF ([LUM] > [test:0] and [LUM] < [test:1]) (set lum 1) \
DOELSEIF ([LUM] > [test:1] and [LUM] < [test:2]) (set lum 2) \
DOELSEIF ([LUM] > [test:2]) (set lum 3)
attr lum_set do always
... und hier mal zur besseren Übersicht die Realwerte eingesetzt:
define lum_set DOIF ([20] < [60]) (set lum 0) \
DOELSEIF ([20] > [60] and [20] < [120]) (set lum 1) \
DOELSEIF ([20] > [120] and [20] < [140]) (set lum 2) \
DOELSEIF ([20] > [140]) (set lum 3)
attr lum_set do always
Bei den vorgegebenen Werten wird direkt die erste Bedingung wahr und sollte demnach lum=0 setzen. Bei allen weiteren Abfragen ist mindestens eine &&- verknüpfte Bedingung unwahr.
Dennoch wird hier nicht lum=0 gesetzt, sondern reproduzierbar lum=1
Dabei ändert sich nichts, wenn ich die Zeilen "auf den Kopf" stelle, also mit der untersten zeile beginne und mit der obersten zeile ende... Entweder bleibt lum=3, wird auf 2 gesetzt oder auf 1, nie aber auf 0
Erbarmt sich bitte mal wer und hilft mir bei der Beseitigung der vermeintlichen Betriebsblindheit, ggf. auch in Hinsicht darauf, warum das vorher denn wochenlang funktioniert hat und nun nicht mehr ?
Irgendwo habe ich mal gelesen, dass Readings nicht mit Ziffern beginnen sollen, vielleicht liegt es daran.
... hmmm ... das wäre mir dann entgangen ...
Aber dann dürfte die Masse (ca. 90%) meiner Dummy's nicht funktionieren. Die haben fast alle Readings aus Ziffern, i.d.R. als 0,1,2(,3,4), da ich damit an vielen Stellen über Berechnungen die Stati verändere (gegenseitige Verriegelungen, Synchronisationen, ...). Die funktionieren aber ausnahmslos alle ohne Probleme.
Also wenn, dann verursachen nicht Dummy's mit Readings aus Ziffern die Probleme, sondern dann bleibt nur DOIF als Ursache über, welches bei der Verarbeitung "bezifferter" Readings Probleme macht (wobei ich ausschließlich mit DOIF arbeite; funktioniert auch überall anders problemlos).
Ich habe vergangene Nacht die Aufgabe erst mal vollkommen anders gelöst. Hässlich, aber funktioniert... Außerdem bin ich gerade dabei, einen weiteren PI neu aufzusetzen, um dort solche problematischen Codes testen zu können, ohne das LiveSystem zu tangieren; die Realdaten wollte ich dann per ser2net an den TestPI übergeben ... Schauen wir mal ...
Dennoch würde ich dieses Phänomen gerne irgendwie begreifen wollen und bestenfalls eine Lösung erarbeiten, was aber ohne eure Kenntnisse der Interna unmöglich ist...
Bei mir funktioniert es, wenn die Readings mit Buchstaben beginnen:
ZitatInternals:
CFGFN
DEF ([LUM] < [test:a]) (set lum 0)
DOELSEIF ([LUM] > [test:a] and [LUM] < [test:b]) (set lum 1)
DOELSEIF ([LUM] > [test:b] and [LUM] < [test:c]) (set lum 2)
DOELSEIF ([LUM] > [test:c]) (set lum 3)
NAME lum_set
NR 473
NTFY_ORDER 50-lum_set
STATE cmd_1
TYPE DOIF
Readings:
2016-08-13 11:35:39 Device test
2016-08-13 11:35:40 cmd 1
2016-08-13 11:35:40 cmd_event test
2016-08-13 11:35:40 cmd_nr 1
2016-08-13 11:35:39 e_test_a 60
2016-08-13 11:35:39 e_test_b 120
2016-08-13 11:35:39 e_test_c 140
2016-08-13 11:35:40 state cmd_1
Condition:
0 InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) < ReadingValDoIf($hash,'test','a','','',AttrVal($hash->{NAME},'notexist',undef))
1 InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) > ReadingValDoIf($hash,'test','a','','',AttrVal($hash->{NAME},'notexist',undef)) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) < ReadingValDoIf($hash,'test','b','','',AttrVal($hash->{NAME},'notexist',undef))
2 InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) > ReadingValDoIf($hash,'test','b','','',AttrVal($hash->{NAME},'notexist',undef)) and InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) < ReadingValDoIf($hash,'test','c','','',AttrVal($hash->{NAME},'notexist',undef))
3 InternalDoIf($hash,'LUM','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) > ReadingValDoIf($hash,'test','c','','',AttrVal($hash->{NAME},'notexist',undef))
Devices:
0 LUM test
1 LUM test
2 LUM test
3 LUM test
all LUM test
Do:
0:
0 set lum 0
1:
0 set lum 1
2:
0 set lum 2
3:
0 set lum 3
Helper:
event a: 60
globalinit 1
last_timer 0
sleeptimer -1
timerdev test
timerevent a: 60
triggerDev test
timerevents:
a: 60
timereventsState:
a: 60
triggerEvents:
a: 60
triggerEventsState:
a: 60
Internals:
0 LUM:STATE
1 LUM:STATE
2 LUM:STATE
3 LUM:STATE
all LUM:STATE
Itimer:
Readings:
0 test:a
1 test:a test:b
2 test:b test:c
3 test:c
all test:a test:b test:c
Regexp:
0:
All:
State:
Trigger:
Attributes:
do always
room 0_Test
... merkwürdig (jetzt hab ich die erste kahle Stelle am Kopf :-\ )
Mit Buchstaben hatte ich es vor 1-2 Tagen auch schon mal probiert, allerdings im gleichen Dummy; das ging auch nicht. Mit getrennten Dummys, auf die ich erst vergangene Nacht gekommen bin, habe ich es noch nicht probiert; mache ich nachher gleich mal ...
Aber auch wenn bleibt die Frage, warum alle anderen Dummys mit bezifferten Readings einwandfrei funktionieren nebst den abfragenden DOIF's ...
Ich denke, ich mache heute erst mal den TestPI fertig und versuche das noch mal ganz systematisch zu ergründen... Oder vielleicht sollte ich heute mal was vollkommen anderes machen, bisschen Moped fahren oder so, um die Birne frei zu bekommen... mal sehen... das macht mich ganz kirre >:(