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:
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):
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?
ZitatAlle 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".
Zitat von: frank am 15 August 2022, 08:43:36
wie ermittelst du das?
man kann devices zb auch in structures oder über devspec "verschleiern".
Ja, sieht ja sehr zyklisch aus -> at?
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:
set TYPE=at inactive
Gruß, Joachim
Zitat von: frank am 15 August 2022, 08:43:36
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.
Zitat von: frank am 15 August 2022, 08:43:36
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 ...
Zitat von: MadMax-FHEM am 15 August 2022, 09:12:52
Ja, sieht ja sehr zyklisch aus -> at?
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:
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
trigLast: fhem:02habt ihr keine Idee?
Hier noch das List des Devices:
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?
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
Zitat"Probably associated with"
diese liste muss weder korrekt noch vollständig sein. hast du ja auch schon selber bemerkt.
ZitattrigLast: fhem:02
der letzte auslöser kam von fhem
ZitatHier fällt mir das "peer self03" auf.
zu den fähigkeiten von hw und fw weisst wohl nur du etwas konkretes zu sagen. ;)
model HB-UNI-SenAct-4-4-SC
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 :D. Ganz ahnungslos bin ich aber auch nicht ;).
Gruß, Hans
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" .*
Den zyklischen Auslöser hast du so aber immer noch!
Zitat von: jhohmann am 16 August 2022, 10:28:17
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" .*
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.