hallo martin,
meine virtuellen tc funktionieren nicht mehr.
1. im virtuellen chn gibt es kein cmd valvePos
2021.01.20 12:07:38.993 3: set VentilControler.Bad_Btn1 valvePos 32 : Unknown argument valvePos, choose one of press pressL:all,noArg,Names,VentilControler.Bad_Btn1 pressS:all,noArg,Names,VentilControler.Bad_Btn1 postEvent:slider,0,1,255 peerChan peerSmart:DimPBU01_Sw1_V01,DimPBU01_Sw1_V02,DimPBU01_chn01,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1,virt_vd_Btn1
vtc device:Internals:
DEF B3B3B3
FUUID 5c4ce2e9-f33f-09c4-1b31-1230b6405bc6517b
IODev hmlan1
NAME VentilControler.Bad
NOTIFYDEV global
NR 271
NTFY_ORDER 50-VentilControler.Bad
STATE CMDs_done
TYPE CUL_HM
channel_01 VentilControler.Bad_Btn1
.attreour:
state
.attrminint:
READINGS:
2021-01-11 11:20:52 .associatedWith VentilControler.Bad,VentilControler.Bad_Btn1,VentilControler.Bad
2021-01-20 12:02:58 .protLastRcv 20210120120258
2021-01-11 14:15:41 CommandAccepted yes
2021-01-20 12:14:02 cfgState ok
2021-01-11 14:15:41 commState CMDs_done
2021-01-11 14:15:41 state CMDs_done
helper:
HM_CMDNR 19
mId FFF1
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
cmds:
TmplKey :1611140854.67338:1611140855.35996
TmplTs 1611140855.35996
cmdKey 0:1:1::VentilControler.Bad:FFF1:00:
cmdLst:
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
peerSmart -peerOpt-
tplSet_0 -tplChan-
virtual [({1}|1..50;1)]
lst:
condition slider,0,1,255
peer VentilControler.Bad,Names
peerOpt DimPBU01_Sw1_V01,DimPBU01_Sw1_V02,DimPBU01_chn01,DimUP01,Fenster.Bad,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
vccu ccu
prefIO:
hmlan1
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
Attributes:
.mId FFF1
IODev hmlan1
IOgrp ccu:hmlan1
event-on-update-reading state
expert defReg,rawReg
group Heizung.Bad
model VIRTUAL
room 40_Bad
subType virtual
webCmd press short:press longvtc channel:Internals:
.triggerUsed 0
DEF B3B3B301
FUUID 5c4ce2e9-f33f-09c4-62c9-b7cbb41e03bd27c3
NAME VentilControler.Bad_Btn1
NOTIFYDEV global
NR 272
NTFY_ORDER 50-VentilControler.Bad_Btn1
STATE Vsoll: 32 %, Status: ValveAdjust:32 %, Kommunikation: ok, Error (tot/lost/avg): 500 / 33 / 3.1, Modus: msgReduce:2
TYPE CUL_HM
chanNo 01
device VentilControler.Bad
peerList Ventil.Bad
.attraggr:
.attreocr:
.*
.attreour:
state
valvePosTC
.attrminint:
.userReadings:
HASH(0x393e3b8)
HASH(0x394ac18)
READINGS:
2021-01-20 12:07:30 .associatedWith VentilControler.Bad,VentilControler.Bad_Btn1,VentilControler.Bad,Ventil.Bad_chn-01
2021-01-20 12:03:08 .next 185;1611140721.28146
2021-01-20 12:14:02 cfgState ok
2020-08-10 23:49:30 ctrStart 2020-08-10 23:49:30
2021-01-20 12:02:01 errorAvg 3.1
2021-01-20 11:42:52 errorCtr 500
2021-01-20 11:45:02 errorState ok
2021-01-11 11:36:08 lostCtr 33
2021-01-20 12:02:01 msgReduce msgReduce:2
2021-01-20 12:07:30 peerList Ventil.Bad
2021-01-20 12:02:01 state ValveAdjust:32 %
2021-01-20 11:45:02 valveCtrl ok
2021-01-20 11:45:02 valveCtrlRam ok
2021-01-20 12:02:01 valvePosTC 32 %
helper:
peerFriend peerSD,peerSens,peerAct
peerIDsState incomplete
peerOpt -:virtual
regLst
cmds:
TmplKey Ventil.Bad:1611140854.67338:1611140855.35998
TmplTs 1611140855.35998
cmdKey 1:0:1::VentilControler.Bad:FFF1:01:Ventil.Bad
cmdLst:
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
tplSet_0 -tplChan-
tplSet_Ventil.Bad -tplPeer-
lst:
condition slider,0,1,255
peer Names,VentilControler.Bad_Btn1
peerOpt DimPBU01_Sw1_V01,DimPBU01_Sw1_V02,DimPBU01_chn01,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1,virt_vd_Btn1
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
param -param-
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
193A9A01 Ventil.Bad_chn-01
role:
chn 1
vrt 1
shadowReg:
tmpl:
vd:
msgRed 2
Attributes:
alias 30. Controler
event-on-change-reading .*
event-on-update-reading state,valvePosTC
expert defReg,rawReg
group Heizung.Bad
model VIRTUAL
param msgReduce:2
peerIDs 193A9A01
room 40_Bad,98_Ventile
stateFormat Vsoll: valvePosTC, Status: state, Kommunikation: valveCtrl, Error (tot/lost/avg): errorCtr / lostCtr / errorAvg, Modus: msgReduce
userReadings msgReduce:valvePosTC.* {AttrVal($name,"param","???")},
errorAvg:(valvePosTC|errorCtr).* {
my $tsStart = ReadingsVal($name,"ctrStart",undef);
my $days = ((defined($tsStart))?sprintf("%.1f",(time() - time_str2num($tsStart)) / (24*60*60)):0);
return sprintf("%.1f",ReadingsVal($name,"errorCtr",0) / (($days < 0.1)?0.1:$days));
}
verbose 2
webCmd press short:press long2. nicht erst seit dem neuesten update gibt es valvePos auch im realen vd!!!
vd:
Internals:
DEF 193A9A
FUUID 5c4ce2e9-f33f-09c4-228d-7240fd7210c013b3
IODev cul868
NAME Ventil.Bad
NOTIFYDEV global
NR 270
NTFY_ORDER 50-Ventil.Bad
STATE Vsoll:32 %, Vist:33, Status:33, Operation:adjusting, OpErr:37, Mot:closing, MotErr:ok, Bat:ok, Verr:15 %
TYPE CUL_HM
chanNo 01
peerList VentilControler.Bad_Btn1
.attraggr:
.attreocr:
.*
.attrminint:
.attrtocr:
battery
motorErr
CL:
Authenticated 0
BUF
FD 98
FW_ID 1406
LASTACCESS 1611143235
NAME WEB_192.168.1.31_50540
NR 1406
PEER 192.168.1.31
PORT 50540
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
.attraggr:
.attrminint:
READINGS:
2021-01-20 12:47:01 state Connected
READINGS:
from archivexx .D-devInfo 010100
from archivexx .D-stc 58
2021-01-20 12:07:30 .associatedWith Ventil.Bad,Ventil.Bad,VentilControler.Bad_Btn1
2021-01-11 14:15:06 .peerListRDate 2021-01-11 14:15:06
2021-01-20 12:02:58 .protLastRcv 20210120120258
2021-01-20 12:12:13 Activity alive
2021-01-20 12:02:58 CommandAccepted yes
from archivexx D-firmware 2.0
from archivexx D-serialNr JEQ0045719
2021-01-11 14:15:06 PairedTo 0x1ACE1F
2021-01-11 14:10:25 R-pairCentral 0x1ACE1F
2021-01-11 11:20:57 R-valveErrorPos 15 %
2021-01-11 11:20:57 R-valveOffset 0 %
2021-01-11 14:15:06 RegL_00. 00:00 02:01 0A:1A 0B:CE 0C:1F
2021-01-11 14:15:40 RegL_05. 00:00 09:00 0A:0F
2021-01-20 12:02:01 ValveDesired 32 %
2021-01-20 12:02:58 ValvePosition 33
2020-12-18 17:59:49 batNotOkCtr 0
2020-12-18 17:59:49 batNotOkFirstTime waiting...
2020-12-18 18:04:13 battery ok
2021-01-20 12:14:02 cfgState ok
2021-01-20 12:02:58 commState CMDs_done
2021-01-20 12:02:58 motor closing
2021-01-11 14:15:40 motorErr ok
2021-01-20 12:02:58 operState adjusting
2021-01-06 14:42:48 operStateErrCnt 37
2021-01-20 12:07:30 peerList VentilControler.Bad_Btn1
2021-01-06 15:13:56 powerOn 2021-01-06 15:13:56
2021-01-20 12:02:58 recentStateType ack
2021-01-20 12:02:58 state 33
helper:
HM_CMDNR 41
mId 003A
oldDes 0
peerFriend
peerIDsState complete
peerOpt p:thermostat
regLst 0,5
rxType 12
tmplChg 0
cmds:
TmplKey VentilControler.Bad_Btn1:1611140854.67338:1611140855.35966
TmplTs 1611140855.35966
cmdKey 1:1:0::Ventil.Bad:003A:01:VentilControler.Bad_Btn1
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_VentilControler.Bad_Btn1 -tplPeer-
unpair noArg
valvePos [({off}|0.0..99.0;0.5)]
lst:
condition slider,0,1,255
peer Names,Ventil.Bad
peerOpt remove_VentilControler.Bad_Btn1
tplChan
tplDel
tplPeer
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 1
det 1
raw 1
tpl 1
io:
newChn +193A9A,00,00,00
rxt 2
vccu ccu
p:
193A9A
00
00
00
prefIO:
hmuart1
mRssi:
mNo
peerIDsH:
00000000 broadcast
B3B3B301 VentilControler.Bad_Btn1
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
shadowReg:
tmpl:
Attributes:
.mId 003A
IODev hmuart1
IOgrp ccu:hmuart1
actCycle 001:30
actStatus alive
alias 40. Ventil
autoReadReg 5_readMissing
comment batChange: 2020-12-18 17:58:24 (oldBat: low since 2020-10-06 22:19:52, now critical)
motErr: 2021-01-06_12:58:55 blocked (F1), adaption (A3) unmöglich, motErr: adjusting range to small (F3), pos=127%
motErr: 2021-01-11_14:15:40 ok, erst nach zerlegen des vd inklusive heraus-/hereindrehen des stössels bis anschlag.
stössel war vermutlich beim adaptieren (A1) zu weit hineingefahren, so dass das gewinde nicht mehr griff.
event-on-change-reading .*
expert defReg,allReg,rawReg,templ
firmware 2.0
group Heizung.Bad
model HM-CC-VD
msgRepeat 0
peerIDs 00000000,B3B3B301
room 40_Bad,98_Ventile
serialNr JEQ0045719
stateFormat Vsoll:ValveDesired, Vist:ValvePosition, Status:state, Operation:operState, OpErr:operStateErrCnt, Mot:motor, MotErr:motorErr, Bat:battery, Verr:R-valveErrorPos
subType thermostat
timestamp-on-change-reading battery,motorErr
webCmd getConfigedit: noansi hatte mich bereits vorgewarnt, allerdings erkenne ich den zusammenhang noch nicht:
Zitat@Frank: solltest Du heute ein Update von CUL_HM und HMInfo fahren wollen, dann beobachte, ob Deine virtuellen TCs anlaufen. Da lauert ein Bug mit den Peer Namen (_chn-01), wie ich beim Umsetzen auf meine Version bemerkt habe, so dass ein virtueller TC nicht mehr checken kann, dass er mit einem VD gepeert ist und daher gar nicht mehr zum virtuellen TC werden kann.
edit2: helper cmdKey sieht "vermischt" aus, ebenso die readings .associatedWith.
jeweils beim vtc channel und vd device. (vielleicht auch nur noch nicht genau verstanden)
Hallo Frank,
Zitatallerdings erkenne ich den zusammenhang noch nicht
Der Zusammenhang nimmt seinen Anfang in der Funktion CUL_HM_ID2PeerList.
Dort wird nach dem FHEM init die {helper}{fkt} für virtual channels gesetzt. Um das korrekt ausführen zu können, muss der devicename des virtuellen devices verwendet werden (Attributabfrage).
Nun führt die letzte Änderung leider mit Nutzung des neuen CUL_HM_getPeers($name,"Names") dazu, dass der Peername des VDs um "_chn-01" ergänzt wird (oder an der Stelle besser: nicht mehr die bereinigten Namen verwendet werden), weil es ein device mit "integriertem" channel 01 ist. (die Ergänzung wird an anderen Stellen aber wieder benötigt, also auch nicht generell einfach weg zu lassen)
Mit dem ergänzten Namen ist aber direkt ein Lesen des Attributs "model" nicht möglich, sondern erst muss das "_chn-01" entfernt werden.
Fehlen der {helper}{fkt} führt als nächstes dazu, dass das virtuelle TC channel-device nicht zum vdCtrl wird, und kein initiales valvePos und restart ausgeführt wird... .
Gruß, Ansgar.
Ich habe mit der Version vom 16.01.2020 folgende Fehlermeldung bei einem HM-TC-IT-WM-W-EU:
021.01.20 17:34:49 3: CUL_HM set RTC_Wohn_Climate controlMode auto
2021.01.20 17:34:49 1: Error: >RTC_Wohn_chn-05< has no TYPE, but following keys: ><
hallo ansgar,
Zitat von: noansi am 20 Januar 2021, 20:05:46
Fehlen der {helper}{fkt} führt als nächstes dazu, dass das virtuelle TC channel-device nicht zum vdCtrl wird, und kein initiales valvePos und restart ausgeführt wird... .
danke für die erklärung.
meine aussage bezog sich allerdings auf das "fehlende" cmd valvePos.
besser gesagt, valvePos ist "umgezogen" und hat sich dabei ein völlig neues gerät gesucht, nicht nur einen "falschen" channel. daher kann das eigentlich kein chn-01 problem sein, sondern eher eine verwechslung von device und peer. ich habe gerade gesehen, dass der cmd valvePos gar nicht "umgezogen" ist, denn in der alten version von cul_hm ist valvePos ebenfalls fälschlicher weise im realen vd vorhanden.
gruss frank
Hallo Frank,
Zitatich habe gerade gesehen, dass der cmd valvePos gar nicht "umgezogen" ist, denn in der alten version von cul_hm ist valvePos ebenfalls fälschlicher weise im realen vd vorhanden.
Hier stellt sich eher die Sinn Frage. Klar gehört ein valvePos im Prinzip zu einem VD, denn die Aktion kann er ja ausführen. Aber eben nur empfangen, wenn er wach ist, was bei Taste drücken wohl auch mal der Fall sein könnte?!
Der valvePos an den VD wird auf jeden Fall auf seinen Kommando Stack gelegt. Wäre hier vielleicht eine Option, den statt dessen auf einen gepeerten virtuellen TC "umzubiegen".
Was passiert denn, wenn Du mal einen valvePos am VD absetzt und der virtuelle TC off ist? Und was, wenn er aktiv ist?
Gruß, Ansgar.
Zitat von: noansi am 21 Januar 2021, 20:22:14
Was passiert denn, wenn Du mal einen valvePos am VD absetzt und der virtuelle TC off ist? Und was, wenn er aktiv ist?
ich habe mal ein valvePos beim vd gesetzt und vtc/valvePos=off.
Device name:Ventil.Bad
org ID :003A Model=HM-CC-VD
alias ID :003A Model=HM-CC-VD
mode :config,wakeup - activity:alive
protState : CMDs_pending pending: 1 CMDs_pendingda der vd als wakeup device geführt wird, wird bis zum "jüngsten tag" auf eine msg vom vd gewartet, um das pending cmd abzusetzen. von selbst sendet der vd nie, soweit ich weiss. quasi ein "silent wakeup mode".
man braucht also immer einen vtc/tc der das kommunikationsfenster trifft, um eine msg vom vd zu bekommen, woraufhin dann weitere msgs gesendet werden können. falls die kommunikation reibungslos verläuft, könnte man wahrscheinlich für einen zyklus die valvePos des tc/vtc "überschreiben".
ich halte das cmd valvePos beim vd für sinnlos. sogar kontraproduktiv, da es den eindruck vermittelt, dass da was gehen könnte.
danke.
mit gestrigem update laufen die vtc wieder.
bleiben noch 2 kosmetische punkte für cmd valvePos:
1. werteauswahl im vtc würde ich reduzieren.
2. cmd im vd ist überflüssig.