Hallo zusammen,
im Zuge einiger Systemtests ist mir bei einigen Modulen, u.A. bei HMNfo, aufgefallen, dass diese event-on-change-reading ignorieren. Mit anderen Worten, ich kann da eintragen was ich will, die Events kommen trotzdem:
Internals:
CHANGED
ERR__protoNames flur.klingelcontrol,flur.unten.licht,stube.licht
ERR_names stube.deckenfluter
I_HM_IOdevices system.hmlan,:ok
NAME system.hminfo
NR 29
STATE Empfang (dB): 59<:12 60>:23 80>:7 99>:0
TYPE HMinfo
Version 01
W__protoNames flur.klingelcontrol,flur.unten.licht,stube.licht,stube.steckdose.tv
CHANGETIME:
Helper:
Dblog:
Err_overheat:
Dblog:
TIME 1404763583.46111
VALUE on:1;
Err_overload:
Dblog:
TIME 1404763583.46111
VALUE on:1;
Readings:
2014-07-07 22:06:23 C_sumDefined entities:130 device:42 channel:108 virtual:1
2014-07-06 21:06:13 ERR__protocol ResndFail:3,CmdDel:3
2014-07-07 22:06:23 ERR_overheat on:1;
2014-07-07 22:06:23 ERR_overload on:1;
2014-06-25 20:55:52 I_actTotal alive:33 dead:0 unkn:0 off:0
2014-07-07 20:06:23 I_rssiMinLevel 59<:12 60>:23 80>:7 99>:0
2014-06-30 20:03:23 I_sum_battery ok:38;
2014-06-24 08:52:49 I_sum_sabotageError off:4;
2014-07-06 21:06:13 W__protocol Resnd:4
Helper:
autoUpdate 1800
Nb:
cnt 0
Attributes:
alias Homematic Info
autoUpdate 00:30
event-on-change-reading neinbittenicht
group System
room System
stateFormat Empfang (dB): I_rssiMinLevel
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update
Trotzdem kommt z.B.:
|| *TIMESTAMP* || *DEVICE* || *TYPE* || *EVENT* || *READING* || *VALUE* || *UNIT* ||
|| 2014-07-07 22:06:23 || system.hminfo || HMINFO || ERR_overload: on:1; || ERR_overload || on:1; || ||
|| 2014-07-07 22:06:23 || system.hminfo || HMINFO || ERR_overheat: on:1; || ERR_overheat || on:1; || ||
|| 2014-07-06 23:06:13 || system.hminfo || HMINFO || ERR_overload: on:1; || ERR_overload || on:1; || ||
|| 2014-07-06 23:06:13 || system.hminfo || HMINFO || ERR_overheat: on:1; || ERR_overheat || on:1; || ||
|| 2014-07-06 00:35:51 || system.hminfo || HMINFO || ERR_overload: on:1; || ERR_overload || on:1; || ||
|| 2014-07-06 00:35:51 || system.hminfo || HMINFO || ERR_overheat: on:1; || ERR_overheat || on:1; || ||
|| 2014-07-05 01:02:16 || system.hminfo || HMINFO || ERR_overload: on:1; || ERR_overload || on:1; || ||
|| 2014-07-05 01:02:16 || system.hminfo || HMINFO || ERR_overheat: on:1; || ERR_overheat || on:1; || ||
|| 2014-07-05 00:02:16 || system.hminfo || HMINFO || ERR__protocol: ResndFail:1,CmdDel:1 || ERR__protocol || ResndFail:1,CmdDel:1 || ||
|| 2014-07-05 00:02:16 || system.hminfo || HMINFO || W__protocol: Resnd:1 || W__protocol || Resnd:1 || ||
|| 2014-07-04 13:32:15 || system.hminfo || HMINFO || I_rssiMinLevel: 59<:13 60>:23 80>:5 99>:0 || I_rssiMinLevel || 59<:13 60>:23 80>:5 99>:0 || ||
|| 2014-07-04 09:02:15 || system.hminfo || HMINFO || I_rssiMinLevel: 59<:13 60>:22 80>:5 99>:0 || I_rssiMinLevel || 59<:13 60>:22 80>:5 99>:0 || ||
|| 2014-07-04 08:02:15 || system.hminfo || HMINFO || I_rssiMinLevel: 59<:13 60>:23 80>:4 99>:0 || I_rssiMinLevel || 59<:13 60>:23 80>:4 99>:0 ||
usw.
Openweather zeigt das gleiche Verhalten (hab ich schon im anderen Forum gepostet).
OK, ich könnte nun die anderen Attribute (z.B. sumError) ändern dann hab ich aber auch keine Anzeige mehr in den Details. Ist das so gewollt oder ein Bug?
Zitatevent-on-change-reading neinbittenicht
cooler einfall. Hast du FHEM schon prosa beigedracht? oder schon einmal die Doku gelesen?
geht das irgendwo?
ZitatOpenweather zeigt das gleiche Verhalten (hab ich schon im anderen Forum gepostet).
nicht verwunderlich.
ZitatMit anderen Worten, ich kann da eintragen was ich will, die Events kommen trotzdem:
schon einmal nach Anleitung probiert?
attr system.hminfo event-on-change-reading .*
Zitat von: martinp876 am 08 Juli 2014, 08:36:36
cooler einfall. Hast du FHEM schon prosa beigedracht? oder schon einmal die Doku gelesen?
Nein und ja ;-) Das war nur als offensichtliches Beispiel für ein Reading gedacht, das es definitiv nicht gibt, und somit nach meinem Verständnis gar keine Events mehr produziert werden sollten. Die Doku habe ich aber schon gelesen:
Zitat
1. If both attributes are not set, any update of any reading of the device creates an event. --> ich will gar keine events, also dürfen nicht beide leer sein
2. If any of the attributes is set, no events occur for updates or changes of readings not listed in any of the attributes. --> genau so soll es sein
Wenn ich also einen Regex als event-on-change-reading angebe, der alle Events rauswirft, wie hier geschehen, sollte überhaupt kein Event entstehen, oder habe ich da offensichtlich etwas falsch verstanden?
Zitat
geht das irgendwo?
Ja, z.B. bei so ziemlich allen Homematic-Devices, wo ich keine Events brauche / haben möchte, mache ich das seit Monaten so ;-) Da trag ich einfach irgendwas bei event-on-change-reading rein und schon bekomme ich z.B. aus Channels, die mich nicht interessieren, auch keine Events mehr. Nun könnte man auch mit DblogExclude arbeiten, aber z.B. zum Debuggen von Notifies ist es schon recht hilfreich, wenn in der Datenbank auch alle wirklich eingetretenen Events stehen. Daher mein vielleicht merkwürdiges, undokumentiertes Vorgehen ;-)
Im Fall von HMInfo ist es ähnlich: Ich brauche keine Events, ich mag halt nur die restliche Funktionalität haben. Betrachte es also als nicht wirklich wichtig, aber es fiel mir halt auf. Offensichtliche Alternative für mich wäre es das Auto-Update abzustellen, dann muss ich halt einmal update klicken, wenn ichs mir im Webinterface anschaue.
Kleiner Nachtrag: Ich habe eben mal folgendes gesetzt:
Attributes:
alias Homematic Info
autoUpdate 00:30
event-on-change-reading .*overload
group System
room System
stateFormat Empfang (dB): I_rssiMinLevel
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update
Es sollten also nur overload-Meldungen kommen, richtig? Danach mal Aufopferungsvoll meinen Baumarkt-Halogenstrahler an den Dimmer gehängt und hminfo geupdatet:
2014-07-08 10:01:22.670 HMinfo system.hminfo ERR_overheat: on:1;
2014-07-08 10:01:22.670 HMinfo system.hminfo ERR_overload: on:1;
Readings werden immer upgedated. Sie lösen einen Trigger (event) asu, wenn vom Developer so eingestellt (bei HM so gut wie immer). Das entspricht event-on-update-reading - also immer, wenn das Reading neu geschrieben wird (auch mit gleichem Inhalt)
nun kannst du
event-on-change-reading
einstellen. Dann werden nur events ausgelöst, wenn sich der entsprechende ReadingINHALT ändert.
Wenn du nun
event-on-change-reading .*
setzt werden für alle Readings nur noch Änderungen als Event ausgegeben.
Nun kannst du mit
event-on-update-reading <name>
wieder das "change" überschreiben und für <name> einen event bei jedem Update erzeugen lassen.
Es gibt kein
event-supress-reading
also "bitte kein Event für diese Readings". Das hatte ich beantragt, hat Rudi abgelehnt - da es keiner braucht.
Zitat von: martinp876 am 08 Juli 2014, 11:40:27
Es gibt kein event-supress-reading also "bitte kein Event für diese Readings". Das hatte ich beantragt, hat Rudi abgelehnt - da es keiner braucht.
Schade auch, hätte ich gerne für z.B. "cover" verwendet. Nun muss man die beiden anderen Attribute setzten, um das hin zu bekommen. Ist aufwendiger, da man nun alles angeben muss was ein Event erzeugen soll. Manches kennt man vielleicht gar nicht (motorError) und unterdrückt es dann. Meines Erachtens wäre eine Blacklist der bessere Weg.
Huhu Martin,
danke für die Antwort. Dann ist aber die Commandref falsch, oder? - da steht, dass man mittels setzen von einem (beliebigen) Regex bzw. einer liste von Regexen für event-on-change-reading, statt .* wie von dir vorschlagen kann, dies begrenzen kann:
Zitat
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created.
Aber genau das passiert eben nicht - im Beispiel oben ist overheat nicht in der "Liste" (der Länge 1) bzw. entspricht nicht dem Regex, erzeugt aber trotzdem ein Event.
Dass dies keiner (außer mir) braucht, mag sein ;) Ich hab eben nochmal gesucht, aber jemand anderes ist vor längerem auch schon darüber gestolpert (ich denke mittlerweile schon ich bin plemm plemm) - http://forum.fhem.de/index.php/topic,20676.msg141983.html#msg141983 - bei dem wirkt bei manchen FHEM-Modulen auch event-on-change-reading .* nicht "richtig" (was ich auch bestätigen kann).
Im übrigen ist das Verhalten auch bei allen Homematic devices genau so wie in der Anleitung, nur eben bei HMInfo nicht.
ZitatYou may use regular expressions in that list.
=> eine Liste von ausdrücken, auch "regular-expressions" ist erlaubt. Also .*, heating.*, Licht..Flur
regexp sagt dir sicher etwas
ZitatIf set, only changes of the listed readings create events.
wenn den der Ausdruck/die regexp mit dem Reading einen match ergibt (und nur dann) werden events
"im falle eines changes" erzeugt.
Ansonsten werden Events (auch) im Falle eines updates erzeugt.
...und falls ihr weiterhin aneinander vorbeiredet:
das overload / overhead etc. muss hinten ein .* haben damit es matched.
z.B. overload.*
Dann sollte es klappen? :-)
geht es nur um overload? Ich dache ein ".*" sollte rein (hier wie überall - im HM bereich jedenfalls)
Huhu Martin,
nee, geht nicht nur um overload, sondern darum, dass sich hminfo bezüglich Auswirkung von event-on-change-reading anders verhält als alle andere Homematic-Devices in FHEM (die ich besitze).
Bleiben wir trotzdem mal beim (Minimal-) Beispiel overload bzw. overheat, mit breiterem Regex (ja, ich weiß, was reguläre Ausdrücke sind, ich bin ein Dippel-Inf. ):
attr system.hminfo event-on-change-reading .*overload.*
attr stube.deckenfluter event-on-change-reading .*overload.*
deleteattr system.hminfo event-on-update-reading
deleteattr stube.deckenfluter event-on-update-reading
Jetzt überladen wir den Dimmer, es kommt sofort
2014-07-08 20:07:10.001 CUL_HM stube.deckenfluter overload: on
--> es kommt NUR das overload-event, obwohl sich auch das overheat-reading des Dimmers genauso von off nach on ändert. Auch bekomme ich keine sonstigen events mehr vom Dimmer (an/aus etc.) - rausgefiltert durch event-on-change-reading - so muss das nach meinem Verständnis auch sein.
Nun updaten wir hminfo:
2014-07-08 20:08:06.674 HMinfo system.hminfo ERR_overheat: on:1;
2014-07-08 20:08:06.674 HMinfo system.hminfo ERR_overload: on:1;
--> hminfo dagegen meldet beides als event, obwohl event-on-change-reading und event-on-update-reading identisch gesetzt ist.
Und das gilt für alle Readings von Hminfo. Overload bzw. Overheat war nur ein Beispiel ;-) Meines erachtens behandeln die Homematic- Devices event-on-change-reading richtig und die meisten anderen FHEM-Module auch; hminfo behandelt es falsch. Auf jeden Fall aber macht es hminfo "anders", nämlich event-on-change-reading so zu interpretieren wie du in deinem letzten Post ("was nicht in event-on-change-reading gelistet ist, produziert immer ein event"). Fast alle anderen FHEM-Devices produzieren dann keine Events. Und das finde ich auch gut so ^^
Ansonsten gilt: Sorry falls ich nerve, falls ja, ignorier es einfach, es ist wirklich nur Minor.
ZitatAnsonsten gilt: Sorry falls ich nerve, falls ja, ignorier es einfach, es ist wirklich nur Minor.
ich halte es nicht für minor - man MUSS wissen, welche Events kommen und wann. Sonst kann man kein sicheres System aufbauen.
Das Verhalten wird aber zentral gemacht - noch kann ich nicht erkennen, was HMInfo damit zu tun hat.
In deinem Beispiel gehe ich davon aus, dass overload und overheat nicht existent war oder der Zähler einen anderen Wert hatte.
jetzt habe ich keinen dimmer mit overload, habe es aber mit anderen Readings getestet. Es funktioniert.
Wichtig ist, den Vorzustand zu kennen - den hast du nicht aufgeführt. Das Reading ist ein Zähler.
Zur Sicherheit:
vor dem Test war
ERR_overheat: NICHT "on:1"
ERR_overload: NICHT "on:1"
korrekt? Dann kann der update und NICHT das Event? Und das Reading war danach gesetzt?
Du kannst es auch einmal "langsam" probieren:
- Attribut autoUpdate löschen, event-on-change-reading .* setzen
- readings kontrollieren (oder löschen)
- das Ereigniss erzeugen (overload/overheat)
- set hm update
=> kommen die events?
=> sind die Readings geändert?
Gruss Martin
Zitat von: martinp876 am 09 Juli 2014, 09:06:17
In deinem Beispiel gehe ich davon aus, dass overload und overheat nicht existent war oder der Zähler einen anderen Wert hatte.
Korrekt. Das Reading war vorher in HMInfo nicht existent, es wurde zumindest in der Detailansicht nicht angezeigt. Danach war es dann da und der Zähler 1, entsprechend dem oben geposteten Event. Das ist möglicherweise auch das Problem!?
Zitat
Zur Sicherheit:
vor dem Test war
ERR_overheat: NICHT "on:1"
ERR_overload: NICHT "on:1"
Korrekt, beide Readings waren gar nicht zu sehen.
Zitat
Dann kann der update und NICHT das Event? Und das Reading war danach gesetzt?
Ich habe, nachdem ich den Dimmer überladen habe, HMInfo geupdatet. In diesem Moment kam ein Event für overheat und overload von HMinfo und die Readings waren danach dann beide erschienen mit on: 1.
Zitat
Du kannst es auch einmal "langsam" probieren:
- Attribut autoUpdate löschen, event-on-change-reading .* setzen
- readings kontrollieren (oder löschen)
- das Ereigniss erzeugen (overload/overheat)
- set hm update
=> kommen die events?
=> sind die Readings geändert?
Das funktioniert wie es soll. Es kommen für beide Readings Events. Und folgendes funktioniert auch:
0.a) Vorher - HMINFO:
Internals:
CHANGED
ERR__protoNames flur.klingelcontrol,flur.unten.licht,stube.licht
ERR_names stube.deckenfluter
I_HM_IOdevices system.hmlan,:ok
NAME system.hminfo
NR 29
STATE Empfang (dB): 59<:11 60>:22 80>:9 99>:0
TYPE HMinfo
Version 01
W__protoNames flur.klingelcontrol,flur.unten.licht,stube.licht,stube.steckdose.tv
CHANGETIME:
Helper:
Dblog:
Err_overheat:
Dblog:
TIME 1404941799.75984
VALUE on:1;
Err_overload:
Dblog:
TIME 1404941799.75984
VALUE on:1;
Readings:
2014-07-07 22:06:23 C_sumDefined entities:130 device:42 channel:108 virtual:1
2014-07-06 21:06:13 ERR__protocol ResndFail:3,CmdDel:3
2014-07-09 23:36:39 ERR_overheat on:1;
2014-07-09 23:36:39 ERR_overload on:1;
2014-06-25 20:55:52 I_actTotal alive:33 dead:0 unkn:0 off:0
2014-07-08 21:36:32 I_rssiMinLevel 59<:11 60>:22 80>:9 99>:0
2014-06-30 20:03:23 I_sum_battery ok:38;
2014-06-24 08:52:49 I_sum_sabotageError off:4;
2014-07-06 21:06:13 W__protocol Resnd:4
Helper:
Nb:
cnt 0
Attributes:
alias Homematic Info
event-on-change-reading .*
group System
room System
stateFormat Empfang (dB): I_rssiMinLevel
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update
0.b) Vorher - Dimmer:
Internals:
DEF 240C58
IODev system.hmlan
LASTInputDev system.hmlan
MSGCNT 76
NAME stube.deckenfluter
NR 103
STATE on
TYPE CUL_HM
lastMsg No:81 - t:10 s:240C58 d:34EF21 0601C800
peerList stube.wandtaster.unten,
protLastRcv 2014-07-11 16:24:23
protSnd 68 last_at:2014-07-11 16:24:23
protState CMDs_done
rssi_at_system.hmlan avg:-47.42 min:-54 max:-43 lst:-43 cnt:76
rssi_stube.wandtaster avg:-55.37 min:-59 max:-51 lst:-55 cnt:8
rssi_system.hmlan avg:-43.84 min:-49 max:-41 lst:-41 cnt:26
system.hmlan_MSGCNT 76
system.hmlan_RAWMSG E240C58,0000,040843CF,FF,FFD5,81A410240C5834EF210601C800
system.hmlan_RSSI -43
system.hmlan_TIME 2014-07-11 16:24:23
CHANGETIME:
Helper:
Dblog:
Devicemsg:
Dblog:
TIME 1404842827.65454
VALUE off (to system.hmlan)
Dim:
Dblog:
TIME 1404842827.65454
VALUE stop:off
Overheat:
Dblog:
TIME 1404842829.8724
VALUE on
Overload:
Dblog:
TIME 1405088663.67822
VALUE off
Pct:
Dblog:
TIME 1405088663.67822
VALUE 100
State:
Dblog:
TIME 1404842827.65454
VALUE off
Readings:
2014-07-11 16:24:18 CommandAccepted yes
2014-06-23 12:34:50 D-firmware 2.3
2014-06-23 12:34:50 D-serialNr KEQ0904483
2014-07-08 20:37:58 PairedTo 0x34EF21
2014-06-23 12:38:07 R-confBtnTime 255 min
2014-07-08 20:37:58 R-intKeyVisib invisib
2014-07-08 20:37:59 R-loadAppearBehav off
2014-07-08 20:37:59 R-loadErrCalib 1
2014-07-08 20:37:58 R-pairCentral 0x34EF21
2014-07-08 20:37:59 R-powerUpAction off
2014-06-23 12:38:08 R-statusInfoMinDly 2 s
2014-06-23 12:38:08 R-statusInfoRandom 1 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgActionTypeDim toggelDim
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtDlyOff geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtDlyOn geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtOff geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtOn geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtRampOff geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtRampOn geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtValHi 100
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgCtValLo 50
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgDimJtDlyOff rampOff
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgDimJtDlyOn rampOn
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgDimJtOff dlyOn
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgDimJtOn dlyOff
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgDimJtRampOff off
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgDimJtRampOn on
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgDimMaxLvl 100 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgDimMinLvl 0 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgDimStep 5 %
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgMultiExec on
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOffDly 0 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgOffDlyBlink on
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOffDlyNewTime 0.4 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOffDlyOldTime 0.4 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOffLevel 0 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOffTime 111600 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgOffTimeMode absolut
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOnDly 0 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgOnDlyMode setToOff
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOnLevel 100 %
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgOnLvlPrio high
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOnMinLevel 10 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgOnTime 111600 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-lgOnTimeMode absolut
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgRampOffTime 0.5 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgRampOnTime 0.5 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-lgRampSstep 5 %
2014-07-08 20:38:01 R-stube.wandtaster.unten-shActionTypeDim jmpToTarget
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtDlyOff geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtDlyOn geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtOff geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtOn geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtRampOff geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtRampOn geLo
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtValHi 100
2014-07-08 20:38:01 R-stube.wandtaster.unten-shCtValLo 50
2014-07-08 20:38:01 R-stube.wandtaster.unten-shDimJtDlyOff rampOff
2014-07-08 20:38:01 R-stube.wandtaster.unten-shDimJtDlyOn rampOn
2014-07-08 20:38:01 R-stube.wandtaster.unten-shDimJtOff dlyOn
2014-07-08 20:38:01 R-stube.wandtaster.unten-shDimJtOn dlyOff
2014-07-08 20:38:01 R-stube.wandtaster.unten-shDimJtRampOff off
2014-07-08 20:38:01 R-stube.wandtaster.unten-shDimJtRampOn on
2014-06-23 12:38:14 R-stube.wandtaster.unten-shDimMaxLvl 100 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-shDimMinLvl 0 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-shDimStep 5 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOffDly 0 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-shOffDlyBlink on
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOffDlyNewTime 0.4 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOffDlyOldTime 0.4 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOffLevel 0 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOffTime 111600 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-shOffTimeMode absolut
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOnDly 0 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-shOnDlyMode setToOff
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOnLevel 100 %
2014-07-08 20:38:01 R-stube.wandtaster.unten-shOnLvlPrio high
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOnMinLevel 10 %
2014-06-23 12:38:14 R-stube.wandtaster.unten-shOnTime 111600 s
2014-07-08 20:38:01 R-stube.wandtaster.unten-shOnTimeMode absolut
2014-06-23 12:38:14 R-stube.wandtaster.unten-shRampOffTime 0.5 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-shRampOnTime 0.5 s
2014-06-23 12:38:14 R-stube.wandtaster.unten-shRampSstep 5 %
2014-07-08 20:37:59 R-transmitTryMax 6
2014-07-08 20:37:58 RegL_00: 02:01 0A:34 0B:EF 0C:21 15:FF 16:00 00:00
2014-07-08 20:37:59 RegL_01: 12:01 30:06 31:00 56:00 57:24 00:00
2014-07-08 20:38:01 RegL_03:stube.wandtaster.unten 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:20 0F:00 10:14 11:C8 12:0A 13:05 14:05 15:00 16:C8 17:0A 18:0A 19:04 1A:04 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:26 8B:14 8C:52 8D:63 8E:20 8F:00 90:14 91:C8 92:0A 93:05 94:05 95:00 96:C8 97:0A 98:0A 99:04 9A:04 00:00
2014-07-11 16:24:23 deviceMsg on (to system.hmlan)
2014-07-11 16:24:23 dim stop:on
2014-07-11 16:24:23 level 100
2014-07-11 16:24:23 overheat off
2014-07-11 16:24:23 overload off
2014-07-11 16:24:23 pct 100
2014-07-08 20:37:59 peerList stube.wandtaster.unten,
2014-07-11 16:24:23 recentStateType info
2014-07-11 16:24:23 reduced off
2014-07-11 16:24:23 state on
2014-07-11 16:24:23 timedOn off
2014-07-09 21:09:14 trigLast stube.wandtaster.unten :short
2014-07-09 21:09:14 trig_stube.wandtaster.unten short
Helper:
cSnd 1134EF21240C580201C80320FFFF
dlvlCmd ++A01134EF21240C580201C80320FFFF
mId 00A3
peerIDsRaw ,1ED7FB02,00000000
rxType 1
Io:
newChn +240C58,00,01,00
nextSend 1405088663.75467
rxt 0
p:
240C58
00
01
00
Mrssi:
mNo 81
Io:
system.hmlan -41
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rpt:
IO system.hmlan
flg A
ts 1405088663.66148
ack:
HASH(0x2598128)
81800234EF21240C5800
Rssi:
At_system.hmlan:
avg -47.421052631579
cnt 76
lst -43
max -43
min -54
Stube.wandtaster:
avg -55.375
cnt 8
lst -55
max -51
min -59
System.hmlan:
avg -43.8461538461539
cnt 26
lst -41
max -41
min -49
Shadowreg:
Attributes:
IODev system.hmlan
alias Deckenfluter Stube
autoReadReg 4_reqStatus
event-on-change-reading pct,overload,reduced
expert 2_full
firmware 2.3
group Beleuchtung
model HM-LC-Dim1L-Pl-2
peerIDs 00000000,1ED7FB02,
room Stube,Wohnung
serialNr KEQ0904483
subType dimmer
webCmd pct
1. Events direkt beim Überladen des Dimmers:
2014-07-11 16:33:12.409 CUL_HM stube.deckenfluter overload: on
2. Events beim Updaten von HMINFO
- keine -
3. Listing von HM-Info danach
Internals:
CHANGED
ERR__protoNames flur.klingelcontrol,flur.unten.licht,stube.licht
ERR_names stube.deckenfluter
I_HM_IOdevices system.hmlan,:ok
NAME system.hminfo
NR 29
STATE Empfang (dB): 59<:11 60>:22 80>:9 99>:0
TYPE HMinfo
Version 01
W__protoNames flur.klingelcontrol,flur.unten.licht,stube.licht,stube.steckdose.tv
CHANGETIME:
Helper:
Dblog:
Err_overheat:
Dblog:
TIME 1404941799.75984
VALUE on:1;
Err_overload:
Dblog:
TIME 1404941799.75984
VALUE on:1;
Readings:
2014-07-07 22:06:23 C_sumDefined entities:130 device:42 channel:108 virtual:1
2014-07-06 21:06:13 ERR__protocol ResndFail:3,CmdDel:3
2014-07-09 23:36:39 ERR_overheat on:1;
2014-07-09 23:36:39 ERR_overload on:1;
2014-06-25 20:55:52 I_actTotal alive:33 dead:0 unkn:0 off:0
2014-07-08 21:36:32 I_rssiMinLevel 59<:11 60>:22 80>:9 99>:0
2014-06-30 20:03:23 I_sum_battery ok:38;
2014-06-24 08:52:49 I_sum_sabotageError off:4;
2014-07-06 21:06:13 W__protocol Resnd:4
Helper:
Nb:
cnt 0
Attributes:
alias Homematic Info
event-on-change-reading .*
group System
room System
stateFormat Empfang (dB): I_rssiMinLevel
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update
D.h. Keine Änderung = Keine Events. Problem scheint also nur das "Neuanlegen" der ERR-Readings im Fehlerfall zu seien - dabei wird event-on-change-reading ausgehebelt.
ZitatKorrekt. Das Reading war vorher in HMInfo nicht existent, ... Das ist möglicherweise auch das Problem!?
nein, das kann die Zentrale.
ZitatIch habe, nachdem ich den Dimmer überladen habe, HMInfo geupdatet... danach dann beide erschienen mit on: 1.
perfekt
ZitatD.h. Keine Änderung = Keine Events. Problem scheint also nur das "Neuanlegen" der ERR-Readings im Fehlerfall zu seien - dabei wird event-on-change-reading ausgehebelt.
hm - das hatte ich so nicht gesehen. Ausserdem sollte das der Kernal können. neu setzen eines Readings ist ein "change" .
teste es noch einmal manuell. Lösche die Readings und mache einen update - das geht so:
{delete $defs{system.hminfo}{READINGS}{ERR_overheat};;return ""}
{delete $defs{system.hminfo}{READINGS}{ERR_overload};;return ""}
set system.hminfo update
{delete $defs{"system.hminfo"}{READINGS}{ERR_overheat};;return ""}
{delete $defs{"system.hminfo"}{READINGS}{ERR_overload};;return ""}
set system.hminfo update
- wenn ich die beiden readings so lösche (klappt, hab nachgesehen, sind weg) und event-on-change-reading .* für hminfo gesetzt habe, kommt korrekterweise:
2014-07-11 19:39:30.345 HMinfo system.hminfo ERR_overheat: on:1;
2014-07-11 19:39:30.345 HMinfo system.hminfo ERR_overload: on:1;
- readings nochmal so löschen; jetzt vorher event-on-change-reading auf .*overload.* gesetzt:
2014-07-11 19:45:08.271 HMinfo system.hminfo ERR_overheat: on:1;
2014-07-11 19:45:08.271 HMinfo system.hminfo ERR_overload: on:1;
- das gleiche nochmal (danke für diese dimmerschonende variante, ich hatte bei den tests vorher angst, er schmort mir irgendwann durch ^^) mit event-on-change-reading overload - also direkt den reading-namen, ohne regex:
2014-07-11 19:48:22.692 HMinfo system.hminfo ERR_overheat: on:1;
2014-07-11 19:48:22.692 HMinfo system.hminfo ERR_overload: on:1;
Ist wohl also echt das Anlegen des Readings!?
Zitat- wenn ich die beiden readings so lösche (klappt, hab nachgesehen, sind weg) und event-on-change-reading .* für hminfo gesetzt habe, kommt korrekterweise:
gut - haben sich geändert, trigger kommt
Zitat- readings nochmal so löschen; jetzt vorher event-on-change-reading auf .*overload.* gesetzt:
gut - haben sich geändert, trigger kommt
Zitat- das gleiche nochmal mit event-on-change-reading overload - also direkt den reading-namen, ohne regex:
auch gut.
In allen 3 Fällen haben sich die Readings geändert - und mussten einen trigger auslösen - das haben sie.
Event-on-change-reading hättest du auch weglassen können. Das filtert nur Events, wenn sich NICHTS ändert. Es ist ein
Event-
only-if-there-is-a-change-in-the-reading.
oder
No-Event-if-reading-does-not-change-its-value
ZitatIst wohl also echt das Anlegen des Readings!?
verstehe ich nicht - sind doch alle gekommen, wie sie sollten. Und Angelegt wurde immer, was ein "change" ist.
Sehen kannst du etwas wenn du
Zitatattr system.hminfo event-on-change-reading .*
{delete $defs{"system.hminfo"}{READINGS}{ERR_overheat};;return ""}
{delete $defs{"system.hminfo"}{READINGS}{ERR_overload};;return ""}
set system.hminfo update
=> Trigger kommen
jetzt noch einmal (keine Änderung)
Zitatset system.hminfo update
=> kein Trigger
Gruss Martin
Jut. Dann ist mir jetzt die Wirkung von event-on-change-reading hoffentlich im Detail klar:
1. Wenn sich ein Reading ändert, dass auf keinen Regex im event-on-change-reading Attribut matcht, wird kein Event erzeugt. --> so isses beim Dimmer
2. Wenn ein Reading neu angelegt wird, dass auf keinen Regex im event-on-change-reading Attribut matcht, wird ein Event erzeugt. --> wie bei HMInfo gesehen
Wenn mans weiß ist das gut und kann es in Notifies etc. berücksichtigen ^^
OK das gehört nun nicht mehr wirklich hier her sondern eher in FHEM allgemein aber ich konnte das mittels eines Dummys tatsächlich so reproduzieren:
define test DUMMY
attr test event-on-change-reading temp
{readingsSingleUpdate($defs{"test"},"temp","1",1)} --> Event kommt
{readingsSingleUpdate($defs{"test"},"hum","1",1)} --> Event kommt
{readingsSingleUpdate($defs{"test"},"hum","2",1)} --> Event kommt nicht
Martin, kann man das Bug nennen? ;)
ZitatMartin, kann man das Bug nennen?
hätte ich schon gesagt - aber man kann ja im Commandref nachlesen. Die Semantik hat sich m.E. geändert. Evtl um erreichen zu könnnen, dass man auch Events
abschalten kann. Das geht jetzt implizit - und daher auch die Änderung.
Aber lesen bildet ;)
1 If both attributes are not set, any update of any reading of the device creates an event.
2 If any of the attributes is set, no events occur for updates or changes of readings not listed in any of the attributes.
3 If a reading is listed in event-on-update-reading, an update of the reading creates an event no matter whether the reading is also listed in event-on-change-reading.
Alle Trigger bei jeden Update
deleteattr test event-on-change-reading .*
deleteattr test event-on-update-reading .*oder
attr test event-on-update-reading .*Alle Trigger nur bei Änderung
attr test event-on-change-reading .*Alle Trigger bei Änderung, nur xxx bei Update
attr test event-on-change-reading .*
attr test event-on-update-reading xxxAlle Trigger bei update, nur xxx bei Änderung ist schwierig. Must du einmal selbst testen.
???Keine Trigger (unterdrücke andere) ausser xxx bei update und yyy bei change
attr test event-on-change-reading yyy
attr test event-on-update-reading xxx