[CUL_HM] patches Oktober 2021 - die Zweite

Beta-User · 28 Oktober 2021, 12:49:37

Zitat von: frank am 27 Oktober 2021, 20:20:20
konnte ich gerade nicht festellen.
das device ist zumindestens weiterhin unter "get assignIDs" beim hmlan zu finden. im log war auch nichts zusehen.

Hmm, dann müßte in diesem Teil noch irgendwo was versteckt sein, das ich auf die Schnelle nicht sehe (#1268ff):

Code Auswählen

if ($attrVal) {
        IOWrite($hash, '', 'remove:'.$hash->{DEF}) if defined $hash->{IODev}->{TYPE} && $hash->{IODev}->{TYPE} =~ m/^HM(?:LAN|UARTLGW)$/s && defined $hash->{DEF};
        delete $hash->{IODev};
        delete $hash->{READINGS}{IODev};
      } else {
        CUL_HM_assignIO($hash) ;
      }

Kann das grade nur auf dem Testsystem checken, und da sehe ich zumindest, dass das Internal IODev gelöscht wird.

Zitat von: frank am 27 Oktober 2021, 18:04:58
das "normale" betreiben der vd ist weiterhin gut, also erstmal nichts dringendes.

Klingt insgesamt danach, als sollte/könnte ich Martin mal wieder aktiv anpingen...?

Zitateine saubere, fehlerfreie io zuordnung finde ich derzeit wichtiger.

Das ist dann in der Tat (leider) weiter eine Baustelle, die anscheinend für mich zu groß ist. Aber evtl. hat da ja jemand "Wissendes" dann auch vollends Ideen, wie man das dann noch gradeziehen kann

?

frank · 28 Oktober 2021, 14:49:42

moin,

ZitatHmm, dann müßte in diesem Teil noch irgendwo was versteckt sein, das ich auf die Schnelle nicht sehe (#1268ff):

scheinbar ein reihenfolgeproblem, wegen iowrite.

Code Auswählen

return if(IsDummy($dev) || IsIgnored($dev));

den block habe ich jetzt ganz vorne platziert, unter

Code Auswählen

if ($cmd eq "set"){

so erscheint bei dummy und ignore im eventmonitor/log

Code Auswählen

2021.10.28 14:01:29.709 0 : HMLAN_Send:  hmlan1 I:-1A164B
2021-10-28 14:01:29.866 Global global ATTR SwitchPBU05 ignore 1

1. die dummy intergration scheint mir noch nicht ganz richtig zu sein, da diese devices nun auch attr .ignored erhalten.
2. attr .ignored verschwindet grundsätzlich nach restart, muss das so?
3. bereits länger ignored devices bekommen beim restart scheinbar trotzdem IODev, sogar mein test reading IODev_test über assignioport ist aktuell.

Code Auswählen

Internals:
   DEF        266A86
   FUUID      603510ca-f33f-09c4-9dc4-ec7b836712fa49ab
   IODev      cul868
   NAME       DimPBU01
   NR         734
   NTFY_ORDER 48-DimPBU01
   STATE      Info_Cleared
   TYPE       CUL_HM
   channel_01 DimPBU01_Dim
   channel_02 DimPBU01_Dim_V_01
   channel_03 DimPBU01_Dim_V_02
   disableNotifyFn 1
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2021-04-17 23:55:11   .D-devInfo      110100
     2021-04-17 23:55:11   .D-stc          20
     2021-10-27 16:21:32   .associatedWith DimPBU01,DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimPBU01
     2021-05-25 21:39:48   .protLastRcv    20210525213948
     2021-06-14 15:50:30   Activity        unknown
     2021-04-15 15:22:36   CommandAccepted yes
     from archivexx        D-firmware      2.6
     from archivexx        D-serialNr      KEQ1110205
     2021-10-27 16:21:27   IODev           cul868
     2021-10-25 15:30:43   IODev_test      cul868
     2021-05-17 14:04:10   PairedTo        0x1ACE1F
     2021-05-17 14:04:09   RegL_00.        00:00 02:81 0A:1A 0B:CE 0C:1F 15:FF 18:00 62:5A
     2021-10-16 17:53:23   cfgState        PairMiss
     2021-10-14 16:29:53   commState       Info_Cleared
     2021-04-15 15:02:48   fwUpdate        done
     2021-04-18 08:20:51   powerOn         2021-04-18 08:20:51
     2021-10-14 16:29:53   state           Info_Cleared
   helper:
     HM_CMDNR   206
     mId        0068
     peerFriend -
     peerOpt    -:dimmer
     regLst     0
     rxType     1
     cmds:
       TmplKey    :1635344497.7944:1635344492.37385
       TmplTs     1635344492.37385
       cmdKey     0:1:0::DimPBU01:0068:00:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         getVersion noArg
         pair       noArg
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt    
         tplChan    
         tplDel     
         tplPeer    
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       flgs       0
       newChn     +266A86,00,00,00
       rxt        0
       vccu       
       p:
         266A86
         00
         00
         00
       prefIO:
     mRssi:
       mNo        
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     tmpl:
Attributes:
   .mId       0068
   IOgrp      ccu:hmlan1
   actCycle   024:00
   actStatus  unknown
   autoReadReg 5_readMissing
   devStateIcon {CUL_HM_getIcon($name)}
   event-on-change-reading .*
   expert     defReg,allReg,rawReg,templ
   firmware   2.9
   ignore     1
   model      HM-LC-DIM1TPBU-FM
   room       CUL_HM
   serialNr   KEQ1110205
   subType    dimmer
   webCmd     getConfig:clear msgEvents

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

zwei ungereimtheiten zu cul_hm_assignio

soweit ich assignioport verstehe, ist es hauptsächlich zum setzen von attribut/reading IODev. ein übergebenes io, wird zudem eventuell auch aussortiert und ggf durch ein gefundenes, typgleiches ersetzt.
das ersetzen durch assignio kann ggf ungereimtheiten hervorrufen, denke ich.

1. nach dem ersten aufruf (wechsel) setzt cul_hm erneut hash/iodev. wenn assignioport nun ein anderes gewählt hat, stimmen reading und internal nicht mehr überein.

2. der zweite aufruf (ohne wechsel) sollte eigentlich überflüssig sein. ausserdem gibt es ärger, wenn gewechselt wurde.

eigentlich müsste man immer nach assignioport prüfen, ob dadurch ein io wechsel vorgenommen wurde.
wenn assignioport ein wechsel durchgeführt hat, stimmt im ersten fall nur das reading nicht und im zweiten fall ist das neue und alte io ggf nicht richtig präpariert.

frank · 28 Oktober 2021, 15:13:44

mist, nach dem löschen von attr ignore, hat nun das device kein io im hash/iodev
und hminfo hat nach einem set hminfo update 4 warnings gemeldet

Code Auswählen

Internals:
   DEF        1A164B
   FUUID      5c4ce2ef-f33f-09c4-0a7b-916ab5f9f48c008a
   IODev      
   LASTInputDev cul868
   MSGCNT     3
   NAME       SwitchPBU05
   NR         614
   NTFY_ORDER 48-SwitchPBU05
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   cul868_MSGCNT 1
   cul868_RAWMSG A0E9480021A164B1ACE1F0101C8003A::-66:cul868
   cul868_RSSI -66
   cul868_TIME 2021-10-28 13:58:37
   disableNotifyFn 1
   hmlan1_MSGCNT 1
   hmlan1_RAWMSG RC6C42D24,0001,185BBB4F,FF,FFC5,9480021A164B1ACE1F0101C8003A
   hmlan1_RSSI -59
   hmlan1_TIME 2021-10-28 13:58:37
   hmuart1_MSGCNT 1
   hmuart1_RAWMSG 050000459480021A164B1ACE1F0101C8003A
   hmuart1_RSSI -69
   hmuart1_TIME 2021-10-28 13:58:37
   lastMsg    No:94 - t:02 s:1A164B d:1ACE1F 0101C8003A
   peerList   Tuer.SZ,self01,self02
   protCmdDel 1
   protLastRcv 2021-10-28 13:58:37
   protRcv    1 last_at:2021-10-28 13:58:37
   protSnd    1 last_at:2021-10-28 13:58:37
   protState  CMDs_done
   protdummy  1 last_at:2021-10-28 13:55:07
   rssi_at_cul868 cnt:1 min:-66 max:-66 avg:-66 lst:-66 
   rssi_at_hmlan1 cnt:1 min:-59 max:-59 avg:-59 lst:-59 
   rssi_at_hmuart1 cnt:1 min:-69 max:-69 avg:-69 lst:-69 
   rssi_hmlan1 cnt:1 min:-58 max:-58 avg:-58 lst:-58 
   CL:
     Authenticated 0
     BUF        
     FD         80
     FW_ID      2215
     LASTACCESS 1635426319
     NAME       WEB_192.168.1.31_56468
     NR         2257
     PEER       192.168.1.31
     PORT       56468
     SNAME      WEB
     SSL        
     STATE      Connected
     TEMPORARY  1
     TYPE       FHEMWEB
     canAsyncOutput 1
     READINGS:
       2021-10-28 15:03:07   state           Connected
   READINGS:
     2021-03-23 13:13:50   Activity        alive
     2021-03-23 15:37:15   CommandAccepted yes
     from archivexx        D-firmware      2.8
     from archivexx        D-serialNr      JEQ0033112
     2021-03-23 15:26:24   PairedTo        0x1ACE1F
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgActionType off
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgCtDlyOff geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgCtDlyOn geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgCtOff geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgCtOn geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgCtValHi 100
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgCtValLo 50
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgMultiExec on
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgOffDly 0 s
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgOffTime unused
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgOffTimeMode absolut
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgOnDly 0 s
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgOnTime unused
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgOnTimeMode absolut
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgSwJtDlyOff on
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgSwJtDlyOn on
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgSwJtOff dlyOn
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-lgSwJtOn on
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shActionType jmpToTarget
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shCtDlyOff geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shCtDlyOn geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shCtOff geLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shCtOn ltLo
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shCtValHi 100
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shCtValLo 50
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shMultiExec off
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shOffDly 0 s
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shOffTime unused
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shOffTimeMode absolut
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shOnDly 0 s
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shOnTime 10 s
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shOnTimeMode absolut
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shSwJtDlyOff off
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shSwJtDlyOn on
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shSwJtOff dlyOn
     2021-10-05 09:55:04   R-Tuer.SZ_chn-01-shSwJtOn dlyOff
     2021-10-04 17:56:34   R-intKeyVisib   visib
     2021-10-04 17:56:34   R-localResDis   off
     2021-10-04 17:56:34   R-pairCentral   0x1ACE1F
     2021-10-04 17:56:34   R-powerUpAction off
     2021-10-05 09:55:02   R-self01-lgActionType off
     2021-10-05 09:55:02   R-self01-lgCtDlyOff geLo
     2021-10-05 09:55:02   R-self01-lgCtDlyOn geLo
     2021-10-05 09:55:02   R-self01-lgCtOff geLo
     2021-10-05 09:55:02   R-self01-lgCtOn geLo
     2021-10-05 09:55:02   R-self01-lgCtValHi 100
     2021-10-05 09:55:02   R-self01-lgCtValLo 50
     2021-10-05 09:55:02   R-self01-lgMultiExec on
     2021-10-05 09:55:02   R-self01-lgOffDly 0 s
     2021-10-05 09:55:02   R-self01-lgOffTime unused
     2021-10-05 09:55:02   R-self01-lgOffTimeMode absolut
     2021-10-05 09:55:02   R-self01-lgOnDly 0 s
     2021-10-05 09:55:02   R-self01-lgOnTime unused
     2021-10-05 09:55:02   R-self01-lgOnTimeMode absolut
     2021-10-05 09:55:02   R-self01-lgSwJtDlyOff off
     2021-10-05 09:55:02   R-self01-lgSwJtDlyOn off
     2021-10-05 09:55:02   R-self01-lgSwJtOff off
     2021-10-05 09:55:02   R-self01-lgSwJtOn dlyOff
     2021-10-05 09:55:02   R-self01-shActionType jmpToTarget
     2021-10-05 09:55:02   R-self01-shCtDlyOff geLo
     2021-10-05 09:55:02   R-self01-shCtDlyOn geLo
     2021-10-05 09:55:02   R-self01-shCtOff geLo
     2021-10-05 09:55:02   R-self01-shCtOn geLo
     2021-10-05 09:55:02   R-self01-shCtValHi 100
     2021-10-05 09:55:02   R-self01-shCtValLo 50
     2021-10-05 09:55:02   R-self01-shMultiExec off
     2021-10-05 09:55:02   R-self01-shOffDly 0 s
     2021-10-05 09:55:02   R-self01-shOffTime unused
     2021-10-05 09:55:02   R-self01-shOffTimeMode absolut
     2021-10-05 09:55:02   R-self01-shOnDly 0 s
     2021-10-05 09:55:02   R-self01-shOnTime 86400 s
     2021-10-05 09:55:02   R-self01-shOnTimeMode absolut
     2021-10-05 09:55:02   R-self01-shSwJtDlyOff off
     2021-10-05 09:55:02   R-self01-shSwJtDlyOn on
     2021-10-05 09:55:02   R-self01-shSwJtOff dlyOn
     2021-10-05 09:55:02   R-self01-shSwJtOn dlyOff
     2021-10-05 09:54:58   R-self02-lgActionType off
     2021-10-05 09:54:58   R-self02-lgCtDlyOff geLo
     2021-10-05 09:54:58   R-self02-lgCtDlyOn geLo
     2021-10-05 09:54:58   R-self02-lgCtOff geLo
     2021-10-05 09:54:58   R-self02-lgCtOn geLo
     2021-10-05 09:54:58   R-self02-lgCtValHi 100
     2021-10-05 09:54:58   R-self02-lgCtValLo 50
     2021-10-05 09:54:58   R-self02-lgMultiExec on
     2021-10-05 09:54:58   R-self02-lgOffDly 0 s
     2021-10-05 09:54:58   R-self02-lgOffTime unused
     2021-10-05 09:54:58   R-self02-lgOffTimeMode absolut
     2021-10-05 09:54:58   R-self02-lgOnDly 0 s
     2021-10-05 09:54:58   R-self02-lgOnTime unused
     2021-10-05 09:54:58   R-self02-lgOnTimeMode absolut
     2021-10-05 09:54:58   R-self02-lgSwJtDlyOff on
     2021-10-05 09:54:58   R-self02-lgSwJtDlyOn on
     2021-10-05 09:54:58   R-self02-lgSwJtOff dlyOn
     2021-10-05 09:54:58   R-self02-lgSwJtOn on
     2021-10-05 09:54:58   R-self02-shActionType off
     2021-10-05 09:54:58   R-self02-shCtDlyOff geLo
     2021-10-05 09:54:58   R-self02-shCtDlyOn geLo
     2021-10-05 09:54:58   R-self02-shCtOff geLo
     2021-10-05 09:54:58   R-self02-shCtOn geLo
     2021-10-05 09:54:58   R-self02-shCtValHi 100
     2021-10-05 09:54:58   R-self02-shCtValLo 50
     2021-10-05 09:54:58   R-self02-shMultiExec off
     2021-10-05 09:54:58   R-self02-shOffDly 0 s
     2021-10-05 09:54:58   R-self02-shOffTime unused
     2021-10-05 09:54:58   R-self02-shOffTimeMode absolut
     2021-10-05 09:54:58   R-self02-shOnDly 0 s
     2021-10-05 09:54:58   R-self02-shOnTime unused
     2021-10-05 09:54:58   R-self02-shOnTimeMode absolut
     2021-10-05 09:54:58   R-self02-shSwJtDlyOff on
     2021-10-05 09:54:58   R-self02-shSwJtDlyOn on
     2021-10-05 09:54:58   R-self02-shSwJtOff dlyOn
     2021-10-05 09:54:58   R-self02-shSwJtOn on
     2021-10-04 17:56:34   R-sign          off
     2021-10-04 17:56:34   R-statusInfoMinDly 0.5 s
     2021-10-04 17:56:34   R-statusInfoRandom 0 s
     2021-10-04 17:56:34   R-transmitTryMax 5
     2021-10-05 09:54:54   RegL_00.        00:00 02:81 0A:1A 0B:CE 0C:1F 15:FF 18:00
     2021-10-05 09:54:56   RegL_01.        00:00 08:00 30:05 56:00 57:01
     2021-10-05 09:55:04   RegL_03.Tuer.SZ_chn-01 00:00 02:00 03:02 04:32 05:64 06:00 07:2A 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:20 8B:13 8C:33
     2021-10-05 09:55:02   RegL_03.self01  00:00 02:00 03:00 04:32 05:64 06:00 07:F8 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:20 8B:64 8C:66
     2021-10-05 09:54:58   RegL_03.self02  00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:00 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:20 8B:13 8C:33
     2021-10-24 14:40:04   cfgState        ok
     2021-10-28 13:58:37   commState       CMDs_done
     2021-10-28 13:58:37   deviceMsg       on (to ccu)
     2021-10-28 13:58:37   level           100
     2021-10-28 13:58:37   pct             100
     2021-10-28 13:54:48   peerList        Tuer.SZ,self01,self02
     2021-10-28 01:11:19   recentStateType ack
     2021-10-28 13:58:37   state           on
     2021-10-27 20:12:36   timedOn         off
     -                     tmpl_self01:long ignore,
     -                     tmpl_self01:short toggleOn-for-timerOff_switch:onTime:86400,
     -                     tmpl_self02:long ignore,
     -                     tmpl_self02:short ignore,
     2021-10-18 01:11:19   trigLast        fhem:02
     2021-10-17 11:04:06   trig_Tuer.SZ    Closed_1
   helper:
     HM_CMDNR   148
     cSnd       ,111ACE1F1A164B0201C80000
     dlvlCmd    ++A0111ACE1F1A164B0201C80000
     lastMsgTm  1635422317.69535
     mId        0069
     peerFriend peerSens,peerVirt
     peerIDsState complete
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     tmplChg    0
     cmds:
       TmplKey    Tuer.SZ,self01,self02:1635422092.56006:1635422092.95002
       TmplTs     1635422092.95002
       cmdKey     1:1:0::SwitchPBU05:0069:01:Tuer.SZ,self01,self02
       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-
         tplPara010_self01_short_toggleOn-for-timerOff_switch_onTime -value-
         tplSet_0   -tplChan-
         tplSet_Tuer.SZ -tplPeer-
         tplSet_self01 -tplPeer-
         tplSet_self02 -tplPeer-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       Tuer.SZ,self01,self02
         peerOpt    remove_Tuer.SZ_chn-01,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    ES_00,ES_device,sw99,test,test01
         tplDel     self01:long>ignore,self02:long>ignore,self02:short>ignore,self01:short>toggleOn-for-timerOff_switch
         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     +1A164B,00,00,00
       nextSend   1635422317.9717
       rxt        0
       vccu       ccu
       p:
         1A164B
         00
         00
         00
       prefIO:
         hmlan1
     mRssi:
       mNo        94
       io:
         cul868:
           -66
           -66
         hmlan1:
           -53
           -53
         hmuart1:
           -69
           -69
     peerIDsH:
       00000000   broadcast
       1A164B01   self01
       1A164B02   self02
       1DE62001   Tuer.SZ_chn-01
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_cul868:
         avg        -66
         cnt        1
         lst        -66
         max        -66
         min        -66
       at_hmlan1:
         avg        -59
         cnt        1
         lst        -59
         max        -59
         min        -59
       at_hmuart1:
         avg        -69
         cnt        1
         lst        -69
         max        -69
         min        -69
       hmlan1:
         avg        -58
         cnt        1
         lst        -58
         max        -58
         min        -58
     shadowReg:
     tmpl:
       self01:long>ignore 
       self01:short>toggleOn-for-timerOff_switch 86400
       self02:long>ignore 
       self02:short>ignore 
Attributes:
   IOgrp      ccu:hmlan1
   actCycle   024:00
   actStatus  alive
   alias      Lampe_Kueche_AP
   autoReadReg 5_readMissing
   commStInCh off
   comment    c26 ausgewechselt: 2020-04-27
   event-on-change-reading .*
   expert     defReg,allReg,rawReg,templ
   firmware   2.8
   group      Beleuchtung
   model      HM-LC-SW1PBU-FM
   peerIDs    00000000,1A164B01,1A164B02,1DE62001
   room       02_handy,30_Kueche
   serialNr   JEQ0033112
   subType    switch
   timestamp-on-change-reading .*
   webCmd     :

Code Auswählen

2021.10.28 14:54:45.495 3 : HMinfo hminfo get:update :
2021.10.28 14:54:45.629 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.630 1 : stacktrace:
2021.10.28 14:54:45.631 1 :     main::__ANON__                      called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.632 1 :     main::HMinfo_status                 called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.632 1 :     main::HMinfo_SetFn                  called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.633 1 :     main::HMinfo_autoUpdate             called by fhem.pl (3427)
2021.10.28 14:54:45.633 1 :     main::HandleTimeout                 called by fhem.pl (695)
2021.10.28 14:54:45.634 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.635 1 : stacktrace:
2021.10.28 14:54:45.635 1 :     main::__ANON__                      called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.636 1 :     main::HMinfo_status                 called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.637 1 :     main::HMinfo_SetFn                  called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.637 1 :     main::HMinfo_autoUpdate             called by fhem.pl (3427)
2021.10.28 14:54:45.638 1 :     main::HandleTimeout                 called by fhem.pl (695)
2021.10.28 14:54:45.638 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.639 1 : stacktrace:
2021.10.28 14:54:45.640 1 :     main::__ANON__                      called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.640 1 :     main::HMinfo_status                 called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.641 1 :     main::HMinfo_SetFn                  called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.642 1 :     main::HMinfo_autoUpdate             called by fhem.pl (3427)
2021.10.28 14:54:45.642 1 :     main::HandleTimeout                 called by fhem.pl (695)
2021.10.28 14:54:45.643 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.643 1 : stacktrace:
2021.10.28 14:54:45.644 1 :     main::__ANON__                      called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.645 1 :     main::HMinfo_status                 called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.645 1 :     main::HMinfo_SetFn                  called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.646 1 :     main::HMinfo_autoUpdate             called by fhem.pl (3427)
2021.10.28 14:54:45.646 1 :     main::HandleTimeout                 called by fhem.pl (695)

meine zeile 379

Code Auswählen

next if($_ !~ m /at_.*$ehash->{IODev}->{NAME}/ );#ignore unused IODev

wahrscheinlich das selbe problem, wie vorher, nun mit cul_hm_assignio, das nun zu früh ist.

frank · 28 Oktober 2021, 15:43:07

so funktioniert jetzt "attr ignore 1|0", aber nicht das löschen des attributs

Code Auswählen

  elsif($attrName eq "ignore" || $attrName eq "dummy"){
    if ($cmd eq "set"){
      if ($attrVal) {
        IOWrite($hash, '', 'remove:'.$hash->{DEF}) if defined $hash->{IODev}->{TYPE} && $hash->{IODev}->{TYPE} =~ m/^HM(?:LAN|UARTLGW)$/s && defined $hash->{DEF};
        delete $hash->{IODev};
        delete $hash->{READINGS}{IODev};
      } 
      $attr{$name}{".ignoreSet"} = $attrVal; # remember user desire
      foreach my $chNm(CUL_HM_getAssChnNames($name)){
        if( $attrVal == 1){
          $attr{$chNm}{$attrName} = 1;
          if ($modules{CUL_HM}{helper}{primary} eq $chNm){#we need to find a new primary 
            CUL_HM_primaryDev();
          }
        }
        elsif( defined $attr{$chNm}{".ignoreSet"}){
          $attr{$chNm}{$attrName} = $attr{$chNm}{".ignoreSet"};
        }
        else{
          delete $attr{$chNm}{$attrName};
        }
      }
      if (!$attrVal) {
        CUL_HM_assignIO($hash);
      }			
    }

Beta-User · 28 Oktober 2021, 15:51:44

Zitat von: frank am 28 Oktober 2021, 14:49:42
moin,

scheinbar ein reihenfolgeproblem, wegen iowrite.
Code Auswählen Erweitern
return if(IsDummy($dev) || IsIgnored($dev));

den block habe ich jetzt ganz vorne platziert, unter
Code Auswählen Erweitern
if ($cmd eq "set"){

OK, macht Sinn! Danke für's aufspüren!

Zitat
so erscheint bei dummy und ignore im eventmonitor/log
Code Auswählen Erweitern
2021.10.28 14:01:29.709 0 : HMLAN_Send: hmlan1 I:-1A164B 2021-10-28 14:01:29.866 Global global ATTR SwitchPBU05 ignore 1

Das ist schon mal was...

Zitat
1. die dummy intergration scheint mir noch nicht ganz richtig zu sein, da diese devices nun auch attr .ignored erhalten.
2. attr .ignored verschwindet grundsätzlich nach restart, muss das so?

Punkt 1 sollte weitgehend korrigiert sein. Beim jetzigen Drüberschauen fand ich überhaupt keine Erklärung, warum dieses versteckte Attribut überhaupt gesetzt wird, und auch die Abfragelogik erschließt sich mir grade nicht. Es macht zwar uU. Sinn, dann auch die Kanaldevices auf dummy/ignored zu setzen, aber den Hilfswert braucht man danach eigentlich nicht, und die Abfrage an sich scheint ins Leere zu gehen. Übersehe vermutlich wieder was...

Jedenfalls dürfte es nicht zu den "erlaubten" Attributen gehören und ist daher nicht Neustart-fest. Tendenziell würde ich es ausbauen/so umbauen, dass das nach der Erfüllung der Hilfsfunktion auch wieder weg ist, aber das sieht so aus, als hätte da jemand noch was vorgehabt?

Wie dem auch sei, meine eigentliche Absicht, das auf diesem Weg "abfangen" zu können, scheint halbwegs zielführend gewesen zu sein. Hätte mich fast gewundert, wenn es auf's erste Mal geklappt hätte

.

Zitat
3. bereits länger ignored devices bekommen beim restart scheinbar trotzdem IODev, sogar mein test reading IODev_test über assignioport ist aktuell.

Dazu habe ich noch keine Idee und fürchte, das kommt aus fhem.pl. Die Frage ist aber, ob das stört, weil jedenfalls CUL_HM im Optimalfall ja weiß, welche Devices bei welchem IO registriert werden müssen (wg. der Acks etc.). Und das sollte jedenfalls bis dahin entfallen sein(?). Reines Empfangen sollte nicht stören. (Übersehe ich ...?)

Zitat
----------------

zwei ungereimtheiten zu cul_hm_assignio

soweit ich assignioport verstehe, ist es hauptsächlich zum setzen von attribut/reading IODev. ein übergebenes io, wird zudem eventuell auch aussortiert und ggf durch ein gefundenes, typgleiches ersetzt.
das ersetzen durch assignio kann ggf ungereimtheiten hervorrufen, denke ich.

1. nach dem ersten aufruf (wechsel) setzt cul_hm erneut hash/iodev. wenn assignioport nun ein anderes gewählt hat, stimmen reading und internal nicht mehr überein.

2. der zweite aufruf (ohne wechsel) sollte eigentlich überflüssig sein. ausserdem gibt es ärger, wenn gewechselt wurde.

eigentlich müsste man immer nach assignioport prüfen, ob dadurch ein io wechsel vorgenommen wurde.
wenn assignioport ein wechsel durchgeführt hat, stimmt im ersten fall nur das reading nicht und im zweiten fall ist das neue und alte io ggf nicht richtig präpariert.

Sehr aufschlussreicher Befund!
Wir nähern uns m.E. des Pudels Kern. Ich habe den Bereich um #10942ff jetzt mal dahingehend umgebaut, dass eigentlich was im Log zu finden sein sollte, wenn fhem.pl den Vorschlag von CUL_HM ignoriert und was anderes assigned. Der Konflikt ist jetzt so herum gelöst, dass CUL_HM die Entscheidung von fhem.pl akzeptiert. Gefällt vermutlich Martin nicht, aber dies v.a., weil es der einfachere Weg war und wir m.E. erst mal feststellen müssen, wann das (warum?) passiert...

EDIT: den 2. Punkt habe ich vermutlich noch nicht ganz gedanklich durchdrungen...

Den "delete"-Fall hoffe ich repariert zu haben.

Edit: Bzgl. "delete" bei den Attributen sollte auch https://forum.fhem.de/index.php/topic,120328.msg1148467.html#msg1148467 jetzt gelöst sein?

Beta-User · 28 Oktober 2021, 16:01:19

Zitat von: frank am 28 Oktober 2021, 15:13:44
meine zeile 379
Code Auswählen Erweitern
next if($_ !~ m /at_.*$ehash->{IODev}->{NAME}/ );#ignore unused IODev

Hmm, eigentlich sollte dann gleich der Teil gar nicht ausgewertet werden. Ein schnelles

Code Auswählen

last if !defined $ehash->{IODev}; davor sollte zumindest den Fehler verhindern...

Beta-User · 28 Oktober 2021, 20:47:04

Habe eben wieder einen kompletten Satz hochgeladen. Da sind die Änderungen von heute drin und evtl. auch was, was wieder ein, zwei Punkte von franks "offener-Punkte-Liste" holen könnte...

frank · 28 Oktober 2021, 21:19:12

dummy und ignore funktionieren im prinzip. ob sie restart überleben wird sich noch zeigen.

bei dummy gibt es noch eine unklarheit.
wenn dummy, dann jetzt kein io mehr. dann sagt aber configcheck fehler:no io.
im prinzip ist das ja nun kein fehler, da ja absichtlich dummy gesetzt ist. andererseits ist es ja eine gute erinnerung, falls es nur vorübergehen geplant war.
wer nutzt es und wofür?

wenn die fehlermeldung bleiben soll, müsste nach dem ändern von dummy noch jeweils ein configcheck -f aufruf eingebaut werden, damit es automatisch kommt.

Beta-User · 28 Oktober 2021, 22:47:44

Bin unentschlossen.
Alternativ könnten wir bei dummy auch das letzte IO im Hash lassen und nur "deregistrieren"? Die prinzipielle Logik scheint ja jetzt zu passen, und an es wäre sowieso noch zu klären, ob die Automatik durch fhem.pl (es wird zumindest bei dummy ein IO beim Start zugewiesen, wenn eines vorhanden ist) irgendwelche unbeabsichtigten Nebenwirkungen hat. Oder reißen wir damit eine neue Lücke?
Muß mir das mal nochmal im Code ansehen, aber eigentlich wäre das doch ausreichend (wenn es nebenwirkungsfrei geht)?

(Sorry, dass das alles irgendwie grade so "Stückwerk" ist).

Weitere Meinungen?

frank · 28 Oktober 2021, 23:11:41

hi,

bei mir gibt es drei phasen bei restart, in denen io in grösserer zahl zugewiesen werden.
das erste mal bei define.
da hier keine attribute existieren, wird jedem definierten device ein io zugeordnet. daher auch für ignore und dummy. ausgelöst durch cul_hm_assignio am ende von define, das könnte und sollte dort ersatzlos gestrichen werden, denke ich.

wenn jemand 100+ nachbar devices definiert hat...

edit: der erste sinnvolle zeitpunkt ist nach dem einlesen der readings, also nach dem save file.

edit2: dieser 2. block ist eigentlich auch zu früh vermutlich.
sinnvoll ist, wenn sowohl readings als auch alle relevanten attribute da sind. initial cleanup?

edit3: perfekt wäre der zeitpunkt, wenn 1. die readings da sind, und 2. die relevanten attribute zur ermittlung des gewünschten, optimalen io bereitstehen, und 3. wenn dies dann operabel ist. dann erst sollte cul_hm_assignio aufgerufen werden.

ich denke, da bräuchte es generell mal einen durchdachten ablaufplan.
mach dir mal meine geposteten logmeldungen in fhem.pl/setReadingsVal, damit du siehst, was ich meine.
https://forum.fhem.de/index.php/topic,123655.msg1182497.html#msg1182497

Beta-User · 29 Oktober 2021, 09:36:32

Anbei mal wieder eine Testversion...

Zitat von: frank am 28 Oktober 2021, 23:11:41
hi,

bei mir gibt es drei phasen bei restart, in denen io in grösserer zahl zugewiesen werden.
das erste mal bei define.
da hier keine attribute existieren, wird jedem definierten device ein io zugeordnet. daher auch für ignore und dummy. ausgelöst durch cul_hm_assignio am ende von define, das könnte und sollte dort ersatzlos gestrichen werden, denke ich.

...irgendwie hat mich der dramatische Begleittext vor diesem assingio bisher davon abgehalten, da was zu ändern. Dabei habe ich vermutlich übersehen, dass das für die timerbasierte Variante wichtig war, und wir ja schon eine ganze Zeitlang andere Abläufe haben...
Jetzt also nur noch assignio an dieser Stelle, wenn kein IODev-Internal+$init_done? Damit sollten "echte" defines at runtime auch erfasst werden.

Zitat
wenn jemand 100+ nachbar devices definiert hat...

...sollte es jetzt helfen, dass bei der Initialisierung ignore und dummy beachtet werden? Zumindest beim Test sah das jetzt gut aus

. Keine IODev-Internals mehr bei dummy=1 nach FHEM-Start, ignore sollte gleich sein.

Zitat
edit: der erste sinnvolle zeitpunkt ist nach dem einlesen der readings, also nach dem save file.

edit2: dieser 2. block ist eigentlich auch zu früh vermutlich.
sinnvoll ist, wenn sowohl readings als auch alle relevanten attribute da sind. initial cleanup?

Genau da müßte es jetzt eigentlich stattfinden

.

Zitatedit3: perfekt wäre der zeitpunkt, wenn 1. die readings da sind, und 2. die relevanten attribute zur ermittlung des gewünschten, optimalen io bereitstehen, und 3. wenn dies dann operabel ist. dann erst sollte cul_hm_assignio aufgerufen werden.

...aus diesem Grund habe ich die NotifyFn mit höherer Prio versehen wie die aus CUL_HM. Eleganter wäre noansi's Vorschlag mit einer eigenen InitFn(), aufzurufen aus fhem.pl. Ggf. muss/sollte man sich Gedanken machen, wie das mit HMUARTLGW und TSCUL gehandhabt werden sollte (habe bisher in beide nicht reingeschaut).

Zitat
ich denke, da bräuchte es generell mal einen durchdachten ablaufplan.
mach dir mal meine geposteten logmeldungen in fhem.pl/setReadingsVal, damit du siehst, was ich meine.
https://forum.fhem.de/index.php/topic,123655.msg1182497.html#msg1182497

Prinzipiell richtig, daher auch mein Aufgreifen des o.g. Vorschlags von noansi. Er hatte das Grundproblem ja sehr schön beschrieben, nur die logische Reihung von IO und Client fehlte da m.E. noch.

Ich werde leider über das WE vermutlich nicht dazu kommen, dieses Logging einzubauen und dann auch noch auszuwerten, zumal ich dann vermutlich auch noch "fliegende Devices" durch die Gegend tragen müßte. Als Minimallösung ist aber derzeit (seit gestern) zumindest mal ein CUL_HM-internes logging aktiviert, wenn es "komische" Wechsel gibt. An sich sollte es auch möglich sein, in CUL_HM/assignio selbst Wechsel zu loggen, ohne auf fhem.pl zurückgreifen zu müssen.

Jetzt wäre es m.E. erst mal sinnvoll, den jetzigen Stand auf "schlichte" Funktionalität zu prüfen.

CCU-FHEM kann man jetzt übrigens auch nur noch auf dummy/ignore setzen, wenn man vorher IOList löscht. Bitte um Rückmeldung, falls das eine blöde Idee gewesen sein sollte.

Wie immer wären daher mutige Tester gern gesehen

, ich weise der guten Ordnung halber darauf hin, dass ich selbst das noch nicht im Echtsystem laufen lassen kann, geht erst irgendwann über das WE. Ich glaube zwar nicht, dass die Änderungen problematisch sind, aber wie üblich ist es leider nicht auszuschließen, dass ich was wichtiges übersehen haben könnte...

MadMax-FHEM · 29 Oktober 2021, 09:44:26

Testen heißt:

diese Version von CUL_HM.pm von hier

Rest von "ganz vorne"?

Weiß zwar niht wann ich dazu komme aber könnte heute klappen, zumindest mal Testsysteme...
Hauptsystem mal sehen.

Gruß, Joachim

P.S.: aktuell stehe ich auf 3 Systemen auf dem Stand von vor knapp 10 Tagen...

Beta-User · 29 Oktober 2021, 09:59:19

Ja, wobei die "Dringlichkeit" immer davon abhängt, was wann wie eingeflossen ist und was konkret im Einsatz ist...

Ich meine, der geänderte Ablauf bei der Initialisierung der IODev ist ein Anlass, die vorhin gepostete Version zu nehmen. Das gilt auch für "normale User", sobald der erste hier meldet, keine Probleme in seinem Echtsystem zu haben!

MadMax-FHEM · 29 Oktober 2021, 10:11:12

Zitat von: Beta-User am 29 Oktober 2021, 09:59:19
Ich meine, der geänderte Ablauf bei der Initialisierung der IODev ist ein Anlass, die vorhin gepostete Version zu nehmen. Das gilt auch für "normale User", sobald der erste hier meldet, keine Probleme in seinem Echtsystem zu haben!

Ok, "normaler User" da sehe ich mich mal

Ich schaue mal, dass ich das bis heute Abend auch auf das Hauptsystem kriege und gebe Bescheid...

Gruß, Joachim

Beta-User · 29 Oktober 2021, 10:28:06

Zitat von: frank am 28 Oktober 2021, 21:19:12
wenn die fehlermeldung bleiben soll, müsste nach dem ändern von dummy noch jeweils ein configcheck -f aufruf eingebaut werden, damit es automatisch kommt.

Bin noch nicht sicher, welche Auswirkungen die letzte Änderung auf dieses spezielle Thema hat.
IODev wird zwar an dieser Code-Stelle im Moment nicht mehr gelöscht, dafür aber eben nach Neustart auch nicht mehr gesetzt => selbes "Problem" (aber mit autom. configcheck?).
Stellt sich die Frage, ob man ignore/dummy in HMinfo überhaupt behandeln sollte. Vorläufig würde ich das als Prio low ansehen. OK?