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.
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
zusätzlich noch 3 probleme bzgl vccu:
1. "get vccu listDevice" zeigt auch leider ignored devices. das habe ich in zeile 4852 unterdrückt:
foreach (@dl){
next if($attr{$_}{ignore});
2. "attr IOgrp" lässt keine option "none" zu. beim versuch erfolgt die meldung:
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, ...
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 :
ad 1: finde ich gut, würde das aber ergänzen zu
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)
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).
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:
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.
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:
foreach my $pIO (@prefIOarr){
return "$pIO is not part if VCCU IOs:$ioLst" if(1 != grep/$pIO/,@ioOpts);
"Kennen" ja, aber wohl vergessen.
Vorschlag für #1113ff:
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...
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.
push @ioOpts, 'none' if $ioLst !~ m{none}; #Beta-User: Might fix #2 from https://forum.fhem.de/index.php/topic,123238.msg1178193.html#msg1178193das 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?
...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:
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...
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.
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?)
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. 8)
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.
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 (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.
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...
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.
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.
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. 8)
ich denke, die version sollte dancatt probieren.
8) :o ;D ... 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):
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....
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.
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.
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
...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).
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. ;)
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...?
- 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.
Die IODev-Reading-Auswertung atttest du nicht testweise eingebaut, oder?
nein, noch nicht.
ich beobachte nun erst mal martins neue versionen.
das verhalten ist besser, wieder anders, mal schauen.
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.
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 (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 (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?
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.
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.
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:
$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
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...
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:
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.
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.
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. 8)
Hmm, m.E. gute Vorschläge, wobei ich das noch etwas radikaler angehen würde:
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
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.
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:"---"));
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.
...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).
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 (https://forum.fhem.de/index.php/topic,121650.msg1179090.html#msg1179090).
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.
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. ;)
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 ;D ...
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.
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:
{join(",",devspec2array('Clients=.*:CUL_HM:.*'))}angelehnt an martins code habe ich nun zeile 1008 geändert zu:
my @IOnames = grep {InternalVal($_,"Clients",
defined $modules{InternalVal($_,"TYPE","")}{Clients}
? $modules{InternalVal($_,"TYPE","")}{Clients}
: "") =~ m /:CUL_HM:/} keys %defs;und zeile 10895 zu:
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
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:
grep{defined($defs{$_}{Clients}) && $defs{$_}{Clients} =~ m/:CUL_HM:/} keys %defsgefunden wird dadurch natürlich weiterhin
kein hmlan.
- es erzeugt zudem ein warning wegen falschem match operator
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:
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.
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.
warum hast du 'none' wieder ausgebaut?
Ups, vermutlich die falsche Basisversion erwischt... Sorry, update EDIT: ist im Anhang.
https://forum.fhem.de/index.php/topic,120856.msg1179854.html#msg1179854 (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 (https://forum.fhem.de/index.php/topic,123436.0.html) zu finden.