1. das aktuelle cul_hm verhindert die kommunikation zwischen vd und virtuellem tc.
es werden keine regelmässigen keep alive messages mehr gesendet.
edit: die keepalive messages werden wieder gesendet, nachdem ich "set valvePos" im chn des vtc ausgeführt habe.
also hat der "automatische" start nach fhem restart nicht funktioniert.
komischer weise ist bei 2 vtc zusätzlich jeweils ein weiterer vtc mit "angesprungen"
2. im channel des virtuellen tc ist das "attr param msgReduce:2" zwar noch vorhanden, aber nicht mehr einstellbar.
es gibt nur noch "attr param showTimed" zur auswahl.
ausserdem hat das attribut keine wirkung, funktioniert also nicht mehr.
3. auffällig ist das fehlende internal .AttrList im channel vom vtc.
dises internal ist in keinem channel eines virtuellen devices zu finden. zb auch nicht in den chn der vccu.
Internals:
.AttrList .devInfo .mId .stc IODev IOgrp actCycle actStatus aesCommReq:1,0 aesKey:5,4,3,2,1,0 autoReadReg:0_off,1_restart,2_pon-restart,3_onChange,4_reqStatus,5_readMissing,8_stateOnly burstAccess:0_off,1_auto commStInCh:on,off do_not_notify:1,0 dummy:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading expert:multiple,defReg,allReg,rawReg,templ,none firmware hmKey hmKey2 hmKey3 hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger ignore:1,0 levelMap levelRange model modelForce:ACTIONDETECTOR,ACTIONDETECTOR,ASH550,ASH550I,CCU-FHEM,CMM,DORMA_ATENT,DORMA_BRC-H,DORMA_RC-H,HM-CC-RT-DN,HM-CC-RT-DN-BOM,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-DIS-EP-WM55,HM-DIS-TD-T,HM-DIS-WM55,HM-DW-WM,HM-ES-PMSW1-DR,HM-ES-PMSW1-PL,HM-ES-PMSW1-PL-DN-R1,HM-ES-PMSW1-PL-DN-R2,HM-ES-PMSW1-PL-DN-R3,HM-ES-PMSW1-PL-DN-R4,HM-ES-PMSW1-PL-DN-R5,HM-ES-PMSW1-SM,HM-ES-TX-WM,HM-HM-LC-DW-WM,HM-LC-AO-SM,HM-LC-BL1-FM,HM-LC-BL1-FM-2,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-BL1-SM-2,HM-LC-BL1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-CV-2,HM-LC-DIM1L-CV-644,HM-LC-DIM1L-PL,HM-LC-DIM1L-PL-2,HM-LC-DIM1L-PL-3,HM-LC-DIM1L-PL-644,HM-LC-DIM1PWM-CV,HM-LC-DIM1PWM-CV-2,HM-LC-DIM1T-CV,HM-LC-DIM1T-CV-2,HM-LC-DIM1T-CV-644,HM-LC-DIM1T-DR,HM-LC-DIM1T-FM,HM-LC-DIM1T-FM-2,HM-LC-DIM1T-FM-644,HM-LC-DIM1T-FM-LF,HM-LC-DIM1T-PL,HM-LC-DIM1T-PL-2,HM-LC-DIM1T-PL-3,HM-LC-DIM1T-PL-644,HM-LC-DIM1TPBU-FM,HM-LC-DIM1TPBU-FM-2,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2L-SM-2,HM-LC-DIM2L-SM-644,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM-2,HM-LC-JA1PBU-FM,HM-LC-RGBW-WM,HM-LC-SW1-BA-PCB,HM-LC-SW1-DR,HM-LC-SW1-FM,HM-LC-SW1-FM-2,HM-LC-SW1-PB-FM,HM-LC-SW1-PCB,HM-LC-SW1-PL,HM-LC-SW1-PL-3,HM-LC-SW1-PL-CT-R1,HM-LC-SW1-PL-CT-R2,HM-LC-SW1-PL-CT-R3,HM-LC-SW1-PL-CT-R4,HM-LC-SW1-PL-CT-R5,HM-LC-SW1-PL-DN-R1,HM-LC-SW1-PL-DN-R2,HM-LC-SW1-PL-DN-R3,HM-LC-SW1-PL-DN-R4,HM-LC-SW1-PL-DN-R5,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-2,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW1PBU-FM,HM-LC-SW2-DR,HM-LC-SW2-DR-2,HM-LC-SW2-FM,HM-LC-SW2-FM-2,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW2PBU-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-DR-2,HM-LC-SW4-PCB,HM-LC-SW4-PCB-2,HM-LC-SW4-SM,HM-LC-SW4-SM-2,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-SW4-WM-2,HM-MOD-EM-8,HM-MOD-EM-8BIT,HM-MOD-RE-8,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CFM-TW,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-FM,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-2-WM55-2,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-4DIS-WM-2,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-2-PBU-FM,HM-RC-2-PBU-FM-2,HM-RC-4,HM-RC-4-2,HM-RC-4-3,HM-RC-4-3-D,HM-RC-4-B,HM-RC-8,HM-RC-DIS-H-X-EU,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-KEY4-2,HM-RC-KEY4-3,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-SEC4-2,HM-RC-SEC4-3,HM-SCI-3-FM,HM-SEC-CEN,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-MDIR-2,HM-SEC-MDIR-3,HM-SEC-RHS,HM-SEC-RHS-2,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-SCO,HM-SEC-SD,HM-SEC-SD-2,HM-SEC-SFA-SM,HM-SEC-SIR-WM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-DB-PCB,HM-SEN-EP,HM-SEN-LI-O,HM-SEN-MDIR-O,HM-SEN-MDIR-O-2,HM-SEN-MDIR-O-3,HM-SEN-MDIR-SM,HM-SEN-MDIR-WM55,HM-SEN-RD-O,HM-SEN-WA-OD,HM-SWI-3-FM,HM-SYS-SRP-PL,HM-TC-IT-WM-W-EU,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS100-C6-O-2,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-OT2-SM-2,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550TECH,IS-WDS-TH-OD-S-R3,KFM-DISPLAY,KFM-SENSOR,KS550,KS550LC,KS550TECH,KS888,OLIGO-SMART-IQ-HM,PS-SWITCH,PS-TH-SENS,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FFK,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FSS-UP3,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,S550IA,SCHUECO_263-130,SCHUECO_263-131,SCHUECO_263-132,SCHUECO_263-133,SCHUECO_263-134,SCHUECO_263-135,SCHUECO_263-144,SCHUECO_263-145,SCHUECO_263-146,SCHUECO_263-147,SCHUECO_263-155,SCHUECO_263-157,SCHUECO_263-158,SCHUECO_263-160,SCHUECO_263-162,SCHUECO_263-167,SCHUECO_263-XXX,SENSOTIMER-ST-6,VIRTUAL,WDF-SOLAR,WS888 msgRepeat oldreadings param peerIDs readOnly:0,1 readingOnDead:multiple,noChange,state,periodValues,periodString,channels rssiLog:1,0 serialNr showtime:1,0 stateFormat:textField-long subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,display,keyMatic,motionAndBtn,motionDetector,no,outputUnit,powerMeter,powerSensor,pushButton,remote,repeater,rgb,senBright,sensRain,sensor,singleButton,siren,smokeDetector,swi,switch,thermostat,threeStateSensor,timer,tipTronic,virtual,winMatic timestamp-on-change-reading
DEF 1C4E25
FUUID 5c4ce2e9-f33f-09c4-f092-82004d6255d7f361
IODev hmlan1
NAME Ventil.AZ.Nord
NR 281
NTFY_ORDER 50-Ventil.AZ.Nord
STATE Vsoll:0 %, Vist:0, Status:0, Operation:onTarget, OpErr:16, Mot:stop, MotErr:ok, Bat:ok, Verr:12 %, Voff:0 %
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
peerList VentilControler.AZ.Nord_Btn1
.attraggr:
.attreocr:
.*
.attrminint:
.attrtocr:
battery
motorErr
CL:
Authenticated 0
BUF
FD 79
FW_ID 1598
LASTACCESS 1632755818
NAME WEB_192.168.1.31_50567
NR 1723
PEER 192.168.1.31
PORT 50567
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
.attraggr:
.attrminint:
READINGS:
2021-09-27 17:16:55 state Connected
READINGS:
1900-01-01 00:00:01 .D-devInfo 010100
1900-01-01 00:00:01 .D-stc 58
2021-09-27 16:23:28 .associatedWith Ventil.AZ.Nord,Ventil.AZ.Nord,VentilControler.AZ.Nord_Btn1
2021-07-03 23:17:32 .peerListRDate 2021-07-03 23:17:32
2021-09-27 16:17:32 .protLastRcv 20210927161732
2021-09-27 16:27:58 Activity alive
2021-09-27 16:17:32 CommandAccepted yes
1900-01-01 00:00:01 D-firmware 2.0
1900-01-01 00:00:01 D-serialNr JEQ0312631
2021-09-27 16:23:26 IODev hmlan1
2021-06-08 17:34:24 PairedTo 0x1ACE1F
2021-09-27 16:23:15 R-pairCentral 0x1ACE1F
2021-09-27 16:23:15 R-valveErrorPos 12 %
2021-09-27 16:23:15 R-valveOffset 0 %
2021-06-08 17:34:24 RegL_00. 00:00 02:01 0A:1A 0B:CE 0C:1F
2021-06-10 00:22:05 RegL_05. 00:00 09:00 0A:0C
2021-09-27 12:44:26 ValveDesired 0 %
2021-09-27 16:17:32 ValvePosition 0
2021-05-13 17:53:25 battery ok
2021-09-27 16:33:34 cfgState ok
2021-09-27 16:17:32 commState CMDs_done
2021-09-27 16:17:32 motor stop
2021-05-13 17:53:25 motorErr ok
2021-09-27 16:17:32 operState onTarget
2021-07-29 13:17:43 operStateErrCnt 16
2021-09-27 16:23:28 peerList VentilControler.AZ.Nord_Btn1
2021-09-27 16:17:32 recentStateType ack
2021-09-27 16:17:32 state 0
helper:
HM_CMDNR 168
cfgStateUpdt 0
mId 003A
oldDes 0
peerFriend
peerIDsState complete
peerOpt p:thermostat
regLst 0,5
rxType 12
tmplChg 0
cmds:
TmplKey VentilControler.AZ.Nord_Btn1:1632752595.86026:1632752608.82646
TmplTs 1632752608.82646
cmdKey 1:1:0::Ventil.AZ.Nord:003A:01:VentilControler.AZ.Nord_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|List7) [-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.AZ.Nord_Btn1 -tplPeer-
unpair noArg
valvePos [({off}|0.0..99.0;0.5)]
lst:
condition slider,0,1,255
peer VentilControler.AZ.Nord_Btn1
peerOpt remove_VentilControler.AZ.Nord_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:
flgs 0
newChn +1C4E25,00,00,00
rxt 2
vccu ccu
p:
1C4E25
00
00
00
prefIO:
hmlan1
mRssi:
mNo
peerIDsH:
00000000 broadcast
B5B5B501 VentilControler.AZ.Nord_Btn1
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
shadowReg:
tmpl:
Attributes:
.mId 003A
IOgrp ccu:hmlan1
actCycle 001:30
actStatus alive
alias 40. Ventil.AZ.Nord
autoReadReg 5_readMissing
comment batChange: 2021-03-03 09:28:25 critical (oldBat: low since 2020-12-18 16:26:27)
event-on-change-reading .*
expert defReg,allReg,rawReg,templ
firmware 2.0
group Heizung.AZ
model HM-CC-VD
msgRepeat 0
peerIDs 00000000,B5B5B501
room 20_AZ,98_Ventile
serialNr JEQ0312631
stateFormat Vsoll:ValveDesired, Vist:ValvePosition, Status:state, Operation:operState, OpErr:operStateErrCnt, Mot:motor, MotErr:motorErr, Bat:battery, Verr:R-valveErrorPos, Voff:R-valveOffset
subType thermostat
timestamp-on-change-reading battery,motorErr
webCmd getConfig
Internals:
.AttrList .devInfo .mId .stc IODev IOgrp actCycle actStatus aesCommReq:1,0 aesKey:5,4,3,2,1,0 autoReadReg:0_off,1_restart,2_pon-restart,3_onChange,4_reqStatus,5_readMissing,8_stateOnly burstAccess:0_off,1_auto commStInCh:on,off cyclicMsgOffset do_not_notify:1,0 dummy:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading expert:multiple,defReg,allReg,rawReg,templ,none firmware hmKey hmKey2 hmKey3 hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger ignore:1,0 model modelForce:ACTIONDETECTOR,ACTIONDETECTOR,ASH550,ASH550I,CCU-FHEM,CMM,DORMA_ATENT,DORMA_BRC-H,DORMA_RC-H,HM-CC-RT-DN,HM-CC-RT-DN-BOM,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-DIS-EP-WM55,HM-DIS-TD-T,HM-DIS-WM55,HM-DW-WM,HM-ES-PMSW1-DR,HM-ES-PMSW1-PL,HM-ES-PMSW1-PL-DN-R1,HM-ES-PMSW1-PL-DN-R2,HM-ES-PMSW1-PL-DN-R3,HM-ES-PMSW1-PL-DN-R4,HM-ES-PMSW1-PL-DN-R5,HM-ES-PMSW1-SM,HM-ES-TX-WM,HM-HM-LC-DW-WM,HM-LC-AO-SM,HM-LC-BL1-FM,HM-LC-BL1-FM-2,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-BL1-SM-2,HM-LC-BL1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-CV-2,HM-LC-DIM1L-CV-644,HM-LC-DIM1L-PL,HM-LC-DIM1L-PL-2,HM-LC-DIM1L-PL-3,HM-LC-DIM1L-PL-644,HM-LC-DIM1PWM-CV,HM-LC-DIM1PWM-CV-2,HM-LC-DIM1T-CV,HM-LC-DIM1T-CV-2,HM-LC-DIM1T-CV-644,HM-LC-DIM1T-DR,HM-LC-DIM1T-FM,HM-LC-DIM1T-FM-2,HM-LC-DIM1T-FM-644,HM-LC-DIM1T-FM-LF,HM-LC-DIM1T-PL,HM-LC-DIM1T-PL-2,HM-LC-DIM1T-PL-3,HM-LC-DIM1T-PL-644,HM-LC-DIM1TPBU-FM,HM-LC-DIM1TPBU-FM-2,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2L-SM-2,HM-LC-DIM2L-SM-644,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM-2,HM-LC-JA1PBU-FM,HM-LC-RGBW-WM,HM-LC-SW1-BA-PCB,HM-LC-SW1-DR,HM-LC-SW1-FM,HM-LC-SW1-FM-2,HM-LC-SW1-PB-FM,HM-LC-SW1-PCB,HM-LC-SW1-PL,HM-LC-SW1-PL-3,HM-LC-SW1-PL-CT-R1,HM-LC-SW1-PL-CT-R2,HM-LC-SW1-PL-CT-R3,HM-LC-SW1-PL-CT-R4,HM-LC-SW1-PL-CT-R5,HM-LC-SW1-PL-DN-R1,HM-LC-SW1-PL-DN-R2,HM-LC-SW1-PL-DN-R3,HM-LC-SW1-PL-DN-R4,HM-LC-SW1-PL-DN-R5,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-2,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW1PBU-FM,HM-LC-SW2-DR,HM-LC-SW2-DR-2,HM-LC-SW2-FM,HM-LC-SW2-FM-2,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW2PBU-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-DR-2,HM-LC-SW4-PCB,HM-LC-SW4-PCB-2,HM-LC-SW4-SM,HM-LC-SW4-SM-2,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-SW4-WM-2,HM-MOD-EM-8,HM-MOD-EM-8BIT,HM-MOD-RE-8,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CFM-TW,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-FM,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-2-WM55-2,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-4DIS-WM-2,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-2-PBU-FM,HM-RC-2-PBU-FM-2,HM-RC-4,HM-RC-4-2,HM-RC-4-3,HM-RC-4-3-D,HM-RC-4-B,HM-RC-8,HM-RC-DIS-H-X-EU,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-KEY4-2,HM-RC-KEY4-3,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-SEC4-2,HM-RC-SEC4-3,HM-SCI-3-FM,HM-SEC-CEN,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-MDIR-2,HM-SEC-MDIR-3,HM-SEC-RHS,HM-SEC-RHS-2,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-SCO,HM-SEC-SD,HM-SEC-SD-2,HM-SEC-SFA-SM,HM-SEC-SIR-WM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-DB-PCB,HM-SEN-EP,HM-SEN-LI-O,HM-SEN-MDIR-O,HM-SEN-MDIR-O-2,HM-SEN-MDIR-O-3,HM-SEN-MDIR-SM,HM-SEN-MDIR-WM55,HM-SEN-RD-O,HM-SEN-WA-OD,HM-SWI-3-FM,HM-SYS-SRP-PL,HM-TC-IT-WM-W-EU,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS100-C6-O-2,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-OT2-SM-2,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550TECH,IS-WDS-TH-OD-S-R3,KFM-DISPLAY,KFM-SENSOR,KS550,KS550LC,KS550TECH,KS888,OLIGO-SMART-IQ-HM,PS-SWITCH,PS-TH-SENS,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FFK,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FSS-UP3,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,S550IA,SCHUECO_263-130,SCHUECO_263-131,SCHUECO_263-132,SCHUECO_263-133,SCHUECO_263-134,SCHUECO_263-135,SCHUECO_263-144,SCHUECO_263-145,SCHUECO_263-146,SCHUECO_263-147,SCHUECO_263-155,SCHUECO_263-157,SCHUECO_263-158,SCHUECO_263-160,SCHUECO_263-162,SCHUECO_263-167,SCHUECO_263-XXX,SENSOTIMER-ST-6,VIRTUAL,WDF-SOLAR,WS888 msgRepeat oldreadings param readOnly:0,1 readingOnDead:multiple,noChange,state,periodValues,periodString,channels rssiLog:1,0 serialNr showtime:1,0 stateFormat:textField-long subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,display,keyMatic,motionAndBtn,motionDetector,no,outputUnit,powerMeter,powerSensor,pushButton,remote,repeater,rgb,senBright,sensRain,sensor,singleButton,siren,smokeDetector,swi,switch,thermostat,threeStateSensor,timer,tipTronic,virtual,winMatic timestamp-on-change-reading
DEF B5B5B5
FUUID 5c4ce2e9-f33f-09c4-41e8-f94c9a0ee1c747e2
IODev hmlan1
NAME VentilControler.AZ.Nord
NR 282
NTFY_ORDER 50-VentilControler.AZ.Nord
STATE CMDs_done
TYPE CUL_HM
channel_01 VentilControler.AZ.Nord_Btn1
disableNotifyFn 1
.attreour:
state
.attrminint:
CL:
Authenticated 0
BUF
FD 79
FW_ID 1176
LASTACCESS 1632755865
NAME WEB_192.168.1.31_50567
NR 1723
PEER 192.168.1.31
PORT 50567
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
.attraggr:
.attrminint:
READINGS:
2021-09-27 17:16:55 state Connected
READINGS:
2021-09-27 16:17:31 .protLastRcv 20210927161731
2021-06-10 00:22:05 CommandAccepted yes
2021-09-27 16:23:26 IODev hmlan1
2021-09-27 16:33:34 cfgState ok
2021-06-10 00:22:05 commState CMDs_done
2021-06-10 00:22:05 state CMDs_done
helper:
HM_CMDNR 223
mId FFF1
peerFriend -
peerOpt -:virtual
regLst 0
rxType 1
tmplChg 0
cmds:
TmplKey :1632752595.86026:1632752608.86521
TmplTs 1632752608.86521
cmdKey 0:1:1::VentilControler.AZ.Nord:FFF1:00:
cmdLst:
assignHmKey noArg
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
raw -data- [...]
reset noArg
unpair noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
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
IOgrp ccu:hmlan1
event-on-update-reading state
expert defReg,rawReg
group Heizung.AZ
model VIRTUAL
msgRepeat 0
room 20_AZ
subType virtual
webCmd press short:press long
Internals:
.triggerUsed 1
DEF B5B5B501
FUUID 5c4ce2e9-f33f-09c4-f9b9-f192af5a6a6260d0
NAME VentilControler.AZ.Nord_Btn1
NR 283
NTFY_ORDER 50-VentilControler.AZ.Nord_Btn1
STATE Vsoll: 0 %, Status: ValveAdjust:0 %, Kommunikation: ok, Error (tot/lost/avg): 1665 / 21 / 12.2, Modus: msgReduce:2
TYPE CUL_HM
chanNo 01
device VentilControler.AZ.Nord
disableNotifyFn 1
peerList Ventil.AZ.Nord
.attraggr:
.attreocr:
.*
.attreour:
state
valvePosTC
.attrminint:
.userReadings:
HASH(0x38ef780)
HASH(0x38f7348)
CL:
Authenticated 0
BUF
FD 79
FW_ID 1176
LASTACCESS 1632755898
NAME WEB_192.168.1.31_50567
NR 1723
PEER 192.168.1.31
PORT 50567
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
.attraggr:
.attrminint:
READINGS:
2021-09-27 17:16:55 state Connected
READINGS:
2021-09-27 16:23:28 .associatedWith VentilControler.AZ.Nord,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.Nord,Ventil.AZ.Nord
2021-09-27 16:17:41 .next 206;1632752377.87581
2021-09-27 16:33:34 cfgState ok
2021-06-10 00:22:05 commState CMDs_done
2021-05-13 17:53:25 ctrStart 2021-05-13 17:53:25
2021-09-27 15:21:54 errorAvg 12.2
2021-09-27 15:21:54 errorCtr 1665
2021-09-27 15:23:57 errorState ok
2021-07-29 13:00:40 lostCtr 21
2021-09-27 12:44:26 msgReduce msgReduce:2
2021-09-27 16:23:28 peerList Ventil.AZ.Nord
2021-09-27 12:44:26 state ValveAdjust:0 %
2021-09-27 15:23:57 valveCtrl ok
2021-09-27 15:23:57 valveCtrlRam ok
2021-09-27 12:44:26 valvePosTC 0 %
helper:
fkt vdCtrl
peerFriend peerSD,peerSens,peerAct
peerIDsState incomplete
peerOpt -:virtual
regLst
tmplChg 0
cmds:
TmplKey Ventil.AZ.Nord:1632752595.86026:1632752608.88651
TmplTs 1632752608.88651
cmdKey 1:0:1:vdCtrl:VentilControler.AZ.Nord:FFF1:01:Ventil.AZ.Nord
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.AZ.Nord -tplPeer-
valvePos (off|0.0..99.0;0.1)
lst:
condition slider,0,1,255
peer Ventil.AZ.Nord
peerOpt DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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.West_Btn1,VentilControler.Bad_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)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
expert:
def 1
det 0
raw 1
tpl 0
peerIDsH:
1C4E2501 Ventil.AZ.Nord_chn-01
role:
chn 1
vrt 1
shadowReg:
tmpl:
Attributes:
alias 30. Controler.AZ.Nord
event-on-change-reading .*
event-on-update-reading state,valvePosTC
group Heizung.AZ
model VIRTUAL
param msgReduce:2
peerIDs 1C4E2501
room 20_AZ,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 long
workaround für das "attr param msgReduce:x"
1. cul_hm version von beta-user nutzen https://forum.fhem.de/index.php/topic,122422.msg1176632.html#msg1176632 (https://forum.fhem.de/index.php/topic,122422.msg1176632.html#msg1176632)
damit kann man das attr im channel des vtc wieder einstellen/verändern.
2. nach jedem fhem restart muss nun noch das attribut explizit erneut gesetzt werden.
Zwischeninfo: meine "Trefferwahrscheinlichkeit" für das korrekte Setzen von .AttrList bei den RT's erhöht sich scheinbar, wenn ca. in #9658
foreach (sort keys %{$culHmModel}){statt
foreach (keys %{$culHmModel}){steht. Evtl. hilft das auch hier? (Die anderen sort-Anweisungen werden damit aber nicht alle überflüssig, das ist irgendwie vertrackt, und ich bin daher nach wie vor nicht sicher, ob das alles war).
sortieren kann ich mir sparen.
es gibt kein internal .AttrList in keinem virtuellen channel.
Das Problem ist nach meinem Verständnis nicht, dass man was vorhandenes sortieren müßte, sondern dass nur was vorhanden ist, wenn die Kanäle in der richtigen Reihenfolge geprüft werden.
Wie im Testsszenarium beschrieben: Mal ist was da, mal nicht. Sowas passiert mAn. im Perl-Umfeld nur, wenn ein unsortierter Hash-Zugriff stattfindet.
Ein Tipp noch: Direkt nach dem Starten mal am Kanal ein refresh ausführen (also "alte FHEM-Seite" offenlassen, den Startbefehl auf der Linux-Kommandozeile abschicken und dann gleich F5@Firefox). Dann bekommt man (ganz ohne Internal .AttrList) die Attributliste aus dem Anhang, sobald die Sanduhr um ist.
Erst danach wird gekappt und das Internal ist nach einem neuerlichen refresh dann da.
Was uns also (auch) interessiert, ist was zwischen dem initialen Einlesen der cfg und dem "Normalbetrieb" passiert...
hier gibt es bisher kein voodoo und kein wackekontakt. :)
alle 6 entities besitzen das attribut param, es war nie weg und immer auszuwählen.
ich hätte auch ohne deine version gestern ein attribut param setzen können. es gab aber eine falsche voreinstellung mit falscher fester argument liste.
mit deiner version kann ich, wie schon immer das argument selber schreiben, ohne liste. (doch zufall?)
dadurch konnte ich das richtige argument setzen.
ein setzen über cmdline hatte ich vorher nicht probiert.
alle fehler die ich bisher sehe, haben mit einem gestörten cul_hm start zu tun. das war noch nie ohne bugs/reibungsverluste.
scheinbar ist das konstrukt selbst für martin "undurchschaubar" mit 1000 sonderlocken. sobald martin an einer ecke "optimiert" funktioniert vieles nur noch "solala" oder gar nicht mehr.
Zitat von: frank am 28 September 2021, 16:49:23
hier gibt es bisher kein voodoo und kein wackekontakt. :)
"Voodoo" ist mein Testszenarium eigentlich nicht, aber man kann damit schön demonstrieren, wie sich "einfache" Hash-Zugriffe auswirken, nämlich genau: Zufällig, falls es kein eindeutiges Ergebnis gibt bzw. man eine Schleife über die (unsortierte!) key-Liste laufen läßt. Oft ist es wirklich egal, in welcher Reihenfolge z.B. keys gelöscht werden. Aber sobald eine nachfolgende Aktion erwartet, dass vorher was sauber durch ist, geht es eben nicht (immer) so aus wie erwünscht, sondern es ist eine moderne Form des Würfelns.
EDIT:
Zitat... und das fällt auf
- Bei der Initialisierung wird zuerst der Schlüssel übergeben und dann der Wert.
- Man ordnet dem Hash ein Array zu!
- Bei Hashes gibt es keine Reihenfolge! Ursache: Die Daten werden nach einem speziellen internen Verfahren gespeichert, auf das man als Programmierer keinen Zugriff hat.
EDIT 2: zum Testen:
{my %test=(1=>1,2=>2,3=>3);;my @y = keys %test;; return join q{ }, @y;;}Einfach mehrfach in die FHEM-Kommandozeile werfen...
Zitat
alle 6 entities besitzen das attribut param, es war nie weg und immer auszuwählen.
ich hätte auch ohne deine version gestern ein attribut param setzen können. es gab aber eine falsche voreinstellung mit falscher fester argument liste.
OK, das kam hier nicht so deutlich an, wo genau das Problem liegt
Zitat
mit deiner version kann ich, wie schon immer das argument selber schreiben, ohne liste. (doch zufall?)
Nach meiner Testerei würde ich behaupten: Begrenzung der Wahrscheinlichkeiten für bestimmte Effekte in der Initialisierung der CUL_HM-Geräte-Hashes, also teilweise gesteuerter Zufall ;) .
Zitat
dadurch konnte ich das richtige argument setzen.
ein setzen über cmdline hatte ich vorher nicht probiert.
Soweit ich das überblicke, geht über cmdline nur, was auch in den dropdowns ist. Nur über direktes cfg-Edit kann man das (ggf. nur temporär) überspielen, und wenn die neueren CUL_HM-Versionen etwas nicht mögen/kennen, hauen die das auch (timergesteuert in der Initialisierung) weg.
Zitat
alle fehler die ich bisher sehe, haben mit einem gestörten cul_hm start zu tun. das war noch nie ohne bugs/reibungsverluste.
scheinbar ist das konstrukt selbst für martin "undurchschaubar" mit 1000 sonderlocken. sobald martin an einer ecke "optimiert" funktioniert vieles nur noch "solala" oder gar nicht mehr.
Nach meinem Eindruck ist es v.a. deswegen undurchschaubar, weil eben mit dem "Universalwerkzeug" "for (keys %whatever)" mit nicht deterministisch sortierten Arrays gearbeitet wird/wurde. Es kann durchaus sein, dass die sort-Aktionen neue Probleme bringen und man die Durchläufe ggf. auch anders strukturieren muss. Aber das ganze weiter dem Zufall zu überlassen halte ich mit meinem heutigen Kenntnisstand für einen handwerklichen Fehler. Und das ganze betrifft definitiv mehrere Stellen, was die Zahl der möglichen Varianten wohl nicht unbedingt verkleinert...
Wenn es sortiert Probleme gibt, muss man die für die Initialisierung erforderlichen Arrays mit den keywords nochmal irgendwo gesondert definieren und dann eben die Codes in den Schleifen entsprechend der erforderlichen Reihenfolge abarbeiten. Nicht schön, weil es weitere Komplexität und zusätzlichen Pflegebedarf verursacht, aber m.E. gibt es keinen anderen Weg. Kann aber natürlich sein, dass es irgendwo eine "Hauptliste" gibt und es schon ausreicht, die "richtig herum" zu initialisieren. Wenn wir Glück haben, sind die "sort"-Anweisungen "zufällig" gleich richtig herum, denn ganz schlimm kann es eigentlich (vor der "Härtung") nicht gewesen sein.
Ich werde meine neue Version nachher mal ins Hauptsystem packen, mal sehen, ob ich dann wieder eine kalte Dusche bekomme...
neue erkenntnisse zum kaputten autostart des vtc:
im log ist zu sehen, dass der befehl valvePos doch automatisch kommt.
allerdings ist valvePos zu dem zeitpunkt noch unbekannt, wodurch der automatismus stirbt.
2021.09.29 20:47:50.868 3: set VentilControler.Bad_Btn1 valvePos 32 : Unknown argument valvePos, choose one of press getRegRaw regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,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 postEvent:slider,0,1,255 getConfig:noArg peerChan
2021.09.29 20:47:51.022 3: set VentilControler.Kueche_Btn1 valvePos 91 : Unknown argument valvePos, choose one of press getRegRaw regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255 regBulk peerBulk getConfig:noArg peerChan
2021.09.29 20:47:51.083 3: set VentilControler.WZ_Btn1 valvePos 0 : Unknown argument valvePos, choose one of clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all regSet press getRegRaw getConfig:noArg peerChan regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255
2021.09.29 20:47:51.122 3: set VentilControler.AZ.Nord_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press getRegRaw getConfig:noArg peerChan regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255
2021.09.29 20:47:51.162 1: CUL_HM start inital cleanup
2021.09.29 20:47:56.055 1: CUL_HM finished initial cleanup
Zitat von: frank am 30 September 2021, 10:18:22
nein, beim virtuellen tc hat sich nichts geändert.
Nachdem ich die lists hier nochmal durchgesehen hatte, habe ich auch eine Idee, warum das so ist:
VIRTUAL-Geräte werden erst mal gesondert behandelt...
Hier scheint noch dazuzukommen, dass der Befehl wohl erst verfügbar wird, wenn bekannt ist, welcher Typ der peer ist, oder deute ich mein Testsystem falsch?
Evtl. muss man beim Start erst mal pauschal alle Befehle verfügbar machen, bis die Initialisierung drüber ist (wie bei den Attributen)?
Was mir aber auffällt: der vtc hat keinen subType (mehr?). Kannst du den mal setzen und dann nochmal testen?UU. führt dann CUL_HM_updateConfig() (dort #424ff) dazu, dass das Paket wieder auf den Weg gebracht wird?(EDIT: Sollte eigentlich automatisch auf "virtual" gesetzt werden...?)
Zitat von: frank am 30 September 2021, 10:18:22
hminfo configcheck findet weiterhin keinen fehler, wenn kein attribut gesetzt ist.
das war damals der grund das attribut mit none zu setzen.
HMinfo hatte ich bisher erst mal ausgeblendet. Letztlich hatte das auf die zugrundeliegenden Probleme ja keinen Einfluss. Allerdings war mir schon länger suspekt, dass da getConfig-Befehle in größerer Zahl _an immer wieder dieselben Geräte_ rausgegangen sind zwischen "start initial cleanup" und "finish". Den Teil wollte ich eigentlich als nächstes ansehen, aber vermutlich ist die Initialisierung der "VIRTUAL" wichtiger?
ZitatWas mir aber auffällt: der vtc hat keinen subType (mehr?).
doch, das hauptdevice vom vtc hat attr subType.
auch haben device und channel jeweils {role}{vrt}
im prinzip wird nur zu "verabredeten" zeiten periodisch an die vd gefunkt (valvePos/keepalive).
direkt beim restart wird aber
sofort ein keepalive rausgehauen, unabhängig vom richtigen zeitpunkt.
eigentlich hat mich das schon immer gestört, aber scheinbar wichtig, damit der autostart erstmal anläuft.
erst die weiteren messages erfolgen wieder zu den
berechneten zeitpunkten.
Zitatvermutlich ist die Initialisierung der "VIRTUAL" wichtiger?
das wichtigste für mich wäre der autostart der vtc, damit die ventile nach restart nicht grundsätzlich einschlafen.
denn sonst ist die heizung 90min aus, oder ich renne durchs haus und muss alles manuell wieder starten.
über ein verzögertes, automatisches senden von valvePos über mein INITIALIZED-notify springt zwar das automatische senden der keepalive wieder an, aber scheinbar stimmen dann die sendezeitpunkte nicht, da bisher immer alle vd einschlafen.
Gefährlich bzw. unklar, was damit an Nebenwirkungen verbunden ist, aber testweise wäre das Abfangen des Kommands in der Initialisierungsphase deaktiviert, wenn man #5059 so ändert:
if(!defined $hash->{helper}{cmds}{cmdLst}{$cmd} && defined $hash->{helper}{cmds}{cmdLst}{cmdKey}) { ### unknown - return the commandlist if initialisation is done
wenn, dann meinst du wohl eher
if(!defined $hash->{helper}{cmds}{cmdLst}{$cmd} && defined $hash->{helper}{cmds}{cmdKey}) { ### unknown - return the commandlist if initialisation is done
mal schauen...
Ups, klar...
Wenn ich das richtig überblicke, sollte man dann ggf. nur im "else"-Fall (ganz unten...) auch noch unterscheiden, ob der betreffende Hash defined ist oder nicht und dann während der Initialisierung für einen unbekannten command eine etwas andere Rückmeldung geben.
Nachtrag zu:
Zitat von: frank am 28 September 2021, 16:49:23
ich hätte auch ohne deine version gestern ein attribut param setzen können. es gab aber eine falsche voreinstellung mit falscher fester argument liste.
Beim Rumtesten damit ist mir aufgefallen, dass mal wieder "Voodoo" im Spiel ist und die "falsche argument liste" eben nicht fest ist, sondern mit jedem Neustart anders auf einen festen Wert eingestellt wird.
"Meine Lieblingslösung" gegen Voodoo ist mal wieder sort, hier in doppelter Ausführung ab #1394
$hash->{AttrList} = join(" ",sort #Beta-User: double sorting in map and noDup seems to bind empty preselection for param to VIRTUAL channel (textfield)
map{my ($foo) = sort keys %{$hash->{ModulAttr}{$_}}; # use first option
my $val = $hash->{AttrX}{$foo}{$_};
$_.($val ? ':'.$val # add colon
: '')
}
CUL_HM_noDup(sort keys %{$hash->{ModulAttr}}) # each attr just once
);Damit ergab sich beim Testen jedenfalls immer ein leeres Eingabefeld. Auch hier kann ich unerwünschte Nebenwirkungen mal wieder nicht ausschließen, glaube aber, dass "sort" besser ist wie Hash-Voodoo....
Komisch ist aber, dass sich das Setzen des param-Attributs zwar auswirkt, man aber keinen Seitenrefresh und damit keine Rückmeldung bekommt - das ist aber scheinbar generell das Verhalten von CUL_HM und nicht spezifisch für dieses eine (lange nichts mehr an meinen Geräten geändert, jedenfalls nicht via Detail-View...)
dies ist grosser murks:
if(!defined $hash->{helper}{cmds}{cmdLst}{$cmd} && defined $hash->{helper}{cmds}{cmdKey}) { ### unknown - return the commandlist if initialisation is done
nur 1 von 6 ventilen hat es geschaft.
zu beginn ein paar
set VentilControler.Bad_Btn1 valvePos 22 : virtual TC support one VD only. Correct number of peers
ausserdem gibt es am laufenden meter ohne ende ständig warnings mit unterschiedlichen zeilen:
PERL WARNING: Use of uninitialized value $paraOpts in substitution (s///) at ./FHEM/10_CUL_HM.pm line 5140.
diverse getconfigs, statusrequest für andere devices sind wohl auch betroffen.
:( Hmm, dann legen wir diese Idee mal besser zur Seite...
Wo kommt eigentlich die "Salve" vor "initial cleanup" her:
Zitat von: frank am 30 September 2021, 10:27:39
2021.09.29 20:47:50.868 3: set VentilControler.Bad_Btn1 valvePos 32 : Unknown argument valvePos, choose one of press getRegRaw regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,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 postEvent:slider,0,1,255 getConfig:noArg peerChan
2021.09.29 20:47:51.022 3: set VentilControler.Kueche_Btn1 valvePos 91 : Unknown argument valvePos, choose one of press getRegRaw regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255 regBulk peerBulk getConfig:noArg peerChan
2021.09.29 20:47:51.083 3: set VentilControler.WZ_Btn1 valvePos 0 : Unknown argument valvePos, choose one of clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all regSet press getRegRaw getConfig:noArg peerChan regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255
2021.09.29 20:47:51.122 3: set VentilControler.AZ.Nord_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press getRegRaw getConfig:noArg peerChan regBulk peerBulk peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 postEvent:slider,0,1,255
2021.09.29 20:47:51.162 1: CUL_HM start inital cleanup
2021.09.29 20:47:56.055 1: CUL_HM finished initial cleanup
Ist das "on board" von CUL_HM oder ein "initialized"-notify (oä.)? Wenn ja: könnte man da einen (kurzen) Timer davor setzen, dass erst initial cleanup durchlaufen kann und die Peers etc. ausgewertet sind?
guter hinweis... , das habe ich völlig verdrängt und dann falsch "eingeordnet". zu viele baustellen gleichzeitig. :)
das muss aus meinem at kommen, dass die hzg regelung alle 60s prüft und ggf ändert. deshalb auch nur immer 4 von 6. diese meldungen kommen aber erst mit aktueller cul_hm.
das bedeutet aber, dass der vtc start in cul_hm_updateconfig doch gar nicht zündet, wovon ich fälschlicherweise ausgegangen bin.
da müssen wohl doch mal ein paar logs in den code.
eigentlich müsste cul_hm ein "homematic_ready" event erzeugen. scheinbar ist global:initialized jetzt viel zu früh.
Boa, alles sehr abstrakt...
Das mit dem CUL_HM:ready-trigger halte ich für eine gute Idee, kann eigentlich nicht schaden, das zusammen mit dem Log-Eintrag für "initial cleanup" rauszuhauen.
Was das at angeht, müßte ggf. ein Hash-Element geprüft werden, in dem steht, ob CUL_HM jetzt "initdone" ist (oder .AttrList vorhanden?). Andererseits sind die Log-Einträge ja gar nicht das Problem, ist halt unschön. Generell ist aber zum einen die Frage, ob das initiale Senden des letzten Werts wirklich nicht implementiert ist (ich meine schon, kann nur sein, dass es (Voodoo?) nicht funktioniert?)? Zum anderen: Wenn man einen Timer braucht (?), wäre es dann nicht besser, den auch direkt in CUL_HM mit reinzucoden und nur (via param-Attribut?) die Timerdauer jeweils einstellbar zu machen? (Schon klar, dass das noch eine Sonderlocke ist, aber irgendwie, na ja... weiß auch nicht...).
Zuletzt&hier OT: Da gibt es eine Variable in main:: ($evtDly). die ist mir hochgradig suspekt, auch wenn irgendwo die Entschuldigung steht, dass das zu verwalten doch eigentlich fhem.pl besser übernehmen sollte.
Nochmal zurück zum Startup-Mechanismus in CUL_HM: Das/die at feuern vor dem CUL_HM_updateConfig(), weil da initial gar kein Timer gesetzt wird, sondern der erst in der NotifyFn erzeugt wird.
Könnte man dadurch bereinigen, dass man es in DefFn mit reinnimmt, was aber dann (so man nicht noch eine Abfrage reinbastelt) viele Timer erzeugt (die dann aber sowieso alle wieder abgeräumt würden, sobald der erste CUL_HM_updateConfig() aufruft). Hab' mal testweise nach "Initialize" gedoppelt, das funktioniert auch und sollte dann genau einen (zusätzlichen) Timer erzeugen (ggf. zu dem aus der NotifyFn).
Das hat nur zwei Probleme: a) ist es vermutlich nicht "rereadcfg-fest" (was mir persönlich aber herzlich gleichgültig wäre) und b) bleibt es (zumindest auf den ersten Blick) empfindlich gegen eine "falsche Reihung" in der cfg. Evtl. kann man da noch tricksen, indem man nicht "1" als Zeit mitgibt, sondern "0.1", aber "na ja"...
Meinungen dazu?
Weiter ist in (ca.) #427 eigentlich eine Timer-Funktion für den vdCrtl eingebaut. Die Frage wäre also: Funktioniert die nicht, oder warum braucht man ein at?
Als erstes fällt auf, dass da kein nummerischer Wert als default hinterlegt ist. Kann natürlich sein, dass das sinnvoll ist, aber wenn es nur nummerische (Prozent-) Werte geben darf, würde ich eher vorschlagen, gleich ReadingsNum zu verwenden und "halbe Kraft voraus" als default zu hinterlegen?
if ($hash->{helper}{fkt} eq "vdCtrl"){
my $d = ReadingsNum($name,'valvePosTC','50');
CUL_HM_Set($hash,$name,"valvePos",$d);
CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
RemoveInternalTimer("valvePos:$vId");
RemoveInternalTimer("valveTmr:$vId");
InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
Meinungen?
Betr. "reg not found" (https://forum.fhem.de/index.php/topic,123139.0.html):
Das bezieht sich auf die offizielle Version und das Problem ist auch nicht durch die Sortiererei "gegessen"?
Zitat von: Beta-User am 01 Oktober 2021, 12:08:03
Weiter ist in (ca.) #427 eigentlich eine Timer-Funktion für den vdCrtl eingebaut. Die Frage wäre also: Funktioniert die nicht, oder warum braucht man ein at?
mein at ist für die regelung meiner therme und in den räumen für die einstellung der ventile, die ich über fhem/pid20 einstelle. damit berechne ich die nötigen ventileinstellungen.
der timer in fhem sorgt dafür, dass regelmässig und nur zu ganz bestimmten zeiten die messages mit der valvepos (keepalive) an den vd gesendet werden. empfängt der vd 6x nichts, schläft der vd 60min ein.
so ähnlich wie die virtuellen tempfühler für den rt, aber etwas komplizierter.
die logmeldungen sind aber erstmal völlig egal, vielleicht sind sie wieder weg, wenn der autostart wieder funktioniert.
ZitatAls erstes fällt auf, dass da kein nummerischer Wert als default hinterlegt ist. Kann natürlich sein, dass das sinnvoll ist, aber wenn es nur nummerische (Prozent-) Werte geben darf, würde ich eher vorschlagen, gleich ReadingsNum zu verwenden und "halbe Kraft voraus" als default zu hinterlegen?
if ($hash->{helper}{fkt} eq "vdCtrl"){
my $d = ReadingsNum($name,'valvePosTC','50');
CUL_HM_Set($hash,$name,"valvePos",$d);
CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
RemoveInternalTimer("valvePos:$vId");
RemoveInternalTimer("valveTmr:$vId");
InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
zur zeit habe ich den verdacht, dass diese stelle nicht erreicht wird, weil irgendwelche bedingungen noch nicht gesetzt sind.
Zitat von: frank am 01 Oktober 2021, 15:26:06
mein at ist für die regelung meiner therme und in den räumen für die einstellung der ventile, die ich über fhem/pid20 einstelle. damit berechne ich die nötigen ventileinstellungen.
Damit ist jedenfalls mAn. die Umstellung auf eine rein timerbasierte Initialisierung zwingend, und evtl. sollten wir versuchen, die CUL_HM-Initialisierung im Timer-Array ganz nach vorne zu mogeln. Deine Lösung ist m.E. ein typischer Anwendungsfall...
Zitat
der timer in fhem sorgt dafür, dass regelmässig und nur zu ganz bestimmten zeiten die messages mit der valvepos (keepalive) an den vd gesendet werden. empfängt der vd 6x nichts, schläft der vd 60min ein.
so ähnlich wie die virtuellen tempfühler für den rt, aber etwas komplizierter.
Von daher dürfte es wichtig sein, dieses System so schnell wie möglich nach einem FHEM-Start wieder zum Einschwingen zu bringen und nicht erst lange zu warten.
Zitat
die logmeldungen sind aber erstmal völlig egal, vielleicht sind sie wieder weg, wenn der autostart wieder funktioniert.
Nach meinem Verständnis wären die Einträge an sich wirklich egal ;) . Das dahinterliegende Problem dürfte nur sein, dass der Code so geschrieben und kommentiert ist, dass das eigentlich nicht passieren sollte. Ergo gehe ich davon aus, dass es wichtig ist, erst mal zu verhindern, dass der Code zur falschen Zeit (schon) aufgerufen wird, weil dadurch uU. inkonsistente Systemzustände vermieden werden (deren Symptome wir hier ggf. diskutieren?).
Zitat
zur zeit habe ich den verdacht, dass diese stelle nicht erreicht wird, weil irgendwelche bedingungen noch nicht gesetzt sind.
Dann wäre das m.E. einer der nächsten Punkte rauszufinden, woran es dafür genau hakt. Es könnte der "falsche" nicht-nummerische default gewesen sein (iVm. einem Aufruf vor $init_done).
Die Bausteinchen sind hier ja verteilt, ich würde nur gerne das ganze erst mal in Ruhe auf mein Echtsystem loslassen, bevor es wieder einen konsolidierten Stand zum Testen gibt, das kann uU. etwas dauern.
[OT]
Mit (oder wegen?) der "großen Schwester" habe ich im Browser (nur noch*) bei CUL_HM-Geräten ständig Timeout-Meldungen und offenbar refreshes der Detail-View-Seiten. Bisher war ich sowieso selten veranlaßt, die aufzurufen, aber derzeit... Irgendeinen Tipp auf die Schnelle und ins Blaue?
* = das war auch bei HMinfo so, das ist aber dort seit dem saveConfig anscheinend weg?
[/OT]
ich habe jetzt 3 logmeldungen eingebaut.
elsif ($st eq "virtual" ) {#setup virtuals
Log(1,"----- test1 ----- -> n:$name");
$hash->{helper}{role}{vrt} = 1;
if ( $hash->{helper}{fkt}
&& $hash->{helper}{fkt} =~ m/^(vdCtrl|virtThSens)$/){
Log(1,"----- test2 ----- -> n:$name");
my $vId = substr($id."01",0,8);
$hash->{helper}{vd}{msgRed}= 0 if(!defined $hash->{helper}{vd}{msgRed});
if(!defined $hash->{helper}{vd}{next}){
($hash->{helper}{vd}{msgCnt},$hash->{helper}{vd}{next}) =
split(";",ReadingsVal($name,".next","0;".gettimeofday()));
$hash->{helper}{vd}{idl} = 0;
$hash->{helper}{vd}{idh} = 0;
}
if ($hash->{helper}{fkt} eq "vdCtrl"){
Log(1,"----- test3 ----- -> n:$name");
my $d = ReadingsVal($name,"valvePosTC","");
$d =~ s/ %//;
CUL_HM_Set($hash,$name,"valvePos",$d);
CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
RemoveInternalTimer("valvePos:$vId");
RemoveInternalTimer("valveTmr:$vId");
InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
}
elsif($hash->{helper}{fkt} eq "virtThSens"){
my $d = ReadingsVal($name,"temperature","");
CUL_HM_Set($hash,$name,"virtTemp",$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
$d = ReadingsVal($name,"humidity","");
CUL_HM_Set($hash,$name,"virtHum" ,$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
}
# delete - virtuals dont have regs
delete $attr{$name}{$_} foreach ("autoReadReg","actCycle","actStatus","burstAccess","serialNr");
}
}
2021.10.01 16:39:09.216 1: CUL_HM start inital cleanup
2021.10.01 16:39:12.174 1: ----- test1 ----- -> n:SDTeam
2021.10.01 16:39:12.215 1: ----- test1 ----- -> n:SDTeam_Btn1
2021.10.01 16:39:13.297 1: ----- test1 ----- -> n:VentilControler.AZ.Nord
2021.10.01 16:39:13.321 1: ----- test1 ----- -> n:VentilControler.AZ.Nord_Btn1
2021.10.01 16:39:13.326 1: ----- test1 ----- -> n:VentilControler.AZ.West
2021.10.01 16:39:13.370 1: ----- test1 ----- -> n:VentilControler.AZ.West_Btn1
2021.10.01 16:39:13.375 1: ----- test1 ----- -> n:VentilControler.Bad
2021.10.01 16:39:13.399 1: ----- test1 ----- -> n:VentilControler.Bad_Btn1
2021.10.01 16:39:13.405 1: ----- test1 ----- -> n:VentilControler.Kueche
2021.10.01 16:39:13.428 1: ----- test1 ----- -> n:VentilControler.Kueche_Btn1
2021.10.01 16:39:13.434 1: ----- test1 ----- -> n:VentilControler.SZ
2021.10.01 16:39:13.477 1: ----- test1 ----- -> n:VentilControler.SZ_Btn1
2021.10.01 16:39:13.483 1: ----- test1 ----- -> n:VentilControler.WZ
2021.10.01 16:39:13.506 1: ----- test1 ----- -> n:VentilControler.WZ_Btn1
2021.10.01 16:39:13.784 1: ----- test1 ----- -> n:rssi_hmuart
2021.10.01 16:39:13.826 1: ----- test1 ----- -> n:rssi_hmuart_Btn1
2021.10.01 16:39:13.971 1: ----- test1 ----- -> n:virtAktorAlarmOff
2021.10.01 16:39:14.014 1: ----- test1 ----- -> n:virtAktorAlarmOff_Btn1
2021.10.01 16:39:14.043 1: ----- test1 ----- -> n:virt_vd
2021.10.01 16:39:14.110 1: ----- test1 ----- -> n:virt_vd_Btn1
2021.10.01 16:39:14.114 1: CUL_HM finished initial cleanup
danach fehlt zu diesem zeitpunkt mindestens {helper}{fkt} in den 6 entities VentilControler.*_Btn1 (vtc)
Demnach wären zwingend die Peers in diesem Fall vorab auszulesen?
Könnte so klappen (unsicher, was 1 oder 0 angeht):
elsif ($st eq "virtual" ) {#setup virtuals
$hash->{helper}{role}{vrt} = 1;
CUL_HM_ID2PeerList($name,'peerUnread',1) if !defined $defs{$name}{helper}{peerIDsH};
if ( $hash->{helper}{fkt}
&& $hash->{helper}{fkt} =~ m/^(vdCtrl|virtThSens)$/){
my $vId = substr($id."01",0,8);
leider keinen schritt weiter
Mal ohne defined- Bedingung?
Kann auch der Parameter sein...
ZitatMal ohne defined- Bedingung?
hat nur frust gebracht, da die peers dann weg waren.
:o Muss ich mir ansehen, aber eigentlich dürfte das nur der Fall sein, wenn der Code vor $init_done ausgeführt wird (weil dann die Attribute nicht komplett eingelesen sein müssen).
Irgendwas hängt da noch schräg...
du hattest doch mal virtuelle tempsensoren für die rt, oder?
die sollten doch ähnliche probleme haben und ihren if block nicht erreichen:
elsif($hash->{helper}{fkt} eq "virtThSens"){
my $d = ReadingsVal($name,"temperature","");
CUL_HM_Set($hash,$name,"virtTemp",$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
$d = ReadingsVal($name,"humidity","");
CUL_HM_Set($hash,$name,"virtHum" ,$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
}
Zitat von: frank am 30 September 2021, 18:01:23
zu viele baustellen gleichzeitig. :)
A propos: Hattest du bei dem Experiment vorher HMinfo angefasst? Das hatte ich nämlich gedanklich als "abgehakt" behandelt, aber leider evtl. nicht deutlich genug geäußert:
Zitat von: Beta-User am 01 Oktober 2021, 14:22:30
Für's erste wäre dann wohl ein hotfix, $init_done mit abzufragen?
if ( !$evtDly && $init_done #noansi: first Readings must be set, helps also not to disturb others
Wenn nicht, ist es einigermaßen wahrscheinlich, dass irgendwas (mangels Kenntnis der Attribut-Werte) Amok läuft,( weil verfrüht der Teil aus CUL_HM rückwärts aufgerufen wird, die 700+ Zeilen im Log)...
M.E. ist es nach etwas Nachdenken über den Punkt eigentlich eine Art "Muss", dass ein "optionales Hilfsmodul" wie HMinfo nicht die Art und Weise beeinflussen darf, wie sich "Münchhausen aus dem Sumpf zieht".
Muss das aber vermutlich wirklich alles im Zusammenhang auch selbst nochmal im Echtsystem laufen lassen, sonst ist es zu unübersichtlich.
PS: Mit den Versionen von gestern hatte ich im Echtsystem jedenfalls keine offensichtlichen Probleme mit meinen virtuellen entities: Einer der virtuellen Tempsensoren ist weg, da blinkt der RT. Das ist aber definitiv ok, weil der echte Sensor in der Tat keine aktuellen Daten liefert, die anderen scheinen online zu sein (sch... ZigBee (hier: Xiaomi), komischerweise sind die BT-Varianten einfach zuverlässigere Datenlieferanten...)
Guten Morgen,
das mit dem Weglassen der Abfrage ist in den gesammelten Werken in https://forum.fhem.de/index.php/topic,123198.msg1177351.html#msg1177351 immer noch so:
Zitat von: frank am 01 Oktober 2021, 18:35:21
hat nur frust gebracht, da die peers dann weg waren.
Daher ist die Abfrage da weiter drin. Meine virtuellen Temp-Sensoren werden aber auch nicht in der Initialisierung mit angefahren/geloggt, aber sowohl Werte wie Peers sind da; müßte daher ok sein.
fyi: Alle Funktionalität aus HMinfo ist jetzt "mit Gewalt" weg von Serverstart verschoben (mind. 30 Sek. müssen um sein, bevor die configCheck -f rausgehen).
Kann dieses WE nicht mehr viel machen, vielleicht findest du ja noch einen Dreh, wie man den virtuellen subType in der Initialisierung beibiegt, wes Geistes Kind sie sind...?
hallo beta-user,
jetzt hast du wohl wieder etwas voodoo eingebaut. 8)
ZitatMeine virtuellen Temp-Sensoren werden aber auch nicht in der Initialisierung mit angefahren/geloggt, aber sowohl Werte wie Peers sind da; müßte daher ok sein.
genauso bei meinen vtc.
2021.10.02 16:57:43.524 1: CUL_HM start inital cleanup
2021.10.02 16:57:48.395 1: CUL_HM finished initial cleanup
2021.10.02 16:57:49.085 1: events: Can't open ./FHEM/holiday/events.holiday: No such file or directory
2021.10.02 16:57:50.238 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:1579
2021.10.02 16:57:50.272 0: HourCounter hc_system_attak Run.598 first run done countsOverall:331
2021.10.02 16:57:50.584 3: CUL_HM set Thermostat.OZ_Climate statusRequest noArg
2021.10.02 16:57:50.720 1: HMLAN_Parse: hmlan1 new condition ok
2021.10.02 16:57:51.052 0: HMLAN_Parse: hmlan1 R:EB3B3B3 stat:0000 t:4A5385B5 d:FF r:FFD5 m:C2 A258 B3B3B3 193A9A 03DC
2021.10.02 16:57:51.056 0: HMLAN_Parse: hmlan1 R:EB1B1B1 stat:0000 t:4A538653 d:FF r:FFD5 m:48 A258 B1B1B1 1BFC52 03FD
2021.10.02 16:57:51.059 0: HMLAN_Parse: hmlan1 R:EB4B4B4 stat:0000 t:4A5386ED d:FF r:FFD5 m:86 A258 B4B4B4 1CE9F5 0300
2021.10.02 16:57:51.063 0: HMLAN_Parse: hmlan1 R:EB2B2B2 stat:0000 t:4A538751 d:FF r:FFD5 m:F5 A258 B2B2B2 1DFC2F 0300
2021.10.02 16:57:51.067 0: HMLAN_Parse: hmlan1 R:EB5B5B5 stat:0000 t:4A53880A d:FF r:FFD5 m:62 A258 B5B5B5 1C4E25 0300
2021.10.02 16:57:51.071 0: HMLAN_Parse: hmlan1 R:EB6B6B6 stat:0000 t:4A53886C d:FF r:FFD5 m:17 A258 B6B6B6 1F91AA 0300warum auch immer werden nun knapp 3s nach initial cleanup trotzdem die ersten valvePos msgs rausgehauen und in der folge auch weiterhin regelmässig gesendet. vielleicht durch mein at, denn die fehlermeldungen wegen ungültigem cmd valvePos sind auch nicht mehr zu sehen. erstmal auch egal, prima so.
das internal .AttrList im channel vom vtc existiert weiterhin nicht, sodass ich das attr param msgReduce:2 weiterhin nach restart erneut setzen muss, damit es wirkung hat. das lässt sich aber erstmal über notify lösen.
Schade nur, dass ich das gar nicht so dolle finde. Gut, es ist besser wie nichts, aber eben Voodoo... (Und nicht so, wie es gedacht gewesen zu sein scheint.)
Kurze Zwischenmeldung - habe mir den Startvorgang jetzt nochmal angeschaut, und bin jetzt irgendwie ratlos:
Wenn HMinfo definiert ist, scheint das eine eigene Startlogik zu fahren, und dann scheint es auch richtig zu sein, dass die configCheck -f-Anfragen nicht mehr abgefeuert werden, schon gleich in der Menge.
Bin noch unsicher, ob es sinnvoll wäre, die configChecks für die Hauptkanäle beim "INITIALIZED"-Event durchzuführen. Beim Versuch, das reinzucoden habe ich dann aber festgestellt, dass jedenfalls das INITIALIZED-Event in der NotifyFn von CUL_HM gar nicht dazu führt, dass der Zweig überhaupt ausgeführt wird. Ergo muss der initDone-Marker für CUL_HM schon aktiviert worden sein. Nur: Wo...?!?
Jetzt bin ich irgendwie grade lost, wie das eigentlich gedacht ist.
Meine aktuellen - möglicherweise wieder völlig falschen - Gedanken:
Wenn HMinfo vorhanden ist, muss das bevorzugt benachrichtigt werden, und dann erst seine INIT-Funktion ausführen (im Moment: wohl früher/zu früh im Rahmen von DefFn?), und dann erst CUL_HM, das dann eigentlich nur noch sicherstellen muss, dass für die virtuellen Kanäle die Einstellungen passen (was derzeit keinen Ort zu haben scheint).
Defür müsste aber die Notify-Priorität von HMinfo erhöht werden, sonst kommt "50-C" vor "50-H". Oder man ruft die INIT-Fn aus CUL_HM heraus auf?
(Das muss niemand verstehen, ist nur, damit ich es irgendwo mal festgehalten habe).
ZitatDas muss niemand verstehen
den zusammenhang von hminfo und vtc verstehe ich wirklich nicht.
durch hminfo werden
zusätzliche funktionen bereitgestellt. aber selbstständig unternimmt es eigentlich nichts, ausser das attr autoupdate ist gesetzt.
alle basis funktionen von cul_hm sind doch hoffentlich unabhängig von hminfo. also auch der restart.
Hmm, irgendwie sind die Funktionsaufrufe teils so ineinander verschachtelt, dass ich ernsthafte Schwierigkeiten habe nachzuvollziehen, was wann aus welchem Anlass und mit welchem Ziel passiert.
Ich hab's jetzt nochmal versucht, auf einen für mich verständlichen Level runterzubrechen ::) . Danach würde ich mal folgenden "Soll-Ablauf" in den Raum werfen:
1. FHEM startet und liest alle Attribute und Readings ein. Bevor $init_done ist, werden v.a. auch die Attribute in den CUL_HM-entities nicht ausgewertet
2. Bevor irgendwas anderes mit den CUL_HM-Instanzen versucht zu arbeiten, müssen die fertig konfiguriert werden. Das kann unterstützt werden durch HMinfo, (v.a. wenn autoupdate gesetzt ist), diese Unterstützung ist aber kein Muss. Nur wenn eingesetzt, sollte HMinfo vor CUL_HM fertig sein.
Da die virtuellen entities von den realen abhängig sind, sollte man sicherheitshalber erst den configCheck über die realen laufen lassen, und dann erst danach die davon ggf. abhängigen (ist evtl. "too much").
3. Erst, wenn das durch ist, dürfen Timer, andere Eventhandler, usw. dann loslegen.
Anbei jetzt doch der Versuch, das event-basiert in den Griff zu bekommen, und zwar erst HMinfo, dann CUL_HM, dann whatever (was halt nicht mit Gewalt nach vorne gedrängt wird). Bitte ggf. das Loggen in msec aktivieren, sonst sieht das uU. von der Reihenfolge her komisch aus.
Ob das irgendwie weiterbringt im Hinblick auf die noch offenen Punkte kann ich aber im Moment nicht sagen...
Ein diff sollte die Stellschrauben offenbaren, damit du ggf. die Reihenfolge auch umdrehen kannst.
ZitatHmm, irgendwie sind die Funktionsaufrufe teils so ineinander verschachtelt, dass ich ernsthafte Schwierigkeiten habe nachzuvollziehen, was wann aus welchem Anlass und mit welchem Ziel passiert.
nach meiner logik, ohne in den code zu schauen, muss hminfo so schnell wie möglich starten, damit die zusätzlichen "komfort" funktionen rechtzeitig existieren, punkt.
cul_hm muss natürlich selber wissen, wann der aufruf einer hminfo funktion sinn macht, logisch.
diese aufrufe können und dürfen aber eben nur zusätzliche infos liefern, da cul_hm auch ohne hminfo funktionieren soll.
ich habe zb den verdacht, dass die vielen doppelten "configCheck -f" aufrufe existieren, weil martin nicht den einen ultimativen zeitpunkt ermilttelt, wann alle voraussetzungen für einen endgültigen configcheck erledigt sind, sondern jeweils erneut nach diversen aktionen, die jeweils eine auswirkung auf configcheck haben könnten.
ein reading cfgState soll ja auch im normalen betrieb, nicht nur nach restart, zu jeder zeit immer das aktuelle configcheck ergebnis wiederspiegeln. diverse aktionen müssen also immer einen configcheck triggern.
ausserdem würde ich keine wette eingehen, dass ein "configcheck -f" in fhem log auch wirklich grundsätzlich zur ausführung kommt. :)
zumindestens statusrequest beim restart zeigt in fhem.log auch diverse fake einträge an.
ZitatDa die virtuellen entities von den realen abhängig sind,
das verstehe ich nicht.
virtuelle geràte müssen doch auch ohne reale geräte existieren können. ob es immer sinn macht ist doch erstmal egal.
Zitat von: frank am 04 Oktober 2021, 14:50:22
nach meiner logik, ohne in den code zu schauen, muss hminfo so schnell wie möglich starten, damit die zusätzlichen "komfort" funktionen rechtzeitig existieren, punkt.
Da sind wir uns einig. Für mich ist nur offen, ob erst CUL_HM fertig werden muss oder HMinfo. Hab's jetzt mal mit Prio HMinfo gelöst, aber es ist einfach, das umzudrehen ($hash->{NotifyOrderPrefix}).
Zitatcul_hm muss natürlich selber wissen, wann der aufruf einer hminfo funktion sinn macht, logisch.
diese aufrufe können und dürfen aber eben nur zusätzliche infos liefern, da cul_hm auch ohne hminfo funktionieren soll.
So sollte es sein. Mein Problem: eine gewisse Anzahl von verketteten Aufrufen kann ich nachvollziehen. Hier hat das aber teilweise Ausmaße, bei denen ich es aufschreiben müßte und ich hatte den Eindruck, dass es teils zufällig war, in welcher Reihenfolge auch an der Stelle dann was (wiederholt?) aufgerufen wurde.
Jetzt habe ich zumindest mal versucht, den "äußeren Rahmen" so festzuzurren, dass Zufälligkeiten weitestgehend eliminiert sein sollten. Was ich noch nicht weiß: ist es die richtige Reihenfolge...
Zitatich habe zb den verdacht, dass die vielen doppelten "configCheck -f" aufrufe existieren, weil martin nicht den einen ultimativen zeitpunkt ermilttelt, wann alle voraussetzungen für einen endgültigen configcheck erledigt sind, sondern jeweils erneut nach diversen aktionen, die jeweils eine auswirkung auf configcheck haben könnten.
Bei einem Teil bin ich einigermaßen sicher, dass das so nicht gedacht gewesen sein kann. Die denkbare (und definitiv nicht auszuschließende) Alternative ist in der Tat, dass es keine andere Möglichkeit gab, diese häufigen Aufrufe als "Nebenwirkung" zu vermeiden.
Da aber bisher so viel zufällig passiert ist, kann es natürlich sein, dass diese Art impliziter Reparaturversuch teilweise geholfen hat, diese Zufälligkeiten zu kompensieren, und der "sortierte Versuch" jetzt (erst mal!) im Ergebnis schlechter ist. ABER: bisher funktionierte die "sortierte Fassung" (ohne configCheck!) von vorgestern ja besser als die fuzzy-logic-repaired svn-Fassung. Von daher halte ich das Risiko an der Stelle für eher gering.
Zitat
ein reading cfgState soll ja auch im normalen betrieb, nicht nur nach restart, zu jeder zeit immer das aktuelle configcheck ergebnis wiederspiegeln. diverse aktionen müssen also immer einen configcheck triggern.
Klar, und die configChecks sind jetzt ja im laufenden Betrieb auch nicht ausgeschaltet, sondern sie müßten jetzt nur im Startvorgang an einer sehr bestimmten Stelle erfolgen (wenn das jetzt alles funktioniert wie gedacht).
Zitatausserdem würde ich keine wette eingehen, dass ein "configcheck -f" in fhem log auch wirklich grundsätzlich zur ausführung kommt. :)
zumindestens statusrequest beim restart zeigt in fhem.log auch diverse fake einträge an.
Das ist ein Punkt, über den ich lange gerätselt habe. Tatsächlich hat der Start aber lt. Log mit den 700+ "-f"-Einträgen ziemlich lange gedauert, ohne dass sonst was an erkennbarer Aktion im Log gestanden hätte. Von daher war an der Stelle meine Arbeitshypothese, dass die Aufrufe auf alle Fälle vorkommen müßten, und zwar
- reduziert auf 1x pro Hauptdevice (da sind dann sowieso alle Kanäle mit drin) und
- vor dem Start von irgendwas anderem (deinem at, z.B., oder dem notify, das das hier (https://forum.fhem.de/index.php/topic,99579.msg1075923.html#msg1075923) erzeugt: https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige#fhemUser.cfg; das war btw. überhaupt der Anlaß, warum ich mir dann doch nochmal einen Ruck gegeben habe...).
Zitat
das verstehe ich nicht.
virtuelle geràte müssen doch auch ohne reale geräte existieren können. ob es immer sinn macht ist doch erstmal egal.
Das tun sie. Aber nur als Buttons. Um was anderes zu werden, brauchen sie "spezielle" Peers, und - soweit ich das jetzt verstanden habe - anhand des Peer-Typs wird ermittelt, welche Kommandos sie verstehen. Ergo sollte die endgültige Konfiguration einer virturellen entity erst erfolgen, wenn die übrige Hardware "bekannt" ist.
In der svn-Version ist das entweder zu früh oder timer-basiert geschehen, wenn meine Interpretation meiner Logs zutreffend ist.
deine aktuelle cul_hm/hminfo kombi von hier hat bezüglich den vtc nicht neues gebracht.
2021.10.04 17:13:44.916 3: CUL_HM set Thermostat.WZ_Climate controlMode central
2021.10.04 17:13:45.606 3: CUL_HM set Thermostat.Bad.OG_Climate controlMode central
2021.10.04 17:13:46.427 3: CUL_HM set Thermostat.Keller_Climate controlMode central
2021.10.04 17:13:46.865 3: CUL_HM set Thermostat.SZ_Climate controlMode central
2021.10.04 17:13:49.646 1: CUL_HM start inital cleanup
2021.10.04 17:13:54.558 1: CUL_HM finished initial cleanup
2021.10.04 17:13:58.738 3: Opening SqueezeBoxServer device 192.168.1.10:9090
2021.10.04 17:14:01.743 1: SqueezeBoxServer: Can't connect to 192.168.1.10:9090: Connection timed out
2021.10.04 17:14:01.761 3: SB_SERVER_Notify(SqueezeBoxServer): DISCONNECTED - STATE: disconnected power: ?
2021.10.04 17:14:01.780 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2021.10.04 17:14:01.799 3: Opening hmuart1 device /dev/ttyAMA0
2021.10.04 17:14:01.801 3: Setting hmuart1 serial parameters to 115200,8,N,1
2021.10.04 17:14:01.805 3: hmuart1 device opened
2021.10.04 17:14:01.952 3: cul433 IT_set: IT09 on
2021.10.04 17:14:02.721 0: Featurelevel: 6
2021.10.04 17:14:02.722 0: Server started with 525 defined entities (fhem.pl:24776/2021-07-19 perl:5.028001 os:linux user:fhem pid:2394)
2021.10.04 17:14:03.475 1: events: Can't open ./FHEM/holiday/events.holiday: No such file or directory
2021.10.04 17:14:04.739 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:1579
2021.10.04 17:14:04.775 0: HourCounter hc_system_attak Run.598 first run done countsOverall:331
2021.10.04 17:14:04.991 1: HMLAN_Parse: hmlan1 new condition ok
2021.10.04 17:14:05.086 3: CUL_HM set Thermostat.OZ_Climate statusRequest noArg
2021.10.04 17:14:05.290 3: CUL_HM set Thermostat.AZ_Climate statusRequest noArg
2021.10.04 17:14:05.399 3: CUL_HM set Thermostat.SZ_Climate statusRequest noArg
2021.10.04 17:14:05.629 0: HMLAN_Parse: hmlan1 R:EB3B3B3 stat:0000 t:54AF75F3 d:FF r:FFD3 m:37 A258 B3B3B3 193A9A 0330
2021.10.04 17:14:05.634 0: HMLAN_Parse: hmlan1 R:EB1B1B1 stat:0000 t:54AF76A2 d:FF r:FFD4 m:BF A258 B1B1B1 1BFC52 03FD
2021.10.04 17:14:05.638 0: HMLAN_Parse: hmlan1 R:EB4B4B4 stat:0000 t:54AF774C d:FF r:FFD4 m:FC A258 B4B4B4 1CE9F5 0300
2021.10.04 17:14:05.642 0: HMLAN_Parse: hmlan1 R:EB2B2B2 stat:0000 t:54AF77B7 d:FF r:FFD4 m:6C A258 B2B2B2 1DFC2F 0300
2021.10.04 17:14:05.646 0: HMLAN_Parse: hmlan1 R:EB5B5B5 stat:0000 t:54AF7868 d:FF r:FFD4 m:D9 A258 B5B5B5 1C4E25 0300
2021.10.04 17:14:05.650 0: HMLAN_Parse: hmlan1 R:EB6B6B6 stat:0000 t:54AF78CF d:FF r:FFD4 m:8E A258 B6B6B6 1F91AA 0300
wegen den fehlenden log einträgen während cleanup, starten die vtc immer noch über voodoo oder mein at.
jetzt allerdings ca 11 sec nach cleanup.
auch bzgl attr param msgReduce nichts neues.
weitere verbesserungen gab es bei den "falschen" configcheck meldungen https://forum.fhem.de/index.php/topic,123152.msg1176825.html#msg1176825 (https://forum.fhem.de/index.php/topic,123152.msg1176825.html#msg1176825). die punkte 1-3 haben sich nun wohl erledigt, wodurch kein manueller configcheck mehr nötig ist.
noch vergessen: zeile 433 erzeugt ja ein event valveCtrl=restart.
nach meinen logs sehe ich das letzte auftreten am 27.09 12:43 uhr. das war vermutlich der restart nach dem update auf martins aktuelle version. siehe erster beitrag hier im thread.
anschliessend habe ich immer mit deinen versionen neu gestartet, die diesen code nicht mehr erreichen. ;)
Kannst du bitte auch mal die Prio drehen ($hash->{NotifyOrderPrefix}-Wert in beiden Modulen einfach vertauschen)? (ich sehe dann zwar weiter keine Einträge von "Stufe 2", aber doppelt genäht...)
Das mit dem entfallenden manuellen configCheck würde ich mal auf das Verschieben in INITIALIZED-NotifyFn schieben.
Ich vermute, dass das mit dem internen vtc-Start noch nie funktioniert hat, aber wenn der Rest jetzt soweit paßt und nicht mehr Voodoo ist, finden wir vielleicht auch noch einen Hebel, um auch das noch zu fixen... (OK, deine Gegenthese betr. die korrekte Ausführung am 27.09. habe ich gesehen).
"11 sec nach cleanup" ist positiv gemeint, oder wie muss ich das deuten?
Zur Erläuterung des Logs: die controlMode-Anweisungen sind Folge der HMinfo-Initialisierung, und was mich etwas wundert, ist dass da zwischen init und finish nix von ActionDetector auftaucht, und auch keine configCheck-Messages (verbose jeweils auf 2, nehme ich an?).
Falls die kommende Stunde nichts gravierendes eintritt, würde ich dazu tendieren, das (mit umgedrehter Prio?) als neuen Komplettpatch in den Ring zu werfen, weil zumindest auch die Punkte 1-3 damit (so oder so?) erledigt sind...?
OK, jetzt zündet zwar auch Stufe 2, allerdings habe ich FHEM jetzt so oft gestartet, dass näherungsweise alle meine virtuellen Temp-Sensoren aus dem Tritt geraten zu sein scheinen. Oder liegt es am Code...? Oder an noch fehlenden "auto"-Einstellungen in HMinfo?
Na ja, hier jedenfalls mal (doch wieder erst zum Testen) der entsprechende Code - dieses Mal ist erst CUL_HM mit der Initialisierung fertig...
EDIT: nachdem sich meine Thermostate über Nacht beruhigt haben: https://forum.fhem.de/index.php/topic,123198.msg1177945.html#msg1177945
mit den neuen versionen zündet stufe2 auch bei mir und alle ventile haben erneut den restart überlebt. 8)
attr param msgreduce muss weiterhin manuell erfolgen.
für dich nun auch mal das log mit verbose=3 für hminfo und actiondetector:
2021.10.05 09:58:46.321 1: CUL_HM start inital cleanup
2021.10.05 09:58:46.471 3: Device DimUP01 added to ActionDetector with 024:00 time
2021.10.05 09:58:46.506 3: Device Fenster.Bad added to ActionDetector with 028:00 time
2021.10.05 09:58:46.541 3: Device SD.AZ added to ActionDetector with 099:00 time
2021.10.05 09:58:46.576 3: Device SD.SZ added to ActionDetector with 099:00 time
2021.10.05 09:58:46.610 3: Device SD.WZ added to ActionDetector with 099:00 time
2021.10.05 09:58:46.861 3: Device SwitchES01 added to ActionDetector with 000:15 time
2021.10.05 09:58:47.023 3: Device SwitchPBU01 added to ActionDetector with 000:10 time
2021.10.05 09:58:47.060 3: Device SwitchPBU03 added to ActionDetector with 028:00 time
2021.10.05 09:58:47.097 3: Device SwitchPBU05 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.134 3: Device SwitchPBU06 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.170 3: Device SwitchUP01 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.206 3: Device SwitchUP02 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.345 3: Device Thermostat.AZ added to ActionDetector with 000:10 time
2021.10.05 09:58:47.476 3: Device Thermostat.Bad added to ActionDetector with 000:10 time
2021.10.05 09:58:47.606 3: Device Thermostat.Bad.OG added to ActionDetector with 000:10 time
2021.10.05 09:58:47.736 3: Device Thermostat.GZ added to ActionDetector with 000:10 time
2021.10.05 09:58:47.867 3: Device Thermostat.Keller added to ActionDetector with 000:10 time
2021.10.05 09:58:47.997 3: Device Thermostat.Kueche added to ActionDetector with 000:10 time
2021.10.05 09:58:48.128 3: Device Thermostat.OZ added to ActionDetector with 000:10 time
2021.10.05 09:58:48.258 3: Device Thermostat.SZ added to ActionDetector with 000:10 time
2021.10.05 09:58:48.390 3: Device Thermostat.WZ added to ActionDetector with 000:10 time
2021.10.05 09:58:48.426 3: Device Tuer.SZ added to ActionDetector with 028:00 time
2021.10.05 09:58:48.462 3: Device Tuer.WZ.Terrasse added to ActionDetector with 028:00 time
2021.10.05 09:58:48.497 3: Device Ventil.AZ.Nord added to ActionDetector with 001:30 time
2021.10.05 09:58:48.533 3: Device Ventil.AZ.West added to ActionDetector with 001:30 time
2021.10.05 09:58:48.569 3: Device Ventil.Bad added to ActionDetector with 001:30 time
2021.10.05 09:58:48.604 3: Device Ventil.Kueche added to ActionDetector with 001:30 time
2021.10.05 09:58:48.640 3: Device Ventil.SZ added to ActionDetector with 001:30 time
2021.10.05 09:58:48.676 3: Device Ventil.WZ added to ActionDetector with 001:30 time
2021.10.05 09:58:48.875 3: Device Wetter.Sued added to ActionDetector with 000:10 time
2021.10.05 09:58:50.694 1: ----- test2 ----- -> n:VentilControler.AZ.Nord_Btn1
2021.10.05 09:58:50.886 3: set VentilControler.AZ.West_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1
2021.10.05 09:58:50.887 3: n_set_VentilControler.AZ.West return value: Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1
2021.10.05 09:58:50.994 1: ----- test2 ----- -> n:VentilControler.AZ.West_Btn1
2021.10.05 09:58:51.283 1: ----- test2 ----- -> n:VentilControler.Bad_Btn1
2021.10.05 09:58:51.572 1: ----- test2 ----- -> n:VentilControler.Kueche_Btn1
2021.10.05 09:58:51.862 1: ----- test2 ----- -> n:VentilControler.SZ_Btn1
2021.10.05 09:58:52.158 1: ----- test2 ----- -> n:VentilControler.WZ_Btn1
2021.10.05 09:58:53.080 1: CUL_HM finished initial cleanup
2021.10.05 09:58:53.101 3: HMinfo hminfo get:configCheck :-f,^(ActionDetector|ActionDetector)$
2021.10.05 09:58:53.102 3: HMinfo hminfo get:configCheck :-f,^(DimUP01|DimUP01)$
2021.10.05 09:58:53.102 3: HMinfo hminfo get:configCheck :-f,^(Fenster.Bad|Fenster.Bad)$
2021.10.05 09:58:53.103 3: HMinfo hminfo get:configCheck :-f,^(SD.AZ|SD.AZ)$
2021.10.05 09:58:53.104 3: HMinfo hminfo get:configCheck :-f,^(SD.SZ|SD.SZ)$
2021.10.05 09:58:53.104 3: HMinfo hminfo get:configCheck :-f,^(SD.WZ|SD.WZ)$
2021.10.05 09:58:53.105 3: HMinfo hminfo get:configCheck :-f,^(SwitchES01|SwitchES01_Pwr|SwitchES01_SenF|SwitchES01_SenI|SwitchES01_SenPwr|SwitchES01_SenU|SwitchES01_Sw|SwitchES01)$
2021.10.05 09:58:53.106 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU01|SwitchPBU01_Btn_01|SwitchPBU01_Btn_02|SwitchPBU01_Sw_01|SwitchPBU01_Sw_02|SwitchPBU01)$
2021.10.05 09:58:53.106 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU03|SwitchPBU03)$
2021.10.05 09:58:53.107 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU05|SwitchPBU05)$
2021.10.05 09:58:53.107 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU06|SwitchPBU06)$
2021.10.05 09:58:53.108 3: HMinfo hminfo get:configCheck :-f,^(SwitchUP01|SwitchUP01)$
2021.10.05 09:58:53.109 3: HMinfo hminfo get:configCheck :-f,^(SwitchUP02|SwitchUP02)$
2021.10.05 09:58:53.109 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.AZ|Thermostat.AZ_Climate|Thermostat.AZ_Weather|Thermostat.AZ_WindowRec|Thermostat.AZ)$
2021.10.05 09:58:53.110 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Bad|Thermostat.Bad_Climate|Thermostat.Bad_Weather|Thermostat.Bad_WindowRec|Thermostat.Bad)$
2021.10.05 09:58:53.111 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Bad.OG|Thermostat.Bad.OG_Climate|Thermostat.Bad.OG_Weather|Thermostat.Bad.OG_WindowRec|Thermostat.Bad.OG)$
2021.10.05 09:58:53.111 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.GZ|Thermostat.GZ_Climate|Thermostat.GZ_Weather|Thermostat.GZ_WindowRec|Thermostat.GZ)$
2021.10.05 09:58:53.112 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Keller|Thermostat.Keller_Climate|Thermostat.Keller_Weather|Thermostat.Keller_WindowRec|Thermostat.Keller)$
2021.10.05 09:58:53.112 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Kueche|Thermostat.Kueche_Climate|Thermostat.Kueche_Weather|Thermostat.Kueche_WindowRec|Thermostat.Kueche)$
2021.10.05 09:58:53.113 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.OZ|Thermostat.OZ_Climate|Thermostat.OZ_Weather|Thermostat.OZ_WindowRec|Thermostat.OZ)$
2021.10.05 09:58:53.114 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.SZ|Thermostat.SZ_Climate|Thermostat.SZ_Weather|Thermostat.SZ_WindowRec|Thermostat.SZ)$
2021.10.05 09:58:53.114 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.WZ|Thermostat.WZ_Climate|Thermostat.WZ_Weather|Thermostat.WZ_WindowRec|Thermostat.WZ)$
2021.10.05 09:58:53.115 3: HMinfo hminfo get:configCheck :-f,^(Tuer.SZ|Tuer.SZ)$
2021.10.05 09:58:53.116 3: HMinfo hminfo get:configCheck :-f,^(Tuer.WZ.Terrasse|Tuer.WZ.Terrasse)$
2021.10.05 09:58:53.116 3: HMinfo hminfo get:configCheck :-f,^(Ventil.AZ.Nord|Ventil.AZ.Nord)$
2021.10.05 09:58:53.117 3: HMinfo hminfo get:configCheck :-f,^(Ventil.AZ.West|Ventil.AZ.West)$
2021.10.05 09:58:53.117 3: HMinfo hminfo get:configCheck :-f,^(Ventil.Bad|Ventil.Bad)$
2021.10.05 09:58:53.118 3: HMinfo hminfo get:configCheck :-f,^(Ventil.Kueche|Ventil.Kueche)$
2021.10.05 09:58:53.119 3: HMinfo hminfo get:configCheck :-f,^(Ventil.SZ|Ventil.SZ)$
2021.10.05 09:58:53.119 3: HMinfo hminfo get:configCheck :-f,^(Ventil.WZ|Ventil.WZ)$
2021.10.05 09:58:53.120 3: HMinfo hminfo get:configCheck :-f,^(Wetter.Sued|Wetter.Sued)$
2021.10.05 09:58:53.121 3: HMinfo hminfo get:configCheck :-f,^(ccu|ccu_Btn1|ccu_Btn2|ccu_Btn3|ccu_Btn4|ccu_Btn5|ccu)$
2021.10.05 09:58:53.121 3: HMinfo hminfo get:configCheck :-f,^(SDTeam|SDTeam_Btn1|SDTeam)$
2021.10.05 09:58:53.122 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.AZ.Nord|VentilControler.AZ.Nord_Btn1|VentilControler.AZ.Nord)$
2021.10.05 09:58:53.123 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.AZ.West|VentilControler.AZ.West_Btn1|VentilControler.AZ.West)$
2021.10.05 09:58:53.124 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.Bad|VentilControler.Bad_Btn1|VentilControler.Bad)$
2021.10.05 09:58:53.124 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.Kueche|VentilControler.Kueche_Btn1|VentilControler.Kueche)$
2021.10.05 09:58:53.125 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.SZ|VentilControler.SZ_Btn1|VentilControler.SZ)$
2021.10.05 09:58:53.125 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.WZ|VentilControler.WZ_Btn1|VentilControler.WZ)$
2021.10.05 09:58:53.126 3: HMinfo hminfo get:configCheck :-f,^(rssi_hmuart|rssi_hmuart_Btn1|rssi_hmuart)$
2021.10.05 09:58:53.127 3: HMinfo hminfo get:configCheck :-f,^(virtAktorAlarmOff|virtAktorAlarmOff_Btn1|virtAktorAlarmOff)$
2021.10.05 09:58:53.163 3: HMinfo hminfo get:loadConfig :
2021.10.05 09:58:53.632 3: HMinfo hminfo get:configCheck :
2021.10.05 09:58:55.237 3: Opening SqueezeBoxServer device 192.168.1.10:9090
2021.10.05 09:58:58.242 1: SqueezeBoxServer: Can't connect to 192.168.1.10:9090: Connection timed out
2021.10.05 09:58:58.260 3: SB_SERVER_Notify(SqueezeBoxServer): DISCONNECTED - STATE: disconnected power: ?
2021.10.05 09:58:58.278 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2021.10.05 09:58:58.297 3: Opening hmuart1 device /dev/ttyAMA0
2021.10.05 09:58:58.299 3: Setting hmuart1 serial parameters to 115200,8,N,1
2021.10.05 09:58:58.303 3: hmuart1 device opened
2021.10.05 09:58:58.448 3: cul433 IT_set: IT09 on
2021.10.05 09:58:59.191 0: Featurelevel: 6
2021.10.05 09:58:59.192 0: Server started with 524 defined entities (fhem.pl:24776/2021-07-19 perl:5.028001 os:linux user:fhem pid:4136)
2021.10.05 09:58:59.916 1: events: Can't open ./FHEM/holiday/events.holiday: No such file or directory
2021.10.05 09:59:00.754 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:1579
2021.10.05 09:59:00.801 0: HourCounter hc_system_attak Run.598 first run done countsOverall:331
2021.10.05 09:59:01.368 4: CUL_Parse: cul868 A 14 17 805E 266EA5 1ACE1F 000000000000000000000023 -56.5
2021.10.05 09:59:01.511 1: HMLAN_Parse: hmlan1 new condition ok
2021.10.05 09:59:01.560 0: HMLAN_Parse: hmlan1 R:EB5B5B5 stat:0000 t:58477DDA d:FF r:FFD5 m:66 A258 B5B5B5 1C4E25 0300
2021.10.05 09:59:01.563 0: HMLAN_Parse: hmlan1 R:EB6B6B6 stat:0000 t:58477F04 d:FF r:FFD5 m:1A A258 B6B6B6 1F91AA 0300
2021.10.05 09:59:01.567 0: HMLAN_Parse: hmlan1 R:EB3B3B3 stat:0000 t:58478025 d:FF r:FFD5 m:C4 A258 B3B3B3 193A9A 034C
2021.10.05 09:59:01.571 0: HMLAN_Parse: hmlan1 R:EB1B1B1 stat:0000 t:58478147 d:FF r:FFD5 m:4C A258 B1B1B1 1BFC52 03FD
2021.10.05 09:59:01.574 0: HMLAN_Parse: hmlan1 R:EB2B2B2 stat:0000 t:58478268 d:FF r:FFD5 m:F8 A258 B2B2B2 1DFC2F 03FD
2021.10.05 09:59:01.578 0: HMLAN_Parse: hmlan1 R:EB4B4B4 stat:0000 t:58478390 d:FF r:FFD5 m:87 A258 B4B4B4 1CE9F5 03FD
anmerkungen:
1. durch die fehlermeldungen merke ich so langsam wieder, was da so alles läuft.
4/6 ventilen werden über mein at mit valvepos gefüttert. die anderen 2 ventile bekommen ihr valvepos über notify von 2 ventilen aus der ersten gruppe, da in 2 räumen jeweils 2 heizkörper existieren.
durch die reihenfolge der bearbeitung der devices in cul_hm_updateconfig wird hier nun einmal eine fehlermeldung durch dieses notify geworfen.
das notify n_set_VentilControler.AZ.West reagiert auf die neue valvepos von VentilControler.AZ.Nord_Btn1 und will VentilControler.AZ.West_Btn1 mit valvepos versorgen. das wird aber erst anschliessend konfiguriert und hat dadurch noch keinen gültigen cmd valvepos.
beim anderen pärchen (VentilControler.SZ_Btn1,VentilControler.WZ_Btn1) passt die reihenfolge zufällig.
2021.10.05 09:58:50.694 1: ----- test2 ----- -> n:VentilControler.AZ.Nord_Btn1
2021.10.05 09:58:50.886 3: set VentilControler.AZ.West_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1
2021.10.05 09:58:50.887 3: n_set_VentilControler.AZ.West return value: Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,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.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1
2021.10.05 09:58:50.994 1: ----- test2 ----- -> n:VentilControler.AZ.West_Btn1
2. die configchecks sind jetzt zwar nicht mehr doppelt, aber noch viele sinnlos, denke ich.
wenn ich das richtig überblicke wird für alle devices (inklusive channel) ein "configcheck -f" ausgelöst.
anschliessend nach loadconfig gibt es noch einen "grossen" configcheck auf alles.
wenn es abschliessend den grossen configcheck gibt, sind die anderen vorher eigentlich alle überflüssig, oder?
ausserdem gibt es einen configcheck für den actiondetector, der sowieso sinnlos ist, oder übersehe ich hier etwas.
eigentlich wollte martin den automatischen configcheck so wenig wie nötig aufrufen, da er das system belastet.
daher gibt es "configcheck -f" aufrufe, denn diese checken ja nur einen kleinen teil des systems. über irgendeine logik wusste er beim restart welche devices zu checken sind. es gab also nicht "configcheck -f" für alle devices, sondern immer nur für einen teil aller devices.
etwa 60s nach dem loadconfig gibt es bei mir noch eine salve "configcheck -f" mit "ausgewählten" devices.
das könnte diese gruppe sein. diese gruppe ist scheinbar auch nach jedem restart anders zusammengesetzt.
vermutlich ist auch diese nachträgliche configcheck salve eigentlich überflüssig durch den bereits erfolgten "grossen" configcheck, den martin eigentlich vermeiden wollte, so wie ich es mal verstanden hatte.
aber wie schon spekuliert, gab es scheinbar ein paar configchecks als "pflaster".
Zitat von: frank am 05 Oktober 2021, 13:49:43
mit den neuen versionen zündet stufe2 auch bei mir und alle ventile haben erneut den restart überlebt. 8)
8) So weit, so gut!
Zitat
attr param msgreduce muss weiterhin manuell erfolgen.
Das klingt danach, als wäre das Attribut zwischendurch mal "nicht erlaubt" (und folglich gelöscht). Stellt sich die Frage, ob man das ggf. (nur während der Initialisierung?) zuläßt (unschön, relativ viel Zusatzcode)? Besser wäre es, die Reihenfolge so zu fixieren, dass das gar nicht erst passiert - ich habe nur noch keine Idee, wo...
Zitat
4/6 ventilen werden über mein at mit valvepos gefüttert. die anderen 2 ventile bekommen ihr valvepos über notify von 2 ventilen aus der ersten gruppe, da in 2 räumen jeweils 2 heizkörper existieren.
OK, das erklärt das "unknown argument" und so langsam habe ich auch eine Idee, warum Martin das timer-basiert machen wollte. Dann wären nämlich alle Basiskonfigurationen durch, bevor "irgendwer anderes" Wind davon bekommt (z.B. dein notify), dass CUL_HM (in Teilen) wieder läuft. Das dürfte der Gedanke hinter der "Doppelverwendung" von $evtDly gewesen sein, aber irgendwo scheint es da noch eine Lücke zu geben. Leider klappt es dann wohl nicht, innerhalb der vorgezogenen event-loop andere Eventhandler erst dann abzuarbeiten, wenn die interne NotifyFn durch ist. Hmmm...
Nach meinen bisherigen Erfahrungen würde ich sagen, dass eine vollständige Rückkehr zu einer timer-Initialisierung keine gute Idee ist. Andere Meinungen?
Ergo brauchen wir sowas wie einen Mittelweg, wobei es zumindest zur Lösung des von dir aufgezeigten Abhängigkeitsproblems wahrscheinlich genügen würde, die Kommandos aus der Initialisierung der paar virtuellen Kanäle rauszunehmen und in eine gesonderte Timer-Funktion zu verlagern.
Dann sollte auch die "zufällige" Reihenfolge kein Problem mehr sein.
Werde ich angehen.
Zitat2. die configchecks sind jetzt zwar nicht mehr doppelt, aber noch viele sinnlos, denke ich.
Na ja, jetzt sind est erst mal "nur noch viele" statt bisher sehr, sehr viele (die wurden nämlich durch die svn-Version auch noch für alle Kanäle aufgerufen, wenn ich das damalige Log richtig im Kopf habe)...
Ob die vorher abgearbeitet wurden (bzw. jetzt, weil in INITIALIZED-loop, also nach $init_done), muss ich mir nochmal gesondert ansehen. Wie bereits mehrfach geschrieben, war diese Unmenge einer der Gründe, warum ich der festen Überzeugung war, dass das so nicht beabsichtigt gewesen sein konnte...
Die wurden zwar in Timer verpackt (die dann implizit zumeist wieder gelöscht wurden?), wenn ich das richtig gedeutet habe, aber die schiere Masse war für sich genommen schon irritierend.
Zitateigentlich wollte martin den automatischen configcheck so wenig wie nötig aufrufen, da er das system belastet.
Solche klaren Aussagen zu dem Thema fehlten mir bisher als Puzzleteilchen.
Zitatdaher gibt es "configcheck -f" aufrufe, denn diese checken ja nur einen kleinen teil des systems. über irgendeine logik wusste er beim restart welche devices zu checken sind. es gab also nicht "configcheck -f" für alle devices, sondern immer nur für einen teil aller devices.
Dann sollte es also wieder Ziel sein, dahin zurückzukommen, dass wir den Check dann abfeuern, wenn er gebraucht wird und den "großen" möglichst ganz vermeiden. Ich habe nur zu wenig Ahnung von den Zusammenhängen, um beurteilen zu können, wie wir das feststellen können, was wann dran ist... Generell irritiert es mich, dass das aus CUL_HM raus angestoßen wird und nicht in HMinfo autonom (zumindest während der Startphase).
Zitatetwa 60s nach dem loadconfig gibt es bei mir noch eine salve "configcheck -f" mit "ausgewählten" devices.
Das ist bei mir auch so, und das wird auch immer mal wieder wiederholt (ich sehe das für ein "kaputtes" Device, das grade nicht erreichbar ist).
ZitatDas klingt danach, als wäre das Attribut zwischendurch mal "nicht erlaubt" (und folglich gelöscht). Stellt sich die Frage, ob man das ggf. (nur während der Initialisierung?) zuläßt (unschön, relativ viel Zusatzcode)? Besser wäre es, die Reihenfolge so zu fixieren, dass das gar nicht erst passiert - ich habe nur noch keine Idee, wo...
alle virtuellen channel entities besitzen weiterhin kein internal ".AttrList".
streng genommen fehlt dann nicht das attribut in der liste, sondern es gibt gar keine liste. somit fehlt es eigentlich auch nicht.
das attribut kann auch zwischenzeitlich nicht gelöscht worden sein, sonst wäre es ja nicht mehr vorhanden.
Zitat von: frank am 05 Oktober 2021, 13:49:43
attr param msgreduce muss weiterhin manuell erfolgen.
...so langsam dämmert mir auch, warum das so ist:
Setzt man das Attribut nach $init_done, werden auch die Werte im helper-Hash entsprechend angepaßt. Während der Start-Phase habe ich jetzt aber nirgends was gefunden, das das Attribut in irgendeiner Form auswerten würde. Da es eigentlich "obvious" ist, dass das irgendwo erfolgen müßte, bin ich immer davon ausgegangen, dass es auch gemacht wird. Da es jedenfalls jetzt nicht mehr der Fall ist:
Jetzt könnte man das ohne weiteres als weiteren individuellen Check auch noch irgendwie in CUL_HM_updateConfig() reinknödeln (wie im aktuellen Anhang), aber an sich ist es nur ein Symptom eines generellen Problems, das wir bisher nur gefühlt, aber nie direkt gesehen haben: Man müßte eigentlich noch eine Schleife basteln, die alle Attribute (in einer bestimmten Reihenfolge?) nochmal durchgeht, und für die Devices, die es nicht "sowieso" richtig machen/wissen dann auch die Auswertung durchführen, die eigentlich in CUL_HM_Attr() schon enthalten ist... Konkret betrifft das mind. bei den VIRTUALs die Attribute "peerIDs" und "param". Wenn es wirklich nur die beiden sind, kann es beim (ungetesteten) angehängten Provisorium bleiben, wenn es mehr ist, sollte man eine explizite Schleife bauen.
EDIT: evtl. ist das io-Problem aus https://forum.fhem.de/index.php/topic,123198.msg1178042.html#msg1178042 (https://forum.fhem.de/index.php/topic,123198.msg1178042.html#msg1178042) auch sowas...? (Ist nur ein erster Gedanke, muss nicht stimmen).
Zitataber wie schon spekuliert, gab es scheinbar ein paar configchecks als "pflaster".
Habe jetzt mal "mutig" die erste Salve deaktiviert, weiß aber noch nicht, ob das gut ist und wohin das ggf. führt...
Warum .AttrList gar nicht gesetzt wird, ist mir im Moment noch ein Rätsel, aber das lichtet sich vielleicht auch noch. Vorläufig bin ich dann froh, den schon fertigen "laß das durch"-Filter erst mal nur deaktiviert zu haben ;D . Vielleicht liegt das auch daran, dass "VIRTUAL" nicht explizit (nach-) gesetzt wird, und daher nicht klar ist, welche subType-spezifischen Werte eigentlich erlaubt sind...
hallo beta-martin ;)
1. param msgReduce funktioniert nun automatisch, obwohl internal .AttrList weiterhin fehlt
2. weiterhin keine cfgState auffälligkeiten
3. valvePos fehlermeldung vom notify weg
4. alle ventile leben
2021.10.05 18:43:38.407 1: Including ./log/fhem.save
2021.10.05 18:43:39.571 1: Messages collected while initializing FHEM:SecurityCheck:
WEBscreenshot is not password protected
WEB is not password protected
telnetPort is not password protected
Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none
2021.10.05 18:43:39.590 1: CUL_HM start inital cleanup
2021.10.05 18:43:44.564 1: CUL_HM finished initial cleanup
2021.10.05 18:43:44.600 3: HMinfo hminfo get:loadConfig :
2021.10.05 18:43:45.191 3: HMinfo hminfo get:configCheck :
...
2021.10.05 18:44:45.030 3: HMinfo hminfo get:configCheck :-f,^(HM_114B05|HM_114B05)$
2021.10.05 18:44:45.145 3: HMinfo hminfo get:configCheck :-f,^(Tuer.SZ|Tuer.SZ)$
2021.10.05 18:44:45.186 3: HMinfo hminfo get:configCheck :-f,^(SwitchES01|SwitchES01_Pwr|SwitchES01_SenF|SwitchES01_SenI|SwitchES01_SenPwr|SwitchES01_SenU|SwitchES01_Sw|SwitchES01)$
5. device HM_114B05 aus der letzten salve ist ein ignored device. ist also auch sinnlos
Internals:
DEF 114B05
FUUID 5c4ce2ef-f33f-09c4-0dfe-f485be94c011b276
IODev hmuart1
NAME HM_114B05
NR 614
NTFY_ORDER 48-HM_114B05
STATE from archivexx D-firmware 1.7
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
peerList self01
.attraggr:
.attrminint:
READINGS:
1900-01-01 00:00:01 .D-devInfo 010100
1900-01-01 00:00:01 .D-stc 20
2021-10-05 18:43:42 .associatedWith HM_114B05,HM_114B05
2019-11-24 19:38:28 .peerListRDate 2019-11-24 19:38:28
from archivexx D-firmware 1.7
from archivexx D-serialNr FEQ0069583
2021-10-05 18:43:38 IODev hmuart1
2021-10-05 18:43:44 R-intKeyVisib visib
2021-10-05 18:43:44 R-loadErrCalib 1
2021-10-05 18:43:44 R-pairCentral 0x1ACE1F
2021-10-05 18:43:44 R-self01-lgActionTypeDim toggleDim
2021-10-05 18:43:44 R-self01-lgCtDlyOff geLo
2021-10-05 18:43:44 R-self01-lgCtDlyOn geLo
2021-10-05 18:43:44 R-self01-lgCtOff geLo
2021-10-05 18:43:44 R-self01-lgCtOn geLo
2021-10-05 18:43:44 R-self01-lgCtRampOff geLo
2021-10-05 18:43:44 R-self01-lgCtRampOn geLo
2021-10-05 18:43:44 R-self01-lgCtValHi 100
2021-10-05 18:43:44 R-self01-lgCtValLo 50
2021-10-05 18:43:44 R-self01-lgDimJtDlyOff rampOff
2021-10-05 18:43:44 R-self01-lgDimJtDlyOn rampOn
2021-10-05 18:43:44 R-self01-lgDimJtOff dlyOn
2021-10-05 18:43:44 R-self01-lgDimJtOn dlyOff
2021-10-05 18:43:44 R-self01-lgDimJtRampOff off
2021-10-05 18:43:44 R-self01-lgDimJtRampOn on
2021-10-05 18:43:44 R-self01-lgDimMaxLvl 100 %
2021-10-05 18:43:44 R-self01-lgDimMinLvl 0 %
2021-10-05 18:43:44 R-self01-lgDimStep 5 %
2021-10-05 18:43:44 R-self01-lgMultiExec on
2021-10-05 18:43:44 R-self01-lgOffDly 0 s
2021-10-05 18:43:44 R-self01-lgOffDlyBlink on
2021-10-05 18:43:44 R-self01-lgOffDlyNewTime 0.4 s
2021-10-05 18:43:44 R-self01-lgOffDlyOldTime 0.4 s
2021-10-05 18:43:44 R-self01-lgOffDlyStep 5 %
2021-10-05 18:43:44 R-self01-lgOffLevel 0 %
2021-10-05 18:43:44 R-self01-lgOffTime unused
2021-10-05 18:43:44 R-self01-lgOffTimeMode absolut
2021-10-05 18:43:44 R-self01-lgOnDly 0 s
2021-10-05 18:43:44 R-self01-lgOnDlyMode setToOff
2021-10-05 18:43:44 R-self01-lgOnLevel 100 %
2021-10-05 18:43:44 R-self01-lgOnLvlPrio high
2021-10-05 18:43:44 R-self01-lgOnMinLevel 10 %
2021-10-05 18:43:44 R-self01-lgOnTime unused
2021-10-05 18:43:44 R-self01-lgOnTimeMode absolut
2021-10-05 18:43:44 R-self01-lgRampOffTime 0.5 s
2021-10-05 18:43:44 R-self01-lgRampOnTime 0.5 s
2021-10-05 18:43:44 R-self01-lgRampSstep 5 %
2021-10-05 18:43:44 R-self01-shActionTypeDim jmpToTarget
2021-10-05 18:43:44 R-self01-shCtDlyOff geLo
2021-10-05 18:43:44 R-self01-shCtDlyOn geLo
2021-10-05 18:43:44 R-self01-shCtOff geLo
2021-10-05 18:43:44 R-self01-shCtOn geLo
2021-10-05 18:43:44 R-self01-shCtRampOff geLo
2021-10-05 18:43:44 R-self01-shCtRampOn geLo
2021-10-05 18:43:44 R-self01-shCtValHi 100
2021-10-05 18:43:44 R-self01-shCtValLo 50
2021-10-05 18:43:44 R-self01-shDimJtDlyOff rampOff
2021-10-05 18:43:44 R-self01-shDimJtDlyOn rampOn
2021-10-05 18:43:44 R-self01-shDimJtOff dlyOn
2021-10-05 18:43:44 R-self01-shDimJtOn dlyOff
2021-10-05 18:43:44 R-self01-shDimJtRampOff off
2021-10-05 18:43:44 R-self01-shDimJtRampOn on
2021-10-05 18:43:44 R-self01-shDimMaxLvl 100 %
2021-10-05 18:43:44 R-self01-shDimMinLvl 0 %
2021-10-05 18:43:44 R-self01-shDimStep 5 %
2021-10-05 18:43:44 R-self01-shMultiExec off
2021-10-05 18:43:44 R-self01-shOffDly 0 s
2021-10-05 18:43:44 R-self01-shOffDlyBlink on
2021-10-05 18:43:44 R-self01-shOffDlyNewTime 0.4 s
2021-10-05 18:43:44 R-self01-shOffDlyOldTime 0.4 s
2021-10-05 18:43:44 R-self01-shOffDlyStep 5 %
2021-10-05 18:43:44 R-self01-shOffLevel 0 %
2021-10-05 18:43:44 R-self01-shOffTime unused
2021-10-05 18:43:44 R-self01-shOffTimeMode absolut
2021-10-05 18:43:44 R-self01-shOnDly 0 s
2021-10-05 18:43:44 R-self01-shOnDlyMode setToOff
2021-10-05 18:43:44 R-self01-shOnLevel 100 %
2021-10-05 18:43:44 R-self01-shOnLvlPrio high
2021-10-05 18:43:44 R-self01-shOnMinLevel 10 %
2021-10-05 18:43:44 R-self01-shOnTime unused
2021-10-05 18:43:44 R-self01-shOnTimeMode absolut
2021-10-05 18:43:44 R-self01-shRampOffTime 0.5 s
2021-10-05 18:43:44 R-self01-shRampOnTime 0.5 s
2021-10-05 18:43:44 R-self01-shRampSstep 5 %
2018-01-26 22:59:37 RegL_00. 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1A 0B:CE 0C:1F 00:00
2018-01-26 22:59:43 RegL_01. 12:01 00:00
2018-01-26 22:59:59 RegL_03.self01 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:20 0F:00 10:14 11:C8 12:0A 13:05 14:05 15:00 16:C8 17:0A 18:0A 19:04 1A:04 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:26 8B:14 8C:52 8D:63 8E:20 8F:00 90:14 91:C8 92:0A 93:05 94:05 95:00 96:C8 97:0A 98:0A 99:04 9A:04 00:00
2021-10-05 18:43:42 peerList self01
helper:
HM_CMDNR 16
cfgStateUpdt 0
mId 0013
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:dimmer
regLst 0,1,3p
rxType 1
cmds:
TmplKey self01:no:1633452222.40431
TmplTs 1633452222.40431
cmdKey 1:1:0::HM_114B05:0013:01:self01
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
down 'change:'[(0..100;1|{10})] [(-ontime-|{0})] [(-ramptime-|{2.4})] 'ontime: 0 = forever'
eventL -peer- -cond-
eventS -peer- -cond-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
old noArg
on noArg
on-for-timer -ontime- [(-ramptime-|{})]
on-till -time- [(-ramptime-|{})]
pair noArg
pct (-value-|old) [(-ontime-|{0})] [(-ramptime-|{2.4})] 'ontime: 0 = forever'
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{self01})]
pressS [(-peer-|{self01})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
stop noArg
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_self01 -tplPeer-
unpair noArg
up 'change:'[(0..100;1|{10})] [(-ontime-|{0})] [(-ramptime-|{2.4})] 'ontime: 0 = forever'
lst:
condition slider,0,1,255
peer self01
peerOpt Fenster.Bad,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,ccu_Btn2,ccu_Btn3,ccu_Btn4,ccu_Btn5,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1
tplChan
tplDel
tplPeer DimOff_long,DimOff_short,DimOn_long,DimOn_short,SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOnCond_long,SwOnCond_short,motionOnDim_long,motionOnDim_short
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:
flgs 0
newChn +114B05,00,00,00
rxt 0
vccu
p:
114B05
00
00
00
prefIO:
mRssi:
mNo
peerIDsH:
00000000 broadcast
114B0501 self01
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
tmpl:
Attributes:
.mId 0013
IODev hmuart1
IOgrp ccu:hmuart1
autoReadReg 0_off
expert defReg,allReg,rawReg,templ
firmware 1.7
ignore 1
model HM-LC-DIM1L-PL
peerIDs 00000000,114B0501
room CUL_HM
rssiLog 1
serialNr FEQ0069583
subType dimmer
webCmd statusRequest:toggle:on:off:up:down
ich habe den verdacht, dass du in deinem hminfo das attr sumERROR um den eintrag "cfgState:ok" erweitern musst.
dann siehst du in der hminfotools tabelle alle entities mit reading cfgState!=ok.
Thx, habe ich mal in meinem HMinfo ergänzt.
Das mit "ignored" ist dem Bauchgefühl nach ein reines HMinfo-Thema, mal schauen...
Was mich weiter beschäftigt ist die Frage, ob man nicht eine Reihe von Attributen "nachsetzen" muss, solange die INITIALIZED-loop läuft - eigentlich ist die VCCU-Initialisierung nämlich auch nichts anderes und findet nur im Moment etwas woanders statt.
Ansonsten sind meine fixes jetzt zunehmend "wild" und nicht schön anzusehen, und es ist vermutlich auch kaum mehr nachzuvollziehen, warum eigentlich was wo vorgeschlagen wird...
Deiner Rückmeldung entnehme ich aber, dass es sinnvoll wäre, im "patches"-Thread dann nur noch die heutigen Stände zu präsentieren und den Rest aus dem Verkehr zu ziehen?
ZitatDas mit "ignored" ist dem Bauchgefühl nach ein reines HMinfo-Thema, mal schauen...
es hat jedenfalls nichts direkt mit vd/vtc zu tun.
höchstens indirekt, da jeder performance gewinn positive auswirkungen auf den vtc betrieb hat.
es ist auf jeden fall ein cul_hm bug, da cul_hm den check bestellt.
wichtiger wäre jetzt für mich ein einwandfreies io handling, denn hier funktioniert nun erst mal wieder alles.
https://forum.fhem.de/index.php/topic,123238.0.html (https://forum.fhem.de/index.php/topic,123238.0.html)
noansi hat gerade ein lebenszeichen gesetzt. vielleicht hat er auch wieder lust zu helfen.
Zitat von: frank am 05 Oktober 2021, 20:57:42
noansi hat gerade ein lebenszeichen gesetzt. vielleicht hat er auch wieder lust zu helfen.
Das wäre mir sehr recht, genauso, wenn Martin sich äußern würde...
Zitat von: frank am 05 Oktober 2021, 20:57:42
es ist auf jeden fall ein cul_hm bug, da cul_hm den check bestellt.
Ja, nein, weiß nicht: Die wechselseitigen Anforderungen laufen teilweise im Kreis herum, und hier meine ich das so zu deuten, dass es eigentlich HMinfo ist, die eine Funktion in CUL_HM aufruft, die dann wieder was von HMinfo haben will...
Zitat
wichtiger wäre jetzt für mich ein einwandfreies io handling, denn hier funktioniert nun erst mal wieder alles.
https://forum.fhem.de/index.php/topic,123238.0.html (https://forum.fhem.de/index.php/topic,123238.0.html)
Den Thread hatte ich "bestellt" - jetzt ist nur die Frage, was man tun müßte, um den Befehl verfügbar machen. Tippen würde ich auf: ein Attribut setzen... (oder jetzt: Großschreibung?)
Was die IO-Initialisierung angeht, klingt das für mich nach "lies das IOgrp-Attribut ein", also noch eines...
mit den aktuellen updates aus dem svn von heute funktionieren vtc/vd wieder wie gewohnt.
danke beta-user und martin.