HMInfo vs. event-on-change-reading

[peterk_de]

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:

Code Auswählen Erweitern


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.:

Code Auswählen Erweitern


|| *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?

[martinp876]

event-on-change-reading neinbittenicht

cooler einfall. Hast du FHEM schon prosa beigedracht? oder schon einmal die Doku gelesen?
geht das irgendwo?

Openweather zeigt das gleiche Verhalten (hab ich schon im anderen Forum gepostet).

nicht verwunderlich.

Mit anderen Worten, ich kann da eintragen was ich will, die Events kommen trotzdem:

schon einmal nach Anleitung probiert?

Code Auswählen Erweitern

attr system.hminfo  event-on-change-reading .*

[peterk_de]

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:

    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?

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.

[peterk_de]

Kleiner Nachtrag: Ich habe eben mal folgendes gesetzt:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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;


[martinp876]

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.

[Deudi]

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.

[peterk_de]

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:

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.

[martinp876]

You 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

If 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.

[Martin Thomas Schrott]

...und falls ihr weiterhin aneinander vorbeiredet:
das overload / overhead etc. muss hinten ein .* haben damit es matched.
z.B. overload.*
Dann sollte es klappen?

[martinp876]

geht es nur um overload? Ich dache ein ".*"  sollte rein (hier wie überall  - im HM bereich jedenfalls)

[peterk_de]

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. ):

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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.

[martinp876]

Ansonsten 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

[peterk_de]

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!?

Zur Sicherheit:
vor dem Test war
ERR_overheat: NICHT "on:1"
ERR_overload: NICHT "on:1"

Korrekt, beide Readings waren gar nicht zu sehen.

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.

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:   
   

Code Auswählen Erweitern


2014-07-11 16:33:12.409 CUL_HM stube.deckenfluter overload: on


2. Events beim Updaten von HMINFO
 

Code Auswählen Erweitern


- keine -


3. Listing von HM-Info danach

Code Auswählen Erweitern

   
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.

[martinp876]

Korrekt. Das Reading war vorher in HMInfo nicht existent, ... Das ist möglicherweise auch das Problem!?

nein, das kann die Zentrale.

Ich habe, nachdem ich den Dimmer überladen habe, HMInfo geupdatet... danach dann beide erschienen mit on: 1.

perfekt

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.

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:

Code Auswählen Erweitern

{delete $defs{system.hminfo}{READINGS}{ERR_overheat};;return ""}
{delete $defs{system.hminfo}{READINGS}{ERR_overload};;return ""}
set system.hminfo update


[peterk_de]

Code Auswählen Erweitern

{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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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!?