[Gelöst] Unerklärliche Logeinträge HM-Sen-MDIR-O-2 und HM-ES-PMSw1-Pl

Begonnen von scooty, 30 Juni 2014, 11:25:39

Vorheriges Thema - Nächstes Thema

scooty

Hallo zusammen,

seit einem Update von fhem letzte Woche (kann leider nicht genau sagen, ab welcher Version), kommen ständig  diese Log-Einträge (global verbose=3) und vergrößern mein Log-File immens:

2014.06.30 11:01:27 1: RCV L:14 N:7C F:84 CMD:5E SRC:HZKG_WMOG DST:broadcast 84D3A3000000000108E801 (powerEvntCyc energy:870493.1 power:0 current:1 voltage:228 frequency:50.01) (,CFG,RPTEN)
2014.06.30 11:03:02 1: RCV L:14 N:E0 F:84 CMD:5E SRC:HZKG_TROG DST:broadcast 80542D000000000008E5FE (powerEvntCyc energy:841015.7 power:0 current:0 voltage:227.7 frequency:52.54) (,CFG,RPTEN)
2014.06.30 11:03:28 1: RCV L:14 N:7D F:84 CMD:5E SRC:HZKG_WMOG DST:broadcast 84D3A3000000000008E0FF (powerEvntCyc energy:870493.1 power:0 current:0 voltage:227.2 frequency:52.55) (,CFG,RPTEN)
2014.06.30 11:03:52 1: RCV L:0D N:57 F:84 CMD:10 SRC:BKOG_SEN DST:F10000 0601D700 (INFO_ACTUATOR_STATUS) (,CFG,RPTEN)
2014.06.30 11:04:22 1: RCV L:0D N:A3 F:84 CMD:10 SRC:SZOG_SEN DST:F10000 0601E300 (INFO_ACTUATOR_STATUS) (,CFG,RPTEN)
2014.06.30 11:05:28 1: RCV L:14 N:E1 F:84 CMD:5E SRC:HZKG_TROG DST:broadcast 80542D000000000008E1FE (powerEvntCyc energy:841015.7 power:0 current:0 voltage:227.3 frequency:52.54) (,CFG,RPTEN)
2014.06.30 11:06:19 1: RCV L:14 N:7E F:84 CMD:5E SRC:HZKG_WMOG DST:broadcast 84D3A3000000000008E2FE (powerEvntCyc energy:870493.1 power:0 current:0 voltage:227.4 frequency:52.54) (,CFG,RPTEN)
2014.06.30 11:07:39 1: RCV L:14 N:E2 F:84 CMD:5E SRC:HZKG_TROG DST:broadcast 80542D000000000008E9FD (powerEvntCyc energy:841015.7 power:0 current:0 voltage:228.1 frequency:52.53) (,CFG,RPTEN)


Die Komponenten, die diese Einträge generieren sind
HM-Sen-MDIR-O-2
HM-ES-PMSw1-Pl
und nur eben diese (habe auch noch mehrere HM-LC-Bl1PBU-FM im Einsatz).

Alle genannten HomeMatic Komponenten haben keine eigenes "verbose"-Attribut.

Mein erster Verdacht waren ActionDetector und HMInfo, aber Änderung des "verbose" Attributs auf 0 brachten keine Besserung.
Nur global verbose=0 wirkt (aber natürlich leider auch auf alles andere, was ich gerne geloggt haben möchte).

Weiß jemand Rat oder werden noch weitere Infos benötigt?

Viele Grüße,
Andreas

PS:
Liste eines der HM-Sen-MDIR-O-2:
Internals:
   CUL_HM_MSGCNT 18
   CUL_HM_RAWMSG A0D5F841027DDA1F100000601D600::-49:CUL_HM
   CUL_HM_RSSI -49
   CUL_HM_TIME 2014-06-30 11:20:20
   DEF        27DDA1
   IODev      CUL_HM
   LASTInputDev CUL_HM
   MSGCNT     18
   NAME       BKOG_SEN
   NR         194
   STATE      motion
   TYPE       CUL_HM
   lastMsg    No:5F - t:10 s:27DDA1 d:F10000 0601D600
   protLastRcv 2014-06-30 11:20:20
   protSnd    14 last_at:2014-06-30 11:18:16
   protState  CMDs_done
   rssi_at_CUL_HM avg:-49.55 min:-50.5 max:-48.5 lst:-49 cnt:18
   Readings:
     2014-06-30 10:22:56   Activity        alive
     2014-06-06 21:18:48   CommandAccepted yes
     2014-06-06 21:19:03   D-firmware      1.6
     2014-06-06 21:19:03   D-serialNr      LEQ0161148
     2014-06-06 21:18:48   PairedTo        0xF10000
     2014-06-06 21:19:03   R-brightFilter  2
     2014-06-06 21:19:03   R-captInInterval off
     2014-06-06 21:19:03   R-evtFltrNum    1
     2014-06-06 21:19:03   R-evtFltrPeriod 3 s
     2014-06-06 21:04:54   R-ledOnTime     0 s
     2014-06-06 21:19:03   R-minInterval   30
     2014-06-06 21:06:07   R-pairCentral   0xF10000
     2014-06-06 21:18:48   RegL_00:        02:01 0A:F1 0B:00 0C:00 00:00
     2014-06-06 21:19:03   RegL_01:        01:16 02:21 08:00 22:00 00:00
     2014-06-30 11:20:20   battery         ok
     2014-06-30 11:20:20   brightness      214
     2014-06-30 11:20:20   cover           closed
     2014-06-30 11:18:16   motion          on (to CUL_HM)
     2014-06-30 11:18:16   motionCount     155_next:14s
     2014-06-30 11:20:20   recentStateType info
     2014-06-30 11:18:16   state           motion
   Helper:
     mId        00C1
     rxType     28
     Io:
       newChn     +27DDA1,00,01,1E
       nextSend   1404120020.25581
       rxt        2
       p:
         27DDA1
         00
         01
         1E
     Mrssi:
       mNo        5F
       Io:
         CUL_HM     -47
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_hm:
         avg        -49.5555555555556
         cnt        18
         lst        -49
         max        -48.5
         min        -50.5
     Shadowreg:
Attributes:
   IODev      CUL_HM
   actCycle   000:10
   actStatus  alive
   autoReadReg 5_readMissing
   event-on-change-reading battery,motionCount,cover,state
   event-on-update-reading motion,brightness
   expert     2_full
   firmware   1.6
   fp_Rosi2_OG 140,850,6,brightness
   group      OG
   icon       motion_detector
   model      HM-Sen-MDIR-O-2
   peerIDs    00000000,
   room       BKOG
   serialNr   LEQ0161148
   subType    motionDetector


List eines der HM-ES-PMSw1-Pl:
Internals:
   DEF        251CC4
   IODev      CUL_HM
   NAME       HZKG_WMOG
   NR         196
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HZKG_WMOG_Sw
   channel_02 HZKG_WMOG_Pwr
   channel_03 HZKG_WMOG_SenPwr
   channel_04 HZKG_WMOG_SenI
   channel_05 HZKG_WMOG_SenU
   channel_06 HZKG_WMOG_SenF
   lastMsg    No:85 - t:5E s:251CC4 d:000000 84D3A3000000000008E1FF
   protLastRcv 2014-06-30 11:23:47
   rssi_at_CUL_HM avg:-82.23 min:-84.5 max:-77.5 lst:-80.5 cnt:25
   Readings:
     2014-05-05 18:53:05   Activity        alive
     2014-05-02 20:10:11   CommandAccepted yes
     2014-05-02 20:10:10   D-firmware      1.4
     2014-05-02 20:10:10   D-serialNr      KEQ0971770
     2014-05-02 20:22:45   PairedTo        0xF10000
     2014-05-02 20:10:11   R-intKeyVisib   invisib
     2014-05-02 20:10:11   R-localResDis   off
     2014-05-02 20:10:11   R-pairCentral   0xF10000
     2014-05-02 20:22:45   RegL_00:        02:01 0A:F1 0B:00 0C:00 18:00 00:00
     2014-05-05 09:08:23   powerOn         -
     2014-06-28 11:40:08   state           CMDs_done
   Helper:
     mId        00AC
     rxType     1
     Io:
       newChn     +251CC4,00,01,00
       nextSend   1404120227.95846
       rxt        0
       p:
         251CC4
         00
         01
         00
     Mrssi:
       mNo        85
       Io:
         CUL_HM     -78.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat   01,02,03,04,05,06
     Role:
       dev        1
     Rssi:
       At_cul_hm:
         avg        -82.24
         cnt        25
         lst        -80.5
         max        -77.5
         min        -84.5
     Shadowreg:
Attributes:
   IODev      CUL_HM
   autoReadReg 5_readMissing
   expert     2_full
   firmware   1.4
   model      HM-ES-PMSw1-Pl
   room       HZKG
   serialNr   KEQ0971770
   subType    powerMeter
   webCmd     getConfig:clear msgEvents
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

frank

ZitatAlle genannten HomeMatic Komponenten haben keine eigenes "verbose"-Attribut.
du kannst aber bei jedem device/channel ein attr verbose setzen. ich glaube ohne setzen wird von default verbose=3 ausgegangen.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

scooty

Halo Frank,

danke für Deine Antwort.

Das mit dem eigenen "verbose" Attribut der Komponenten war wohl etwas unglücklich ausgedrückt.
Wollte eher sagen, dass ich das so auch nicht möchte (man verliert sonst leicht den Überblick) und alles in meiner Umgebung ist auf das globale verbose=3 ausgerichtet.

Aber selbst ein verbose=0 direkt in den o.a. Device-Definitionen hat keine Auswirkung auf diese (für mich) unerklärlichen Logeinträge.

Viele Grüße,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

frank

die logeinträge zb des energiemessschalters sind aber nicht unerklärlich, sondern ganz normale, zyclische funktelegramme des schalters. das du sie jetzt zu sehen bekommst, könnte an den umstellungen im zusammenhang mit der neuen virtuellen ccu stehen. da bei mir die logeinträge fehlen und ich eine vccu definiert habe, spekuliere ich einmal, dass du keine vccu definiert hast. sollte das so sein, kannst du ja mal probieren eine zu erstellen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

scooty

#4
Hallo Frank und alle anderen Mitleser,

eine VCCU (ich gebe zu, ich habe noch nicht so ganz geblickt, wozu eine VCCU nun wirklich da ist) habe ich jetzt definiert,die Logeinträge tauchen aber leider weiterhin auf.  :(

In dem Wust von Logeinträgen habe ich jetzt auch noch die Einträge der HM-LC-Bl1PBU-FM gefunden, also werden alle Funktelegramme aller Homematic-Komponenten mitgeloggt.

An welcher Stelle kann man sonst noch ansetzen, um diese Logeinträge wegzubekommen?
Konfiguration der VCCU (verbose der VCCU habe ich auf 0 gesetzt)?

Ich gehe davon aus, dass solche Funktelegramme generell eher etwas für verbose 4 oder 5 sein sollten, oder?

Vielen Dank schonmal und viele Grüße,
Andreas

Anbei das List meiner VCCU:
Internals:
   CFGFN
   DEF        F10000
   NAME       V_CCU
   NR         895
   STATE      ???
   TYPE       CUL_HM
   Readings:
   Helper:
     Io:
       newChn     +F10000,00,01,00
       rxt        0
       p:
         F10000
         00
         01
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
     Shadowreg:
Attributes:
   autoReadReg 4_reqStatus
   expert     2_full
   room       Global
   verbose    0
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol

frank

du musst deine definition erweitern.
attr  V_CCU IODev hmlan1
attr  V_CCU IOList hmlan1,cul868,hmusb1
attr  V_CCU model CCU-FHEM
attr  V_CCU subType virtual

die namen der io durch deine namen ersetzen.

die devices benötigen dann
attr <dev> IOgrp V_CCU
oder bei mehreren io ein bevorzugtes wählen
attr <dev> IOgrp V_CCU:hmlan1

speichern nicht vergessen und shutdown restart.

nach deiner signatur hast du ein cul. daher könnte ein verbose=0 beim cul helfen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

scooty

Zitat von: frank am 30 Juni 2014, 17:31:09
nach deiner signatur hast du ein cul. daher könnte ein verbose=0 beim cul helfen.

Das ist der goldene Tipp für einen Workaround, vielen Dank!
:)
Mit der VCCU werde ich mich dann 'mal in einer ruhigen Stunde beschäftigen.

Vielen Dank für die prompte Hilfe,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH1080 / IO Homecontrol