Edit: Syntax wurde geändert
Ich habe neue Optionen für Readingangaben eingebaut. Man kann jetzt Readings über die letzten X-Werte auswerten lassen. Dazu gibt es die Funktionen
avg für Durchschnitt,
med für Median,
diff für die Differenz und
inc für prozentualen Anstieg von Werten. Die Option steht überall zur Verfügung, wo Readings innerhalb eines DOIF angegeben werden können: DOIF-Bedingungen, DOIF-Ausführungsteile, DOIF_Readings-Attribut usw.
Syntax
[<Device>:<Reading>:
avg<Anzahl der letzten Werte>]
[<Device>:<Reading>:
med<Anzahl der letzten Werte>]
[<Device>:<Reading>:
diff<Anzahl der letzten Werte>]
[<Device>:<Reading>:
inc<Anzahl der letzten Werte>]
<Anzahl der letzten Werte> ist optional. Wird sie nicht angegeben, so werden die letzten beiden Werte ausgewertet. <Anzahl der letzten Werte> gleich eins ist nicht sinnvoll.
Zu beachten ist, dass der Durchschnitt/Median/Differenz/Anstieg bereits gebildet werden, sobald die ersten Werte eintrudeln, beim ersten Wert ist der Durchschnitt bzw. Median logischerweise der Wert selbst, Differenz und prozentualer Anstieg ist in diesem Fall 0.
Die angegebenen Readings werden intern automatisch für die Auswertung nach Zahlen gefiltert.
Ein Testbeispiel (mit "set bla <Zahl>" kann die Definition mit einem Dummy namens "bla" getestet werden)
defmod accu DOIF ##
attr accu DOIF_Readings avg:[bla:state:avg],\
avg3:[bla:state:avg3],\
avg5:[bla:state:avg5],\
med:[bla:state:med],\
med3:[bla:state:med3],\
med5:[bla:state:med5],\
diff:[bla:state:diff],\
diff3:[bla:state:diff3],\
diff5:[bla:state:diff5]
Bei diff bzw. inc wird der letzte und x-te zurückliegende Wert ausgewertet.
Edit: letzte Version wurde eingecheckt
top feature, danke!
Gesendet von meinem SM-J510FN mit Tapatalk
Klasse, danke dafür.
Nur ne Frage:
Wäre nicht :a: für average besser gewesen als s ?
Cheers
mi.ke
Zitat von: mi.ke am 13 Januar 2019, 10:11:25
Klasse, danke dafür.
Nur ne Frage:
Wäre nicht :a: für average besser gewesen als s ?
Cheers
mi.ke
ja, hatte ich zuvor gehabt, dann dachte ich Glättung = (s)moothing wäre besser.
Ich habe die Version bewusst noch nicht eingecheckt, um die Praxistauglichkeit erst prüfen zu lassen.
Toll, da bin ich sofort bei den Tests - mein CO2-Sensor ist sehr reagible und bisher habe ich die Events (Messwerte) aggregiert und geglättet. Wenn DOIF das jetzt kann, wird einiges übersichtlicher.
Herzliche Grüße
Christian
Man kann das neue Feature natürlich auch beim DOIF_Readings- oder State-Attribut anwenden.
Bsp.:
attr smooth DOIF_Readings temp:[Aussensensor:temperature],\
temp2:[Aussensensor:temperature:s2]
Hier wird neben dem Reading temp auch ein geglättetes Reading temp2 definiert, das man im DOIF auswerten kann.
Ist es richtig, wenn ich in einem Listing, in dem ich ein Reading in 5 Bedigungen jeweils über die letzten 10 Werte glätten lassen will, insgesamt so ein Listing bekomme?
Internals:
DEF ([CO2Sensor:CO2:s10] and [?Lueftung] eq "max") (set Steller_Zuluft gpio 255) (set Steller_Abluft gpio 255)
DOELSEIF ([CO2Sensor:CO2:s10] and ([?abwesend] eq "an" or [?Lueftung] eq "AUS")) (set Steller_Zuluft gpio 0) (set Steller_Abluft gpio 0)
DOELSEIF ([CO2Sensor:CO2:s10] and ([?Lueftung] eq "min" or [CO2Sensor:CO2:s5]<550)) (set Steller_Zuluft gpio 55) (set Steller_Abluft gpio 45)
DOELSEIF ([?Lueftung] eq "auto" and [CO2Sensor:CO2:s10]>([$SELF:CO2_alt]+25) and [Steller_Zuluft:gpio]<230) (setreading $SELF CO2_alt [CO2Sensor:CO2:s10],setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]+25))},set Steller_Zuluft gpio [$SELF:Stell_neu]) (setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]*.75))},set Steller_Abluft gpio [$SELF:Stell_neu])
DOELSEIF ([?Lueftung] eq "auto" and [CO2Sensor:CO2:s10]<([$SELF:CO2_alt]-25) and [Steller_Zuluft:gpio]>80) (setreading $SELF CO2_alt [CO2Sensor:CO2:s10],setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]-25))},set Steller_Zuluft gpio [$SELF:Stell_neu]) (setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]*.75))},set Steller_Abluft gpio [$SELF:Stell_neu])
MODEL FHEM
NAME DI_Lueftung
NR 117
NTFY_ORDER 50-DI_Lueftung
STATE Betrieb
TYPE DOIF
READINGS:
2019-01-13 22:34:02 CO2_alt 1317.27700831025
2019-01-13 22:37:21 Device CO2Sensor
2019-01-13 22:34:17 Stell_neu 79
2019-01-13 22:34:17 cmd 5.2
2019-01-13 22:34:17 cmd_event set_cmd_5
2019-01-13 22:34:17 cmd_nr 5
2019-01-13 22:34:17 cmd_seqnr 2
2019-01-13 22:37:21 e_CO2Sensor_CO2 802
2019-01-13 15:23:18 mode enabled
2019-01-13 22:34:17 state Betrieb
2019-01-13 22:34:17 wait_timer no timer
Regex:
akku:
CO2Sensor CO2:
940
940
940
940
945
945
945
945
945
945
938
938
938
938
938
938
944
944
944
944
944
944
949
949
949
949
949
949
941
941
941
941
941
941
938
938
938
938
938
938
931
931
931
931
931
931
951
951
951
951
951
951
931
931
931
931
931
931
937
937
937
937
937
937
952
952
952
952
952
952
928
928
928
928
928
928
927
927
927
927
927
927
921
921
921
921
921
921
940
940
940
940
940
940
929
929
929
929
929
929
921
921
921
921
921
921
1913
1913
1913
1913
1913
1913
2416
2416
2416
2416
2416
2656
2656
2656
2656
2656
2721
2721
2721
2721
2721
2870
2870
2870
2870
2870
2744
2744
2744
2744
2744
1659
1659
1659
1659
1659
1155
1155
1155
1155
1155
1033
1033
1033
1033
1033
989
989
989
989
989
1003
1003
1003
1003
1003
2395
2395
2395
2395
2395
2330
2330
2330
2330
2330
1813
1813
1813
1813
1813
2386
2386
2386
2386
2386
2221
2221
2221
2221
2221
2010
2010
2010
2010
2010
1858
1858
1858
1858
1858
1664
1664
1664
1664
1664
1512
1512
1512
1512
1512
1620
1620
1620
1620
1620
1769
1769
1769
1769
1769
1125
1125
1125
1125
1125
1008
1008
1008
1008
1008
973
973
973
973
973
955
955
955
955
955
932
932
932
932
932
928
928
928
928
928
917
917
917
917
917
922
922
922
922
922
911
911
911
911
911
909
909
909
909
909
896
896
896
896
896
897
897
897
897
897
895
895
895
895
895
890
890
890
890
890
877
877
877
877
877
894
894
894
894
894
896
896
896
896
896
884
884
884
884
884
869
869
869
869
869
879
879
879
879
879
886
886
886
886
886
882
882
882
882
882
966
966
966
966
966
2258
2258
2258
2258
2258
2542
2542
2542
2542
2542
2809
2809
2809
2809
2809
2671
2671
2671
2671
2671
2524
2524
2524
2524
2524
1465
1465
1465
1465
1465
1076
1076
1076
1076
1076
987
987
987
987
987
949
949
949
949
949
932
932
932
932
932
918
918
918
918
918
897
897
897
897
897
904
904
904
904
904
912
912
912
912
912
881
881
881
881
881
871
871
871
871
871
1890
1890
1890
1890
1890
2466
2466
2466
2466
2466
2740
2740
2740
2740
2740
2517
2517
2517
2517
2517
2591
2591
2591
2591
2591
2731
2731
2731
2731
2731
2665
2665
2665
2665
2665
2691
2691
2691
2691
2691
2090
2090
2090
2090
2090
1133
1133
1133
1133
1133
1008
1008
1008
1008
1008
975
975
975
975
975
1340
1340
1340
1340
1340
2302
2302
2302
2302
2302
2533
2533
2533
2533
2533
2396
2396
2396
2396
2396
2359
2359
2359
2359
2359
2255
2255
2255
2255
2255
2119
2119
2119
2119
2119
2145
2145
2145
2145
2145
2199
2199
2199
2199
2199
2292
2292
2292
2292
2292
2254
2254
2254
2254
2254
1972
1972
1972
1972
1972
2204
2204
2204
2204
2204
2219
2219
2219
2219
2219
2142
2142
2142
2142
2142
2069
2069
2069
2069
2069
2229
2229
2229
2229
2229
2185
2185
2185
2185
2185
2290
2290
2290
2290
2290
2143
2143
2143
2143
2143
2164
2164
2164
2164
2164
2135
2135
2135
2135
2135
1581
1581
1581
1581
1581
1094
1094
1094
1094
1094
1002
1002
1002
1002
1002
953
953
953
953
953
933
933
933
933
933
896
896
896
896
896
893
893
893
893
893
870
870
870
870
870
877
877
877
877
877
884
884
884
884
884
871
871
871
871
871
855
855
855
855
855
854
854
854
854
854
856
856
856
856
856
867
867
867
867
867
845
845
845
845
845
840
840
840
840
840
844
844
844
844
844
825
825
825
825
825
829
829
829
829
829
844
844
844
844
844
843
843
843
843
843
823
823
823
823
823
817
817
817
817
817
816
816
816
816
816
815
815
815
815
815
818
818
818
818
818
817
817
817
817
817
826
826
826
826
826
818
818
818
818
818
824
824
824
824
824
822
822
822
822
822
848
848
848
848
848
838
838
838
838
838
1240
1240
1240
1240
1240
2138
2138
2138
2138
2138
2119
2119
2119
2119
2119
2043
2043
2043
2043
2043
2477
2477
2477
2477
2477
2210
2210
2210
2210
2210
2219
2219
2219
2219
2219
1262
1262
1262
1262
1262
972
972
972
972
972
901
901
901
901
901
864
864
864
864
864
856
856
856
856
856
833
833
833
833
833
826
826
826
826
826
816
816
816
816
816
803
803
803
803
803
805
805
805
805
805
804
804
804
804
804
805
805
805
805
805
792
792
792
792
792
787
787
787
787
787
791
791
791
791
791
789
789
789
789
789
788
788
788
788
788
779
779
779
779
779
768
768
768
768
768
771
771
771
771
771
770
770
770
770
770
771
771
771
771
771
763
763
763
763
763
761
761
761
761
761
759
759
759
759
759
755
755
755
755
755
769
769
769
769
769
754
754
754
754
754
762
762
762
762
762
747
747
747
747
747
749
749
749
749
749
1332
1332
1332
1332
1332
2130
2130
2130
2130
2130
2343
2343
2343
2343
2343
2052
2052
2052
2052
2052
1920
1920
1920
1920
1920
1496
1496
1496
1496
1496
939
939
939
939
939
843
843
843
843
843
803
803
803
803
803
786
786
786
786
786
766
766
766
766
766
753
753
753
753
753
751
751
751
751
751
749
749
749
749
749
760
760
760
760
760
772
772
772
772
772
789
789
789
789
789
814
814
814
814
814
1836
1836
1836
1836
1836
2279
2279
2279
2279
2279
2327
2327
2327
2327
2327
1710
1710
1710
1710
1710
1057
1057
1057
1057
1057
921
921
921
921
921
887
887
887
887
887
842
842
842
842
842
828
828
828
828
828
810
810
810
810
810
810
818
818
818
818
818
818
802
802
802
802
802
802
attr:
cmdState:
repeatsame:
1
1
1
0
0
wait:
0:
0
15
1:
0
15
2:
0
15
3:
0
15
4:
0
15
5:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'CO2Sensor','CO2','','s10') and ::InternalDoIf($hash,'Lueftung','STATE') eq "max"
1 ::ReadingValDoIf($hash,'CO2Sensor','CO2','','s10') and (::InternalDoIf($hash,'abwesend','STATE') eq "an" or ::InternalDoIf($hash,'Lueftung','STATE') eq "AUS")
2 ::ReadingValDoIf($hash,'CO2Sensor','CO2','','s10') and (::InternalDoIf($hash,'Lueftung','STATE') eq "min" or ::ReadingValDoIf($hash,'CO2Sensor','CO2','','s5')<550)
3 ::InternalDoIf($hash,'Lueftung','STATE') eq "auto" and ::ReadingValDoIf($hash,'CO2Sensor','CO2','','s10')>(::ReadingValDoIf($hash,'DI_Lueftung','CO2_alt')+25) and ::ReadingValDoIf($hash,'Steller_Zuluft','gpio')<230
4 ::InternalDoIf($hash,'Lueftung','STATE') eq "auto" and ::ReadingValDoIf($hash,'CO2Sensor','CO2','','s10')<(::ReadingValDoIf($hash,'DI_Lueftung','CO2_alt')-25) and ::ReadingValDoIf($hash,'Steller_Zuluft','gpio')>80
devices:
0 CO2Sensor
1 CO2Sensor
2 CO2Sensor
3 CO2Sensor DI_Lueftung Steller_Zuluft
4 CO2Sensor DI_Lueftung Steller_Zuluft
all CO2Sensor DI_Lueftung Steller_Zuluft
do:
0:
0 set Steller_Zuluft gpio 255
1 set Steller_Abluft gpio 255
1:
0 set Steller_Zuluft gpio 0
1 set Steller_Abluft gpio 0
2:
0 set Steller_Zuluft gpio 55
1 set Steller_Abluft gpio 45
3:
0 setreading DI_Lueftung CO2_alt [CO2Sensor:CO2:s10],setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]+25))},set Steller_Zuluft gpio [DI_Lueftung:Stell_neu]
1 setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]*.75))},set Steller_Abluft gpio [DI_Lueftung:Stell_neu]
4:
0 setreading DI_Lueftung CO2_alt [CO2Sensor:CO2:s10],setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]-25))},set Steller_Zuluft gpio [DI_Lueftung:Stell_neu]
1 setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]*.75))},set Steller_Abluft gpio [DI_Lueftung:Stell_neu]
5:
helper:
event CO2: 802
globalinit 1
last_timer 0
sleepdevice set_cmd_5
sleepsubtimer -1
sleeptimer -1
timerdev CO2Sensor
timerevent CO2: 810
triggerDev CO2Sensor
DOIF_eventas:
cmd_nr: 5
cmd_seqnr: 2
cmd_event: set_cmd_5
state: Betrieb
timerevents:
CO2: 810
timereventsState:
CO2: 810
triggerEvents:
CO2: 802
triggerEventsState:
CO2: 802
internals:
0 Lueftung:STATE
1 abwesend:STATE Lueftung:STATE
2 Lueftung:STATE
3 Lueftung:STATE
4 Lueftung:STATE
all Lueftung:STATE abwesend:STATE
itimer:
readings:
0 CO2Sensor:CO2
1 CO2Sensor:CO2
2 CO2Sensor:CO2
3 CO2Sensor:CO2 DI_Lueftung:CO2_alt Steller_Zuluft:gpio
4 CO2Sensor:CO2 DI_Lueftung:CO2_alt Steller_Zuluft:gpio
all CO2Sensor:CO2 DI_Lueftung:CO2_alt Steller_Zuluft:gpio
trigger:
uiState:
uiTable:
Attributes:
DbLogExclude .*
event-on-change-reading cmd
repeatsame 1:1:1:0:0
room Lueftung
startup set $SELF checkall
state Betrieb
verbose 2
wait 0,15:0,15:0,15:0,15:0,15:0
Das Reading CO2 wird alle zwei Minuten geschrieben.
Christian
Würde ich nur einmal in DOIF_Readings berechnen und das abfragen.
Da sind noch paar Stellen, die noch nachgebessert werden müssen. Z. Zt. wird nur eine Dezimalstelle ausgewertet, also maximal bis 9 Werte. Durch s10 wird s1 ausgewertet. Was z. Zt. nicht funktioniert, sind verschiedene Angaben in einem DOIF für das gleiche Reading, bei Dir also s10 und s5.
Am besten ist es, bei mehrfachen Abfragen, wie Ellert vorgeschlagen hat, ein DOIF_Reading zu definieren.
Zitat von: Damian am 12 Januar 2019, 23:18:58
Zu beachten ist, dass der Durchschnitt bereits gebildet wird, sobald die ersten Werte eintrudeln, beim ersten Wert ist der Durchschnitt logischerweise der Wert selbst.
Wird der Durchschnitt eigentlich als Reading ausgegeben?
Zitat von: mi.ke am 14 Januar 2019, 08:56:25
Wird der Durchschnitt eigentlich als Reading ausgegeben?
Den Durchschnitt liefert doch die Angabe [....:s.] selbst. Wenn du es sichtbar haben willst, musst du ein DOIF_Reading definieren.
Zitat von: Damian am 13 Januar 2019, 18:20:47
Man kann das neue Feature natürlich auch beim DOIF_Readings- oder State-Attribut anwenden.
Bsp.:
attr smooth DOIF_Readings temp:[Aussensensor:temperature],\
temp2:[Aussensensor:temperature:s2]
Hier wird neben dem Reading temp auch ein geglättetes Reading temp2 definiert, das man im DOIF auswerten kann.
Jaa, jetzt hab auch ich es verstanden.
Danke
Zitat von: Damian am 13 Januar 2019, 23:23:47
Durch s10 wird s1 ausgewertet.
Das verstehe ich nicht: Hatte s10 als Glättung über die letzten 10 Werte verstanden. Bin ich da auf dem Holzweg?
Zitat von: Damian am 13 Januar 2019, 23:23:47
Was z. Zt. nicht funktioniert, sind verschiedene Angaben in einem DOIF für das gleiche Reading, bei Dir also s10 und s5.
Erwischt! Hier hatte ich beim Ausprobieren nicht sauber glattgezogen. Danke vor allem für:
Zitat von: Damian am 13 Januar 2019, 23:23:47
Am besten ist es, bei mehrfachen Abfragen, wie Ellert vorgeschlagen hat, ein DOIF_Reading zu definieren.
Das ist sicherlich der richtigere und übersichtlichere Weg...
Christian
Zitat von: cwagner am 14 Januar 2019, 18:08:22
Das verstehe ich nicht: Hatte s10 als Glättung über die letzten 10 Werte verstanden. Bin ich da auf dem Holzweg?
Erwischt! Hier hatte ich beim Ausprobieren nicht sauber glattgezogen. Danke vor allem für:
Das ist sicherlich der richtigere und übersichtlichere Weg...
Christian
z. Zt. geht eben nur s<d> mit d eine Ziffer
Wenn ich das richtig lese, geht das nur in DOIF´s.
Kann ich das irgendwie umbiegen, daß es auch z.B. eingelesene Werte für ein Plot "stablisiert"?
Zitat von: Neuhier am 15 Januar 2019, 13:31:52
Wenn ich das richtig lese, geht das nur in DOIF´s.
Kann ich das irgendwie umbiegen, daß es auch z.B. eingelesene Werte für ein Plot "stablisiert"?
Du kanns z. B. verschiedene Reading in einem DOIF glätten lassen und dort als eigene Readings ablegen, die du dann plotten kannst.
define smoothValues DOIF\
{set_Reading("reading1",[mydev1:readingbla1:s3],1)}\
{set_Reading("reading2",[mydev2:readingbla2:s3],1)}
...
War ich doch richtig, zur Nutzung muß ein DOIF erstellt werden.
Zitat von: Neuhier am 15 Januar 2019, 15:36:36
War ich doch richtig, zur Nutzung muß ein DOIF erstellt werden.
ja, es ist Programmcode, der im DOIF-Modul drinsteckt. So etwas könnte jemand allgemein als set_Extensions für alle Devices programmieren, denn die Glättung als weiteres Reading wäre am besten dort aufgehoben, wo die Daten entstehen, nämlich beim Sensor.
Gibts dafür nicht den event-aggregator?
Was wird zur Glättung verwendet? Average oder Median? Letzteres wäre unter Umständen robuster.
Habe es mal versucht:
define Flo1Value DOIF {set_Reading("Lux1",[Flower1:Lux:s3],1)}
Bekomme aber ( trotz Update vor 10min ) nur:
DOIF: unknown expression format: s3
Zitat von: Neuhier am 15 Januar 2019, 18:02:48
Habe es mal versucht:
define Flo1Value DOIF {set_Reading("Lux1",[Flower1:Lux:s3],1)}
Bekomme aber ( trotz Update vor 10min ) nur:
DOIF: unknown expression format: s3
Dann hast du nicht die neue DOIF-Version aus dem ersten Post bei dir aktiv ;)
´Ähm
Sogar hinterher nochmal Update ( s.o. ) gemacht und FHEM neu gestartet.
Version DOIF muss v0.1 liefern. Vermutlich überschreibt dein Update die Test-Version aus dem ersten Post durch die eingecheckte - das kann ich bereits an der Größe von DOIF sehen.
Zitat von: mumpitzstuff am 15 Januar 2019, 17:56:04
Gibts dafür nicht den event-aggregator?
Was wird zur Glättung verwendet? Average oder Median? Letzteres wäre unter Umständen robuster.
ja event-aggregator dafür gibt offensichtlich schon. Entweder ist es für viele unbekannt oder die Syntax der Definition zu umständlich. Ich habe die Existenz offenbar schon verdrängt.
Es war einfach ein schneller Hack im DOIF-Modul von mir. Die Erweiterung lässt sich so recht einfach in bestehenden DOIF-Definitionen anpassen.
Falls es sich als praktikabel erweist, könnte man es ausbauen z. B.
[device:reading:avr<Anzahl der Werte>] für Durchschnitt
[device:reading:med<Anzahl der Werte>] Median
[device:reading:diff] Differenz der letzten beiden Werte
...
Zitat von: Damian am 15 Januar 2019, 19:17:40[device:reading:diff] Differenz der letzten beiden Werte
Würde mir gut gefallen!
Evtl. sogar :time (oder so) als Alter der letzten Meldung. Also wie :sec, nur das :sec in dem Fall wieder 0 wäre.
oh ja, bitte erweitern!
die diff hätts mir ganz besonders angetan ...
Zitat von: Damian am 15 Januar 2019, 19:17:40
ja event-aggregator dafür gibt offensichtlich schon. Entweder ist es für viele unbekannt oder die Syntax der Definition zu umständlich. Ich habe die Existenz offenbar schon verdrängt.
Es war einfach ein schneller Hack im DOIF-Modul von mir. Die Erweiterung lässt sich so recht einfach in bestehenden DOIF-Definitionen anpassen.
Falls es sich als praktikabel erweist, könnte man es ausbauen z. B.
[device:reading:avr<Anzahl der Werte>] für Durchschnitt
[device:reading:med<Anzahl der Werte>] Median
[device:reading:diff] Differenz der letzten beiden Werte
...
Nützlich finde ich auch eine gleitende lineare Regression, mit Zugriff auf die zugehörigen Parameter (Steigung, Mittelwerte, Aschsenabschnitte, Korellationskoeffizient und Standartabweichung) in der Ausgabeformatierung. Sowas gibt es nicht im Attribut event-aggregator, das muss sich jeder selbst bastelt. Es hätte den Vorteil, das die zeitliche Lage der Messwerte im Ergebnis berücksichtigt wird.
Ich muss allerdings einiges an der Programmierlogik noch ändern. Z. Zt. findet die Auswertung bzw. Speicherung des aktuellen Wertes in der Queue in der Perlroutine zu [...:s..]. Dadurch darf z. Zt. zu einem bestimmten Reading nur einmal die Angabe [...:s..] im DOIF gemacht werden, sonst wird der aktuelle Wert mehrfach in der Queue abgelegt. Mehrfache Angaben zum gleichen Reading müssen z. Zt. über DOIF_Reading gemacht werden.
Zitat von: Ellert am 16 Januar 2019, 16:12:38
Nützlich finde ich auch eine gleitende lineare Regression, mit Zugriff auf die zugehörigen Parameter (Steigung, Mittelwerte, Aschsenabschnitte, Korellationskoeffizient und Standartabweichung) in der Ausgabeformatierung. Sowas gibt es nicht im Attribut event-aggregator, das muss sich jeder selbst bastelt. Es hätte den Vorteil, das die zeitliche Lage der Messwerte im Ergebnis berücksichtigt wird.
Kannst du ein konkretes Beispiel machen, wie du es dir vorstellst?
Hallo Damian,
ohne diesen Thread vorher gelesen zu haben, hatte ich mir just heute DOIF um den Median erweitert, einen Patch findest hier (https://bitbucket.org/christoph-morrison/fhem-patches/raw/master/FHEM/98_DOIF.pm/ahphei9Mu7.patch).
Gruß
Christoph
Zitat von: Christoph Morrison am 16 Januar 2019, 18:08:54
Hallo Damian,
ohne diesen Thread vorher gelesen zu haben, hatte ich mir just heute DOIF um den Median erweitert, einen Patch findest hier (https://bitbucket.org/christoph-morrison/fhem-patches/raw/master/FHEM/98_DOIF.pm/ahphei9Mu7.patch).
Gruß
Christoph
Ja, das ist eine gute Sache - kann ich glatt übernehmen. Allerdings hast du es in der Aggregationsfunktion eingebaut.
Hier geht es um die Auswertung
vergangener X-Werte eines Readings. Dazu müssen die Werte des jeweiligen Readings in einer internen Queue gesammelt werden.
Zitat von: Damian am 16 Januar 2019, 18:19:10
Ja, das ist eine gute Sache - kann ich glatt übernehmen. Allerdings hast du es in der Aggregationsfunktion eingebaut.
Hier geht es um die Auswertung vergangener X-Werte eines Readings. Dazu müssen die Werte des jeweiligen Readings in einer internen Queue gesammelt werden.
Ich weiß, ich wollte das auch in der Aggregatsfunktion haben (um Temperaturwerte zu glätten) und kannte den Thread bis eben nicht. Die Berechnung des Median könntest du aber in eine Subroutine auslagern und dann auch bei den vergangenen Werten nutzen.
Zitat von: Christoph Morrison am 16 Januar 2019, 18:31:49
Ich weiß, ich wollte das auch in der Aggregatsfunktion haben (um Temperaturwerte zu glätten) und kannte den Thread bis eben nicht. Die Berechnung des Median könntest du aber in eine Subroutine auslagern und dann auch bei den vergangenen Werten nutzen.
Klar, den Median wollte ich sowieso einbauen.
Wo hast du denn deine Temperaturwerte zum Auswerten über die Aggregatsfunktion abgelegt?
Zitat von: Damian am 16 Januar 2019, 18:34:19
Klar, den Median wollte ich sowieso einbauen.
Wo hast du denn deine Temperaturwerte zum Auswerten über die Aggregatsfunktion abgelegt?
Ich hab mehrere Temperaturdevices auf meinem Grundstück, die jeweils ein Reading temperature haben. Darin ist die Temperatur ohne Gradzeichen abgelegt. Die hole ich mir alle zusammen und berechne den Medianwert, da gelegentlich mal eines nicht aktualisiert wird und ein arithmetisches Mittel dann sehr stark abweichende Werte liefern würde. Hier mal der Code in meiner Testumgebung:
define dummy.0 dummy
define dummy.1 dummy
define dummy.2 dummy
define dummy.4 dummy
setstate dummy.0 1
setstate dummy.0 2019-01-16 14:36:43 state 1
setstate dummy.1 2.5
setstate dummy.1 2019-01-16 14:40:04 state 2.5
setstate dummy.2 3
setstate dummy.2 2019-01-15 21:13:59 state 3
setstate dummy.4 4
setstate dummy.4 2019-01-16 15:48:43 state 4
Und die DOIFs mit denen ich getest habe:
define doif.0 DOIF ##
attr doif.0 state [#median:"dummy.*":state]
attr doif.0 verbose 5
define doif.1 DOIF ##
attr doif.1 state [@median:"dummy.*":state]
attr doif.1 verbose 5
setstate doif.0 2.75
setstate doif.0 2019-01-16 15:48:43 state 2.75
setstate doif.1 dummy.0,dummy.1,dummy.2,dummy.4
setstate doif.1 2019-01-16 15:48:43 state dummy.0,dummy.1,dummy.2,dummy.4
pah hat doch mal eine subroutine geschrieben.....
Gesendet von meinem E6653 mit Tapatalk
sub movingAverage($$$){
my ($name,$reading,$avtime) = @_;
my $hash = $defs{$name};
my @new = my ($val,$time) = (ReadingsVal($name,$reading,undef),ReadingsTimestamp($name,$reading,undef));
my ($cyear, $cmonth, $cday, $chour, $cmin, $csec) = $time =~ /(\d{4})-(\d{2})-(\d{2})\s(\d{2}):(\d{2}):(\d{2})/;
my $ctime = $csec+60*$cmin+3600*$chour;
my $num;
my $arr;
#-- initialize if requested
if( ($avtime eq "-1") ){
$hash->{helper}{history}=undef;
}
#-- test for existence
if( !$hash->{helper}{history}){
#Log 1,"ARRAY CREATED";
push(@{$hash->{helper}{history}},\@new);
$num = 1;
$arr=\@{$hash->{helper}{history}};
} else {
$num = int(@{$hash->{helper}{history}});
$arr=\@{$hash->{helper}{history}};
my $starttime = $arr->[0][1];
my ($syear, $smonth, $sday, $shour, $smin, $ssec) = $starttime =~ /(\d{4})-(\d{2})-(\d{2})\s(\d{2}):(\d{2}):(\d{2})/;
my $stime = $ssec+60*$smin+3600*$shour;
#-- correct for daybreak
$stime-=86400
if( $stime > $ctime);
if( ($num < 25)&&( ($ctime-$stime)<$avtime) ){
#Log 1,"ARRAY has $num elements, adding another one";
push(@{$hash->{helper}{history}},\@new);
}else{
shift(@{$hash->{helper}{history}});
push(@{$hash->{helper}{history}},\@new);
}
}
#-- output and average
my $average = 0;
for(my $i=0;$i<$num;$i++){
$average+=$arr->[$i][0];
Log 4,"[$name moving average] Value = ".$arr->[$i][0]." Time = ".$arr->[$i][1];
}
$average=sprintf( "%5.3f", $average/$num);
#--average
Log 4,"[$name moving average] calculated over $num values is $average";
return $average;
}
Zitat von: Damian am 16 Januar 2019, 18:06:14
Kannst du ein konkretes Beispiel machen, wie du es dir vorstellst?
Für ein Reading temperature werden bei jedem Event die gemessenen Werte (y) als Zeitreihe in fortgeschrieben, wie beim Glätten aber mit Zeitstempel (x).
Zurückgegeben werden die Werte, mit der die Lage der besten Geraden in dem Datenfeld beschrieben wird. Für die Gerade y = a
0 + a
1x
würde [Sensor:temperature:reg10] dann a
0, a
1, x
m, y
m,,Standartabweichung, Korrelationskoeffizent als kommagetrennte Werte zurückliefern, berechnet aus 10 Wertepaaren.
Wenn die Ausgabeformatierung verwendet wird, dann sollten $a0, $a1, $xm, $ym, $stabw, $corr zur Verfügung stehen um ein eigenes Ausgabeformat zu erstellen.
Diese Werte werden durch die Perlfunktion Statistics::lineFit bereitgestellt https://metacpan.org/pod/release/RANDERSON/Statistics-LineFit-0.01/lib/Statistics/LineFit.pm
Die Mittelwerte x
m, y
m müssten noch berechnet werden.
Zitat von: Ellert am 16 Januar 2019, 20:28:32
Für ein Reading temperature werden bei jedem Event die gemessenen Werte (y) als Zeitreihe in fortgeschrieben, wie beim Glätten aber mit Zeitstempel (x).
Zurückgegeben werden die Werte, mit der die Lage der besten Geraden in dem Datenfeld beschrieben wird. Für die Gerade y = a0 + a1x
würde [Sensor:temperature:reg10] dann a0, a1, xm, ym,,Standartabweichung, Korrelationskoeffizent als kommagetrennte Werte zurückliefern, berechnet aus 10 Wertepaaren.
Wenn die Ausgabeformatierung verwendet wird, dann sollten $a0, $a1, $xm, $ym, $stabw, $corr zur Verfügung stehen um ein eigenes Ausgabeformat zu erstellen.
Diese Werte werden durch die Perlfunktion Statistics::lineFit bereitgestellt https://metacpan.org/pod/release/RANDERSON/Statistics-LineFit-0.01/lib/Statistics/LineFit.pm
Die Mittelwerte xm, ym müssten noch berechnet werden.
Es müsste also für die Berechnung jeweils ein Wertepaar aus Zeitpunkt=X und dem eigentlichen Wert=Y in der Queue gespeichert werden.
Zitat von: Christoph Morrison am 16 Januar 2019, 19:14:36
Ich hab mehrere Temperaturdevices auf meinem Grundstück, die jeweils ein Reading temperature haben. Darin ist die Temperatur ohne Gradzeichen abgelegt. Die hole ich mir alle zusammen und berechne den Medianwert, da gelegentlich mal eines nicht aktualisiert wird und ein arithmetisches Mittel dann sehr stark abweichende Werte liefern würde. Hier mal der Code in meiner Testumgebung:
define dummy.0 dummy
define dummy.1 dummy
define dummy.2 dummy
define dummy.4 dummy
setstate dummy.0 1
setstate dummy.0 2019-01-16 14:36:43 state 1
setstate dummy.1 2.5
setstate dummy.1 2019-01-16 14:40:04 state 2.5
setstate dummy.2 3
setstate dummy.2 2019-01-15 21:13:59 state 3
setstate dummy.4 4
setstate dummy.4 2019-01-16 15:48:43 state 4
Und die DOIFs mit denen ich getest habe:
define doif.0 DOIF ##
attr doif.0 state [#median:"dummy.*":state]
attr doif.0 verbose 5
define doif.1 DOIF ##
attr doif.1 state [@median:"dummy.*":state]
attr doif.1 verbose 5
setstate doif.0 2.75
setstate doif.0 2019-01-16 15:48:43 state 2.75
setstate doif.1 dummy.0,dummy.1,dummy.2,dummy.4
setstate doif.1 2019-01-16 15:48:43 state dummy.0,dummy.1,dummy.2,dummy.4
Das Zwischenspeichern der Werte in Dummys könntest du dir zukünftig sparen und da, wo du die bereinigten Werte benötigst mit [device:temperature:med7] darauf zugreifen.
Zitat von: Damian am 16 Januar 2019, 20:42:07
Das Zwischenspeichern der Werte in Dummys könntest du dir zukünftig sparen und da, wo du die bereinigten Werte benötigst mit [device:temperature:med7] darauf zugreifen.
Äh, das ist temporärer Code aus meiner Testumgebung, kein produktiver Code ...
Zitat von: Damian am 16 Januar 2019, 20:38:55
Es müsste also für die Berechnung jeweils ein Wertepaar aus Zeitpunkt=X und dem eigentlichen Wert=Y in der Queue gespeichert werden.
Ja, wobei es flexibler wäre, wenn [Sensor:temperature:ref10,5] nur 2 Referenzen auf @x, und @y liefert, die man dann in einem DOIF_Reading beliebig auswerten könnte und man ist nicht festgelegt auf einen bestimmten Algorithmus und könnte noch Wichtungen vornehmen.
ref
10.
5 bedeutet dann es werden 2 Referenzen geliefert auf 2 Arrays mit je
10 Elementen, die nächsten Referenzen werden erst geliefert, wenn das Array um
5 Elemente weiter geschoben ist. Dann wird die Berechnung nur alle 5 Werte ausgeführt, damit könnte man die Zahl zeitintensiver Berechnungen reduzieren.
Zitat von: Ellert am 17 Januar 2019, 14:56:05
Ja, wobei es flexibler wäre, wenn [Sensor:temperature:ref10,5] nur 2 Referenzen auf @x, und @y liefert, die man dann in einem DOIF_Reading beliebig auswerten könnte und man ist nicht festgelegt auf einen bestimmten Algorithmus und könnte noch Wichtungen vornehmen.
ref10.5 bedeutet dann es werden 2 Referenzen geliefert auf 2 Arrays mit je 10 Elementen, die nächsten Referenzen werden erst geliefert, wenn das Array um 5 Elemente weiter geschoben ist. Dann wird die Berechnung nur alle 5 Werte ausgeführt, damit könnte man die Zahl zeitintensiver Berechnungen reduzieren.
Ich befürchte, dass der allgemeingültige Ansatz zwar sehr viele Möglichkeiten bietet, aber von 99 % der User als zu komplex gesehen wird. Ich schätze, dass bereits der event-aggregator die meisten in seinen Möglichkeiten überfordert. Zudem wäre die bisherige Semantik bzgl. des Rückgabewertes von [device:reading] verletzt - es wäre kein einfacher Wert (Skalar) mehr, den man in den üblichen Bedingungen auswerten kann.
Was brauchen die meisten?
Ich denke, sie wollen Ausreißer eliminieren und das mit einfacher Syntax wie z. B. [device:reading:med] (med wie Median)
Damit würde ich zunächst anfangen.
Zitat von: Damian am 12 Januar 2019, 23:18:58
Ich habe mal eine neue Option für Readingangaben (s wie smoothing) eingebaut. Man kann jetzt den Wert eines Readings über die letzten X-Werte glätten lassen.
Entspricht dies dem https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen?
Danke, -MN
Zitat von: Morgennebel am 17 Januar 2019, 17:37:21
Entspricht dies dem https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen?
Danke, -MN
Im wesentlichen ja. Die Zeitspanne wird nicht angegeben, da muss der User selbst überlegen, wie viele Werte er auswerten will.
Es gibt sicherlich unzählige Funktionen, die so etwas leisten. Den Durchschnitt zu berechnen ist nichts besonderes, wobei der Median für Ausreißer viel interessanter ist.
Der eigentlicher Vorteil dieser Funktion ist, dass man bestehende Abfragen z. B. [aussen:temperature] <0 in [aussen:temperature:
s7] <0 ändern kann, ohne weitere Definitionen oder Funktionsaufrufe irgendwo vornehmen zu müssen.
Zitat von: Morgennebel am 17 Januar 2019, 17:37:21
Entspricht dies dem https://wiki.fhem.de/wiki/Gleitende_Mittelwerte_berechnen_und_loggen?
Danke, -MN
Das habe ich etwas vorher angeführt....
Das ist die Funktion für die myutils..... [emoji6]
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 17 Januar 2019, 18:28:03
Das habe ich etwas vorher angeführt....
Das ist die Funktion für die myutils..... [emoji6]
Gesendet von meinem E6653 mit Tapatalk
ja, die DOIF-Erweiterung ist in erster Linie für DOIF-Nutzer interessant (oder die es werden wollen).
Wenn jemand bisher kein DOIF genutzt hat, kann natürlich trotzdem gern relativ einfach bereinigte Readings zum Plotten erzeugen:
https://forum.fhem.de/index.php/topic,95759.msg888625.html#msg888625
Doif ist schon cool......
Und mächtig.....
Vereinfacht vieles......
Und polarisiert..... [emoji6]
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 17 Januar 2019, 18:46:03
Doif ist schon cool......
Und mächtig.....
Vereinfacht vieles......
Und polarisiert..... [emoji6]
Gesendet von meinem E6653 mit Tapatalk
Die Diskussion wollen wir lieber nicht wieder anfangen ;)
Ich hoffe, ich komme dazu am Wochenende die neue Funktionalität sauber im DOIF abzubilden. Es soll Folgendes möglich sein:
-beliebig viele Angaben in einem DOIF zu einem Reading (bisher eine)
-beliebig viele Werte (bisher 9)
Folgende Funktionen:
Durchschnitt: [device:reading
:avr<Anzahl>] (kein
s mehr)
Median [device:reading
:med<Anzahl>] sollte bevorzugt für typische Ausreißer genutzt werden
Den Rest überlegen wir uns noch genau.
Zitat von: Damian am 17 Januar 2019, 17:14:54
Ich befürchte, dass der allgemeingültige Ansatz zwar sehr viele Möglichkeiten bietet, aber von 99 % der User als zu komplex gesehen wird. Ich schätze, dass bereits der event-aggregator die meisten in seinen Möglichkeiten überfordert. Zudem wäre die bisherige Semantik bzgl. des Rückgabewertes von [device:reading] verletzt - es wäre kein einfacher Wert (Skalar) mehr, den man in den üblichen Bedingungen auswerten kann.
Was brauchen die meisten?
Ich denke, sie wollen Ausreißer eliminieren und das mit einfacher Syntax wie z. B. [device:reading:med] (med wie Median)
Damit würde ich zunächst anfangen.
Wenn es einen Mechanismus gibt, der die Daten eines Readings sammelt, wäre es halt schön, wenn man auf die Daten zugreifen könnte. Die Aggregationsfunktion liefert z.B. eine Auflistung von Dateinamen zurück, das könnte auch eine Liste von Arrayreferenzen sein.
Aber ich gebe Dir recht, viele würden das wohl nicht nutzen.
Zitat von: Ellert am 17 Januar 2019, 19:08:14
Wenn es einen Mechanismus gibt, der die Daten eines Readings sammelt, wäre es halt schön, wenn man auf die Daten zugreifen könnte. Die Aggregationsfunktion liefert z.B. eine Auflistung von Dateinamen zurück, das könnte auch eine Liste von Arrayreferenzen sein.
Aber ich gebe Dir recht, viele würden das wohl nicht nutzen.
Dafür kann man sich recht einfach eine Routine (hier sammeln) programmieren, die man so aufrufen kann:
DOIF {sammeln ($_myarray,[device:reading])}Auf die gesammelten Werte kannst du dann über die globale Variable hier
$_myarray überall innerhalb des DOIF zwecks Auswertung zugreifen.
Edit: Natürlich kann man als X-Wert auch den Zeitstempel des Readings mit übergeben
Zitat von: Damian am 17 Januar 2019, 18:54:13
Durchschnitt: [device:reading:avr<Anzahl>] (kein s mehr)
Spricht was dagegen, die übliche Abkürzung
avg für den Durchschnitt zu verwenden?
Zitat von: Brockmann am 26 Januar 2019, 14:00:36
Spricht was dagegen, die übliche Abkürzung avg für den Durchschnitt zu verwenden?
nein, bin bisher eh noch nicht dazu gekommen das neue Feature sauber einzubauen.
Neue Version mit Kurzbeschreibung im ersten Post.
Es war aufwändiger als ich dachte. Ich konnte es aber so umsetzen, wie ich es wollte - man kann jetzt in einem DOIF beliebig viele Angaben zum gleichen Reading machen.
Ich blicke da nicht durch.
Eintrag ist: attr HumAK DOIF_Readings humidity:[AK:humidity:avg5]
AK ist ein Sensor, der die Feuchtigkeit liefert.
Es kommt: error in DOIF_Readings avg5, unknown expression format
Zitat von: Neuhier am 27 Januar 2019, 19:13:24
Ich blicke da nicht durch.
Eintrag ist: attr HumAK DOIF_Readings humidity:[AK:humidity:avg5]
AK ist ein Sensor, der die Feuchtigkeit liefert.
Es kommt: error in DOIF_Readings avg5, unknown expression format
Hatten wir das Problem nicht schon mal?
Version DOIF?
Ja, glaube auch.
Bin aber da nicht weitergekommen, selbst mit Update von FHEM nicht....
Habe so angefangen:
define HumAK DOIF ##
dann oben die geopsteten attr, mehr nicht.
Entspricht IMHO dem Beispiel im ersten Beitrag.
Ausgelesen wird AK.humidity korrekt, wird im Plot angezeigt.
Stelle ich mich nur doof an?
Zitat von: Neuhier am 27 Januar 2019, 19:28:14
Ja, glaube auch.
Bin aber da nicht weitergekommen, selbst mit Update von FHEM nicht....
Habe so angefangen:
define HumAK DOIF ##
dann oben die geopsteten attr, mehr nicht.
Entspricht IMHO dem Beispiel im ersten Beitrag.
Ausgelesen wird AK.humidity korrekt, wird im Plot angezeigt.
Stelle ich mich nur doof an?
Du braucht die aktuelle Version aus dem ersten Post z. Zt. v0.4
File Rev Last Change
# $Id: 98_DOIF.pm v0.4 Damian $
98_DOIFtools.pm 18333 2019-01-19 09:13:38Z Ellert
doif.js 15546 2017-12-03 09:57:42Z Ellert
fhemweb.js 18399 2019-01-24 13:18:20Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Zitat von: Neuhier am 27 Januar 2019, 20:16:04
File Rev Last Change
# $Id: 98_DOIF.pm v0.4 Damian $
98_DOIFtools.pm 18333 2019-01-19 09:13:38Z Ellert
doif.js 15546 2017-12-03 09:57:42Z Ellert
fhemweb.js 18399 2019-01-24 13:18:20Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
System durchgestartet?
Bei mir funktioniert alles, wie beschrieben.
Weil es so viel Spaß macht, habe ich noch den prozentualen Anstieg eingebaut :)
Bsp.:
DOIF ([Bad:humidity:inc]>0.1)(set echo Fenster öffnen)
Wenn die Feuchtigkeit um über 10 % zwischen zwei gemessenen Werten ansteigt, dann Ansage.
Wenn mehr Werte dazwischen liegen sollen, dann kann man ebenfalls wie bei diff eine Zahl dranhängen.
Version v0.5 im ersten Post.
Der Fehler, bei mir ,ist der Doppelpunkt hinter dem Device.
Setze ich dort nur einen Punkt, kommt keine Fehlermeldung mehr.
Zitat von: Neuhier am 27 Januar 2019, 20:42:29
Der Fehler, bei mir ,ist der Doppelpunkt hinter dem Device.
Setze ich dort nur einen Punkt, kommt keine Fehlermeldung mehr.
Poste mal list von dem DOIF-Device
list HumAK
ZitatInternals:
CFGFN
DEF ##
MODEL FHEM
NAME HumAK
NR 435
NTFY_ORDER 50-HumAK
STATE initialized
TYPE DOIF
CHANGED:
humidity:
CHANGEDWITHSTATE:
humidity:
DOIF_Readings:
humidity ::ReadingValDoIf($hash,'AK.humidity','avg5')
READINGS:
2019-01-27 20:54:18 cmd 0
2019-01-27 20:54:51 humidity
2019-01-27 20:54:18 mode enabled
2019-01-27 20:54:18 state initialized
Regex:
DOIF_Readings:
AK.humidity:
humidity:
avg5 ^AK.humidity$:^avg5:
condition:
devices:
do:
0:
helper:
DOIF_Readings_events
globalinit 1
last_timer 0
sleeptimer -1
itimer:
uiState:
uiTable:
Attributes:
DOIF_Readings humidity:[AK.humidity:avg5]
Zitat von: Neuhier am 27 Januar 2019, 21:03:48
list HumAK
So wie du es jetzt angegeben hast, ist avg5 ein Reading. Es muss schon die korrekte Syntax sein, sonst kann es nicht funktionieren.
[AK:humidity:avg5]
Warten wir ab, ob es bei den anderen Usern funktioniert.
[AK:humidity:avg5] ergibt den geposteten Fehler.
[AK.humidity:avg5] geht ohne Fehler.
Aber es ist nix Wichtiges, kann also abwarten, ob es woanderst fehlerfrei läuft.
Zitat von: Damian am 27 Januar 2019, 21:20:58
Warten wir ab, ob es bei den anderen Usern funktioniert.
ich habe zwar nur kurz getestet aber bei mir funktioniert die v0.4.
Gruß,
Claudiu
Teste die neuen Aggregat-Funktionen und dabei fiel mir auf: es scheint weiterhin so zu sein, dass z.B. med nur über max 9 Werte läuft. Bei med20 z.B. bekomme ich als Fehlermeldung
error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
Befremdlich: benutze ich med20 direkt in der Bedingung eines DOIFs bekomme ich keine Fehlermeldung und im Listing wird auch korrekt Dim 20 für die Größe des Arrays angegeben.
Christian
Zitat von: cwagner am 01 Februar 2019, 14:00:14
Teste die neuen Aggregat-Funktionen und dabei fiel mir auf: es scheint weiterhin so zu sein, dass z.B. med nur über max 9 Werte läuft. Bei med20 z.B. bekomme ich als Fehlermeldung
error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
Befremdlich: benutze ich med20 direkt in der Bedingung eines DOIFs bekomme ich keine Fehlermeldung und im Listing wird auch korrekt Dim 20 für die Größe des Arrays angegeben.
Christian
Poste bitte das Listing vom dem DOIF-Device.
Hier das Listing mit dem Versuch, in einem DOIF-Reading einen Median über 20 Werte zu bilden:
nternals:
CHANGED
DEF ([Lueftung] eq "max") (set Steller_Zuluft gpio 255) (set Steller_Abluft gpio 255)
DOELSEIF ([abwesend] eq "an" or [Lueftung] eq "AUS") (set Steller_Zuluft gpio 0) (set Steller_Abluft gpio 0)
DOELSEIF ([Lueftung] eq "min" or [$SELF:sCO2]<700) (set Steller_Zuluft gpio 55) (set Steller_Abluft gpio 55) ##LWR 0,8/h
DOELSEIF ([?Lueftung] eq "auto" and [$SELF:sCO2]>([$SELF:CO2_alt]+10) and [Steller_Zuluft:gpio]<250) (setreading $SELF CO2_alt [$SELF:sCO2],setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]+5))},set Steller_Zuluft gpio [$SELF:Stell_neu]) (setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]))},set Steller_Abluft gpio [$SELF:Stell_neu]) ## Vereinfachung möglich mit dirkten Einstetzen von Stellwert-Zuluft als Steuerwert bei Abluft
DOELSEIF ([?Lueftung] eq "auto" and [$SELF:sCO2]<([$SELF:CO2_alt]+10) and [Steller_Zuluft:gpio]>59) (setreading $SELF CO2_alt [$SELF:sCO2],setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]-5))},set Steller_Zuluft gpio [$SELF:Stell_neu]) (setreading $SELF Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]))},set Steller_Abluft gpio [$SELF:Stell_neu])
FUUID 5c43298b-f33f-e1df-09ea-ab76a5ff2ccd3b93
MODEL FHEM
NAME DI_Lueftung
NR 115
NTFY_ORDER 50-DI_Lueftung
STATE Betrieb
TYPE DOIF
DOIF_Readings:
sCO2 ::ReadingValDoIf($hash,'CO2Sensor','CO2','','med20')
OLDREADINGS:
READINGS:
2019-02-01 08:25:47 CO2_alt 1253
2019-02-01 14:38:41 Device DI_Lueftung
2019-02-01 08:26:02 Stell_neu 55
2019-02-01 09:24:02 cmd 3.2
2019-02-01 09:23:47 cmd_count 1
2019-02-01 09:24:02 cmd_event DI_Lueftung
2019-02-01 09:24:02 cmd_nr 3
2019-02-01 09:24:02 cmd_seqnr 2
2019-02-01 14:38:41 e_DI_Lueftung_sCO2 error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
2019-02-01 09:22:33 mode enabled
2019-02-01 14:38:41 sCO2 error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
2019-02-01 09:24:02 state Betrieb
2019-02-01 09:24:02 wait_timer no timer
2019-02-01 14:38:41 warning condition c03: Argument "error in DOIF_Readings: Modification of non-creatable ar..." isn't numeric in numeric lt (<)
Regex:
DOIF_Readings:
CO2Sensor:
sCO2:
CO2 ^CO2Sensor$:^CO2:
DI_Lueftung:
accu:
CO2Sensor:
accu:
CO2 ^CO2Sensor$:^CO2:
accu:
CO2Sensor CO2:
dim 9
value:
968
951
954
968
975
970
985
967
985
akku:
CO2Sensor CO2:
945
949
949
926
926
932
932
947
947
attr:
cmdState:
repeatsame:
1
1
1
0
0
wait:
0:
0
15
1:
0
15
2:
0
15
3:
0
15
4:
0
15
5:
0
waitdel:
condition:
0 ::InternalDoIf($hash,'Lueftung','STATE') eq "max"
1 ::InternalDoIf($hash,'abwesend','STATE') eq "an" or ::InternalDoIf($hash,'Lueftung','STATE') eq "AUS"
2 ::InternalDoIf($hash,'Lueftung','STATE') eq "min" or ::ReadingValDoIf($hash,'DI_Lueftung','sCO2')<700
3 ::InternalDoIf($hash,'Lueftung','STATE') eq "auto" and ::ReadingValDoIf($hash,'DI_Lueftung','sCO2')>(::ReadingValDoIf($hash,'DI_Lueftung','CO2_alt')+10) and ::ReadingValDoIf($hash,'Steller_Zuluft','gpio')<250
4 ::InternalDoIf($hash,'Lueftung','STATE') eq "auto" and ::ReadingValDoIf($hash,'DI_Lueftung','sCO2')<(::ReadingValDoIf($hash,'DI_Lueftung','CO2_alt')+10) and ::ReadingValDoIf($hash,'Steller_Zuluft','gpio')>59
devices:
0 Lueftung
1 abwesend Lueftung
2 Lueftung DI_Lueftung
3 DI_Lueftung Steller_Zuluft
4 DI_Lueftung Steller_Zuluft
all Lueftung abwesend DI_Lueftung Steller_Zuluft
do:
0:
0 set Steller_Zuluft gpio 255
1 set Steller_Abluft gpio 255
1:
0 set Steller_Zuluft gpio 0
1 set Steller_Abluft gpio 0
2:
0 set Steller_Zuluft gpio 55
1 set Steller_Abluft gpio 55
3:
0 setreading DI_Lueftung CO2_alt [DI_Lueftung:sCO2],setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]+5))},set Steller_Zuluft gpio [DI_Lueftung:Stell_neu]
1 setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]))},set Steller_Abluft gpio [DI_Lueftung:Stell_neu]
4:
0 setreading DI_Lueftung CO2_alt [DI_Lueftung:sCO2],setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]-5))},set Steller_Zuluft gpio [DI_Lueftung:Stell_neu]
1 setreading DI_Lueftung Stell_neu {(sprintf "%.0f", ([Steller_Zuluft:gpio]))},set Steller_Abluft gpio [DI_Lueftung:Stell_neu]
5:
helper:
DOIF_Readings_events
event sCO2: error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
globalinit 1
last_timer 0
sleepdevice DI_Lueftung
sleepsubtimer -1
sleeptimer -1
timerdev DI_Lueftung
timerevent sCO2: error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
triggerDev DI_Lueftung
DOIF_eventas:
cmd_nr: 3
cmd_seqnr: 2
cmd_event: DI_Lueftung
state: Betrieb
timerevents:
sCO2: error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
timereventsState:
sCO2: error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
triggerEvents:
sCO2: error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
triggerEventsState:
sCO2: error in DOIF_Readings: Modification of non-creatable array value attempted, subscript -20 at ./FHEM/98_DOIF.pm line 1040.
internals:
0 Lueftung:STATE
1 abwesend:STATE Lueftung:STATE
2 Lueftung:STATE
3 Lueftung:STATE
4 Lueftung:STATE
all Lueftung:STATE abwesend:STATE
itimer:
readings:
2 DI_Lueftung:sCO2
3 DI_Lueftung:sCO2 DI_Lueftung:CO2_alt Steller_Zuluft:gpio
4 DI_Lueftung:sCO2 DI_Lueftung:CO2_alt Steller_Zuluft:gpio
all DI_Lueftung:sCO2 DI_Lueftung:CO2_alt Steller_Zuluft:gpio
trigger:
uiState:
uiTable:
Attributes:
DOIF_Readings sCO2:[CO2Sensor:CO2:med20]
DbLogExclude .*
do always
event-on-change-reading cmd
repeatsame 1:1:1:0:0
room Lueftung
startup set $SELF checkall
state Betrieb
verbose 2
wait 0,15:0,15:0,15:0,15:0,15:0
Die Behauptung, es funktioniere in einer DOIF-Bedingung ist falsch (hätte ich doch ordentlich auf checkall geklickt)
Liebe Grüße
Christian
Das Problem ist, dass du nachdem du DOIF_Readings definiert hast, die DOIF-Definition (DEF-Bereich) noch mal geändert hast. Wenn du die DOIF-Definition änderst, musst du danach noch mal DOIF-Readings anklicken und übernehmen.
Ich werde da noch einen Automatismus einbauen.
Das kann ich so nicht bestätigen: Ohne die DEF angefasst zu haben, erhalte ich beim Speichern des attr DOIF-Readings sofort die Fehlermeldungen...
Christian
Zitat von: Damian am 01 Februar 2019, 14:56:09
Das Problem ist, dass du nachdem du DOIF_Readings definiert hast, die DOIF-Definition (DEF-Bereich) noch mal geändert hast. Wenn du die DOIF-Definition änderst, musst du danach noch mal DOIF-Readings anklicken und übernehmen.
Ich werde da noch einen Automatismus einbauen.
Version 0.6 im ersten Post.
Jetzt werden alle Attribut-Definitionen neu gesetzt, wenn man defmod aufruft. Dadurch wird sichergestellt, dass eine nachträgliche Änderung der Definition (DEF) des DOIF-Devices zur Laufzeit keine Probleme mehr bereitet.
PS. Ich denke, dass med3 ausreichen sollte, um Ausreißer zu eliminieren. Es müssten dann schon bei drei nacheinander folgenden Werten zwei Ausreißer dabei sein, damit einer durchkommt - das sollte recht unwahrscheinlich sein.
Zitat von: cwagner am 01 Februar 2019, 21:03:08
Das kann ich so nicht bestätigen: Ohne die DEF angefasst zu haben, erhalte ich beim Speichern des attr DOIF-Readings sofort die Fehlermeldungen...
Christian
Korrigierte Version 0.7 im ersten Post.
Da muss man erst mal drauf kommen, dass {max(4,10)} 4 liefert >:(
Es scheint hier die lexikografische Reihenfolge gemeint zu sein. Ich habe es jetzt selber programmiert.
Funktioniert nun - getestet mit med20
Was ist die Bedeutung von accu und akku im Listing?
Und immer wieder: Danke für Deine Super-Arbeit!
Christian
Zitat von: cwagner am 01 Februar 2019, 23:40:18
Funktioniert nun - getestet mit med20
Was ist die Bedeutung von accu und akku im Listing?
Und immer wieder: Danke für Deine Super-Arbeit!
Christian
Unterhalb von accu werden die Daten der Sensoren gespeichert.
Ursprünglich hieß es intern akku. Mit der neuen Version und einem durchgestarteten System sollte akku nicht mehr sichtbar sein.
Mit med20 werden die Daten aus meiner Sicht unnötig stark verfälscht. Zusätzlich wird bei jedem Trigger mehr Rechenpower benötigt.
Du könntest, um herauszufinden, welcher Wert für dich am besten ist, folgendes DOIF bauen:
define CO2Med DOIF\
{set_Reading("ori",[CO2Sensor:CO2],1)}\
{set_Reading("med3",[CO2Sensor:CO2:med3],1)}\
{set_Reading("med5",[CO2Sensor:CO2:med5],1)}\
{set_Reading("med7",[CO2Sensor:CO2:med7],1)}\
{set_Reading("med20",[CO2Sensor:CO2:med20],1)}Im Gegensatz zum Attribut DOIF_Readings werden hier bewusst Events nach außen produziert. Dadurch kann man die Werte als Graphen in einem Plot gegenüberstellen und die Abweichungen zum Originalwert erkennen.
Beim Median würde ich immer ungerade Zahlen nehmen, da bei geraden immer ein Mittelwert gebildet wird.
Und wenn med3 ausreicht, würde ich den nehmen, da bei jedem Trigger von CO2Sensor:CO2 weniger Rechenpower benötigt wird als bei med20.
Edit: Für angehende Informatiker: Der Sortieraufwand (der im Median drinsteckt) ist mit mindestens n*log(n) (oft n^2) immer überproportional hoch. Vergleich: 3*log(3)=1,49 bis 3*3=
9 dagegen 20*log(20)=26,02 bis 20*20=
400. Für den Laien heißt das, dass die Angabe med20 schlimmstenfalls 400/9=
44,44 mal mehr Rechenleistung dem System abverlangt als med3. Bei med100 z. B. wäre es schon ein Faktor 100*100/(3*3)=
1111,11 gegenüber med3 ;)
Vielen Dank, Damian, da habe ich wieder eine Menge gelernt, was mich weiterbringt. Ich habe Deinen Ratschlag folgend dann mal das kleine Vergleichs-Doif genommen und auf die Messwerte gelegt, die aktuell in größeren Abständen extreme Spitzen haben, die meine Steuerung sehr stark hochschaukeln würden.
Da sind Deine Aussagen dann grafisch sehr plakativ belegt. Sehr auffällig ist auch die zeitliche Verschiebung der eingeebneten Spitzen.
Herzliche Grüße
Christian
Zitat von: cwagner am 03 Februar 2019, 07:24:01
Vielen Dank, Damian, da habe ich wieder eine Menge gelernt, was mich weiterbringt. Ich habe Deinen Ratschlag folgend dann mal das kleine Vergleichs-Doif genommen und auf die Messwerte gelegt, die aktuell in größeren Abständen extreme Spitzen haben, die meine Steuerung sehr stark hochschaukeln würden.
Da sind Deine Aussagen dann grafisch sehr plakativ belegt. Sehr auffällig ist auch die zeitliche Verschiebung der eingeebneten Spitzen.
Herzliche Grüße
Christian
Ich nehme an, dass die rote Kurve die Originalwerte sind und die gelbe med20.
Das sieht mir aber nicht nach Ausreißern aus, sondern nach einem kontinuierlichen Anstieg, den du ebnen willst. In diesem Fall würde ich nicht den Median nehmen, der ja nur extreme Werte entfernt, sondern den Durchschnitt avg.
Ich wollte ein bisschen mit den neuen Features herumspielen und habe mir mal folgendes DOIF gebaut:
Internals:
DEF ([":^measured-temp",0:diff]>0.1)
( {Log 1, "ACHTUNG! $DEVICE: temp steigt! avg: [$DEVICE:measured-temp:avg] med: [$DEVICE:measured-temp:med] diff: [$DEVICE:measured-temp:diff] inc: [$DEVICE:measured-temp:inc]"})
DOELSEIF ([":^measured-temp",0:diff]<0.1)
( {Log 1, "ACHTUNG! $DEVICE: temp sinkt! avg: [$DEVICE:measured-temp:avg] med: [$DEVICE:measured-temp:med] diff: [$DEVICE:measured-temp:diff] inc: [$DEVICE:measured-temp:inc]"})
FUUID 5c584550-f33f-a31c-6ce0-db61cd1082209d8b
MODEL FHEM
NAME DOIF_test
NR 902
NTFY_ORDER 50-DOIF_test
STATE cmd_1
TYPE DOIF
READINGS:
2019-02-04 21:17:56 Device KUECHE.klima_Climate
2019-02-04 21:17:56 cmd 1
2019-02-04 21:17:56 cmd_event KUECHE.klima_Climate
2019-02-04 21:17:56 cmd_nr 1
2019-02-04 21:17:05 mode enabled
2019-02-04 21:17:56 state cmd_1
Regex:
accu:
$DEVICE:
accu:
measured-temp ^$DEVICE$:^measured-temp:
ERIK.heizung:
accu:
measured-temp ^ERIK.heizung$:^measured-temp:
ERIK.heizung_Clima:
accu:
measured-temp ^ERIK.heizung_Clima$:^measured-temp:
KUECHE.klima_Climate:
accu:
measured-temp ^KUECHE.klima_Climate$:^measured-temp:
WOHN.SOFA.heizung:
accu:
measured-temp ^WOHN.SOFA.heizung$:^measured-temp:
cond:
:
0:
":^measured-temp" :^measured-temp
1:
":^measured-temp" :^measured-temp
accu:
$DEVICE measured-temp:
dim 2
value:
ERIK.heizung measured-temp:
dim 2
value:
ERIK.heizung_Clima measured-temp:
dim 2
value:
KUECHE.klima_Climate measured-temp:
dim 2
value:
WOHN.SOFA.heizung measured-temp:
dim 2
value:
attr:
cmdState:
wait:
waitdel:
condition:
0 ::EventDoIf('',$hash,'^measured-temp',0,'[^\:]*: (.*)','','0:diff')>0.1
1 ::EventDoIf('',$hash,'^measured-temp',0,'[^\:]*: (.*)','','0:diff')<0.1
devices:
do:
0:
0 {Log 1, "ACHTUNG! $DEVICE: temp steigt! avg: [$DEVICE:measured-temp:avg] med: [$DEVICE:measured-temp:med] diff: [$DEVICE:measured-temp:diff] inc: [$DEVICE:measured-temp:inc]"}
1:
0 {Log 1, "ACHTUNG! $DEVICE: temp sinkt! avg: [$DEVICE:measured-temp:avg] med: [$DEVICE:measured-temp:med] diff: [$DEVICE:measured-temp:diff] inc: [$DEVICE:measured-temp:inc]"}
2:
helper:
event measured-temp: 21.9
globalinit 1
last_timer 0
sleeptimer -1
timerdev KUECHE.klima_Climate
timerevent measured-temp: 21.9
triggerDev KUECHE.klima_Climate
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: KUECHE.klima_Climate
state: cmd_1
timerevents:
desired-temp: 5.0
humidity: 42
measured-temp: 21.9
T: 21.9 desired: 5.0
timereventsState:
desired-temp: 5.0
humidity: 42
measured-temp: 21.9
state: T: 21.9 desired: 5.0
triggerEvents:
desired-temp: 5.0
humidity: 42
measured-temp: 21.9
T: 21.9 desired: 5.0
triggerEventsState:
desired-temp: 5.0
humidity: 42
measured-temp: 21.9
state: T: 21.9 desired: 5.0
internals:
itimer:
readings:
trigger:
uiState:
uiTable:
Attributes:
DbLogExclude .*
do always
Im Log kommt dann Folgendes an:
2019.02.04 21:17:56 1 : ACHTUNG! KUECHE.klima_Climate: temp steigt! avg: 21.9 med: 21.9 diff: 0 inc: 0
2019-02-04 21:17:56 DOIF DOIF_test cmd_nr: 1
2019-02-04 21:17:56 DOIF DOIF_test cmd: 1
2019-02-04 21:17:56 DOIF DOIF_test cmd_event: KUECHE.klima_Climate
2019-02-04 21:17:56 DOIF DOIF_test cmd_1
2019-02-04 21:17:56 CUL_HM KUECHE.klima_Climate desired-temp: 5.0
2019-02-04 21:17:56 CUL_HM KUECHE.klima_Climate humidity: 42
2019-02-04 21:17:56 CUL_HM KUECHE.klima_Climate measured-temp: 21.9
2019-02-04 21:17:56 CUL_HM KUECHE.klima_Climate T: 21.9 desired: 5.0
"DIFF" ist eigentlich immer 0, aber trotzdem triggert das DOIF.
Was läuft da schief?
Habe ich was übersehen?
Die neuen Features funktionieren nur auf konkrete Readings siehe Syntax im ersten Post und nicht auf allgemeine Event-Abfragen.
Läuft bei mir prima, damit entfällt für mich das "gleitende Mittelwert" aus dem Wiki.
Ich setze es bei der Steuerung meines Fußboden-Mischers ein:
Internals:
DEF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 22 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 1: Schnell oeffnen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 26 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 2: Ganz langsam oeffnen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 30 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 3: Noch ein bisschen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 33 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 4: Noch ein bisschen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] > 40)
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}) ## Cmd 5: Viel zu heiss, schnell zu
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] > 39)
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}) ## Cmd 6: Viel zu heiss, schnell zu
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] > 38)
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}) ## Cmd 7: Zu heiss, schnell zu
DOELSEIF ([03:50])
(set SM_Fussbodenmischer calibrate, set SM_Fussbodenmischer reset) ## Cmd 8: Calibrieren fuer Tagprogramm
DOELSEIF ([04:00])
(set SM_Fussbodenmischer 40) ## Cmd 9: Headstart, Ende der Nachtabsenkung
FUUID 5c59701c-f33f-9a7b-8505-03f23afcd7562e8f
MODEL FHEM
NAME DI_MischerCommands
NR 69
NTFY_ORDER 50-DI_MischerCommands
STATE cmd_7
TYPE DOIF
READINGS:
2019-02-06 09:39:45 Device 1W_HWR.FussbodenMischer_Vorlauf
2019-02-06 08:44:46 cmd 7
2019-02-06 08:44:46 cmd_event 1W_HWR.FussbodenMischer_Vorlauf
2019-02-06 08:44:46 cmd_nr 7
2019-02-06 09:39:45 e_1W_HWR.FussbodenMischer_Vorlauf_temperature 36.87
2019-02-06 09:39:45 e_RP_FussbodenPumpe_Sw_STATE on
2019-02-05 16:53:13 mode enabled
2019-02-06 08:44:46 state cmd_7
2019-02-06 03:50:00 timer_01_c08 07.02.2019 03:50:00
2019-02-06 04:00:00 timer_02_c09 07.02.2019 04:00:00
2019-02-06 08:44:46 wait_timer no timer
Regex:
accu:
1W_HWR.FussbodenMischer_Vorlauf:
accu:
temperature ^1W_HWR.FussbodenMischer_Vorlauf$:^temperature:
accu:
1W_HWR.FussbodenMischer_Vorlauf temperature:
dim 5
value:
36.81
36.87
36.87
36.93
36.87
attr:
cmdState:
cmdpause:
60
120
360
480
60
180
300
0
0
wait:
0:
180
1:
240
2:
360
3:
600
4:
90
5:
180
6:
420
7:
0
8:
0
waitdel:
condition:
0 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') < 22 and ::InternalDoIf($hash,'RP_FussbodenPumpe_Sw','STATE') eq "on"
1 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') < 26 and ::InternalDoIf($hash,'RP_FussbodenPumpe_Sw','STATE') eq "on"
2 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') < 30 and ::InternalDoIf($hash,'RP_FussbodenPumpe_Sw','STATE') eq "on"
3 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') < 33 and ::InternalDoIf($hash,'RP_FussbodenPumpe_Sw','STATE') eq "on"
4 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') > 40
5 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') > 39
6 ::ReadingValDoIf($hash,'1W_HWR.FussbodenMischer_Vorlauf','temperature','','med5') > 38
7 ::DOIF_time_once($hash,0,$wday)
8 ::DOIF_time_once($hash,1,$wday)
days:
devices:
0 1W_HWR.FussbodenMischer_Vorlauf RP_FussbodenPumpe_Sw
1 1W_HWR.FussbodenMischer_Vorlauf RP_FussbodenPumpe_Sw
2 1W_HWR.FussbodenMischer_Vorlauf RP_FussbodenPumpe_Sw
3 1W_HWR.FussbodenMischer_Vorlauf RP_FussbodenPumpe_Sw
4 1W_HWR.FussbodenMischer_Vorlauf
5 1W_HWR.FussbodenMischer_Vorlauf
6 1W_HWR.FussbodenMischer_Vorlauf
all 1W_HWR.FussbodenMischer_Vorlauf RP_FussbodenPumpe_Sw
do:
0:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}
1:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}
2:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}
3:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}
4:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}
5:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}
6:
0 set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}
7:
0 set SM_Fussbodenmischer calibrate, set SM_Fussbodenmischer reset
8:
0 set SM_Fussbodenmischer 40
9:
helper:
event temperature: 36.87
globalinit 1
last_timer 2
sleepdevice 1W_HWR.FussbodenMischer_Vorlauf
sleepsubtimer -1
sleeptimer -1
timerdev 1W_HWR.FussbodenMischer_Vorlauf
timerevent temperature: 38.12
triggerDev 1W_HWR.FussbodenMischer_Vorlauf
DOIF_eventas:
cmd_nr: 7
cmd: 7
cmd_event: 1W_HWR.FussbodenMischer_Vorlauf
state: cmd_7
timerevents:
temperature: 38.12
timereventsState:
temperature: 38.12
triggerEvents:
temperature: 36.87
triggerEventsState:
temperature: 36.87
internals:
0 RP_FussbodenPumpe_Sw:STATE
1 RP_FussbodenPumpe_Sw:STATE
2 RP_FussbodenPumpe_Sw:STATE
3 RP_FussbodenPumpe_Sw:STATE
all RP_FussbodenPumpe_Sw:STATE
interval:
intervalfunc:
itimer:
localtime:
0 1549507800
1 1549508400
readings:
0 1W_HWR.FussbodenMischer_Vorlauf:temperature
1 1W_HWR.FussbodenMischer_Vorlauf:temperature
2 1W_HWR.FussbodenMischer_Vorlauf:temperature
3 1W_HWR.FussbodenMischer_Vorlauf:temperature
4 1W_HWR.FussbodenMischer_Vorlauf:temperature
5 1W_HWR.FussbodenMischer_Vorlauf:temperature
6 1W_HWR.FussbodenMischer_Vorlauf:temperature
all 1W_HWR.FussbodenMischer_Vorlauf:temperature
realtime:
0 03:50:00
1 04:00:00
time:
0 03:50:00
1 04:00:00
timeCond:
0 7
1 8
timer:
0 0
1 0
timers:
7 0
8 1
trigger:
triggertime:
1549507800:
localtime 1549507800
hash:
1549508400:
localtime 1549508400
hash:
uiState:
uiTable:
Attributes:
cmdpause 60:120:360:480:60:180:300:0:0
do always
room R_HWR,SYS_Events
verbose 0
wait 180:240:360:600:90:180:420:0:0
und würde als einzigen Wunsch äußern, daß ich gerne den "Funktionswert" als zusätzliches Reading hätte. Also in meinem Fall den
1W_HWR.FussbodenMischer_Vorlauf:temperature:med5
Wert als Reading, um diesen mit den "normalen" Wert besser vergleichen und zu visualisieren.
Danke, -MN
Zitat von: Morgennebel am 06 Februar 2019, 09:42:47
Läuft bei mir prima, damit entfällt für mich das "gleitende Mittelwert" aus dem Wiki.
Ich setze es bei der Steuerung meines Fußboden-Mischers ein:
Internals:
DEF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 22 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 1: Schnell oeffnen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 26 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 2: Ganz langsam oeffnen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 30 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 3: Noch ein bisschen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] < 33 and [RP_FussbodenPumpe_Sw] eq "on")
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]+1)}) ## Cmd 4: Noch ein bisschen
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] > 40)
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}) ## Cmd 5: Viel zu heiss, schnell zu
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] > 39)
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}) ## Cmd 6: Viel zu heiss, schnell zu
DOELSEIF ([1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] > 38)
(set SM_Fussbodenmischer {([SM_Fussbodenmischer:position]-1)}) ## Cmd 7: Zu heiss, schnell zu
DOELSEIF ([03:50])
(set SM_Fussbodenmischer calibrate, set SM_Fussbodenmischer reset) ## Cmd 8: Calibrieren fuer Tagprogramm
DOELSEIF ([04:00])
...
und würde als einzigen Wunsch äußern, daß ich gerne den "Funktionswert" als zusätzliches Reading hätte. Also in meinem Fall den
1W_HWR.FussbodenMischer_Vorlauf:temperature:med5
Wert als Reading, um diesen mit den "normalen" Wert besser vergleichen und zu visualisieren.
Danke, -MN
Die Vorgehensweise ist in diesem Fall eine Andere.
Du definierst für [1W_HWR.FussbodenMischer_Vorlauf:temperature:med5] ein DOIF_Reading (so wie im ersten Post) und benutzt nur noch diesen im DOIF.
Damit ist der bereinigte Wert sichtbar, die Angaben in der Bedingung sind kürzer und der hohe Rechenaufwand für den Median wird nur einmal, statt mehrfach durchgeführt.
Danke, werde ich gleich ändern...
Ciao, -MN
Hi Damian,
ich habe eine dbLog-Anweisung der Form:
./db.conf .*:(temperature|desired-temp|measured-temp|humidity|ValvePosition|dewpoint|on|off|position|cond|hmTraffic|motion|motionCount|motionDuration|noMotion|energy|energyCalc|energyOffset|power|gasCnt|gasCntCalc|gasPower|Diesel|SuperE5|AVG\sT|FussbodenMischer_VorlaufMED).*
d.h. beliebige Geräte, aber nur die angegebenen Readings. Mich interessiert das FussbodenMischer_VorlaufMED-Reading ganz am Ende, daß ein med10-DOIF-Reading ist.
attr DI_MischerCommands DOIF_Readings FussbodenMischer_VorlaufMED:[1W_HWR.FussbodenMischer_Vorlauf:temperature:med10]
Leidert triggert das dbLog nicht:
MariaDB [DB_FHEMLOG]> select * from history where DEVICE="%MED%";
Empty set (0.00 sec)
Unterstützen die neuen Funktionen überhaupt das Loggen mit dbLog (d.h. liegt der Fehler eher irgendwo anders bei mir)?
Danke, -MN
DOIF_Readings triggern nur intern und produzieren keine Events nach außen.
Wenn das Reading Events produzieren soll, so bietet sich der Perl-Modus an:
define bereinigte_Readings DOIF {set_Reading("FussbodenMischer_VorlaufMED",[1W_HWR.FussbodenMischer_Vorlauf:temperature:med10],1}
Dieser ist allerdings nicht mit dem FHEM-Modus kombinierbar. Natürlich kann man statt über DOIF_Readings auf [bereinigte_Readings:FussbodenMischer_VorlaufMED] im anderen DOIF darauf zugreifen und es auch loggen.
Bedingt durch die neuen Features steigt offenbar der Bedarf nach Events (zwecks Protokollierung) bei DOIF_Readings.
Ich habe ein neues Attribut definiert namens event_Readings. Dieses hat die gleiche Syntax wie DOIF_Readings. Der Unterschied besteht darin, dass event_Readings im Gegensatz zu DOIF_Readings jedes mal Events produziert. event_Readings kann aber auch das eigene DOIF-Device triggern, kümmert sich jedoch im Gegensatz zu DOIF_Readings nicht um den Zustand der Readings (DOIF_Readings triggert nur, wenn sich der Zustand des definierten Readings ändert). Das kann bei Bedarf bei event_Readings über das FHEM-Attribut event-on-change-reading angepasst werden.
Bsp.
define di DOIF ([$SELF:tempMed] < 0) (set frost on)
attr di event_Readings tempMed:[ausssen:temperature:med3]
Die bereinigte Temperatur in di:tempMed lässt sich hierbei loggen.
PS: Sind Events des definierten Readings nicht erforderlich und die Triggerung des eigenen DOIF-Moduls nur bei Änderung interessant, dann sollte man zum Attribut DOIF_Readings greifen, da es durch die interne Triggerung des Moduls weniger das System belastet als event_Readings.
Version 0.9 im ersten Post.
Dankeschön! Super Feature!
Läßt sich damit auch das nicht mehr gepflegte https://wiki.fhem.de/wiki/VALVES VALVES-Modul ersetzen?
Ein DOIF, daß über alle Heizungen den Durchschnitt der Ventilöffnungen ermittelt?
Als über die Heizungsthermostaten:
HM_EG.ARBEITZ_HeizungLinks_Clima
HM_EG.ESSZMMR_HeizungLinks_Clima
HM_EG.ESSZMMR_HeizungMitte_Clima
HM_EG.ESSZMMR_HeizungRechts_Clima
HM_EG.WINTERG_Heizung_Clima
...
den Durchschnitt des Readings ValvePosition?
Danke, -MN
Die neuen Features funktionieren nur auf konkrete Readings. Jedes Reading welches man anpassen will, muss einmal angegeben werden.
Neue Version wurde eingecheckt.
Beschreibung in der Commandref:
https://fhem.de/commandref_DE.html#DOIF_Reading_Funktionen
und
https://fhem.de/commandref_DE.html#DOIF_event_Readings
Hallo Damian!
Die neuen Features sind toll!
Danke für deine Arbeit!
lG
Michael
Hallo guten Abend zusammen,
nachdem ich im Log von meinem Aussen-Sensor festgestellt habe, dass der "humidity" Wert sich bei Regen
z.B. innerhalb ca. 5 Minuten von 61 auf 65 % erhöht, möchte ich mit diesem DOIF :
define Regen DOIF ([TH_Aussentemp:humidity:inc4] > 0.04 and [FS_Bad:state] eq "open") (set regen Fenster_zu) DOELSE (set regen Fenster_ok)
bei einem geöffneten Dachfenster eine Meldung an mein FTUI-Tablet senden.
Die neue Möglichkeit in DOIF sollte das mit diesem DOIF ja ermöglichen, mir ist nur nicht klar wie ich die Zeit bestimme,
in der die Änderung erfolgen muss ?
Würde mich über einen Tipp freuen.
LG Peter aus Calw
Zitat von: Peter aus Calw am 24 März 2019, 21:41:47
Hallo guten Abend zusammen,
nachdem ich im Log von meinem Aussen-Sensor festgestellt habe, dass der "humidity" Wert sich bei Regen
z.B. innerhalb ca. 5 Minuten von 61 auf 65 % erhöht, möchte ich mit diesem DOIF :
define Regen DOIF ([TH_Aussentemp:humidity:inc4] > 0.04 and [FS_Bad:state] eq "open") (set regen Fenster_zu) DOELSE (set regen Fenster_ok)
bei einem geöffneten Dachfenster eine Meldung an mein FTUI-Tablet senden.
Die neue Möglichkeit in DOIF sollte das mit diesem DOIF ja ermöglichen, mir ist nur nicht klar wie ich die Zeit bestimme,
in der die Änderung erfolgen muss ?
Würde mich über einen Tipp freuen.
LG Peter aus Calw
Die Zeitspanne ergibt sich aus dem zeitlichen Abstand der gesendeten Events des Devices. Konkret, wenn TH_Aussentemp:humidity z. B. alle 6 Minuten sendet, dann liegt das viertletzte vor 3 x 6 = 18 Minuten
Hallo Damian,
danke für Deine schnelle Antwort.
Das ist mein Problem, normal sendet der Sensor im Abstand von 20-60(oder mehr) Minuten.
Bei Regen ändert sich der Wert in wenigen Minuten und genau diese in kurzer Zeit anfallenden Werte-Änderungen
soll das DOIF auswerten.
Wahrscheinlich kapiere ich den Ablauf der auszuwertenden Werte in Bezug zu "inc4" nicht ?
LG Peter
Zitat von: Peter aus Calw am 24 März 2019, 22:17:41
Hallo Damian,
danke für Deine schnelle Antwort.
Das ist mein Problem, normal sendet der Sensor im Abstand von 20-60(oder mehr) Minuten.
Bei Regen ändert sich der Wert in wenigen Minuten und genau diese in kurzer Zeit anfallenden Werte-Änderungen
soll das DOIF auswerten.
Wahrscheinlich kapiere ich den Ablauf der auszuwertenden Werte in Bezug zu "inc4" nicht ?
LG Peter
Bei diesen Features findet seitens DOIF keine Zeitmessung statt. Du kannst aber beim TH_Aussentemp das Attribut event-min-interval setzen, damit die Events im gleichmäßigen Abstand kommen.
Hallo Damian,
Deinen Vorschlag werde ich einrichten und morgen kann das bei der erwarteten heftigen Wetteränderung gleich getestet werden.
Besten Dank für Deine nun schon fast unendliche Hilfe und das für richtige User unerreichte
DOIF :) :) :)
Beste Grüße von Peter
Man kann erst mal mit diff experimentieren, ich bin mir nicht sicher, ob ein Anteil mit inc bei Feuchtigkeit tatsächlich besser ist.
Bei einem event-min-interval von einer Minute wäre :diff16 eine Differenz zwischen dem aktuellen Wert und dem Wert vor 15 Minuten (16 Werte zurück in die Vergangenheit).
ok Damian, dann werde ich das mal versuchen, heute hat es mit inc3 trotz diesem Log nicht funktioniert :
2019-03-25_13:41:40 TH_Aussentemp humidity: 45
2019-03-25_13:43:56 TH_Aussentemp humidity: 48
2019-03-25_13:45:58 TH_Aussentemp humidity: 48
2019-03-25_13:48:49 TH_Aussentemp humidity: 51
2019-03-25_13:51:26 TH_Aussentemp humidity: 52
es hat exakt in diesem Zeitabschnitt ziemlich ergiebig geregnet, wurde aber nicht ausgewertet.
Wäre dann dieser Versuch so richtig ?
([TH_humidity:state:diff16] > 4) (set regen F_zu) DOELSE (set regen F_ok)
Gruß Peter
Zitat von: Peter aus Calw am 25 März 2019, 17:58:30
ok Damian, dann werde ich das mal versuchen, heute hat es mit inc3 trotz diesem Log nicht funktioniert :
2019-03-25_13:41:40 TH_Aussentemp humidity: 45
2019-03-25_13:43:56 TH_Aussentemp humidity: 48
2019-03-25_13:45:58 TH_Aussentemp humidity: 48
2019-03-25_13:48:49 TH_Aussentemp humidity: 51
2019-03-25_13:51:26 TH_Aussentemp humidity: 52
es hat exakt in diesem Zeitabschnitt ziemlich ergiebig geregnet, wurde aber nicht ausgewertet.
Wäre dann dieser Versuch so richtig ?
([TH_humidity:state:diff16] > 4) (set regen F_zu) DOELSE (set regen F_ok)
Gruß Peter
Bei inc5 (fünf Werte auseinander) wäre: (52-45)/45=0,155 > 0,1 hätte also funktioniert.
Die Zeitintervalle sind hier größer als eine Minute, hier hätte schon ([TH_humidity:state:diff5] > 5) zugeschlagen, da 52-45=7 > 5
diff16 würde hier schon eine Zeitspanne von über einer halben Stunde bedeutet.
Dank Damian,
habe jetzt die Variante
diff5 >5
eingestellt und werde berichten.
Gruß Peter
Ich habe mir den heutigen Tag bei uns genauer angeschaut, es ist ein typischer Aprilwettertag mit kurzen Regenfällen. Ein steiler Anstieg von über 5 % in 15 Minuten lässt vermutlich auf Regen schließen (siehe Anhang).
Edit:
Wenn in der gleichen Zeitspanne (hier 15 Minuten) auch noch die Temperatur um 0,5 Grad fällt (and [Sensor:temperature:diff5] < -0.5), wird die Annahme zusätzlich bekräftigt (siehe Anhang). Wie es sich im Sommer mit dem Wetterumschwung verhält, müsste man zunächst beobachten und auswerten. Man könnte sogar nur mit einem Temperatur- und Feuchtigkeitssensor vermutlich ein Gewitter bzw. Unwetter erkennen (hier dürften die Anstiege/Abfälle entsprechend höher ausfallen). Die Wetterexperten werden selbstverständlich noch andere Sensoren zur Wetterauswertung installiert haben ;)
ganz so comfortabel ist mein Bild nicht, aber man kann auch die Ausschläge erkennen.
Da man beim älterwerden nicht mehr an alles denkt (bei 3 Dachfenstern) wäre solch eine
Erinnerungshilfe schon praktisch - also optische und akustische Anzeige im FTUI.
Gruß Peter
ja, ich habe mir gerade noch weitere Plots bei mir angeschaut und konnte natürlich auch den Helligkeitsabfall durch die Regenwolken als zusätzliches Kriterium ausfindig machen, siehe Anhang. Es ist ein umgebauter Feuchtesensor, daher steht da noch humidity, obwohl es Helligkeit ist. Dass man auch die Plots der Photovoltaikanlage als zusätzliches Kriterium heranziehen kann - ist klar. All das lässt sich mit einer simplen diff-Angabe und and-Verknüpfung als Warnmeldung beim DOIF leicht umsetzen :)
zu der Auswertung der Helligkeitseinschränkung würde ich eher nicht tendieren da ja auch Wolken ohne Inhalt
vorüberziehen.
Die doch sehr zuverlässige und auch recht schnelle Änderung der Luftfeuchtewerte des HM-WDS10-TH-O
haben mich schon sehr überzeugt und wenn das nun mit einer der beiden Varianten "diff" bzw. "inc" funktioniert,
werde ich sehr happy sein.
Bin jetzt gerade auf der Suche wie die Meldung auch an unsere beiden Smartphons weitergebe wenn wir
demnächst (Anfang Mai) im angrenzenden Tochterhäusle unseren Enkel betreuen dürfen.
Gruß Peter
Zitat von: Peter aus Calw am 25 März 2019, 20:07:09
zu der Auswertung der Helligkeitseinschränkung würde ich eher nicht tendieren da ja auch Wolken ohne Inhalt
vorüberziehen.
Klar, aber wenn Feuchtezunahme (als Regenanzeichen), dann muss Helligkeit in dieser Zeit abnehmen: helligkeit:diff2 < 0 oder deine Wattzahl vom Dach abnehmen, daher nur als zusätzlichen UND-Verknüpfung.
Zitat
Die doch sehr zuverlässige und auch recht schnelle Änderung der Luftfeuchtewerte des HM-WDS10-TH-O
haben mich schon sehr überzeugt und wenn das nun mit einer der beiden Varianten "diff" bzw. "inc" funktioniert,
werde ich sehr happy sein.
Bin jetzt gerade auf der Suche wie die Meldung auch an unsere beiden Smartphons weitergebe wenn wir
demnächst (Anfang Mai) im angrenzenden Tochterhäusle unseren Enkel betreuen dürfen.
Gruß Peter
Ich habe bei mir pushbullet installiert, klappt sehr gut und kostet nichts.
Hallo Damian,
habe die letzten Stunden versucht mich mit pushbullet bekannt zu machen.
Das ist für mich schon etwas anstrengend, eine APP auf dem Smartphon ist zwar installiert - auch auf meinem
WIN 10 PC ist nun eine, in pushbullet.com bin ich mit meinem google-Konto auch bekannt,aber mit den notwendigen
API-Key wird es schon beschwerlich.
Mache aber morgen Abend wieder weiter.
Gruß und gute Nacht von Peter
Hallo Damian,
habe es geschafft :D
kann von FHEM Nachrichten an Smartphon und WIN 10 PC senden (gleichzeitig oder einzeln)
Danke für den Tipp ! :D :D :D
Gruß Peter
Zitat von: Peter aus Calw am 26 März 2019, 19:55:57
Hallo Damian,
habe es geschafft :D
kann von FHEM Nachrichten an Smartphon und WIN 10 PC senden (gleichzeitig oder einzeln)
Danke für den Tipp ! :D :D :D
Gruß Peter
ja, das freut mich. Jetzt muss nur noch Regen kommen, damit du deine Warnung auch testen kannst :)
Hey,
ich hab ja gelesen, das die avg funktionen oder so nur auf spezielle Werte gesetzt werden.
Wäre es dann für allgemeinere Dinge ein DOIF_Readings so einzusetzen, das die Werte für die Readings erstellt werden?
attr bla DOIF_Readings Duenger_DEVICE:[$DEVICE:Fertility:med3]
und eine Verständnissfrage, was müsste ich verwenden, damit ich herausfinde, ob wie bei wait z.B. 3x der gleiche Wert eintrifft? unabhängig von der Pull-Intervallszeit? also mein einen Sensor frag ich 5-Minütlich ab, den anderen nur alle 20 Minuten?
Vielen dank für die Ganzen Funkionen im DOIF..
Zitat von: kotaro am 23 April 2019, 12:11:03
Hey,
ich hab ja gelesen, das die avg funktionen oder so nur auf spezielle Werte gesetzt werden.
Wäre es dann für allgemeinere Dinge ein DOIF_Readings so einzusetzen, das die Werte für die Readings erstellt werden?
attr bla DOIF_Readings Duenger_DEVICE:[$DEVICE:Fertility:med3]
und eine Verständnissfrage, was müsste ich verwenden, damit ich herausfinde, ob wie bei wait z.B. 3x der gleiche Wert eintrifft? unabhängig von der Pull-Intervallszeit? also mein einen Sensor frag ich 5-Minütlich ab, den anderen nur alle 20 Minuten?
Vielen dank für die Ganzen Funkionen im DOIF..
1) Das Triggern auf verschiedene Devices über $DEVICE dürfte nicht funktionieren. Die neuen Funktionen arbeiten mit konkreten Readings und damit auch mit konkreten Devices.
2) Man könnte mit Hilfe von Instanzvariablen im Perl-Mode definieren:
DOIF
init {$_last=[?<mydevice>:<myreading>];$_count=0;}
{if ([<mydevice>:<myreading>] == $_last) {
$_count++;
if ($_count == 3) {
set_fhem"....";
$_count =0;
}
} else {
$_count=0;
}
$_last=[<mydevice>:<myreading>]
}
Ich kram diesen Thread heraus - wegen einer Frage bezüglich der :diff Funktion mit Zeiten. Ich habe die suche bemüht, aber nichts finden können. -.- (wenn es schon einen Thread dazu gibt bitte einen Link zur Verfügung stellen)
Folgendes habe ich vor: Abends wird ein Badfenster zum Lüften geöffnet und gern vergessen. Um dies gerade im Winter zu verhindern sende ich eine Nachricht an eine Enigma2 Box. Das funktioniert. Nun würde ich das gern smarter machen, da es gerade im Herbst und Frühling durchaus noch schöne Tage gibt bei denen das Fenster länger aufbleiben kann. Dann drückt man die Nachricht weg - und aus den Augen, aus dem Sinn. ::)
Ich möchte nun, dass die Nachricht gesendet wird wenn entweder eine Differenz oder die maximale Zeit erreicht wird, nachdem das Fenster geöffnet worden ist. Mein DOIF sieht derzeit so aus:
(([fenster:state] eq "open")
and ([enigma2:state] eq "on"))
(set enigma2 msg info 5 "Fenster ist noch auf!")
Mit wait 720 und do resetwait.
Mit :diff hab ich mir das so vorgestellt:
(([fenster:state] eq "open")
and ([sensor:temperature:diff3] > 5)
and ([enigma2:state] eq "on"))
(set enigma2 msg info 5 "Fenster ist noch auf!")
Meines Verständnisses nach wirkt sich wait "nur" auf die Wartezeit, bis der Befehl (cmd_1) ausgeführt wird, aus - verzögerte Ausführung also.
Hätte demnach also eine verzögernde Wirkung auf die Ausführung nachdem die Differenz überschritten ist. Allerdings möchte ich die vergangene Zeit mit als weitere Bedingung einbeziehen - mit pseudo code ungefähr so:
(([fenster:state] eq "open")
and (([sensor:temperature:diff3] > 5) or (time_difference > 10))
and ([enigma2:state] eq "on"))
(set enigma2 msg info 5 "Fenster ist noch auf!")
Über einen Denkanstoß wäre ich dankbar.
Ich hatte da mal etwas Ähnliches gebastelt, vielleicht kannst du es für deinen Anwendungsfall gebrauchen:
defmod di_Fenster_Bad_Ansage DOIF subs {\
sub send_alexa {\
my ($dev,$text,$volume)=@_;;\
$volume=20 if (!defined ($volume));;\
fhem("attr $dev speak_volume $volume");;\
fhem("set $dev speak $text");;\
}\
}\
\
{if ([$SELF:increase]) {send_alexa("echo_Bad","Bitte Fenster öffnen");;set_State("Ansage Öffnen")}}\
{if ([BadFenster:state] eq "open") {set_Reading ("temp",ReadingsVal("TH_Bad_HM","measured-temp",0));;set_State("Fenster geöffnet")}}\
{if ([$SELF:cold]) {send_alexa("echo_Bad","Bitte Fenster schließen");;set_State("Ansage Schließen")}}
attr di_Fenster_Bad_Ansage DOIF_Readings increase: [?BadFenster] eq "closed" and [TH_Bad_HM:humidity:diff] > 5,\
cold:[?BadFenster] eq "open" and ([$SELF:temp] - [TH_Bad_HM:measured-temp]) > 0.5
Hi,
soweit ich das wait verstanden habe, und es auch im Commandref steht, wird nach einem Wait der Timer abgebrochen, wenn ein anderer Fall wahr wird. --> Hier wäre eine Kontrolle, ob ein DOELSE ausgeführt wird (ohne Befehle - Sichtbar an cmd_2) und dadurch nicht ausgeführt wird.
Zitat von: yersinia am 21 Mai 2020, 14:32:07
Mit :diff hab ich mir das so vorgestellt:
(([fenster:state] eq "open")
and ([sensor:temperature:diff3] > 5)
and ([enigma2:state] eq "on"))
(set enigma2 msg info 5 "Fenster ist noch auf!")
Meines Verständnisses nach wirkt sich wait "nur" auf die Wartezeit, bis der Befehl (cmd_1) ausgeführt wird, aus - verzögerte Ausführung also.
Hätte demnach also eine verzögernde Wirkung auf die Ausführung nachdem die Differenz überschritten ist. Allerdings möchte ich die vergangene Zeit mit als weitere Bedingung einbeziehen - mit pseudo code ungefähr so:
(([fenster:state] eq "open")
and (([sensor:temperature:diff3] > 5) or (time_difference > 10))
and ([enigma2:state] eq "on"))
Letzte Änderung: Heute um 10:17:28
+ Erweiterte Optionen...
Shortcuts: mit Alt+S Beitrag schreiben oder Alt+P für Vorschau
(set enigma2 msg info 5 "Fenster ist noch auf!")
Über einen Denkanstoß wäre ich dankbar.
Ich würde einfach ein anderen DOELSEIF fall einfügen
([?fenster:state] eq "open"
and [?enigma2:state] eq "on"
and ([sensor:temperature:diff3] > 5 )
(set enigma2 msg info 5 "Fenster ist noch auf und ein Temperaturabfall >5°C")
(DOELSEIF[fenster:state] eq "open"
and [?enigma2:state] eq "on")
(set enigma2 msg info 5 "Fenster ist noch auf!")
attr xxx wait 10:720
Achso, ich weiß nicht, warum du so viele Klammern eingefügt hast, das ist eher notwendig um eigene Prioritäten mit or festzulegen.
Hier nochmal ein Hinweis, um es zu lesen https://wiki.fhem.de/wiki/DOIF/Operatorenrangfolge (https://wiki.fhem.de/wiki/DOIF/Operatorenrangfolge)
Hoffe es klappt so, und ich es richtig verstanden habe
Edit: hatte nochmal die Reihenfolge geändert und ? vor einigen Werten gesetzt, da diese doch kein Trigger darstellen sollen, das DOIF zu triggern.
Danke kotaro, das hat geholfen. Ich habe das DOIF umgebaut und werde Testen. :)
Zitat von: kotaro am 22 Mai 2020, 10:14:10Achso, ich weiß nicht, warum du so viele Klammern eingefügt hast, das ist eher notwendig um eigene Prioritäten mit or festzulegen.
Hier nochmal ein Hinweis, um es zu lesen https://wiki.fhem.de/wiki/DOIF/Operatorenrangfolge (https://wiki.fhem.de/wiki/DOIF/Operatorenrangfolge)
Das nutze ich bezüglich der Übersichtlichkeit - insbesondere das Synthax-Highlighting. Bei der UND-Verknüpfung benötige ich das eigtl nicht, stimmt.
Danke auch für den Hinweis mit dem
?, das wusste ich noch nicht. :)
Zitat von: Christoph Morrison am 16 Januar 2019, 18:08:54
Hallo Damian,
ohne diesen Thread vorher gelesen zu haben, hatte ich mir just heute DOIF um den Median erweitert, einen Patch findest hier (https://bitbucket.org/christoph-morrison/fhem-patches/raw/master/FHEM/98_DOIF.pm/ahphei9Mu7.patch).
Gruß
Christoph
Der Median bei Aggregationsfunktionen ist jetzt in der aktuellen DOIF-Version drin: siehe https://fhem.de/commandref_DE.html#DOIF_aggregation
Danke dir :)
Hallo,
ich bekomme mit folgender Def einen Fehler im event_Readings
avg_Cpu_Prozent:[sysmon:Cpu_Prozent:avg2],\
avg_Cpu_Temperatur:[sysmon:Cpu_Temperatur:avg2]
Fehler error in event_Readings \ avg_Cpu_Temperatur:[sysmon:Cpu_Temperatur:avg2], wrong reading specification for: \ avg_Cpu_Temperatur
Vermutlich passt die ,/ nicht.
Mit einem , schluckt er es aber der zweite Wert wird nicht gemittelt. Hier wird er ohne zu mitteln nur der letzte Wert übernommen. Der erste Wert wird aber gemittelt. Was mach ich den falsch?
Zitat von: neyzen am 08 Februar 2021, 00:45:28
Hallo,
ich bekomme mit folgender Def einen Fehler im event_Readings
avg_Cpu_Prozent:[sysmon:Cpu_Prozent:avg2],\
avg_Cpu_Temperatur:[sysmon:Cpu_Temperatur:avg2]
Fehler error in event_Readings \ avg_Cpu_Temperatur:[sysmon:Cpu_Temperatur:avg2], wrong reading specification for: \ avg_Cpu_Temperatur
Vermutlich passt die ,/ nicht.
Mit einem , schluckt er es aber der zweite Wert wird nicht gemittelt. Hier wird er ohne zu mitteln nur der letzte Wert übernommen. Der erste Wert wird aber gemittelt. Was mach ich den falsch?
Im Editor des Attributes werden keine \ eingegeben, dass wir ja gerade bemängelt.
Dann werde ich wohl zwei DOIF`s erstellen für jeden einzelnen Mittelwert :-\
Zitat von: neyzen am 08 Februar 2021, 16:00:16
Dann werde ich wohl zwei DOIF`s erstellen für jeden einzelnen Mittelwert :-\
Wozu?
avg_Cpu_Prozent:[sysmon:Cpu_Prozent:avg2],
avg_Cpu_Temperatur:[sysmon:Cpu_Temperatur:avg2]
Sollte im Attribut-Feld funktionieren (ohne \)
Ja das aktzeptiert er ja,nur wird der zweite wert
avg_Cpu_Prozent:[sysmon:Cpu_Prozent:avg2],
avg_Cpu_Temperatur:[sysmon:Cpu_Temperatur:avg2]
nicht gemittelt. Hier wird er einfach von dem reading so übernommen wie er ausgegeben wird.
Der erste wird aber gemittelt.
Bei mir funktioniert es:
Internals:
CFGFN
DEF ##
FUUID 60217791-f33f-c0d4-cc07-18d3dcd4a49987dc
MODEL FHEM
NAME di_avg
NOTIFYDEV test,global
NR 5120
NTFY_ORDER 50-di_avg
STATE initialized
TYPE DOIF
VERSION 22913 2020-10-04 21:46:02
READINGS:
2021-02-08 18:42:52 av1 2
2021-02-08 18:43:32 av2 3.5
2021-02-08 18:40:33 cmd 0
2021-02-08 18:40:33 mode enabled
2021-02-08 18:40:33 state initialized
getestet mit:
setreading test r1 2
setreading test r3 3
setreading test r3 4
Jetzt habe ich mal ein dummy mit 2 verschiedenen readings gesetzt so wie in deinem Beispiel. Hier wird genau für beide auch der Mittelwert gebildet. Aber beim tatsächlichen reading geht das beim zweiten nicht. Er übernimmt weiter einfach den letzten reading. Auch wenn ich avg3 mache,selbes Problem. Ich kanns nicht erklären.
Ich hab ein zweites DOIF erstellt mit dem gleichen event_readings. Da wird dann der erste nicht gemittelt aber dafür der zweite :)
?
Zitat von: neyzen am 08 Februar 2021, 19:45:34
Jetzt habe ich mal ein dummy mit 2 verschiedenen readings gesetzt so wie in deinem Beispiel. Hier wird genau für beide auch der Mittelwert gebildet. Aber beim tatsächlichen reading geht das beim zweiten nicht. Er übernimmt weiter einfach den letzten reading. Auch wenn ich avg3 mache,selbes Problem. Ich kanns nicht erklären.
Ich hab ein zweites DOIF erstellt mit dem gleichen event_readings. Da wird dann der erste nicht gemittelt aber dafür der zweite :)
?
ja, ich konnte das Problem nachstellen, es passiert immer dann, wenn die Readings in einem Event-Block kommen. Ich werde es korrigieren.
Bei mir sind es userReadings die ich gerne mitteln möchte. Vielleicht brauchen die die eine weile bis sie berechnet werden.
Danke dir
Ich habe es korrigiert.
Teste mal die angehängte Version.
Edit: Version wurde eingecheckt
Hi,
jetzt werden beide readings gemittelt.
Danke dir :)
Zitat von: neyzen am 10 Februar 2021, 11:08:14
Hi,
jetzt werden beide readings gemittelt.
Danke dir :)
OK. Ich habe die neue Version gerade eingecheckt.