[cul_hm] falsche io zuweisungen nach fhem restart

[frank]

das löschen von attr IODev, falls eine vccu vorhanden ist,  führt nun zu jeder menge falscher io zuweisungen beim fhem restart.

der letzte fhem restart ist schon etwas her. die falschen zuweisungen betreffen in folgender liste nur virtuelle devices.

Code Auswählen Erweitern

devices using ccu
current IO / preferred
  cul868 / cul868 HM_196BD8
  cul868 / cul868 SwitchES01
  cul868 / cul868 SwitchPBU07
  cul868 / cul868 SwitchPBU08
  cul868 / cul868 SwitchPBU09
  cul868 / cul868 Thermostat.GZ
  cul868 / cul868 Thermostat.Keller
  cul868 / cul868 Tuer.SZ
  cul868 / cul868 Wetter.Sued
  cul868 / cul868 rssi_hmuart
  cul868 / cul868 test
  cul868 / hmlan1 SDTeam
  cul868 / hmlan1 VentilControler.AZ.Nord
  cul868 / hmlan1 VentilControler.AZ.West
  cul868 / hmlan1 VentilControler.Bad
  cul868 / hmlan1 VentilControler.Kueche
  cul868 / hmlan1 VentilControler.SZ
  cul868 / hmlan1 VentilControler.WZ
  cul868 / hmlan1 ccu
  cul868 / hmlan1 virtAktorAlarmOff
  hmlan1 / hmlan1 DimPBU01
  hmlan1 / hmlan1 DimUP01
  hmlan1 / hmlan1 Fenster.Bad
  hmlan1 / hmlan1 SD.AZ
  hmlan1 / hmlan1 SD.SZ
  hmlan1 / hmlan1 SD.WZ
  hmlan1 / hmlan1 SwitchPBU01
  hmlan1 / hmlan1 SwitchPBU03
  hmlan1 / hmlan1 SwitchPBU04
  hmlan1 / hmlan1 SwitchPBU05
  hmlan1 / hmlan1 SwitchPBU06
  hmlan1 / hmlan1 SwitchPL01
  hmlan1 / hmlan1 SwitchPL02
  hmlan1 / hmlan1 SwitchUP01
  hmlan1 / hmlan1 Thermostat.AZ
  hmlan1 / hmlan1 Thermostat.Bad
  hmlan1 / hmlan1 Thermostat.Kueche
  hmlan1 / hmlan1 Thermostat.OZ
  hmlan1 / hmlan1 Thermostat.WZ
  hmlan1 / hmlan1 Tuer.WZ.Terrasse
  hmlan1 / hmlan1 Ventil.AZ.Nord
  hmlan1 / hmlan1 Ventil.Bad
  hmlan1 / hmlan1 Ventil.SZ
  hmlan1 / hmlan1 virt_vd
  hmlan1 / hmlan1,none SwitchUP02
  hmuart1 / hmuart1 HM_114B05
  hmuart1 / hmuart1 SwitchPBU02
  hmuart1 / hmuart1 Thermostat.Bad.OG
  hmuart1 / hmuart1 Thermostat.SZ
  hmuart1 / hmuart1 Ventil.AZ.West
  hmuart1 / hmuart1 Ventil.Kueche
  hmuart1 / hmuart1 Ventil.WZ
  hmuart1 / hmuart1 Wetter.Nord

[frank]

zusätzlich noch 3 probleme bzgl vccu:

1. "get vccu listDevice" zeigt auch leider ignored devices. das habe ich in zeile 4852 unterdrückt:

Code Auswählen Erweitern

      foreach (@dl){
        next if($attr{$_}{ignore});

2. "attr IOgrp" lässt keine option "none" zu. beim versuch erfolgt die meldung:

Code Auswählen Erweitern

none is not part if VCCU IOs:cul868,hmlan1,hmuart1,hmusb1cul868,hmlan1,hmuart1,hmusb1
die auflistung der io ist nicht ganz korrekt, da doppelt.

3. falsches attribut handling, wenn attr IOgrp in fhem.cfg die option "none" bereits enthält.
zb helper/io zeigt fehlende einträge, attr IODev nicht gelöscht, ...

Code Auswählen Erweitern

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:showTimed 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
   .triggerUsed 1
   DEF        285A44
   FUUID      5c4ce2eb-f33f-09c4-81bd-f766b72b92785b80
   IODev      hmlan1
   LASTInputDev hmlan1
   MSGCNT     7
   NAME       SwitchUP02
   NR         443
   NTFY_ORDER 48-SwitchUP02
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   cul868_MSGCNT 2
   cul868_RAWMSG A0E048002285A441ACE1F0101000040::-69:cul868
   cul868_RSSI -69
   cul868_TIME 2021-10-06 11:32:48
   disableNotifyFn 1
   hmlan1_MSGCNT 3
   hmlan1_RAWMSG R54F2C5CD,0001,5DC410A4,FF,FFC3,048002285A441ACE1F0101000040
   hmlan1_RSSI -61
   hmlan1_TIME 2021-10-06 11:32:48
   hmuart1_MSGCNT 2
   hmuart1_RAWMSG 0500003A048002285A441ACE1F0101000040
   hmuart1_RSSI -58
   hmuart1_TIME 2021-10-06 11:32:48
   lastMsg    No:04 - t:02 s:285A44 d:1ACE1F 0101000040
   peerList   self01
   protLastRcv 2021-10-06 11:32:48
   protRcv    2 last_at:2021-10-06 11:32:48
   protSnd    3 last_at:2021-10-06 11:32:48
   protState  CMDs_done
   rssi_at_cul868 cnt:2 min:-69 max:-69 avg:-69 lst:-69
   rssi_at_hmlan1 cnt:3 min:-61 max:-61 avg:-61 lst:-61
   rssi_at_hmuart1 cnt:2 min:-58 max:-58 avg:-58 lst:-58
   rssi_hmlan1 cnt:2 min:-65 max:-64 avg:-64.5 lst:-64
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .attrtocr:
     .*
   CL:
     Authenticated 0
     BUF       
     FD         94
     FW_ID      1689
     LASTACCESS 1633516455
     NAME       WEB_192.168.1.31_50181
     NR         1691
     PEER       192.168.1.31
     PORT       50181
     SNAME      WEB
     SSL       
     STATE      Connected
     TEMPORARY  1
     TYPE       FHEMWEB
     canAsyncOutput 1
     .attraggr:
     .attrminint:
     READINGS:
       2021-10-06 12:34:08   state           Connected
   READINGS:
     from archivexx        .D-devInfo      010100
     from archivexx        .D-stc          10
     2021-10-06 11:31:45   .associatedWith SwitchUP02,SwitchUP02
     2021-07-03 23:17:31   .peerListRDate  2021-07-03 23:17:31
     2021-10-06 11:32:48   .protLastRcv    20211006113248
     2021-05-13 16:19:10   Activity        alive
     2021-05-13 16:18:02   CommandAccepted yes
     from archivexx        D-firmware      1.12
     from archivexx        D-serialNr      LEQ0130401
     2021-10-06 11:32:48   IODev           hmlan1
     2021-05-13 16:29:56   PairedTo        0x1ACE1F
     2021-10-06 10:10:13   R-intKeyVisib   visib
     2021-10-06 10:10:13   R-pairCentral   0x1ACE1F
     2021-10-06 10:10:13   R-self01-lgActionType jmpToTarget
     2021-10-06 10:10:13   R-self01-lgCtDlyOff geLo
     2021-10-06 10:10:13   R-self01-lgCtDlyOn geLo
     2021-10-06 10:10:13   R-self01-lgCtOff geLo
     2021-10-06 10:10:13   R-self01-lgCtOn geLo
     2021-10-06 10:10:13   R-self01-lgCtValHi 100
     2021-10-06 10:10:13   R-self01-lgCtValLo 50
     2021-10-06 10:10:13   R-self01-lgMultiExec on
     2021-10-06 10:10:13   R-self01-lgOffDly 0 s
     2021-10-06 10:10:13   R-self01-lgOffTime unused
     2021-10-06 10:10:13   R-self01-lgOffTimeMode absolut
     2021-10-06 10:10:13   R-self01-lgOnDly 0 s
     2021-10-06 10:10:13   R-self01-lgOnTime unused
     2021-10-06 10:10:13   R-self01-lgOnTimeMode absolut
     2021-10-06 10:10:13   R-self01-lgSwJtDlyOff off
     2021-10-06 10:10:13   R-self01-lgSwJtDlyOn on
     2021-10-06 10:10:13   R-self01-lgSwJtOff dlyOn
     2021-10-06 10:10:13   R-self01-lgSwJtOn dlyOff
     2021-10-06 10:10:13   R-self01-shActionType jmpToTarget
     2021-10-06 10:10:13   R-self01-shCtDlyOff geLo
     2021-10-06 10:10:13   R-self01-shCtDlyOn geLo
     2021-10-06 10:10:13   R-self01-shCtOff geLo
     2021-10-06 10:10:13   R-self01-shCtOn geLo
     2021-10-06 10:10:13   R-self01-shCtValHi 100
     2021-10-06 10:10:13   R-self01-shCtValLo 50
     2021-10-06 10:10:13   R-self01-shMultiExec off
     2021-10-06 10:10:13   R-self01-shOffDly 0 s
     2021-10-06 10:10:13   R-self01-shOffTime unused
     2021-10-06 10:10:13   R-self01-shOffTimeMode absolut
     2021-10-06 10:10:13   R-self01-shOnDly 0 s
     2021-10-06 10:10:13   R-self01-shOnTime unused
     2021-10-06 10:10:13   R-self01-shOnTimeMode absolut
     2021-10-06 10:10:13   R-self01-shSwJtDlyOff off
     2021-10-06 10:10:13   R-self01-shSwJtDlyOn on
     2021-10-06 10:10:13   R-self01-shSwJtOff dlyOn
     2021-10-06 10:10:13   R-self01-shSwJtOn dlyOff
     2021-10-06 10:10:13   R-sign          off
     2021-05-13 16:29:56   RegL_00.        00:00 02:81 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1A 0B:CE 0C:1F
     2021-05-13 16:29:56   RegL_01.        00:00 08:00
     2021-05-13 16:29:58   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63
     2021-10-04 17:56:47   cfgState        ok
     2021-10-06 11:32:48   commState       CMDs_done
     2021-10-06 01:11:18   deviceMsg       off (to ccu)
     2021-10-06 01:11:18   level           0
     2021-10-06 01:11:18   pct             0
     2021-10-06 11:31:45   peerList        self01
     2021-10-06 11:32:48   recentStateType ack
     2021-10-06 11:32:48   state           off
     2021-09-28 22:23:09   test            off
     2021-09-28 22:23:09   timedOn         off
     -                     tmpl_0          sw99,
     2021-05-13 16:18:01   trigLast        fhem:02
   helper:
     HM_CMDNR   4
     cSnd       011ACE1F285A44010E,111ACE1F285A440201000000
     dlvlCmd    ++A0111ACE1F285A440201000000
     lastMsgTm  1633512768.74952
     mId        0002
     peerFriend peerSens,peerVirt
     peerIDsState complete
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     cmds:
       TmplKey    self01:1633512706.75605:1633512707.21596
       TmplTs     1633512707.21596
       cmdKey     1:1:0::SwitchUP02:0002:01:self01
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         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
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         pair       noArg
         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
         toggle     noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_self01 -tplPeer-
         unpair     noArg
       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,SwitchPBU02_Btn_01,SwitchPBU02_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,virt_vd_Btn1
         tplChan    sw99
         tplDel     0>sw99
         tplPeer    SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOff_long,SwOff_short,SwOnCond_long,SwOnCond_short,SwOn_long,SwOn_short,SwToggleIgnore,SwToggle_long,SwToggle_short,autoOff_long,autoOff_short,ignore_long,ignore_short,motionOnSw_long,motionOnSw_short,off-for-timer_switch_long,off-for-timer_switch_short,toggleOn-for-timerOff_switch_long,toggleOn-for-timerOff_switch_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     +285A44,00,00,00
       nextSend   1633512768.87684
       rxt        0
       vccu       
       p:
         285A44
         00
         00
         00
       prefIO:
     mRssi:
       mNo        04
       io:
         cul868:
           -69
           -69
         hmlan1:
           -57
           -57
         hmuart1:
           -58
           -58
     peerIDsH:
       00000000   broadcast
       285A4401   self01
     prt:
       bErr       0
       sProc      0
       tryMsg:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_cul868:
         avg        -69
         cnt        2
         lst        -69
         max        -69
         min        -69
       at_hmlan1:
         avg        -61
         cnt        3
         lst        -61
         max        -61
         min        -61
       at_hmuart1:
         avg        -58
         cnt        2
         lst        -58
         max        -58
         min        -58
       hmlan1:
         avg        -64.5
         cnt        2
         lst        -64
         max        -64
         min        -65
     shadowReg:
     tmpl:
       0>sw99     
Attributes:
   .mId       0004
   IODev      hmlan1
   IOgrp      ccu:hmlan1,none
   actCycle   024:00
   actStatus  alive
   alias      Fluter_Garten
   autoReadReg 5_readMissing
   commStInCh off
   event-on-change-reading .*
   expert     defReg,allReg,rawReg,templ
   firmware   1.12
   group      Beleuchtung
   model      HM-LC-SW1-FM
   peerIDs    00000000,285A4401
   room       02_handy,70_Garten_Licht
   serialNr   LEQ0130401
   subType    switch
   timestamp-on-change-reading .*
   webCmd     :

[Beta-User]

ad 1: finde ich gut, würde das aber ergänzen zu

Code Auswählen Erweitern

next if IsIgnored($_) || IsDummy($_);

ad 2:
a) "none" für IOgrp ist vermutlich in der Folge tricky. Würde darauf verweisen, dass man das beim IO machen kann (da wird dann dummy gesetzt).
b) zu "doppelt" kann ich noch nichts sagen, bis dato vermute ich keine gravierenden Probleme dahinter, ist halt "ein Userfehler" (?)...

Zum Generellen:
Ohne Attribut (neuerdings) kein Startpunkt. Es greift dann (~#10927)

Code Auswählen Erweitern

tricky: use first active IO else use any IO for CUL_HM

Wenn man daran was ändern wollte, ohne den User auf das/die zu setzende(n) Attribut(e) IOgrp/IODev zu verweisen (?), müßte man m.E. davor noch einen "elsif"-Zweig reinbasteln, der die VIRTUALs einer Sonderbehandlung unterzieht. Das _könnte_ die Auswertung der Peers sein. Dabei wären aber noch Kriterien festzulegen, nach denen die Auswahl erfolgen soll... (relativ viel Aufwand für ein m.E. sowieso vom User zu prüfendes Ergebnis).

[frank]

ich habe den verdacht, dass du die option "none" für prefered io in attr IOgrp nicht kennst.
sie wurde erst kurz vor der einführung des neuen attribut handlings "repariert" und hat bestens funktioniert.
nun wurde die option im attribut check vergessen/übersehen.

bsp aus der commandref:

Code Auswählen Erweitern

attr myDevice2 IOgrp vccu:prefIO1,prefIO2,none

es werden nur prefIO1,prefIO2 von der vccu für dieses io verwendet.
sind die angegebenen prefered io nicht operabel, werden weitere io der IOList nicht verwendet.
die reihenfolge der prefered io ist massgebend für die auswahl des aktuellen io.

[frank]

b) zu "doppelt" kann ich noch nichts sagen, bis dato vermute ich keine gravierenden Probleme dahinter, ist halt "ein Userfehler" (?)...

da muss man nur etwas weglassen in zeile 1118, zb:

Code Auswählen Erweitern

        foreach my $pIO (@prefIOarr){
          return "$pIO is not part if VCCU IOs:$ioLst" if(1 != grep/$pIO/,@ioOpts);


[Beta-User]

"Kennen" ja, aber wohl vergessen.

Vorschlag für #1113ff:

Code Auswählen Erweitern

        my @ioOpts = split(",",$ioLst);
        return "$ioCCU not a valid CCU with IOs assigned" if (!scalar @ioOpts);
        push @ioOpts, 'none' if $ioLst !~ m{none}; #Beta-User: Might fix #2 from https://forum.fhem.de/index.php/topic,123238.msg1178193.html#msg1178193
        @prefIOarr = split(",",$prefIO);
        foreach my $pIO (@prefIOarr){
          return "$pIO is not an allowed value for preferred IO list. Leave unassigned or choose one or more of ".join(",",@ioOpts) if(1 != grep/$pIO/,@ioOpts);
        }Kann aber sein, dass ich mal wieder was übersehe...

[frank]

Kann aber sein, dass ich mal wieder was übersehe...

ich hatte ja oben noch einen 3. punkt angefügt, dass die option none nicht nur nicht einzugeben ist, sondern auch nicht richtig bei fhem start behandelt wird.

Code Auswählen Erweitern

push @ioOpts, 'none' if $ioLst !~ m{none}; #Beta-User: Might fix #2 from https://forum.fhem.de/index.php/topic,123238.msg1178193.html#msg1178193
das if ist schlecht, da "none" zb im namen "hm_funkkanone" vorkommt. 
none muss ja grundsätzlich erlaubt sein, aber sinnvoll eigentlich nur am ende von IOgrp und wenn davor mindestens ein io steht.

mit deinem vorschlag würde none auch in helper/io/prefio stehen. ist das so vorgesehen?

[Beta-User]

...wie es vorgesehen ist, kann ich wieder mal nicht beantworten...

Den Hash und die Eingabemöglichkeiten bekommt man jedenfalls m.E. erst mal dadurch gradegebogen, dass man das wie folgt macht:

Code Auswählen Erweitern

if ($prefIO){
        my @ioOpts = split(",",$ioLst);
        return "$ioCCU not a valid CCU with IOs assigned" if (!scalar @ioOpts);
        push @ioOpts, 'none'; #Beta-User: Might fix #2 from https://forum.fhem.de/index.php/topic,123238.msg1178193.html#msg1178193
        @prefIOarr = split(",",$prefIO);
        foreach my $pIO (@prefIOarr){
          return "$pIO is not an allowed value for preferred IO list. Leave unassigned or choose one or more of ".join(",",@ioOpts) if(1 != grep m{\A$pIO\z},@ioOpts);
          return "'none' may not be used without precedent other IO and has to be last!" if $prefIO eq 'none' || $prefIO =~ m{\bnone[\b]*.+\z};
        }
        pop @prefIOarr if $prefIOarr[-1] eq 'none';
      }
Anmerkungen:
- $ioLst ist in der Regel "sauber", wenn man nicht dusseligerweise ein zulässiges IO-Type-Gerät mit "none" benannt hat, ergo kann man einfach anfügen;
- die Regex ist jetzt schärfer, vorher paßte "a" auch für "myHmuart";- 'none' muss jetzt hinten stehen (wenn gesetzt);
- 'none' wird nicht mehr in die helper-Liste übernommen.

Bin mal gespannt, welche Seiteneffekte das ggf. hat...

[frank]

eingabe und erkennung IOgrp/none scheint ok.
es funktioniert nur nicht. sowohl mit als auch ohne "none" unter helper/io/prefio

mit attr IOgrp ccu:hmlan1,none switched die vccu trotzdem auf ein anderes, verbotenes io, obwohl ich den hmlan mit set close disconnectet habe.

[Beta-User]

Ohne damit behaupten zu wollen, dass ich  ansatzweise verstehen würde, wie das abläuft und ob und wo ggf. durch die Umstellerei neue Probleme entstanden sein könnten: Hat das mal funktioniert? (oder schauen wir nur sehr viel genauer hin?)

[frank]

Ohne damit behaupten zu wollen, dass ich  ansatzweise verstehen würde, wie das abläuft und ob und wo ggf. durch die Umstellerei neue Probleme entstanden sein könnten: Hat das mal funktioniert? (oder schauen wir nur sehr viel genauer hin?)

vermutlich, schwören werde ich nicht. 
ausserdem ist die frage, ob martin noansis reparatur korrekt übernommen hat und ich dann auch noch martins version getestet habe. zumindestens nutzt noansi die option in seiner cul_hm erfolgreich, um einen hmuart von einem virtuellen device fernzuhalten. hmuarts können das nicht leisten und stürzen sogar gelegentlich dabei ab.

[frank]

only for interest.

ich habe mal ein wenig den code von der "aktuellen" cul_hm und der, die ich vorher benutzt habe (https://forum.fhem.de/index.php/topic,121139.msg1158983.html#msg1158983), verglichen.

1. in helper/io/prefio muss auch "none" auftauchen, wenn gesetzt. => also die poll zeile wieder weg.

2. in CUL_HM_assignIO gab es eine untersuchung auf "none", die jetzt nicht mehr existiert.
mir ist allerdings noch nicht ganz klar, ob der code dort letztendlich auch die gewünschte wirkung hat. eventuell wird dort das zunächst richtige ergebnis im weiteren verlauf wieder "ausgehebelt".
wahrscheinlich müsste ich die version mal daraufhin testen (fraglich, ob ich dann wieder zurückkehre  ).

3. ausserdem gab es helper/io/restoredIO, dass aktuell nur noch für noansis tscul genutzt wird.
kein wunder, wenn jetzt nichts mehr funktioniert wie es mal war.

[Beta-User]

Anbei meine aktuelle experimentelle Version - läuft aber noch nicht lange im Hauptsystem. Bisher keine Auffälligkeiten, es wurden über der Zeit ein paar "inadäquate" Attribute gelöscht, ansonsten: keine Massen an configCheck -f-Einträgen, der eine oder andere RT blinkt noch, aber da bin ich optimistisch...

Eingearbeitet sind einige Dinge, die mir aus noansi's Vorschlag zu 24374 sinnvoll erschienen (zugegeben: Bauchgefühl...), einige Kommentare, wo das nicht erfolgt ist bzw. mir noch zu viel unklar war oder die schiere Masse zu hoch.

Im Ergebnis: Wundertüte. Keine Ahnung, was man davon wirklich braucht, was zu viel ist und was schädlich bzw. was auch durch andere Mechanismen bereits abgefrühstückt, ich wollte einfach wieder eine lauffähige Version haben, die ggf. als Basis zum Weiterüberlegen taugt. noansi hatte wohl eine Option vorgesehen, Nachrichten zu puffern. Das ist an der Stelle noch nicht vollständig eingearbeitet und wohl dann erst mal die nächste Baustelle.

Was "restoredIO" angeht, bin ich zwischenzeitlich nicht sicher, ob es nicht ausreicht, das Reading "IODev" auszulesen (rechtzeitig, bevor was reinkommt, das ggf. die Info überschreibt?)? Muss aber ggf. erst mal sehen, wo das überhaupt herkommt...

Jetzt bin ich aber erst mal auf Rückmeldungen gespannt bzw. die Frage, ob es auch auf längere Sicht erst mal stressfrei läuft...

[frank]

das hauptproblem ist die verfügbarkeit der io beim start.
mein cul ist schon verfügbar, da wacht cul_hm wahrscheinlich gerade erst auf. 

so bekommen viele devices automatisch (fhem.pl?) den cul zugewiesen. das falsche zuweisen betrifft scheinbar hauptsächlich devices mit prefered hmlan. der ist am spätesten fertig.
das umswitschen auf den richtigen io erfolgt erst, wenn msgs an diese devices gesendet werden.

der automatische statusrequest "richtet" es quasi bei einigen davon.

nach iodev reading setzen bringt erst was, wenn mal alle devices richtig zugeordnet wären. alle config devices bleiben quasi ewig beim cul.

zusätzlich passt die io präparation beim hmlan nicht zur liste listDevices der ccu. beim start behält er die prep von vor dem start, im internal iodev steht der cul bis zur ersten msg.

[Beta-User]

das hauptproblem ist die verfügbarkeit der io beim start.
mein cul ist schon verfügbar, da wacht cul_hm wahrscheinlich gerade erst auf. 

...wenn schon, denn schon: Die Reihenfolge in der cfg sollte keine Rolle spielen . Ein CUL ist zwar schnell wieder da, wenn man die Baudrate gesetzt hat, aber es kann durchaus sein, dass CUL_HM da schon geladen ist (wenn auch meistens vermutlich nicht schon INITIALIZED durch ist).

so bekommen viele devices automatisch (fhem.pl?) den cul zugewiesen. das falsche zuweisen betrifft scheinbar hauptsächlich devices mit prefered hmlan. der ist am spätesten fertig.

Vermutlich ist jedes "remote" Gerät ein Problem, weil zumindest bei einem "richtigen" Server (oder Pi mit RTC) kann es durchaus sein, dass nach einem Stromausfall oä. dann erst mal nur eines von vielen IO's verfügbar ist, (weil das Netz noch weg ist,) und auch beim HMUART bin ich nicht sicher, ob man den "gleich" benutzen kann. Unabhängig davon frage ich mich, ob man nicht einige Zeit nach dem Start mal (ggf. wiederholend) checken sollte, ob denn alle IO-Einstellungen zu den Wunschvorstellungen des Users passen.

das umswitschen auf den richtigen io erfolgt erst, wenn msgs an diese devices gesendet werden.

Danke für den Hinweis, diesen Mechanismus hätte ich sonst vermutlich ewig gesucht. (ohne behaupten zu wollen, das im Code schon lokalisiert zu haben...)

der automatische statusrequest "richtet" es quasi bei einigen davon.

dto.

nach iodev reading setzen bringt erst was, wenn mal alle devices richtig zugeordnet wären. alle config devices bleiben quasi ewig beim cul.

Jein. Es geht uU. auch darum, das IODev-Reading von unmittelbar beim Start (=Stand statefile) beizubehalten bzw. wiederherzustellen, selbst, wenn AssignIO (?) erst mal (mangels Bereitschaft dieses IO's) was anderes gemacht hat. Weiter ist mir unklar, ob die "proposed"-Funktionalität von AssignIO genutzt wird (bzw.: wieso ggf. nicht). Da könnte man eigentlich zumindest das erste "preferred" mit übergeben und hätte dadurch zumindest zwei Optionen (Reading und proposed).

zusätzlich passt die io präparation beim hmlan nicht zur liste listDevices der ccu. beim start behält er die prep von vor dem start, im internal iodev steht der cul bis zur ersten msg.

...das muss ich erst mal verstehen und würde tippen, dass das (u.a. auch) die Folge der geänderten Reihenfolge ist. Würde also erst nochmal den Startvorgang (einschl. einer eventuellen "Nachbehandlung") ansehen. Da gibt es auch eine Sonderbehandlung von HMLAN in NotifyFn, die uU. auch wieder mit da reinspielt.