Hallo,
ich habe schon länger einen HM-CC-RT-DN im Einsatz und habe nach Anleitung im Wiki (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren)) einen virtuellen Fensterkontakt angelegt. Das hat auch immer prima funktioniert. Neulich hat sich das Thermostat mal aufgehangen und ich musste es resetten, neu mit FHEM peeren, ging alles. Nur der virtuelle Fensterkontakt will nicht mehr. Wenn ich wie im Wiki beschrieben eingebe:
set CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec regSet winOpnTemp 5 virtualArbeitszimmerDoor
bekomme ich:
cannot calculate value. Please issue set CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec getConfig first - invalid
den angegebenen Befehl abzusetzen hilft dann leider auch nicht.
Wie kann ich die beiden wieder einander näher bringen?
was sagt hminfo configcheck? fhem ist up-to-date?
FHEM ist up to date, hminfo configcheck sagt:
peer not verified. Check that peer is set on both sides
virtualArbeitszimmerDoor p:CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec
und, hast du den hinweis befolgt?
ich dachte genau das tut set CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec regSet winOpnTemp 5 virtualArbeitszimmerDoor
Oder wie kann ich dafür sorgen, dass das Peer auf beiden Seiten gesetzt ist?
peeren (verbindung von einem sensor chn mit einem aktor chn) wird mit "set peerChan" gemacht.
dein befehl "set regSet winOpnTemp 5 virtualArbeitszimmerDoor" setzt das register winOpnTemp für den peer virtualArbeitszimmerDoor auf 5 grad. da der peer im chn window_rec des rt wahrscheinlich noch nicht existiert, wird das register auch noch nicht verfügbar sein.
bei einem erfogreichen peering müssen beide chn den jeweiligen korrespondierenden chn aufweisen. siehe bei details der channel.
Danke für die Antwort!
"set peerChan" wird im Wiki nur für das virtuelle Device gemacht, nicht für das Thermostat. Ein list des virtuellen Device gibt:
ZitatInternals:
DEF 22113301
NAME virtualArbeitszimmerDoor
NOTIFYDEV global
NR 182
STATE set_postEvent open
TYPE CUL_HM
chanNo 01
device virSC
peerList CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec,
Readings:
2017-04-12 13:26:37 peerList CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec,
2017-04-12 15:39:34 state set_postEvent open
Helper:
count 5
Expert:
def 1
det 1
raw 0
tpl 0
Role:
chn 1
vrt 1
Tmpl:
Attributes:
expert 1
group Virtual
model virtual_1
peerIDs 22ADD203,
room Arbeitszimmer
webCmd postEvent open:postEvent closed
Da scheint also das WindowRec gepeert zu sein.
Umgekeht beim Thermostat:
ZitatInternals:
DEF 22ADD203
NAME CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec
NOTIFYDEV global
NR 151
STATE last:virtualArbeitszimmerDoor:open
TYPE CUL_HM
chanNo 03
device HeizungArbeitszimmer
Readings:
2015-11-13 16:03:17 R-sign off
2017-04-11 17:58:34 RegL_01. 08:00 00:00
2017-04-12 13:26:34 state unpeered
2017-04-12 15:39:34 trigLast virtualArbeitszimmerDoor:open
2017-04-12 15:39:34 trig_virtualArbeitszimmerDoor open
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,
stateFormat last:trigLast
"unpeered" dürfte das Problem sein. Dort kann ich aber gar kein "set peerChan" auslösen.
Wie ist da vorzugehen?
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
mit dem befehl aus dem wiki werden beide seiten gepeert. siehe commandref.
im hauptdevice siehst du, ob alle cmds abgearbeitet sind, oder noch pending sind. zeig mal ein list vom hauptchannel.
Hier die Info zum Hauptdevice:
Internals:
DEF 22ADD2
HMLAN1_MSGCNT 5202
HMLAN1_RAWMSG R71AF362C,0001,91CD2630,FF,FFCF,47800222ADD2321ABC00
HMLAN1_RSSI -49
HMLAN1_TIME 2017-04-15 14:56:00
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 5202
NAME HeizungArbeitszimmer
NOTIFYDEV global
NR 147
STATE CMDs_pending
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_RT_DN_22ADD2_Weather
channel_02 CUL_HM_HM_CC_RT_DN_22ADD2_Climate
channel_03 CUL_HM_HM_CC_RT_DN_22ADD2_WindowRec
channel_04 CUL_HM_HM_CC_RT_DN_22ADD2_Clima
channel_05 CUL_HM_HM_CC_RT_DN_22ADD2_ClimaTeam
channel_06 CUL_HM_HM_CC_RT_DN_22ADD2_remote
lastMsg No:47 - t:02 s:22ADD2 d:321ABC 00
protCmdDel 16
protCmdPend 29 CMDs pending
protCondBurst off
protLastRcv 2017-04-15 14:56:00
protResnd 1734 last_at:2017-04-15 14:56:03
protResndFail 1 last_at:2017-04-13 15:05:15
protSnd 3504 last_at:2017-04-15 14:56:00
protState CMDs_pending
rssi_at_HMLAN1 avg:-47.57 min:-61 max:-42 lst:-49 cnt:5202
Readings:
2017-04-12 13:26:35 Activity alive
2017-04-15 14:56:00 CommandAccepted yes
2017-03-23 22:15:23 D-firmware 1.1
2017-03-23 22:15:23 D-serialNr KEQ0725687
2017-04-06 13:05:17 PairedTo 0x321ABC
2015-11-13 16:03:15 R-backOnTime 10 s
2017-04-06 13:05:17 R-burstRx off
2015-11-13 16:03:15 R-cyclicInfoMsg on
2015-11-13 16:03:15 R-cyclicInfoMsgDis 0
2017-03-23 01:01:20 R-pairCentral 0x321ABC
2017-04-06 13:05:17 RegL_00. 01:00 02:01 09:01 0A:32 0B:1A 0C:BC 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2017-04-06 13:19:09 RegL_07.
2017-04-15 14:55:59 actuator 0
2017-04-15 14:55:59 battery ok
2017-04-15 14:55:59 batteryLevel 2.6
2017-04-15 14:55:59 desired-temp 17.0
2017-04-15 14:55:59 measured-temp 19.2
2017-04-15 14:55:59 motorErr ok
2017-03-23 00:47:33 powerOn 2017-03-23 00:47:32
2017-03-23 00:47:33 recentStateType info
2017-04-15 14:56:03 state CMDs_pending
2017-04-14 20:07:47 time-request -
cmdStack:
++A44122113322ADD2011300
++A44122113322ADD2011400
++A44122113322ADD2011500
++A44122113322ADD2011600
++A44122113322ADD2011700
++A44122113322ADD20118C8
++A011321ABC22ADD281042A
++A011321ABC22ADD2860422
++A011321ABC22ADD2860422
++A011321ABC22ADD28004
++A011321ABC22ADD28004
++A011321ABC22ADD281042A
++A011321ABC22ADD2860422
++A011321ABC22ADD2860422
++A011321ABC22ADD28004
++A011321ABC22ADD28004
++A44122113322ADD2011900
++A44122113322ADD2011AC8
++A44122113322ADD2011B00
++A44122113322ADD2011C00
++A44122113322ADD2011D00
++A44122113322ADD2011E00
++A44122113322ADD2011F00
++A44122113322ADD20120C8
++A44122113322ADD2012100
++A44122113322ADD20122C8
++A44122113322ADD2012300
++A44122113322ADD20124C8
++A44122113322ADD2012500
++A44122113322ADD20126C8
Helper:
HM_CMDNR 72
PONtest 1
mId 0095
rxType 140
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +22ADD2,02,00,00
nextSend 1492260960.1768
prefIO
rxt 2
vccu
p:
22ADD2
00
00
00
Mrssi:
mNo 47
Io:
HMLAN1 -47
Prt:
awake 0
bErr 0
brstWu 0
sProc 2
wuReSent 2
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
At_hmlan1:
avg -47.572279892349
cnt 5202
lst -49
max -42
min -61
Shregw:
07 04
Tmpl:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.1
model HM-CC-RT-DN
room Arbeitszimmer
serialNr KEQ0725687
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Ich habe eben nochmal das Thermostat resettet und neu gepeert. Danach gab's zunächst das gleiche Verhalten, 4 CMDs_pending was sich aber nach kurzer Zeit von selbst erledigt hat und das Thermostat nun wieder auf den virtuellen Fensterkontakt reagiert.
In solchen Fällen: löschen der msgs. Set device clear msgevents.
Dann kannst du wieder Nachrichten senden. Erst wenn dies nicht klappt musst du redeten.
vielleicht auch mal ein fw update beim rt riskieren.