HM-Gerät wird jede Minute geschaltet - durch was?

[rih]

Ich habe hier das Problem, dass jede Minute das Device "PV_Speicher_Sw_03" auf off geschaltet wird. Ich habe aber keine Ahnung, wodurch dies ausgelöst wird. Alle beteiligten DOIF's, at oder notify's sind versuchsweise deaktiviert bzw. disabled. Hier ein Auszug des Eventmonitors:

Code Auswählen Erweitern

2022-08-14 20:13:54 OBIS ZSensor Netzeinspeisung: 96.247
2022-08-14 20:13:54 OBIS ZSensor Last_Aktuell: 144
2022-08-14 20:13:54 CUL_HM PV_Speicher commState: CMDs_pending
2022-08-14 20:13:54 CUL_HM PV_Speicher CMDs_pending
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 set_off
2022-08-14 20:13:54 CUL_HM PV_Speicher commState: CMDs_processing...
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 trigLast: fhem:02
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 trigLast: fhem:02
2022-08-14 20:13:54 CUL_HM PV_Speicher commState: CMDs_done
2022-08-14 20:13:54 CUL_HM PV_Speicher CMDs_done
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 deviceMsg: off (to VCCU)
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 level: 0 %
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 pct: 0
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 off
2022-08-14 20:13:54 CUL_HM PV_Speicher_Sw_03 timedOn: off
2022-08-14 20:13:55 PRESENCE Raspi17_Check present
2022-08-14 20:13:55 PRESENCE Raspi17_Check presence: present

Dies wiederholt sich jede Minute (Auszug Logfile):

Code Auswählen Erweitern

2022.08.14 20:05:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:06:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:07:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:08:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:09:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:10:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:11:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:12:54 3: CUL_HM set PV_Speicher_Sw_03 off
2022.08.14 20:13:54 3: CUL_HM set PV_Speicher_Sw_03 off

Beim Device selbst sehe ich auch keine weiteren Hinweise. Kann aber gerne ein List nachreichen. Auslöser scheint "fhem:02" zu sein, oder?. Aber was ist das? Wie komme ich der Ursache auf die Spur?

[frank]

Alle beteiligten DOIF's, at oder notify's sind versuchsweise deaktiviert bzw. disabled.

wie ermittelst du das?
man kann devices zb auch in structures oder über devspec "verschleiern".

[MadMax-FHEM]

wie ermittelst du das?
man kann devices zb auch in structures oder über devspec "verschleiern".

Ja, sieht ja sehr zyklisch aus -> at?

Code Auswählen Erweitern


list TYPE=at


Und dann alle mal deaktivieren -> set inactive
Entweder einzeln, zumindest das/die, die alle Minute was tun...
...oder gleich alle in einem Rutsch:

Code Auswählen Erweitern


set TYPE=at inactive


Gruß, Joachim

[rih]

wie ermittelst du das?

Das ermittle über die Liste "Probably associated with" des betroffenen Devices. Tatsächlich sind das nur 3 DOIF's und ein Notify. Und die habe ich disabled und deaktiviert.

man kann devices zb auch in structures oder über devspec "verschleiern".

Wüsste ich jetzt nicht, dass ich derartiges gemacht hätte. Müsste mich da jetzt auch erst einlesen dazu ...

Ja, sieht ja sehr zyklisch aus -> at?

Code Auswählen Erweitern


list TYPE=at


Und dann alle mal deaktivieren -> set inactive
Entweder einzeln, zumindest das/die, die alle Minute was tun...
...oder gleich alle in einem Rutsch:

Code Auswählen Erweitern


set TYPE=at inactive


Gruß, Joachim

AT's habe ich einige, die jede Minute etwas auslösen. Die haben aber aus meiner Sicht nichts mit dem Setzen des Devices auf "off" zu tun und laufen schon lange so.
Trotzdem hätte ich das Deaktivieren aller AT's versucht, aber seltsamerweise hörte der Spuk gestern Abend kurze Zeit nach dem Erstellen dieses Themas auf. Auch nach dem wieder aktivieren und enablen der DOIF's und des Notify blieb alles ruhig. Das war schon einmal so, deshalb bin ich sicher, dass das Problem wieder kommt.

Zu dem

Code Auswählen Erweitern

trigLast: fhem:02
habt ihr keine Idee?

Hier noch das List des Devices:

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        F3310303
   FUUID      62a1004d-f33f-17f9-d9e4-2a76470d0a85dc60
   NAME       PV_Speicher_Sw_03
   NOTIFYDEV  global
   NR         767527
   STATE      off
   TYPE       CUL_HM
   chanNo     03
   device     PV_Speicher
   peerList   self03
   READINGS:
     2022-08-14 20:13:54   CommandAccepted yes
     2022-08-10 15:08:12   RegL_01.         00:00 08:00 30:06 56:00 57:24
     2022-08-10 15:08:17   RegL_03.self03   00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:01 8B:14 8C:63
     2022-08-14 21:50:06   cfgState        ok
     2022-08-14 20:13:54   deviceMsg       off (to VCCU)
     2022-08-14 20:13:54   level           0 %
     2022-08-14 20:13:54   pct             0
     2022-08-10 15:08:13   peerList        self03
     2022-08-14 20:13:54   recentStateType ack
     2022-08-14 20:13:54   state           off
     2022-08-14 20:13:54   timedOn         off
     2022-08-14 20:13:54   trigLast        fhem:02
   helper:
     dlvl       00
     dlvlCmd    ++A011112233F331030203000000
     peerFriend peerSens,peerVirt
     peerIDsRaw ,F3310303,00000000
     peerOpt    3:custom
     regLst     1,3p
     cmds:
       TmplKey    self03:no:1654718547.73707
       TmplTs     1654718547.73707
       cmdKey     1:0:0::PV_Speicher:F331:03:self03
       cmdLst:
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         eventL     -peer- -cond-
         eventS     -peer- -cond-
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         inhibit    [(on|{off})]
         off        noArg
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerIODev  [IO] -btn- [({set}|unset)] 'not for future use'
         peerSmart  -peerOpt-
         press      [(long|{short})] [(-peer-|{self03})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{self03})]
         pressS     [(-peer-|{self03})]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         sign       [(on|{off})]
         statusRequest noArg
         toggle     noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_self03 -tplPeer-
       lst:
         condition  slider,0,1,255
         peer       self03
         peerOpt    3K_Sensor_Aussen_Sw_01,3K_Sensor_Aussen_Sw_02,3K_Sensor_Aussen_Sw_03,Bad_Fenster,Bad_Heizung_SenF,Bad_Heizung_SenI,Bad_Heizung_SenPwr,Bad_Heizung_SenU,Briefkastenschalter,EZ_Fenster_rechts,Entfeuchter_Btn_01,Entfeuchter_Btn_02,Entfeuchter_Btn_03,Entfeuchter_Btn_04,Flur_Fenster,Garage_Tor_FB,Garage_Tuer,Gosund_SP1_HM_SenF,Gosund_SP1_HM_SenI,Gosund_SP1_HM_SenPwr,Gosund_SP1_HM_SenU,HM_F33103_Btn_01,HM_F33103_Btn_02,HM_F33103_Btn_03,HM_F33103_Btn_04,Herd_Btn_01,Herd_Btn_02,Herd_Btn_03,Herd_Btn_04,KZ_Fenster_mitte,KZ_Heizung_SenF,KZ_Heizung_SenI,KZ_Heizung_SenPwr,KZ_Heizung_SenU,Keller_Fenster_oben,Keller_Fenster_unten,Kueche_Fenster,Kuehlschrank_SenF,Kuehlschrank_SenI,Kuehlschrank_SenPwr,Kuehlschrank_SenU,Regensensor_Rain,SZ_Fenster_links,SZ_Heizung_SenF,SZ_Heizung_SenI,SZ_Heizung_SenPwr,SZ_Heizung_SenU,VCCU_Btn1,VCCU_Btn2,WZ_Fenster_links,Wetterstation_Test_Weather,Wetterstation_Weather
         tplChan   
         tplDel     
         tplPeer    SwCondAbove_short,SwOnCond_short,SwCondAbove_long,SwOn_short,autoOff_long,SwToggle_short,SwOn_long,motionOnSw_long,SwOff_long,motionOnSw_short,SwOnCond_long,SwCondBelow_short,SwToggle_long,SwOff_short,autoOff_short,SwCondBelow_long
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
   hmccu:
Attributes:
   alias      Batterie_Lader
   group      PV-Speicher
   model      HB-UNI-SenAct-4-4-SC
   peerIDs    00000000,F3310303,


Hier fällt mir das "peer self03" auf. Tatsächlich habe ich das Device nicht wissentlich gepeert. Kann dadurch dieses Verhalten entstehen? Aber warum ist es dann nicht dauerhaft?

[Otto123]

Hi,

self03 ist er selbst, er ist also von Haus aus sein eigener Peer.

Definiere Dir mal grep https://wiki.fhem.de/wiki/Cmdalias und suche nach Device Namen, DEF und Bestandteilen davon. Der findet auch Hinweise in der 99_myUtils - die nicht mit Probably associated with gefunden wird

Gruß Otto

[frank]

"Probably associated with"

diese liste muss weder korrekt noch vollständig sein. hast du ja auch schon selber bemerkt.

trigLast: fhem:02

der letzte auslöser kam von fhem

Hier fällt mir das "peer self03" auf.

zu den fähigkeiten von hw und fw weisst wohl nur du etwas konkretes zu sagen. 

Code Auswählen Erweitern

model      HB-UNI-SenAct-4-4-SC

[rih]

Vielen Dank für die bisherigen Hinweise und Hilfe. Ich kann das Problem gerade nicht weiter eingrenzen, da im Moment alles i.O. ist.

Die fhem.cfg sowie die 99_myUtils.pm habe ich jetzt mittels Notepad++ durchsucht. Ausser den mir bekannten Einträgen zu dem Device gibt es nichts Auffälliges. Und sonst habe ich nirgends "rumgemacht". Die fhem.cfg wurde auch noch nie direkt händisch geändert.

@Frank:
Der HB-UNI-SenAct-4-4-SC ist ein Selbstbau-4fach-Aktor / 4fach-Sensor, in FHEM eingebunden mittels HMConfig_AskSinPPCustom.pm. Habe ich halt nach Anleitung nachgebaut, ohne jetzt der große Spezialist in Sachen hw und fw zu sein . Ganz ahnungslos bin ich aber auch nicht .

Gruß, Hans

[jhohmann]

Wenn du bei dem Device das Attribut event-on-change-reading sinnvoll pflegst, sollten zumindest keine Log-Einträge mehr entstehen. Hier muss mindestens state rein, oder der "Glückmacher"

Code Auswählen Erweitern

.*
Den zyklischen Auslöser hast du so aber immer noch!

[rih]

Wenn du bei dem Device das Attribut event-on-change-reading sinnvoll pflegst, sollten zumindest keine Log-Einträge mehr entstehen. Hier muss mindestens state rein, oder der "Glückmacher"

Code Auswählen Erweitern

.*
Den zyklischen Auslöser hast du so aber immer noch!

Danke. Ja, wäre auch eine Möglichkeit gewesen. Aber wie du schon schreibst, hätte ich den für mich unerklärlichen zyklischen Auslöser trotzdem immer noch. Zumal er augenscheinlich nur sporadisch auftrat.

Ich habe jetzt die ganze Pogrammierung um das betroffene Devive weg von DOIF's und Notify in die 99_myUtils verlagert. Ist übersichtlicher und ich weiß genau, was wann warum passiert. Insofern kann das Problem als gelöst angesehen werden.