[gelöst] keine kommunikation zwischen vd und virtuellem tc nach fhem restart

frank · 27 September 2021, 17:15:26

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.

Code Auswählen

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

Code Auswählen

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

Code Auswählen

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

frank · 28 September 2021, 15:05:47

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
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.

Beta-User · 28 September 2021, 15:21:55

Zwischeninfo: meine "Trefferwahrscheinlichkeit" für das korrekte Setzen von .AttrList bei den RT's erhöht sich scheinbar, wenn ca. in #9658

Code Auswählen

foreach (sort keys %{$culHmModel}){
statt

Code Auswählen

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).

frank · 28 September 2021, 15:33:12

sortieren kann ich mir sparen.
es gibt kein internal .AttrList in keinem virtuellen channel.

Beta-User · 28 September 2021, 15:57:35

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...

frank · 28 September 2021, 16:49:23

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.

Beta-User · 28 September 2021, 17:35:47

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:

Code Auswählen

{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...

frank · 30 September 2021, 10:27:39

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.

Code Auswählen

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

Beta-User · 30 September 2021, 11:01:00

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?

frank · 30 September 2021, 11:54:40

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.

Beta-User · 30 September 2021, 12:01:15

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:

Code Auswählen

  if(!defined $hash->{helper}{cmds}{cmdLst}{$cmd} && defined $hash->{helper}{cmds}{cmdLst}{cmdKey}) { ### unknown - return the commandlist if initialisation is done

frank · 30 September 2021, 12:43:50

wenn, dann meinst du wohl eher

Code Auswählen

  if(!defined $hash->{helper}{cmds}{cmdLst}{$cmd} && defined $hash->{helper}{cmds}{cmdKey}) { ### unknown - return the commandlist if initialisation is done

mal schauen...

Beta-User · 30 September 2021, 12:48:18

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.

Beta-User · 30 September 2021, 16:23:16

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

Code Auswählen

    $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...)

frank · 30 September 2021, 17:04:50

dies ist grosser murks:

Code Auswählen

 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

Code Auswählen

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:

Code Auswählen

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.

Beta-User · 30 September 2021, 17:19:19

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
Code Auswählen Erweitern
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?

frank · 30 September 2021, 18:01:23

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.

Beta-User · 30 September 2021, 18:16:45

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.

Beta-User · 01 Oktober 2021, 12:08:03

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?

Code Auswählen

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"?

frank · 01 Oktober 2021, 15:26:06

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?
Code Auswählen Erweitern
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.

Beta-User · 01 Oktober 2021, 15:56:22

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]

frank · 01 Oktober 2021, 16:47:28

ich habe jetzt 3 logmeldungen eingebaut.

Code Auswählen

    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"); 
      }
    }

Code Auswählen

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)

Beta-User · 01 Oktober 2021, 17:10:32

Demnach wären zwingend die Peers in diesem Fall vorab auszulesen?

Könnte so klappen (unsicher, was 1 oder 0 angeht):

Code Auswählen

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);

frank · 01 Oktober 2021, 17:30:52

leider keinen schritt weiter

Beta-User · 01 Oktober 2021, 17:38:49

Mal ohne defined- Bedingung?
Kann auch der Parameter sein...

frank · 01 Oktober 2021, 18:35:21

ZitatMal ohne defined- Bedingung?

hat nur frust gebracht, da die peers dann weg waren.

Beta-User · 01 Oktober 2021, 18:41:19

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...

frank · 01 Oktober 2021, 18:51:58

du hattest doch mal virtuelle tempsensoren für die rt, oder?
die sollten doch ähnliche probleme haben und ihren if block nicht erreichen:

Code Auswählen

        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]*$/);
        }

Beta-User · 01 Oktober 2021, 23:55:12

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?
Code Auswählen Erweitern
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...)

Beta-User · 02 Oktober 2021, 08:39:33

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...?

frank · 02 Oktober 2021, 18:01:32

hallo beta-user,

jetzt hast du wohl wieder etwas voodoo eingebaut.

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.

Code Auswählen

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 0300

warum 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.

Beta-User · 02 Oktober 2021, 18:10:25

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.)

Beta-User · 03 Oktober 2021, 13:16:16

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).

frank · 04 Oktober 2021, 12:51:49

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.

Beta-User · 04 Oktober 2021, 13:14:43

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.

frank · 04 Oktober 2021, 14:50:22

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.

Beta-User · 04 Oktober 2021, 15:29:08

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 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.

frank · 04 Oktober 2021, 18:51:10

deine aktuelle cul_hm/hminfo kombi von hier hat bezüglich den vtc nicht neues gebracht.

Code Auswählen

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. die punkte 1-3 haben sich nun wohl erledigt, wodurch kein manueller configcheck mehr nötig ist.

frank · 04 Oktober 2021, 19:05:39

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.

Beta-User · 04 Oktober 2021, 19:27:25

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...?

Beta-User · 04 Oktober 2021, 22:55:07

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

frank · 05 Oktober 2021, 13:49:43

mit den neuen versionen zündet stufe2 auch bei mir und alle ventile haben erneut den restart überlebt.

attr param msgreduce muss weiterhin manuell erfolgen.

für dich nun auch mal das log mit verbose=3 für hminfo und actiondetector:

Code Auswählen

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.

Code Auswählen

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".

Beta-User · 05 Oktober 2021, 15:32:19

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.

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).

frank · 05 Oktober 2021, 16:48:07

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.

Beta-User · 05 Oktober 2021, 17:01:50

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 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

. Vielleicht liegt das auch daran, dass "VIRTUAL" nicht explizit (nach-) gesetzt wird, und daher nicht klar ist, welche subType-spezifischen Werte eigentlich erlaubt sind...

frank · 05 Oktober 2021, 19:17:40

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

Code Auswählen

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

Code Auswählen

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

frank · 05 Oktober 2021, 19:24:10

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.

Beta-User · 05 Oktober 2021, 19:45:40

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?

frank · 05 Oktober 2021, 20:57:42

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
noansi hat gerade ein lebenszeichen gesetzt. vielleicht hat er auch wieder lust zu helfen.

Beta-User · 05 Oktober 2021, 21:20:45

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

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...

frank · 10 Oktober 2021, 12:16:23

mit den aktuellen updates aus dem svn von heute funktionieren vtc/vd wieder wie gewohnt.
danke beta-user und martin.