[cul_hm] falsche io zuweisungen nach fhem restart

frank · 04 Oktober 2021, 11:57:56

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

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 · 06 Oktober 2021, 12:02:22

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

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

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

Code Auswählen

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

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 · 06 Oktober 2021, 12:50:05

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

Code Auswählen

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

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 · 06 Oktober 2021, 13:14:16

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

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 · 06 Oktober 2021, 13:20:59

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

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

Beta-User · 06 Oktober 2021, 13:29:46

"Kennen" ja, aber wohl vergessen.

Vorschlag für #1113ff:

Code Auswählen

        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 · 06 Oktober 2021, 15:21:34

ZitatKann 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

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 · 06 Oktober 2021, 16:03:41

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

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 · 06 Oktober 2021, 22:30:28

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 · 06 Oktober 2021, 22:40:25

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 · 06 Oktober 2021, 23:01:11

Zitat von: Beta-User am 06 Oktober 2021, 22:40:25
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 · 07 Oktober 2021, 12:08:40

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 · 07 Oktober 2021, 22:10:54

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 · 07 Oktober 2021, 22:35:06

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 · 08 Oktober 2021, 07:08:13

Zitat von: frank am 07 Oktober 2021, 22:35:06
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).

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

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

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

dto.

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

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

frank · 08 Oktober 2021, 13:23:36

Zitat von: frank am 07 Oktober 2021, 22:35:06
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.

mit deiner nightly version scheint das problem behoben zu sein, da hmlan und hmuart nun wieder nach restart komplett präpariert werden. zumindestens zeigt es fhem.log.

getconfig auf 2 thermostate mit cul/hmlan liefen wie gewohnt sauber durch.

noch keine negativen auffälligkeiten.

ich denke, die version sollte dancatt probieren.

Beta-User · 08 Oktober 2021, 13:49:15

... denn sie wissen nicht, was sie tun...

OK, der Reihe nach: Ich habe versucht zu verstehen, was da in dem IODev-Handling-Thread diskutiert wurde, und muss zugeben, dass da sehr viel drinsteht, von dem ich 0 (in Worten: NULL) Plan habe, und mir war auch nicht mehr klar, wie da teils die Gemütslage war... Na ja, Schwamm drüber, dann versuchen wir uns mal ans Aufräumen zu machen, denn das "Coding" ist ja teils wild.

Der Haupt-Trick scheint gewesen zu sein, die NotifyFn-Prio zu erhöhen, das geht in die Richtung der Anforderung von Martin, eine gesonderte "Preparation-done"-Fn haben zu wollen, das ganze verbunden damit, erst zu senden (aus den VIRTUALs), wenn timer abgearbeitet werden. Puh, scheinbar Glück gehabt (und die dankenswerterweise erfolgten Rückmeldungen der diversen freiwilligen und unfreiwilligen Tester wohl zutreffend interpretiert)...

Was ggf. noch eine Test wert wäre, wäre tatsächlich (das ungeliebte) Reading auszuwerten (ab #235):

Code Auswählen

    for (@hmdev){
      $defs{$_}->{helper}{io}{restoredIO} = ReadingsVal($_,'IODev',undef) if ReadingsVal($_,'IODev',undef); #Beta-User: try to keep startup info somewhere
      if ( defined $attr{$_}{IODev} ) {

Vielleicht magst du das noch testen, es könnte aber sein, dass das "falsch" ist, wenn/weil AssignIoPort() über die Attributauswertung (vorher schon) "nachgesetzt" hatte und wir daher zu spät kommen.

Ansonsten wäre die Frage, wie dancatt die Info bekommt, und wer den Code-Mist dann wieder aufräumt....

frank · 08 Oktober 2021, 15:10:01

immer langsam.

vorhin habe ich nur davon gesprochen, dass die präparation der eq3 io (hmlan/hmuart) jetzt vermutlich von anfang an synchron ist mit dem internal IODev.

das bedeutet aber noch lange nicht, dass die aktuelle zuordung (internal IODev) der io dem entspricht, was unter IOgrp/prefered eingestellt ist. jetzt werden dem hmlan beim initialisieren sämtliche devices zunächst "entzogen" ("I:-", unassigned), da bis zu diesem zeitpunkt dem hmlan scheinbar kein einziges device zugeordnet wurde.
zu diesem zeitpunkt vermute ich bei allen devices den cul im internal IODev.

Code Auswählen

2021.10.08 12:26:47.230 1: CUL_HM start inital cleanup
2021.10.08 12:26:52.183 1: CUL_HM finished initial cleanup
2021.10.08 12:26:52.266 3: HMinfo hminfo get:loadConfig :
2021.10.08 12:26:52.853 3: HMinfo hminfo get:configCheck :
2021.10.08 12:26:54.459 3: Opening SqueezeBoxServer device 192.168.1.10:9090
2021.10.08 12:26:57.464 1: SqueezeBoxServer: Can't connect to 192.168.1.10:9090: Connection timed out
2021.10.08 12:26:57.540 3: SB_SERVER_Notify(SqueezeBoxServer): DISCONNECTED - STATE: disconnected power: ?
2021.10.08 12:26:57.560 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2021.10.08 12:26:57.578 0: HMLAN_Send:  hmlan1 I:Y01,00,
2021.10.08 12:26:57.579 0: HMLAN_Send:  hmlan1 I:Y02,00,
2021.10.08 12:26:57.580 0: HMLAN_Send:  hmlan1 I:Y03,00,
2021.10.08 12:26:57.581 3: Opening hmuart1 device /dev/ttyAMA0
2021.10.08 12:26:57.583 3: Setting hmuart1 serial parameters to 115200,8,N,1
2021.10.08 12:26:57.587 3: hmuart1 device opened
2021.10.08 12:26:57.741 3: cul433 IT_set: IT09 on
2021.10.08 12:26:58.494 0: Featurelevel: 6
2021.10.08 12:26:58.495 0: Server started with 524 defined entities (fhem.pl:24776/2021-07-19 perl:5.028001 os:linux user:fhem pid:12019)
2021.10.08 12:26:59.185 0: HMLAN_Send:  hmlan1 I:-1F64D8
2021.10.08 12:26:59.187 0: HMLAN_Send:  hmlan1 I:-1C1BE3
2021.10.08 12:26:59.188 0: HMLAN_Send:  hmlan1 I:-52C4DF
2021.10.08 12:26:59.190 0: HMLAN_Send:  hmlan1 I:-52BB90
2021.10.08 12:26:59.192 0: HMLAN_Send:  hmlan1 I:-52BB9D
2021.10.08 12:26:59.193 0: HMLAN_Send:  hmlan1 I:-24AF1D
2021.10.08 12:26:59.195 0: HMLAN_Send:  hmlan1 I:-266EA5
2021.10.08 12:26:59.197 0: HMLAN_Send:  hmlan1 I:-25E38E
2021.10.08 12:26:59.198 0: HMLAN_Send:  hmlan1 I:-1A164B
2021.10.08 12:26:59.200 0: HMLAN_Send:  hmlan1 I:-3913D3
2021.10.08 12:26:59.202 0: HMLAN_Send:  hmlan1 I:-285A54
2021.10.08 12:26:59.203 0: HMLAN_Send:  hmlan1 I:-285A44
2021.10.08 12:26:59.205 0: HMLAN_Send:  hmlan1 I:-206278
2021.10.08 12:26:59.206 0: HMLAN_Send:  hmlan1 I:-1936FF
2021.10.08 12:26:59.208 0: HMLAN_Send:  hmlan1 I:-206487
2021.10.08 12:26:59.210 0: HMLAN_Send:  hmlan1 I:-2064CB
2021.10.08 12:26:59.212 0: HMLAN_Send:  hmlan1 I:-206219
2021.10.08 12:26:59.213 0: HMLAN_Send:  hmlan1 I:-1D252E
2021.10.08 12:26:59.215 0: HMLAN_Send:  hmlan1 I:-20DFE1
2021.10.08 12:26:59.217 0: HMLAN_Send:  hmlan1 I:-1DFDA5
2021.10.08 12:26:59.219 0: HMLAN_Send:  hmlan1 I:-1BF81B
2021.10.08 12:26:59.220 0: HMLAN_Send:  hmlan1 I:-1DE620
2021.10.08 12:26:59.222 0: HMLAN_Send:  hmlan1 I:-1DF7C6
2021.10.08 12:26:59.224 0: HMLAN_Send:  hmlan1 I:-1C4E25
2021.10.08 12:26:59.225 0: HMLAN_Send:  hmlan1 I:-1F91AA
2021.10.08 12:26:59.227 0: HMLAN_Send:  hmlan1 I:-193A9A
2021.10.08 12:26:59.229 0: HMLAN_Send:  hmlan1 I:-1BFC52
2021.10.08 12:26:59.230 0: HMLAN_Send:  hmlan1 I:-1DFC2F
2021.10.08 12:26:59.232 0: HMLAN_Send:  hmlan1 I:-1CE9F5
2021.10.08 12:26:59.234 0: HMLAN_Send:  hmlan1 I:-6869B6

die explizit gewünschte zuordnung gemäss attr IOgrp/prefered wird weiterhin erst durch messages an die devices nach und nach quasi zufällig hergestellt, ggf nie.

Code Auswählen

2021.10.08 12:27:00.970 3: CUL_HM set Thermostat.OZ_Climate statusRequest noArg
2021.10.08 12:27:00.973 0: HMLAN_Send:  hmlan1 I:+20DFE1,02,00,00

Beta-User · 08 Oktober 2021, 15:24:22

...die Frage ist vermutlich doof (oder ketzerisch), aber was ist schädlich daran, wenn die Zuordnung erst beim ersten Senden gemacht wird?

Mal abgesehen von einem gewissen wear-out des EEPROM (falls das IO keinen volatilen Speicher für sowas hat) zur Speicherung/dem Löschen dieser Infos macht es für das Empfangen erst mal keinen Unterschied, wer diese Art Info an ParseFn weitergibt. Das hilft ggf. sogar erst mal um festzustellen, wie die aktuelle sendetechnische Landschaft so aussieht (RSSI-Werte sammeln und auswerten). Allenfalls für das Versenden von rechtzeitigen Acks könnte das ein Problem darstellen, wobei das dann auch nur (jeweils einmalig) eine etwas längere Empfangsbereitschaft (Batteriekapazität) der empfangenden Geräte bedeutet, oder?
Ansonsten ist es doch ausreichend, wenn die Landschaft erst nach und nach wieder (dynamisch) aufgebaut wird.

Oder gibt es prinzipielle Probleme bei der Auswahl nach den Prio-Listen (Device/VCCU)?

(Sorry, ich bin eigentlich nicht tief genug in dieser ganzen Materie drin).

frank · 08 Oktober 2021, 17:21:34

genau, IOgrp legt nur das io zum senden fest.

Zitat...die Frage ist vermutlich doof (oder ketzerisch), aber was ist schädlich daran, wenn die Zuordnung erst beim ersten Senden gemacht wird?

was ist eigentlich schädlich daran, immer sofort das richtige zu tun?
vor allem wenn man direkt angegeben hat, was das richtige ist.

du rennst doch sicherlich auch nicht immer zunächst gegen die tür und machst dann erst im nächsten versuch die tür vorher auf.

Beta-User · 09 Oktober 2021, 13:53:16

Hmm, weiß nicht recht, na jedenfalls:

wenn ich das Log richtig deute, ist das Problem, dass HMLAN eigentlich irgendwie weiß, welche Devices bei ihm gemeldet waren. Ich unterstelle, dass die I-Geräte nur ein Teil sind und genau die erst mal abgemeldet sind. Man könnte also genausogut erst mal checken, ob die Tür schon offen ist (also die Devices am HMLAN gemeldet sind), und ob das erwünscht ist (also das zu prefIO paßt). Ich unterstelle mal, dass der Mechanismus prinzipiell derselbe ist wie die verbliebene Abfrage bei TSCUL. Soweit korrekt?
Falls du auch einen TSCUL hast: Dazu steht ja nichts im Log. Es wäre daher naheliegend, die Anfrage beim HMLAN dann zumindest testweise auch da noch reinzuknödeln? Wenn ich das richtig im Kopf habe, wird da ja für TSCUL auch nur ein restoredIO-Eintrag erzeugt. Werde mich aber vermutlich nicht vor Anfang kommender Woche damit befassen können und kann auch nichts testen - vielleicht magst du das angehen...?

frank · 09 Oktober 2021, 14:38:54

- klar kennt der hmlan "seine" assignten devices, so lange fhem sie nicht àndert.
- die "I:-" einträge behandelt alle existierenden, realen devices. das hast du gerade eingebaut. vorher wurde nichts getan.
das hat wohl dazu geführt, dass mindestens einmal bei hmlan und hmuart jeweils das selbe device assignt war. alle 3min wurde das device autonom angefunkt.
- auslesen ist scheinbar nicht möglich/bekannt?
- eigene listen im hash sind nach restart leer.
- ich habe nur einen cul kein tscul. der wird gar nicht präpariert, das ist auch wunderbar so.

als attr IODev noch existierte, hat es scheinbar dafür gesorgt, dass dieser eintrag nach restart auch sicher gesetzt wurde.

Beta-User · 09 Oktober 2021, 16:23:32

Die IODev-Reading-Auswertung atttest du nicht testweise eingebaut, oder?

frank · 09 Oktober 2021, 21:53:54

nein, noch nicht.

frank · 10 Oktober 2021, 12:22:49

ich beobachte nun erst mal martins neue versionen.
das verhalten ist besser, wieder anders, mal schauen.

frank · 10 Oktober 2021, 15:50:42

erste erfahrungen:

1. attr IOgrp option none
kann man nun setzen und hash wird immer entsprechend gefüllt.
ausschluss von io weiterhin nicht möglich. siehe oben.

2. zuweisung der io nach restart
reale devices erhalten nun regelmässig nach IOgrp/prefered ein io zugewiesen. (eventuell wegen iodev reading?)

bei virtuellen devices scheint es einen unterschied zu geben. sieht mehr nach regelmässigem zufall aus.

Beta-User · 11 Oktober 2021, 15:06:26

Zitat von: frank am 10 Oktober 2021, 12:22:49
ich beobachte nun erst mal martins neue versionen.
das verhalten ist besser, wieder anders, mal schauen.

Nur zur Sicherheit: Im Moment gehe ich mal davon aus, dass du dich meldest, wenn noch Bedarf für weitere Lösungsfindung besteht.

ad:

Zitat von: frank am 10 Oktober 2021, 15:50:42
erste erfahrungen:

1. attr IOgrp option none
kann man nun setzen und hash wird immer entsprechend gefüllt.
ausschluss von io weiterhin nicht möglich. siehe oben.

Ich gehe nach dem Code davon aus, dass nach der neuen Logik immer ein IO festgelegt werden muss. Sonst müßte man konsequenter Weise dsa Device dann auch auf dummy o. disabled setzen. Problem bleibt dann aber, dass die Doku nicht zum Verhalten paßt.

Zitat
2. zuweisung der io nach restart
reale devices erhalten nun regelmässig nach IOgrp/prefered ein io zugewiesen. (eventuell wegen iodev reading?)

Vermute auch: wg. des Readings. Das ist die interne Funktionalität von AssignIO.

Zitat
bei virtuellen devices scheint es einen unterschied zu geben. sieht mehr nach regelmässigem zufall aus.

Soweit bin ich noch nicht, aber in dem Zusammenhang eine Rückfrage: Ich habe eine ganze Reihe virtueller Devices/Kanäle und zwei CUL-TYPE IO und einen HMUARTLGW. Irgendwo war zu lesen, dass VIRTUALs und HMUARTLGW nicht so gut zusammenpassen. Ergo scheint die Empfehlung daher zu sein, die VIRTUALS den beiden CUL-TYPE als IO zuzuweisen (je nachdem, wer näher dran ist).
Zumindest in https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU fehlt dazu jedoch bisher ein Hinweis - da habe ich aber grade diverse Änderungen betr. IODev-Löschung eingefügt (wäre nett, wenn noch ein Wissender drübersehen würde). Falls zutreffend: Besser aufgehoben wäre es wohl in https://wiki.fhem.de/wiki/HomeMatic#Besondere_Entities, denn bei der VCCU geht es ja eigentlich eher um die Steuerung der Kommunikation zu echter Hardware (?).

PS: Ist eigentlich noch was offen von deiner langen Liste?

frank · 11 Oktober 2021, 16:39:46

ZitatIch gehe nach dem Code davon aus, dass nach der neuen Logik immer ein IO festgelegt werden muss. Sonst müßte man konsequenter Weise dsa Device dann auch auf dummy o. disabled setzen. Problem bleibt dann aber, dass die Doku nicht zum Verhalten paßt.

ein io soll ja auch weiterhin zugeordnet bleiben, aber keins, das durch IOgrp/none ausgeschlossen wurde.
wenn zb nur eins erlaubt ist, muss man gar nicht erst versuchen, ein anderes zu finden. ist das io nicht operabel, wird eben nichts gesendet. das ist ja schliesslich auch der sinn. darum gibt es ja "none" => kein weiteres io, ausser den prefererd io.
stell dir vor, du hast ein einzelnes device am ende deiner ranch, das nur mit einem io kommunizieren kann, welches in unmittelbarer nähe positioniert ist. es ist doch dann völlig sinnlos ios zum senden an das device zu nötigen, die vielleicht 1km entfernt sind. im ungünstigsten fall geht das "sinnlose" io dadurch in overload und legt somit das restliche system lahm.

ZitatVermute auch: wg. des Readings. Das ist die interne Funktionalität von AssignIO.

einige test haben das bereits wiederlegt.
egal was vorher war, nach restart bekomme ich immer die selbe zuordnung.
reale devices gemäss IOgrp, virtuelle devices nach "geheimer" regel.

ZitatIch habe eine ganze Reihe virtueller Devices/Kanäle und zwei CUL-TYPE IO und einen HMUARTLGW. Irgendwo war zu lesen, dass VIRTUALs und HMUARTLGW nicht so gut zusammenpassen. Ergo scheint die Empfehlung daher zu sein, die VIRTUALS den beiden CUL-TYPE als IO zuzuweisen (je nachdem, wer näher dran ist).

ein problem taucht dann auf, wenn ein device eine msg an ein virtuelles device (mit eigener hmid) sendet, die den hmuart nötigt zu antworten. der hmuart kann nicht im namen dieser hmid (autonome) ACKs senden, weswegen dann im log folgender hinweis erscheint.

Code Auswählen

2021.05.23 09:45:39.114 0: HMUARTLGW hmuart1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!

das problem existiert also nur in bestimmten situationen und die auswirkungen sind sicherlich vom jeweiligen device abhängig. bei der kombi vd/vtc immer dann, wenn der vd konfiguriert wurde. da keine ACKs an den vd gesendet werden, wiederholt er dann sein anliegen permanent, wodurch unnötiger traffic entsteht, was wiederum auf die batterielebensdauer auswirkungen hat.

Beta-User · 11 Oktober 2021, 17:21:32

Zitat von: frank am 11 Oktober 2021, 16:39:46
ein io soll ja auch weiterhin zugeordnet bleiben, aber keins, das durch IOgrp/none ausgeschlossen wurde.

Also ist das in der commandref beschriebene Verhalten das erwünschte.
Die IO-Zuweisung bei vccu ist nach meinem Verständnis in dem if-Pfad ab ~#10867 zu verorten. Da könnte uU. ein "jetzt geht es nicht" am Ende helfen? Dazu gleich noch testweise die Auswertung des Readings im darauffolgenden Zweig:

Code Auswählen


    $newIODevH  = $defs{$iom} if($iom);
    return 0 if $iom && $iom eq 'none';
  }
  
  
  if (!defined $newIODevH) {# not assigned thru CCU - try normal
    my $dIo = AttrVal($hash->{NAME},"IODev",ReadingsVal($hash->{NAME},'IODev',''));

(mir ist schon klar, was damit grundsätzlich bezweckt wird, und danke für die Erläuterung. Das macht klar, dass das Entfallen des features wohl auch keine Absicht ist.

Zitat
einige test haben das bereits wiederlegt.

Mir war nicht klar, dass sich das bereits auf die neue Version bezogen hatte.

Zitat
egal was vorher war, nach restart bekomme ich immer die selbe zuordnung.
reale devices gemäss IOgrp, virtuelle devices nach "geheimer" regel.

IOgrp ist ja erst mal gut, als "geheime Regel" könnte "letztes in der cfg stehendes" in Frage kommen (so geht AssignIOPort vor, wenn ich das richtig im Kopf habe)?
Wobei man sich fragt, warum da nicht auch die allgemeinen preferred-Vorgaben aus einer vermutlich vorhandenen VCCU verwendet werden.
Aber warum bekommen die VIRTUALs eine Sonderbehandlung? Gut, die senden nur von intern, aber wenn da mal was festgelegt wurde (und sei es durch IOgrp), dann sollte das doch durchschlagen? Jedenfalls bisher ist mir beim Drüberfliegen über den Code auch nichts aufgefallen, was das "speziell" sein soll.

Zitat
Code Auswählen Erweitern
2021.05.23 09:45:39.114 0: HMUARTLGW hmuart1: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!

Hatte ich bisher noch nicht bewußt wahrgenommen, aber wenn, müßte das auch ein Problem sein, wenn man virtuelle Fensterkontakte gepeert hat. Die dürften ein ACK anfordern, oder?
Muss aber mal schauen, auf welchem IO die jetzt gelandet sind...

frank · 12 Oktober 2021, 16:12:27

moin,
zunächst mal folgendes:

die 2 funktionen CUL_HM_operIObyIOHash/CUL_HM_operIObyIOName sind nicht ganz korrekt, denke ich.

1. beide sollten die selben kriterien prüfen, also auch beide IsDisabled, oder?
2. die IsDisabled/IsDummy prüfung in CUL_HM_operIObyIOName ist doch falsch geklammert, oder kapiere ich das nicht?
3. der defaultwert von InternalVal($ioname,'XmitOpen',1) muss doch eigentlich 0 sein, damit zb ein hmlan ohne das internal auch als nicht operabel gilt. eventuell kann dieser fall nicht vorkommen, aber ist das wirklich sicher?
4. die prüfungen xmitopen/disconnected sollen doch laut kommentar abhängig vom io type erfolgen. sie werden aber immer für beide durchgeführt. die disconnected prüfung für hmlan sollte aber zumindestens nicht stören.

ich habe die funktionen bei mir jetzt mal so eingebaut:

Code Auswählen

sub CUL_HM_operIObyIOHash($){ # noansi: in iohash, return iohash if IO is operational, else undef
  return if (!defined($_[0]));
  my $ioname = $_[0]->{NAME};
  return if (   !$ioname
             || $_[0]->{TYPE} =~ m/^(HMLAN|HMUARTLGW|TSCUL)$/ && InternalVal($ioname,'XmitOpen',0) == 0 # HMLAN/HMUSB/TSCUL
             || ReadingsVal($ioname,'state','disconnected') eq 'disconnected' # CUL
             || IsDummy($ioname)
             || IsDisabled($ioname)                                                                                                
            );
  return $_[0];
}
sub CUL_HM_operIObyIOName($){ # noansi: in ioname, return iohash if IO is operational, else undef
  return if (!$_[0]);
  my $iohash = $defs{$_[0]};
  return if (   !defined($iohash)
             || $iohash->{TYPE} =~ m/^(HMLAN|HMUARTLGW|TSCUL)$/ && InternalVal($_[0],'XmitOpen',0) == 0 # HMLAN/HMUSB/TSCUL
             || ReadingsVal($_[0],'state','disconnected') eq 'disconnected' # CUL
             || IsDummy($_[0])
             || IsDisabled($_[0])                                                                                                
            );
  return $iohash;
}

5. zusätzlich habe ich noch in zeile 234 den actiondetector rausgefiltert, da dieser sonst unnötigerweise ein io bekommt, was später wieder entfernt wird.

Code Auswählen

    my @hmdev = devspec2array("TYPE=CUL_HM:FILTER=DEF=......:FILTER=DEF!=000000");   # devices only

6. die folgenden 2 zeilen in cul_hm_updateconfig habe ich getauscht, da das setzen von IOList ebenfalls, aber eine andere auswirkung auf das io zeigt, als IOgrp. so gewinnt wenigstens IOgrp.

Code Auswählen

        CUL_HM_Attr('set',$name,'IOList',AttrVal($name,'IOList','')) if AttrVal($name,'IOList',undef); #Beta-User: Fix missing io->ioList in VCCU at startup, https://forum.fhem.de/index.php/topic,122848.msg1174047.html#msg1174047
        CUL_HM_Attr("set",$name,"IOgrp",$IOgrp);

7. auch mit deinen 2 änderungen aus deinem letzten post bleibt es insgesamt noch eine wundertüte.

Beta-User · 12 Oktober 2021, 17:09:37

Hmm, m.E. gute Vorschläge, wobei ich das noch etwas radikaler angehen würde:

Code Auswählen

sub CUL_HM_operIObyIOHash($){ # noansi: in iohash, return iohash if IO is operational, else undef
  return if (!defined($_[0]));
  return CUL_HM_operIObyIOName($_[0]->{NAME}); #Beta-User: use shortcut to get simimar behaviour...
}
sub CUL_HM_operIObyIOName($){ # noansi: in ioname, return iohash if IO is operational, else undef
  return if (!$_[0]);
  my $iohash = $defs{$_[0]};
  return if (   !defined($iohash)
             || defined InternalVal($_[0],'XmitOpen',undef) && InternalVal($_[0],'XmitOpen',0) == 0 # HMLAN/HMUSB/TSCUL
             || ReadingsVal($_[0],'state','disconnected') eq 'disconnected' # CUL
             || IsDummy($_[0])
             || IsDisabled($_[0])
            );
  return $iohash;
}

Ob man das mit XmitOpen so braucht, sei mal dahingestellt, vermutlich hatte der "falsche" Default-Wert den Zweck, die CUL-TYPE Geräte auf billige Art rauszufiltern (regex ist vergleichsweise teuer, daher der obige Vorschlag, der auch etwas "generischer" ist, falls es wider Erwarten neue Geräte/IO-TYPE gäbe...)

Habe gestern noch meine VIRTUALs alle auf CUL-TYPE IOs als preferred umgezogen, das war soweit erkennbar auch "Neustartfest". Vorher war ein Teil beim HMUARTLGW gehangen, der Rest beim CUL, nichts beim Maple

frank · 13 Oktober 2021, 15:22:31

hallo beta-user,

mit folgendem anfang meiner CUL_HM_assignIO(), ist preferedIO/none nun wirksam, so dass keine weiteren io mehr gewählt werden.

das verhalten meines test aktors (fhem device) ist ziehmlich perfekt.
commstate zeigt eine zeitlang pending, dann cmds_done_errors und im state dann sogar IOerr, wodurch das nächste automatische hminfo update das device in die HMinfoTools tabelle pusht.

Code Auswählen

sub CUL_HM_assignIO($){ #check and assign IO, returns 1 if IO changed
  # assign IO device
  # only called after init_done
  # prio:
  # 0) no change if transmission is active
  # 1) with vccu check preferred list   as long as operational
  # 2) with vccu check remaining IOs    as long as operational sort by rssi
  # 3) with vccu first preferred        if assinged - unconditional
  # 4) with vccu first any              if defined - unconditional

  # 5) no vccu -> attr IODev            as long as defined (obey user decission)
  # 6) current IO                       as long as defined
  # 7) any IO with client "CUL_HM"      as long as operational
  # 8) any IO with client "CUL_HM"      unconditional
  # no option - 
	
  my $hash = shift;
  
  my $oldIODevH = $hash->{IODev};
  my $hh = $hash->{helper};
  my $iom;
  Log(1,"----- assignio-Test0 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));

  return 0 if (   (   defined($hh->{prt}{sProc})
                    && $hh->{prt}{sProc} == 1           #don't change while send in process
                    && $oldIODevH                 )     #with an operational IO
                || defined($hh->{aesCommRq})            #don't change while CUL aesCommReq in progress
                || $modules{CUL_HM}{helper}{updateStep} #don't change while a fwupdate is in progress, only IO for update is in 100kbit/s speed
                );
  my $newIODevH;
  Log(1,"----- assignio-Test1 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
  
  if ($hh->{io}{vccu}){# second option - any IO from the
    #my $iom;
    ($iom) = grep {CUL_HM_operIObyIOName($_)} @{$hh->{io}{prefIO}}                  if(!$iom && @{$hh->{io}{prefIO}});
    Log(1,"----- assignio-Test2 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
    ($iom) = grep {$_ eq 'none'} @{$hh->{io}{prefIO}}                               if(!$iom && @{$hh->{io}{prefIO}});
    Log(1,"----- assignio-Test3 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
    return 0 if $iom && $iom eq 'none'; #########
    if(!$iom){
      Log(1,"----- assignio-Test4 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
      my @ioccu = grep{CUL_HM_operIObyIOName($_)} @{$defs{$hh->{io}{vccu}}{helper}{io}{ioList}};
      ($iom) =    ((sort {@{$hh->{mRssi}{io}{$b}}[0] <=>     # This is the best choice
                            @{$hh->{mRssi}{io}{$a}}[0] } 
                          (grep { defined @{$hh->{mRssi}{io}{$_}}[0]} @ioccu))
                         ,(grep {!defined @{$hh->{mRssi}{io}{$_}}[0]} @ioccu))      if(@ioccu);
      Log(1,"----- assignio-Test5 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));
    } 
    ($iom) = grep{defined $defs{$_}} @{$hh->{io}{prefIO}}                           if(!$iom && @{$hh->{io}{prefIO}});
    ($iom) = grep{defined $defs{$_}} @{$defs{$hh->{io}{vccu}}{helper}{io}{ioList}}  if(!$iom && @{$defs{$hh->{io}{vccu}}{helper}{io}{ioList}});
    return 0 if $iom && $iom eq 'none'; #########
    $newIODevH  = $defs{$iom} if($iom);
  }
  Log(1,"----- assignio-Test6 ----- => n:$hash->{NAME} ioOld:".(defined($oldIODevH->{NAME})?$oldIODevH->{NAME}:"---")." ioNew:".(defined($iom)?$iom:"---"));

Code Auswählen

2021.10.13 14:46:50.942 3 : CUL_HM set SwitchUP02 on noArg
2021.10.13 14:46:50.994 1 : ----- assignio-Test0 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:46:50.995 1 : ----- assignio-Test1 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:46:50.996 1 : ----- assignio-Test2 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:46:50.997 1 : ----- assignio-Test3 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:46:50.998 1 : ----- assignio-Test6 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:46:51.001 0 : HMLAN_Send:  hmlan1 S:S79B0EFF3 stat:  00 t:00000000 d:01 r:79B0EFF3 m:C9 A011 1ACE1F 285A44 0201C80000
2021.10.13 14:46:51.050 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 27 msg: C9 A0 11 1ACE1F 285A44 0201C80000
2021.10.13 14:46:51.191 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 38 msg: C9 80 02 285A44 1ACE1F 0101C80046
2021.10.13 14:46:51.224 0 : HMLAN_Parse: hmlan1 R:R79B0EFF3 stat:0001 t:129D5091 d:FF r:FFBE     m:C9 8002 285A44 1ACE1F 0101C80046
2021.10.13 14:47:05.616 3 : CUL_HM set SwitchUP02 off noArg
2021.10.13 14:47:05.667 1 : ----- assignio-Test0 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:05.668 1 : ----- assignio-Test1 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:05.668 1 : ----- assignio-Test2 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:47:05.669 1 : ----- assignio-Test3 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:47:05.670 1 : ----- assignio-Test6 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:hmlan1
2021.10.13 14:47:05.672 0 : HMLAN_Send:  hmlan1 S:S79B12943 stat:  00 t:00000000 d:01 r:79B12943 m:CA A011 1ACE1F 285A44 0201000000
2021.10.13 14:47:05.706 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 27 msg: CA A0 11 1ACE1F 285A44 0201000000
2021.10.13 14:47:05.840 0 : HMLAN_Parse: hmlan1 R:R79B12943 stat:0001 t:129D89E2 d:FF r:FFC4     m:CA 8002 285A44 1ACE1F 0101000046
2021.10.13 14:47:05.914 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 38 msg: CA 80 02 285A44 1ACE1F 0101000046
2021.10.13 14:47:15.225 1 : HMLAN_Parse: hmlan1 new condition disconnected
2021.10.13 14:47:27.147 3 : CUL_HM set SwitchUP02 on noArg
2021.10.13 14:47:27.199 1 : ----- assignio-Test0 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:27.201 1 : ----- assignio-Test1 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:27.201 1 : ----- assignio-Test2 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:---
2021.10.13 14:47:27.202 1 : ----- assignio-Test3 ----- => n:SwitchUP02 ioOld:hmlan1 ioNew:none

zuerst set on/off mit funktionierem io (hmlan1), danach set hmlan close mit anschliessendem set on.
=> keine messages werden gesendet.

Beta-User · 13 Oktober 2021, 15:49:52

...klingt gut, auch wenn ich mir das im Detail noch in Ruhe ansehen müßte...

Wie wäre denn der Vorschlag zum weiteren Vorgehen? Wir machen wieder eine Art "rolling release candidate" fertig und hoffen zum einen auf Tester und warten zum anderen auf Martin (und noansi), wann er/sie Zeit findet/n, sich das anzusehen?

Eigentlich wäre dein "offene Punkte"-Thread dafür prädestiniert, es kann aber auch wieder einen neuen Thread geben.

Da ich 0 Überblick habe (und das meiste auch nicht verstehe

): die Liste ist aktuell, oder? Vielleicht solltest du so oder so nochmal einen push machen, wenn alles dann halbwegs up to date ist (du scheinst die Liste ja im Lichte des aktuellen svn-updates nochmal durchgegangen zu sein).

frank · 13 Oktober 2021, 16:55:47

meine liste ist noch in arbeit und bekommt abschliessend einen push. hab noch nicht alles getestet.

deine oktober patches wurden ja komplett übernommen, oder? der thread könnte ja zu, damit martin nicht durcheinander kommt. dafür einen neuen mit neuen patches und im alten einen link zum neuen.

zur zeit habe ich die patches von hier plus den patch von dort: https://forum.fhem.de/index.php/topic,121650.msg1179090.html#msg1179090.

Beta-User · 13 Oktober 2021, 17:06:38

Soweit ich das beurteilen kann, hat Martin so ziemlich alles übernommen, teilweise aber nicht 1:1. Akribisch gegengecheckt habe ich aber nicht.

Danach sind unsere Stände jedenfalls derzeit praktisch gleich und wir könnten dann ggf. auch einfach diesen hier zum "patch-Thread Oktober II" erklären. Den anderen würde ich dann ggf. dazu nutzen, den aktuellen kundzutun und dann erst schließen. Wichtig wäre mAn. nur, dass wir das so machen, dass Martin weiß, wo er denn den jeweils letzten (funktionierenden) Stand findet.

frank · 13 Oktober 2021, 18:55:29

bis antwort #24 hier hatte martin die änderungen ebenfalls schon eingearbeitet.

diesen thread zum "allgemeinen" patch-thread zu machen finde ich nicht gut. sonst kommen hier lauter "ich kann mein device auch nicht pairen" posts.

Beta-User · 13 Oktober 2021, 19:21:51

Zitat von: frank am 13 Oktober 2021, 18:55:29
sonst kommen hier lauter "ich kann mein device auch nicht pairen" posts.

ymmd!

(Es ist doch ganz egal, ob man einen neuen macht oder nicht, diese Art Rückmeldung wird es immer geben, sobald was als "Sammelthread" angesehen wird...)

Zitat von: frank am 13 Oktober 2021, 18:55:29
bis antwort #24 hier hatte martin die änderungen ebenfalls schon eingearbeitet.

Das ist ein gutes Argument dagegen, schon gut...

Werde dann bei Gelegenheit alles in der bekannten Form zusammenpacken und "gerne vorab testen" rufen

...

Beta-User · 14 Oktober 2021, 07:18:44

Hier mal der hoffentlich korrekt konsolidierte Stand - läuft erst kurz, aber unauffällig.

Ohne das näher analysiert zu haben, scheinen aber - trotz anderer Priorisierung in der VCCU - relativ wenige Geräte den HMUART verwenden zu wollen. Meine Installation ist aber einfacher, und "none" brauche ich auch nicht.

frank · 15 Oktober 2021, 14:55:00

moin beta-user,
deine datei läuft bei mir und enthält wohl auch alles, prima.

ein altes thema ist immer noch aktuell: bei der suche nach ios werden hmlan/hmusb weiterhin an 3 stellen nicht gefunden!

1. zeilen 1008 und 10895 finden jeweils nur cul und hmuart.
scheinbar hat noch niemand mit hmlan/hmusb und ohne vccu die neue cul_hm getestet.

getestet in der fhem eingabezeile mit:

Code Auswählen

{join(",",devspec2array('Clients=.*:CUL_HM:.*'))}

angelehnt an martins code habe ich nun zeile 1008 geändert zu:

Code Auswählen

        my @IOnames = grep {InternalVal($_,"Clients",
                            defined $modules{InternalVal($_,"TYPE","")}{Clients}
                            ? $modules{InternalVal($_,"TYPE","")}{Clients}
                            : "") =~ m /:CUL_HM:/} keys %defs;

und zeile 10895 zu:

Code Auswählen

      my @IOs = grep {InternalVal($_,"Clients",
                      defined $modules{InternalVal($_,"TYPE","")}{Clients}
                      ? $modules{InternalVal($_,"TYPE","")}{Clients}
                      : "") =~ m /:CUL_HM:/} keys %defs;

2. ebenso um zeile 7273 findet auch der cmd "set vccu assignIO über grep{$defs{$_}{Clients} =~ m/:CUL_HM:/} keys %defs)} kein hmlan/hmusb. assignIO hat vermutlich noch nie jemand benutzt, denn

- es erzeugt "millonen" warnings und findet nur cul und hmuart

Code Auswählen

2021.10.15 09:49:53.961 1 : PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 7373.
2021.10.15 09:49:53.961 1 : stacktrace:
2021.10.15 09:49:53.962 1 :     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (7373)
2021.10.15 09:49:53.962 1 :     main::CUL_HM_Set                    called by fhem.pl (3889)
2021.10.15 09:49:53.963 1 :     main::CallFn                        called by fhem.pl (1938)
2021.10.15 09:49:53.964 1 :     main::DoSet                         called by fhem.pl (1970)
2021.10.15 09:49:53.964 1 :     main::CommandSet                    called by fhem.pl (1265)
2021.10.15 09:49:53.965 1 :     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2773)
2021.10.15 09:49:53.965 1 :     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1006)
2021.10.15 09:49:53.966 1 :     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (598)
2021.10.15 09:49:53.967 1 :     main::FW_Read                       called by fhem.pl (3894)
2021.10.15 09:49:53.967 1 :     main::CallFn                        called by fhem.pl (773)

das könnte man lösen durch:

Code Auswählen

grep{defined($defs{$_}{Clients}) && $defs{$_}{Clients} =~ m/:CUL_HM:/} keys %defs
gefunden wird dadurch natürlich weiterhin kein hmlan.

- es erzeugt zudem ein warning wegen falschem match operator

Code Auswählen

2021.10.15 09:49:53.952 1 : PERL WARNING: Argument "set" isn't numeric in numeric ne (!=) at ./FHEM/10_CUL_HM.pm line 7371.
2021.10.15 09:49:53.953 1 : stacktrace:
2021.10.15 09:49:53.954 1 :     main::__ANON__                      called by ./FHEM/10_CUL_HM.pm (7371)
2021.10.15 09:49:53.954 1 :     main::CUL_HM_Set                    called by fhem.pl (3889)
2021.10.15 09:49:53.955 1 :     main::CallFn                        called by fhem.pl (1938)
2021.10.15 09:49:53.956 1 :     main::DoSet                         called by fhem.pl (1970)
2021.10.15 09:49:53.956 1 :     main::CommandSet                    called by fhem.pl (1265)
2021.10.15 09:49:53.957 1 :     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2773)
2021.10.15 09:49:53.957 1 :     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (1006)
2021.10.15 09:49:53.958 1 :     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (598)
2021.10.15 09:49:53.959 1 :     main::FW_Read                       called by fhem.pl (3894)
2021.10.15 09:49:53.959 1 :     main::CallFn                        called by fhem.pl (773)

- ausserdem muss die logik des if negiert sein, damit die gefundenen io auch genutzt werden können.
- eine info in der commandref wäre sicherlich auch ganz nützlich

durch die folgenden änderungen der 2 return befehle kann ich das cmd nun fehlerfrei nutzen:

Code Auswählen

    return "$io not suitable for CUL_HM" if(!scalar(grep{$_ eq $io}
                                                    grep {InternalVal($_,"Clients",
                                                          defined $modules{InternalVal($_,"TYPE","")}{Clients}
                                                          ? $modules{InternalVal($_,"TYPE","")}{Clients}
                                                          :"") =~ m /:CUL_HM:/} keys %defs));

-----------------------------

ZitatOhne das näher analysiert zu haben, scheinen aber - trotz anderer Priorisierung in der VCCU - relativ wenige Geräte den HMUART verwenden zu wollen. Meine Installation ist aber einfacher, und "none" brauche ich auch nicht.

das liegt an einer mischung aus

ein paar "zufällige" abhängigkeiten:
- hardware/anbindung aller vorhandenen io
- reihenfolge der definitionen in fhem.cfg
- reihenfolge der io in "attr vccu IOList"
- zeitpunkt, wann ein io definiert ist
- zeitpunkt, wann ein io operabel ist
- zeitpunkt, wann ein io den ersten rssi ermittelt hat
- zeitpunkt, wann fhem die erste msg an ein device sendet (zb automatische statusrequest)

zu aller letzt ist entscheidend, wann man dann zb mit "get vccu listDevices" nach fhem restart die io verteilung anschaut.

bei mir ist der cul bereits vor dem ersten define der vccu operabel.
als nächstes ist der hmlan operabel, zur zeit vor dem ersten automatischen statusrequest
der hmuart braucht am längsten.

Beta-User · 15 Oktober 2021, 17:25:38

Wow, klingt einleuchtend. Hab's mal auf die Schnelle eingearbeitet und auch commandref+Logik zu assignIO entsprechend meinem Verständnis geändert.
Ist nur kurz im Testsystem angetestet, und die fraglichen Stellen sind auch nicht die, die ich im Hauptsystem nutze. Von daher kann ein kritischer Blick vorab nicht schaden, weil mir dann auch mind. noch eine andere Kleinigkeit nebenbei aufgefallen ist.

frank · 15 Oktober 2021, 20:34:15

warum hast du 'none' wieder ausgebaut?

Beta-User · 15 Oktober 2021, 21:50:41

Ups, vermutlich die falsche Basisversion erwischt... Sorry, update EDIT: ist im Anhang.

https://forum.fhem.de/index.php/topic,120856.msg1179854.html#msg1179854 muss ich mir erst ansehen, dann baue ich die Teile ggf. auch gleich in HMinfo ein.

EDIT: Patches - auch zu HMinfo - sind jetzt konsolidiert in https://forum.fhem.de/index.php/topic,123436.0.html zu finden.