Hallo,
ich habe jetzt die commandref bzgl. "event-aggregator" durchgelesen, aber mein event-aggregator funktioniert irgendwie nicht.
was ich habe:
Einen Aeotec ZW100 Sensor - von dem ich die Anzahl der Bewegungsmeldungen innerhalb einer Zeit zählen will.
...bzw. eigentlich will ich sie aufintegrieren ... - aber Zählen ist einfacher zu verifizieren.
in der Commandref zu 'attr event-aggregator' steht - dass man idealerweise ein userReading dazu nehmen sollte.
gemacht, getan - GEHT auch wie erwartet:
attr SENSOR_2 userReadings alarmTime:.*alarm.*Motion.* {ReadingsTimestamp("$NAME","alarm",99999);; }, MotionFreq:basicSet.* \
{ if (ReadingsNum("$NAME","basicSet",0) > 0) { Log 1,"uR: $NAME = 1.0";; return 1.0;;} else {Log 1,"uR: $NAME = 0.0";; return 0.0;;} }
...und diese zwei userReadings funktionieren auch soweit - laut Log-Meldungen - insbes. das "MotionFreq" Reading:
2019.12.14 20:04:18 1: uR: SENSOR_2 = 1.0
2019.12.14 20:06:02 1: uR: SENSOR_2 = 0.0
2019.12.14 20:07:13 1: uR: SENSOR_2 = 1.0
2019.12.14 20:07:53 1: uR: SENSOR_2 = 0.0
2019.12.14 20:07:53 1: uR: SENSOR_2 = 0.0
2019.12.14 20:07:53 1: uR: SENSOR_2 = 0.0
2019.12.14 20:08:13 1: uR: SENSOR_2 = 1.0
2019.12.14 20:08:38 1: uR: SENSOR_2 = 0.0
2019.12.14 20:08:43 1: uR: SENSOR_2 = 1.0
2019.12.14 20:10:28 1: uR: SENSOR_2 = 0.0
2019.12.14 20:12:17 1: uR: SENSOR_2 = 1.0
DIES funktioniert wirklich, weil ich es mit einem Notify kontrolliert habe:
defmod ntf_sensor2_motionFreq notify SENSOR_2:MotionFreq.* { Log 1,"Notify MotionFreq: $NAME $EVENT";;}
Output im Log FAST wie erwartet: (man sieht, es sind INT nicht Float Werte - macht nix)
2019.12.14 20:50:48 1: uR: SENSOR_2 = 1.0
2019.12.14 20:50:48 1: Notify MotionFreq: SENSOR_2 MotionFreq: 1
Soweit - so gut :-)
Dann setze ich auf 'MotionFreq' einen event-aggregator - und es passiert NIX mehr :-(
...zuerst ganz banal - er soll zählen, wieviele Events es innerhalb von 300 Sekunden es gab:
attr SENSOR_2 event-aggregator MotionFreq::none:count:300:10
...leider will das Teil nicht mal zählen - und auch der Notify 'sieht' nie wieder ein Event von DEM userReading :-(
da die commandref nicht "lügt" - muss ich irgendwas hier ziemlich falsch machen - aber WAS?
Wo hast Du "count" in den Methoden gesehen?
Zitat von: amenomade am 14 Dezember 2019, 22:10:03
Wo hast Du "count" in den Methoden gesehen?
'count' sollte doch die 'function' sein, weil 'interval' leer ist, 'none' ist die Methode:
attr SENSOR_2 event-aggregator MotionFreq::none:count:300:10
... nochmal genau nachgesehen --- das WIKI sagt, dass es 'count' gibt:
https://wiki.fhem.de/wiki/Event-aggregator
Allerdings - die commandref erwähnt das in der Tat nicht.
die syntax aus der commandref: reading:interval:method:function:holdTime
OK - dann, gleiches Problem mit der integral Funktion.
'interval' darf ja leer bleiben ("With holdTime defined the interval can be kept undefined"),
weil ich ja 'holdTime' verwenden will (sonst wuerde er ja nur summieren, das waere ja praktisch 'count' :-) )
'const' als 'method' --- 'integral' als 'function' - und 600 Sek als 'holdTime':
attr SENSOR_2 event-aggregator MotionFreq::const:integral:600
...geht genausowenig - bzw. macht nicht das was ich erwarte :-( - und das Reading bleibt auf 0.
Zeig mal ein "list" vom Device bitte
Du hast mind. ein Parameter zu viel.
MotionFreq::none:count:300:10
reading:interval:method:function:holdTime
Steht nichts in der Log?
hier in aller Pracht:
Internals:
DEF cff0272b 25
FUUID 5d1a1c38-f33f-431b-666d-45f4a2bd6b1d28ad
IMAGE /fhem/deviceimages/zwave/ZC10-17115891
IODev ZSTICK
LASTInputDev ZSTICK
MSGCNT 1695
NAME SENSOR_2
NR 209
STATE configGroup1Interval 300
TYPE ZWave
ZSTICK_MSGCNT 1695
ZSTICK_RAWMSG 00040019053105050136
ZSTICK_TIME 2019-12-14 23:32:58
ZWaveSubDevice no
homeId cff0272b
isWakeUp
lastMsgSent 1576360994.9127
nodeIdHex 19
READINGS:
2018-12-17 23:18:05 CMD ZW_APPLICATION_UPDATE
2019-12-14 23:29:12 MotionFreq 0
2018-12-18 00:02:15 SEND_DATA failed:00
2019-12-07 07:11:16 UNPARSED COLOR_CONTROL 0133
2019-12-14 23:29:12 alarm HomeSecurity: Event cleared: Previous Events cleared
2019-12-14 23:28:48 alarmTime 2019-12-14 23:28:48
2019-11-21 16:35:28 alarmTypeSupported HomeSecurity
2018-12-17 23:10:04 assocGroup_1 Max 5 Nodes ZSTICK
2018-12-17 23:10:04 assocGroups 1
2019-12-14 23:29:12 basicSet 0
2019-11-21 16:56:48 battery 100 %
2019-11-21 16:56:48 batteryPercent 100
2019-11-21 16:56:48 batteryState ok
2019-11-21 16:34:33 configAwakeTimeout 15
2019-11-21 16:34:34 configBatteryReportingThreshold 10
2019-11-21 16:34:34 configCommandOptions BasicSet
2019-11-21 16:34:35 configCurrentPowerMode 2
2019-11-21 16:34:35 configEnableDisableLockConfiguration Disable
2019-11-21 16:34:36 configEnableDisableToSendAReportOn48 0
2019-11-21 16:34:36 configEnableMotionSensor EnabledLevel5
2019-11-21 16:34:36 configGetTheOutOfLimitStateOfThe61 0
2019-11-22 17:29:41 configGroup1Interval 120
2019-11-21 16:34:39 configGroup1Reports 240
2019-11-21 16:34:39 configGroup2Interval 3600
2019-11-21 16:34:40 configGroup2Reports 0
2019-11-21 16:34:40 configGroup3Interval 3600
2019-11-21 16:34:41 configGroup3Reports 0
2019-11-21 16:34:41 configHumidityCalibration 3
2019-11-21 16:34:42 configHumidityReportingThreshold 3
2019-11-21 16:34:42 configLEDBlinkingReport EnableLEDBlinking
2019-11-21 16:34:43 configLowBattery 20
2019-11-21 16:34:43 configLowTempAlarm Enabled
2019-11-21 16:34:44 configLuminanceCalibration 0
2019-11-21 16:34:44 configLuminanceReportingThreshold 3
2019-11-21 16:34:45 configOnTime 15
2019-11-21 16:34:45 configReportOnlyOnThresholds Enabled
2019-11-21 16:34:46 configSetTheLowerLimitValueOf50 256
2019-11-21 16:34:46 configSetTheLowerLimitValueOf56 4
2019-11-21 16:34:47 configSetTheLowerLimitValueOfHumidity52 50
2019-11-21 16:34:49 configSetTheLowerLimitValueOfLighting54 100
2019-11-21 16:34:49 configSetTheRecoverLimitValueOf57 5121
2019-11-21 16:34:50 configSetTheRecoverLimitValueOf58 5
2019-11-21 16:34:50 configSetTheRecoverLimitValueOf59 10
2019-11-21 16:34:50 configSetTheRecoverLimitValueOf60 2
2019-11-21 16:34:51 configSetTheUpperLimitValueOf49 18350336
2019-11-21 16:34:51 configSetTheUpperLimitValueOf55 8
2019-11-21 16:34:52 configSetTheUpperLimitValueOfHumidity51 60
2019-11-21 16:34:53 configSetTheUpperLimitValueOfLighting53 1000
2019-11-26 13:24:51 configTemperatureCalibration 61185
2019-11-21 16:34:54 configTemperatureReportingThreshold 1310976
2019-11-21 16:34:54 configTemperatureScale Celsius
2019-11-21 16:34:55 configUVReportingThreshold 2
2019-11-21 16:34:55 configUltravioletCalibration 0
2019-11-21 16:34:56 configWakeUp10MinutesOnPowerOn EnableFr
2019-12-14 23:32:58 dewPoint 9.58
2019-12-14 23:32:58 humidity 54 %
2019-12-14 23:32:56 luminance 22 Lux
2019-10-10 22:01:57 model AEON Labs ZW100 MultiSensor 6
2019-10-10 22:01:57 modelConfig aeotec/zw100.xml
2019-10-10 22:01:57 modelId 0086-0002-0064
2019-10-15 20:35:40 neighborList STECKER_1 ALWAYS_ON ZBULB1 DIMMER_OFFICE THERMOSTAT_OFFICE1 THERMOSTAT_OFFICE2
2019-11-21 16:38:47 neighborUpdate done
2019-11-21 16:33:54 powerlvl current 0 remain 0
2019-11-21 16:33:45 powerlvlTest node 14 status 1 frameAck 100
2019-10-06 17:06:25 reportedState closed
2019-10-26 05:49:52 seismicIntensity 0 mercalli
2019-11-22 17:29:56 state configGroup1Interval 300
2019-12-14 23:32:58 temperature 19.1 C
2019-12-14 23:03:15 timeToAck 0.223
2019-12-14 23:03:15 transmit OK
2019-12-14 23:32:56 ultraviolet 0 UV
2019-10-10 23:06:05 version Lib 3 Prot 4.54 App 1.13 HW 100 FWCounter 0
2019-12-14 23:03:12 wakeup notification
Attributes:
IODev ZSTICK
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY MARK
comment 1
devStateIcon .*:temperature_humidity
event-aggregator MotionFreq::const:integral:600
icon temperature_humidity
neighborListPos 104.69,351.19
room OFFICE,ZWave
userReadings alarmTime:.*alarm.*Motion.* {ReadingsTimestamp("$NAME","alarm",99999); }, MotionFreq:basicSet.*
{ if (ReadingsNum("$NAME","basicSet",0) > 0) { Log 1,"uR: $NAME = 1.0"; return 1.0;} else {Log 1,"uR: $NAME = 0.0"; return 0.0;} }, dewPoint:temperature.* {urDewpoint($name)}
vclasses ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2
Zitat von: amenomade am 14 Dezember 2019, 23:30:40
Du hast mind. ein Parameter zu viel.
MotionFreq::none:count:300:10
reading:interval:method:function:holdTime
ja, bei DER Version mit 'count' - in der Tat - aber akt. mit 'integral' sollte es korrekt sein:
event-aggregator MotionFreq::const:integral:600Zitat
Steht nichts in der Log?
wie schon geschrieben: nein - also nix offensichtliches, keine Fehler etc.
die debug-Log-Meldungen des userReadings kommen nach wie vor im fhem-Log.
und im Sensor-Log-File - sieht alles ok aus, bis auf den Punkt, dass keine Updates von diesem userReading 'MotionFreq' erfolgen.
die anderen userReadings werden ja generiert. (z.B. 'alarmTime' und 'dewPoint' )
wenn ich das event-aggregator Attribut loesche, dann funktioniert der Notify auf das 'MotionFreq' Reading sofort wieder.
(und es kommen auch im Sensor_log-file die entsprechenden Meldungen)
ist der event-aggregator gesetzt - passiert nix mehr. :-(
Hmmm komisch. Ich kann das nicht reproduzieren.
Hast Du genüge Events auf basicSet, damit die Integrale auf der Periode nicht 0 ist?
Kannst Du bei dir mit folgendem dummy testen?
defmod SENSOR_2_test dummy
attr SENSOR_2_test event-aggregator MotionFreq::const:integral:600
attr SENSOR_2_test readingList basicSet
attr SENSOR_2_test setList basicSet:slider,0,1,100
attr SENSOR_2_test userReadings MotionFreq:basicSet.* { if (ReadingsNum("$NAME","basicSet",0) > 0) { Log 1,"uR: $NAME = 1.0";; return 1.0;;} else {Log 1,"uR: $NAME = 0.0";; return 0.0;;} }
attr SENSOR_2_test webCmd basicSet
Und bei Gelegenheit, zeig mal das Ergebnis von:
{ Dumper($defs{"SENSOR_2"}{READINGS}{"MotionFreq"}{".ts"}) } in der Kommandozeile
{ Dumper($defs{"SENSOR_2"}{READINGS}{"MotionFreq"}{".ts"}) }
$VAR1 = bless( {
'_M' => '222145.995299021',
'_S' => '535654274279.998',
'_t' => '1576368930.00505',
'_t0' => '1576368441.61963',
'_v' => 10000,
'autoreset' => undef,
'count' => 7,
'holdTime' => 600,
'integral' => '1332875.97179413',
'lost' => 0,
'max' => 10000,
'mean' => '2729.1477529466',
'median' => undef,
'method' => 'const',
'min' => 0,
'n' => 6,
'sd' => '4021.10899610649',
't' => '1576368930.00505',
't0' => '1576368441.61963',
'tSeries' => [
'1576368441.61963',
'1576368492.06582',
'1576368493.26136',
'1576368518.90147',
'1576368864.72274',
'1576368921.92403',
'1576368930.00505'
],
'v' => 10000,
'v0' => 10000,
'vSeries' => [
10000,
0,
10000,
0,
10000,
0,
10000
]
}, 'TimeSeries' );
Zitat von: amenomade am 15 Dezember 2019, 00:13:58
Kannst Du bei dir mit folgendem dummy testen?
defmod SENSOR_2_test dummy
attr SENSOR_2_test event-aggregator MotionFreq::const:integral:600
attr SENSOR_2_test readingList basicSet
attr SENSOR_2_test setList basicSet:slider,0,1,100
attr SENSOR_2_test userReadings MotionFreq:basicSet.* { if (ReadingsNum("$NAME","basicSet",0) > 0) { Log 1,"uR: $NAME = 1.0";; return 1.0;;} else {Log 1,"uR: $NAME = 0.0";; return 0.0;;} }
attr SENSOR_2_test webCmd basicSet
verhaelt sich bei mir wie 'bekannt':
a.) basicSet auf 100 - und 'set'
b.) F5 - zum web-reload - und MotionFreq steht auf '1'
c.) basicSet auf 0 - 'set' ---> reload -> MotionFreq ist '0'
...es gibt keine floating-point Zwischenwerte ... - also OK - alles auf 10k skalieren
dann sollten doch 4 Stellen fuer Integer Arithmetik uebrig sein :-)
mit 10000 und 0 probiert - gleiches Verhalten. nur 10k oder 0 - keine Zahl dazwischen.
im webif - wenn ich die 'raw definition' ein/aus-klappe - sehe ich den 'setstate' der Variablen.
die folgen 100% zeitsynchron einander ...
und das Reading loest keine Events/Updates im webif aus - die web-seite bleibt gleich.
erst ein 'Reload' - updated den Zeitstempel vom Reading - aber der Wert ist nur 10k oder 0.
(beim 'basicSet' Reading - sobald ich 'set' mache - wird die Zeit des Readings geupdated und rot gefaerbt, ohne reload)
... er integriert ueber die Zeit nicht.
und wenn ich die holdTime weglasse - muesste er doch hochzaehlen - macht er auch nicht.
der Zustand folgt einfach nur dem basicSet.
der fhem-update-check sagt 'nothing to do' - weil ich das schon heute vormittag gemacht hatte ;-)
Zitat'integral' => '1332875.97179413'
Also... wird doch kalkuliert.
Zitat 'tSeries' => [
'1576368441.61963',
'1576368492.06582',
'1576368493.26136',
'1576368518.90147',
'1576368864.72274',
'1576368921.92403',
'1576368930.00505'
],
'vSeries' => [
10000,
0,
10000,
0,
10000,
0,
10000
]
und er hat mehrere Werte mit unterschiedlichen Timestamps gespeichert
Dein Problem ist wahrscheinlich eher ein Problem von Aktualisierung der Weboberfläsche.
Nw. hast Du mit meiner Definition ein slider neben dem Name, um direkt den Wert zu setzen. basicSet und MotionFreq sollten sofort aktualisieren.
Wie ist das longpoll Attribut auf deiner FHEMWEB (i.d.R. Name=WEB) Instanz gesetzt?
Zitat von: amenomade am 15 Dezember 2019, 01:27:10
Also... wird doch kalkuliert.und er hat mehrere Werte mit unterschiedlichen Timestamps gespeichert
ACK! - das wuerde ich auch draus lesen :-)
Zitat
Dein Problem ist wahrscheinlich eher ein Problem von Aktualisierung der Weboberfläsche.
Nw. hast Du mit meiner Definition ein slider neben dem Name, um direkt den Wert zu setzen. basicSet und MotionFreq sollten sofort aktualisieren.
Wie ist das longpoll Attribut auf deiner FHEMWEB (i.d.R. Name=WEB) Instanz gesetzt?
vorher hatte ich longpoll gar nicht gesetzt. Laut Dok ist es dann aktiv.
dann habe ich mit 'attr WEB longpoll 1' probiert - kein Unterschied im UI.
dann mit 'attr WEB longpoll 0' - da updated er ja im webBrowser das basicSet nicht, wenn ich den Slider via 'set' setze.
... habe ich 'longpoll 1' - dann ist es wieder OK.
...das Reading "MotionFreq" muesste aber doch den Wert aus 'integral' aus dem Dumper-Output haben - richtig ?
und events generieren, auf die ein Notify triggert...
Zitat von: sz_wolfi am 15 Dezember 2019, 01:56:13
...das Reading "MotionFreq" muesste aber doch den Wert aus 'integral' aus dem Dumper-Output haben - richtig ?
und events generieren, auf die ein Notify triggert...
Sollte, ja. Bzw. vielleicht nicht genau den gleichen Wert sondern den vorherign. Aber doch was.
Mir kommt im Moment keine neue Idee
Zitat von: amenomade am 15 Dezember 2019, 02:12:14
Sollte, ja. Bzw. vielleicht nicht genau den gleichen Wert sondern den vorherign. Aber doch was.
Mir kommt im Moment keine neue Idee
Danke erstmal - soweit ist mir jetzt klar, dass es 'im Prinzip' korrekt ist/war.
Muss irgendwas spez. an meiner Installation sein ... - zumindest DAS weiss ich jetzt.
Ich werde mir mal 'ne neue VM (centos-7.5) aufsetzen - und mit paar Dummies da weiter testen.
... ich update diesen Thread, wenn ich dazu gekommen bin :-)
1. Update: frische VM, neues fhem-5.9.tar -> SENSOR_2_test dummy: funktioniert ! - integrale werden angezeigt. - GEHT!
... jetzt muss ich diese 'funktionierende' fhem-instanz auf die alte VM dazu packen - um es weiter einzugrenzen. :-(
(liegt's an fhem - oder liegt's am perl ? - das OS ist ja beides mal gleich - bzw. 'fast gleich')
2nd Update: frisches fhem-5.9 auf der gleichen VM geht AUCH ! - liegt also nicht am perl.
ich habe als "Produktions"-Release - mit fhem-5.7 angefangen - und das dauernd upgedatet.
(ein update-check sagt 'nothing to do ...')
scheint aber nicht das gleiche zu sein wie ein 'frisches' 5.9 :-(
3. Update:
fhem 5.9 'stock' (also das tar.gz ohne Updates) - funktioniert - und wenn ich da drin 'update' machen (also: 16.12.2019) -> geht's wieder NICHT mehr!
wird (fuer mich) akt. etwas zu aufwaendig, das Update (was ja nicht gerade klein ist) weiter zu zerpflücken :-(
... aber soweit kann ich es rel. sicher eingrenzen.
Ich habe nicht alles gelesen aber kannst du mal probieren folgendes zurückzubauen?
https://forum.fhem.de/index.php/topic,92841.0.html (https://forum.fhem.de/index.php/topic,92841.0.html)
Dieser Patch wurde vor kurzem eingecheckt und hat jetzt vielleicht doch andere Auswirkungen als gedacht.
Zitat von: mumpitzstuff am 16 Dezember 2019, 17:47:59
Ich habe nicht alles gelesen aber kannst du mal probieren folgendes zurückzubauen?
https://forum.fhem.de/index.php/topic,92841.0.html (https://forum.fhem.de/index.php/topic,92841.0.html)
Dieser Patch wurde vor kurzem eingecheckt und hat jetzt vielleicht doch andere Auswirkungen als gedacht.
bingo!
fhem:/opt/fhem # diff -u fhem.pl-ORIG fhem.pl
--- fhem.pl-ORIG 2019-12-16 21:29:19.686210089 +0100
+++ fhem.pl 2019-12-16 21:31:42.283311657 +0100
@@ -4874,8 +4874,10 @@
} else {
require "TimeSeries.pm";
$ts = TimeSeries->new( { method => $method,
- autoreset=>(looks_like_number($duration) ? $duration:undef),
- holdTime =>(looks_like_number($holdTime) ? $holdTime:undef)});
+ autoreset => $duration,
+ holdTime => $holdTime } );
+# autoreset=>(looks_like_number($duration) ? $duration:undef),
+# holdTime =>(looks_like_number($holdTime) ? $holdTime:undef)});
$readings->{".ts"}= $ts;
# access from command line:
# { $defs{"myClient"}{READINGS}{"myValue"}{".ts"}{max} }
wenn ich die zwei Zeilen so zurückbaue - geht's wieder :-)
...jetzt habe ich noch einen weiteren kleinen Bug:
ich nehme diesen Dummy: --- Integral ueber 60 Sekunden:
defmod AGGR_test dummy
attr AGGR_test event-aggregator MotionFreq::const:integral:60
attr AGGR_test readingList basicSet
attr AGGR_test room TESTING
attr AGGR_test setList basicSet:slider,0,1,100
attr AGGR_test userReadings MotionFreq:basicSet.* { if (ReadingsNum("$NAME","basicSet",0) > 0) { Log 1,"uR: $NAME = 1";; return 1;;} else {Log 1,"uR: $NAME = 0";; return 0;;} }
attr AGGR_test webCmd basicSet
und dieses DOIF - um den Dummy - alle 5 sek umzuschalten:
defmod doif_half DOIF ( [+00:00:05] and [AGGR_test:basicSet] == 0 )\
( { Log 1,"doif_half: set to 1";;} set AGGR_test basicSet 1;;)\
DOELSEIF\
( [+00:00:05] and [AGGR_test:basicSet] == 1 )\
( { Log 1,"doif_half: set to 0";;} set AGGR_test basicSet 0;;)
attr doif_half disable 0
attr doif_half do always
attr doif_half room TESTING
...also - alle 5 Sek toggle zwischen 0 und 1
MEINE Erwartung waere - dass das Integral - ueber 60 Sek - immer '30' ist.
aber das Reading geht dauernd hoeher ... ist jetzt bei 299.x - also 300 !
äh - Moment - da war ja was vorher:
{ Dumper($defs{"AGGR_test"}{READINGS}{"MotionFreq"}{".ts"}) }
und schon kommt die Antwort: (nur der Anfang - langt aber um die Loesung zu sehen):
$VAR1 = bless( {
'_M' => '2.49998664259911',
'_S' => '789.285900270158',
'_t' => '1576531377.00512',
'_t0' => '1576530777.00487',
'_v' => 0,
'autoreset' => '',
'count' => 121,
>>>>>>> 'holdTime' => 600,
'integral' => '299.998397111893',
'lost' => 0,
... die 'holdTime' - kann man nicht mehr im laufenden Betrieb ändern - via 'attr'.
Klar, das WEB-interface zeigt den 'neuen' Wert an - ist aber 'fake news'. ;-)
war auf 600 - und hatte sie später via 'attr' auf 60 "geändert".
Da hilft kein 'attribut'-Delete ( und neu setzen ) - nur ein fhem-restart :-(
ABER:
fuer '600' Sek 'holdtime' - und 50% "Tastverhältnis" - ist das Integral dann mit ~300 vollkommen korrekt.
... meine "Wusel"-Frequenz-Berechnung sollte dann funktionieren :-)
Zitat von: sz_wolfi am 16 Dezember 2019, 21:35:16
bingo!
fhem:/opt/fhem # diff -u fhem.pl-ORIG fhem.pl
--- fhem.pl-ORIG 2019-12-16 21:29:19.686210089 +0100
+++ fhem.pl 2019-12-16 21:31:42.283311657 +0100
@@ -4874,8 +4874,10 @@
} else {
require "TimeSeries.pm";
$ts = TimeSeries->new( { method => $method,
- autoreset=>(looks_like_number($duration) ? $duration:undef),
- holdTime =>(looks_like_number($holdTime) ? $holdTime:undef)});
+ autoreset => $duration,
+ holdTime => $holdTime } );
+# autoreset=>(looks_like_number($duration) ? $duration:undef),
+# holdTime =>(looks_like_number($holdTime) ? $holdTime:undef)});
$readings->{".ts"}= $ts;
# access from command line:
# { $defs{"myClient"}{READINGS}{"myValue"}{".ts"}{max} }
wenn ich die zwei Zeilen so zurückbaue - geht's wieder :-)
Bei mir ebenso, nach zurückändern dieser beiden Zeilen, geht bei mir die Event-Aggregatoren wieder.
Ich habe auch die beiden Zeilen wieder zurück geändert, weil event-aggregator nicht mehr funktioniert hat.
Grüße
ergerd
Ich habe noch mal nachgesehen.
Wenn ich bei "median" für das Intervall eine ":0:" anstelle von "::" eintrage geht es mit der aktuellen fhem.pl wieder.
Für mich reicht das erst mal, ohne Änderungen an den Dateien vorzunehmen.
Seit meinem FHEM-Dezember-Update funktioniert meine event-aggregator Konfiguration ebenfalls nicht mehr.
Folgendes habe ich benutzt um bei einem Sensor Ausreißer auszuschließen:
attr Sensor event-aggregator Messwert::none:median:900
Nun werden die Sensorwerte nicht mehr geloggt.
Zitat von: stromer-12 am 29 Dezember 2019, 20:17:33
Ich habe noch mal nachgesehen.
Wenn ich bei "median" für das Intervall eine ":0:" anstelle von "::" eintrage geht es mit der aktuellen fhem.pl wieder.
Für mich reicht das erst mal, ohne Änderungen an den Dateien vorzunehmen.
Werde dies gleich mal testen...
Sag bitte Bescheid ob es dann wieder funktioniert. Falls ja, werde ich die Doku dazu anpassen. Der Patch sollte eigentlich eine nervige Fehlermeldung im Log beheben, hat aber anscheinend unvorhergesehene Auswirkungen.
Ich habe zwei Readings mit einem event-aggregator in einer Kommaseparierten Liste. Beim zweiten Reading in der Liste funktioniert die Null. Beim ersten scheint sich nichts zu ändern, hier greift die Konfiguration nicht.
Jetzt habe ich die fhem.pl zurückgeändert und die zwei Nullen wieder entfernt.
Melde mich sobald ich Ergebnisse habe...
":0:" oder ehemalige fhem.pl-Version scheint vom Ergebnis doch gleich zu sein.
In folgender Reihe sortiert die median-Funktion die 0.4 nicht mehr aus. Dies hat vor dem update noch funktioniert.
Das kann aber auch an was anderem liegen:
2019-12-29_20:53:45 0.4
2019-12-29_20:53:45 352.5
2019-12-29_20:53:45 352.7
2019-12-29_20:53:48 352.6
2019-12-29_20:58:47 0.4
2019-12-29_20:58:48 352.6
2019-12-29_20:58:48 352.7
2019-12-29_20:58:50 352.7
2019-12-29_21:03:50 0.4
2019-12-29_21:03:50 352.5
2019-12-29_21:03:50 352.9
2019-12-29_21:03:53 352.7
2019-12-29_21:08:52 0.4
2019-12-29_21:08:52 352.7
2019-12-29_21:08:53 352.6
2019-12-29_21:08:55 352.8
2019-12-29_21:13:54 0.4
2019-12-29_21:13:55 352.7
2019-12-29_21:13:55 352.6
2019-12-29_21:13:58 352.9
Hmm das ist tatsächlich eigenartig. Eigentlich sollte die 0.4 hier tatsächlich raus fliegen.
Ich schau mir erst mal das Problem mit :: und :0: noch mal genau an. Alles andere kann ich schlecht beurteilen, da ich nicht der Author des Event aggregators bin.
DOIF kann aber neuerdings auch sowas. Vielleicht liefert das ja bessere Ergebnisse.
Jetzt funktioniert mein event-aggregator wieder. Habe für alle drei voneinander abhängigen Readings (zwei davon userReadings) den Aggregator mit median definiert. Komisch, dass ein Reading allein nicht funktioniert.
Moin.
Ich schließ mich hier mal an:) Hatte das selbe Problem, nach einem Update (gerade eben) funktioniert es wieder.
Danke!