[gelöst] Fehler 'Unknown argument displayWM' beim Homematic Display HM-Dis-WM55

Begonnen von huntsman, 05 Oktober 2021, 20:14:48

Vorheriges Thema - Nächstes Thema

huntsman

Mit dem Upgrade auf einen Raspi4 und dabei auf die neuste FHEM 6.0 Version tritt bei mir beim Homematic Display HM-Dis-WM55 bem Aufruf von 'set HM_6D72EC_Dis_01 displayWM short  line1 e:{myLineA(1,0)}'  folgender Fehler auf:

Unknown argument displayWM, choose one of regBulk regSet peerBulk getRegRaw getConfig:noArg clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all

Dies scheint früher schon mal aufgetreten zu sein https://forum.fhem.de/index.php/topic,99579.msg1176645.html#msg1176645

Infos zum Device:
list Display:
Internals:
   DEF        6D72EC
   FUUID      615c76ec-f33f-9964-992b-1348e15b6fc7e915
   IODev      CUL_0
   NAME       Display
   NR         220
   NTFY_ORDER 48-Display
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_6D72EC_Dis_01
   channel_02 HM_6D72EC_Dis_02
   channel_03 HM_6D72EC_Dis_03
   channel_04 HM_6D72EC_Dis_04
   channel_05 HM_6D72EC_Dis_05
   channel_06 HM_6D72EC_Dis_06
   channel_07 HM_6D72EC_Dis_07
   channel_08 HM_6D72EC_Dis_08
   channel_09 HM_6D72EC_Dis_09
   channel_0A HM_6D72EC_Dis_10
   disableNotifyFn 1
   READINGS:
     2021-10-03 21:40:52   CommandAccepted yes
     2021-09-21 15:42:38   D-firmware      1.0
     2021-09-21 15:42:38   D-serialNr      QEQ0294715
     2021-10-05 18:01:48   IODev           CUL_0
     2021-10-03 21:40:52   battery         ok
     2021-10-03 21:40:52   commState       CMDs_done
     2021-10-03 21:40:52   state           CMDs_done
   helper:
     HM_CMDNR   155
     mId        00D3
     peerFriend -
     peerOpt    -:display
     regLst     0
     rxType     4
     cmds:
       TmplKey    :no:1633449713.18416
       TmplTs     1633449713.18416
       cmdKey     0:1:0::Display:00D3: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-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplDel     
       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        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +6D72EC,00,00,00
       rxt        0
       vccu       
       p:
         6D72EC
         00
         00
         00
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
     tmpl:
Attributes:
   IODev      CUL_0
   IOgrp      vccu:CUL_0
   autoReadReg 4_reqStatus
   expert     defReg,rawReg
   firmware   1.0
   model      HM-Dis-WM55
   msgRepeat  3
   room       CUL_HM
   serialNr   QEQ0294715
   subType    display
   webCmd     getConfig:clear msgEvents

list -r Display:
define Display CUL_HM 6D72EC
attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
attr Display autoReadReg 4_reqStatus
attr Display expert defReg,rawReg
attr Display firmware 1.0
attr Display model HM-Dis-WM55
attr Display msgRepeat 3
attr Display room CUL_HM
attr Display serialNr QEQ0294715
attr Display subType display
attr Display webCmd getConfig:clear msgEvents

setstate Display CMDs_done
setstate Display 2021-10-05 18:01:53 .associatedWith Display,HM_6D72EC_Dis_01,HM_6D72EC_Dis_02,HM_6D72EC_Dis_03,HM_6D72EC_Dis_04,HM_6D72EC_Dis_05,HM_6D72EC_Dis_06,HM_6D72EC_Dis_07,HM_6D72EC_Dis_08,HM_6D72EC_Dis_09,HM_6D72EC_Dis_10,Display
setstate Display 2021-10-03 21:40:52 .protLastRcv 20211003214052
setstate Display 2021-10-03 21:40:52 CommandAccepted yes
setstate Display 2021-09-21 15:42:38 D-firmware 1.0
setstate Display 2021-09-21 15:42:38 D-serialNr QEQ0294715
setstate Display 2021-10-05 18:01:48 IODev CUL_0
setstate Display 2021-10-03 21:40:52 battery ok
setstate Display 2021-10-03 21:40:52 commState CMDs_done
setstate Display 2021-10-03 21:40:52 state CMDs_done

Vielen Dank für Eure Hilfe dazu

frank

du musst schon ein aktuelles fhem nutzen, sonst kann dir wahrscheinlich keiner helfen.

solange in deinen cul_hm devices attr IODev existiert, bist du nicht aktuell.

du hast scheinbar noch kein update cmd in deinem fhem ausgeführt.
anschliessend trotzdem noch die aktuellen dateien von beta-user einspielen.
danach das list posten, möglichst noch mit code tags formatieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

hast du überhaupt ein vccu definiert?
das list sieht komisch aus.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

huntsman

Meine FHEM version ist die vom nightly, zugegeben von vor einer Woche oder so. Die eingespielte config ist allerdings die von meiner vorherigen FHEM version, daher vielleicht das IODev? Bis jetzt hat das Übernehmen der Konfig auf eine neue FHEM Version immer ohne Probleme funktioniert. Oder muß ich dann alle Geräte nochmal neu einrichten?
Jedenfall keine Änderung mit update über apt-get auf die aktuellste nighly fhem_6.0.25047 und danach Austausch der 10_CUL_HM.pm und 98_HMinfo.pm vom Oktober Patch von heute.
VCCU habe ich definiert:
define vccu CUL_HM AFFE98
attr vccu IODev CUL_0
attr vccu IOList CUL_0
attr vccu model CCU-FHEM
attr vccu subType virtual
attr vccu webCmd virtual:update



list Display:
Internals:
   CUL_0_MSGCNT 2
   CUL_0_RAWMSG A0A0980026D72ECAFFE9800::-53:CUL_0
   CUL_0_RSSI -53
   CUL_0_TIME 2021-10-05 21:04:56
   DEF        6D72EC
   FUUID      615ca1b9-f33f-9964-da50-fa10e321c8e6b33d
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     2
   NAME       Display
   NR         220
   NTFY_ORDER 48-Display
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_6D72EC_Dis_01
   channel_02 HM_6D72EC_Dis_02
   channel_03 HM_6D72EC_Dis_03
   channel_04 HM_6D72EC_Dis_04
   channel_05 HM_6D72EC_Dis_05
   channel_06 HM_6D72EC_Dis_06
   channel_07 HM_6D72EC_Dis_07
   channel_08 HM_6D72EC_Dis_08
   channel_09 HM_6D72EC_Dis_09
   channel_0A HM_6D72EC_Dis_10
   disableNotifyFn 1
   lastMsg    No:09 - t:02 s:6D72EC d:AFFE98 00
   protLastRcv 2021-10-05 21:04:56
   protRcv    2 last_at:2021-10-05 21:04:56
   protSnd    2 last_at:2021-10-05 21:04:56
   protState  CMDs_done
   rssi_at_CUL_0 cnt:2 min:-53 max:-51.5 avg:-52.25 lst:-53
   READINGS:
     2021-10-05 21:04:56   CommandAccepted yes
     2021-09-21 15:42:38   D-firmware      1.0
     2021-09-21 15:42:38   D-serialNr      QEQ0294715
     2021-10-05 21:04:56   IODev           CUL_0
     2021-10-05 21:04:56   battery         ok
     2021-10-05 21:04:56   commState       CMDs_done
     2021-10-05 21:04:56   state           CMDs_done
   helper:
     HM_CMDNR   9
     cSnd       ,11AFFE986D72EC80010203
     lastMsgTm  1633460696.59442
     mId        00D3
     peerFriend -
     peerOpt    -:display
     regLst     0
     rxType     4
     supp_Pair_Rep 0
     ack:
       vccu       HM_6D72EC_Dis_01:08
     cmds:
       TmplKey    :no:1633460670.58908
       TmplTs     1633460670.58908
       cmdKey     0:1:0::Display:00D3:01:
       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-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplDel     
       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        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +6D72EC,00,00,00
       nextSend   1633460696.6403
       rxt        0
       vccu       
       p:
         6D72EC
         00
         00
         00
       prefIO:
     mRssi:
       mNo        09
       io:
         CUL_0:
           -47
           -47
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
     rssi:
       at_CUL_0:
         avg        -52.25
         cnt        2
         lst        -53
         max        -51.5
         min        -53
     tmpl:
Attributes:
   IODev      CUL_0
   IOgrp      vccu:CUL_0
   autoReadReg 4_reqStatus
   expert     defReg,rawReg
   firmware   1.0
   model      HM-Dis-WM55
   msgRepeat  3
   room       CUL_HM
   serialNr   QEQ0294715
   subType    display
   webCmd     getConfig:clear msgEvents


list -r Display
define Display CUL_HM 6D72EC
attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
attr Display autoReadReg 4_reqStatus
attr Display expert defReg,rawReg
attr Display firmware 1.0
attr Display model HM-Dis-WM55
attr Display msgRepeat 3
attr Display room CUL_HM
attr Display serialNr QEQ0294715
attr Display subType display
attr Display webCmd getConfig:clear msgEvents

setstate Display CMDs_done
setstate Display 2021-10-05 21:04:30 .associatedWith Display,HM_6D72EC_Dis_01,HM_6D72EC_Dis_02,HM_6D72EC_Dis_03,HM_6D72EC_Dis_04,HM_6D72EC_Dis_05,HM_6D72EC_Dis_06,HM_6D72EC_Dis_07,HM_6D72EC_Dis_08,HM_6D72EC_Dis_09,HM_6D72EC_Dis_10,Display
setstate Display 2021-10-05 21:04:56 .protLastRcv 20211005210456
setstate Display 2021-10-05 21:04:56 CommandAccepted yes
setstate Display 2021-09-21 15:42:38 D-firmware 1.0
setstate Display 2021-09-21 15:42:38 D-serialNr QEQ0294715
setstate Display 2021-10-05 21:04:56 IODev CUL_0
setstate Display 2021-10-05 21:04:56 battery ok
setstate Display 2021-10-05 21:04:56 commState CMDs_done
setstate Display 2021-10-05 21:04:56 state CMDs_done


Beta-User

Kannst du mal "model" auf Großschreibung umstellen (falls das in der Auswahlliste ist).

PS: betr. update in FHEM müssen wir nochmal gesondert diskutieren...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

das device hat nie einen attr check durchlaufen, sage ich.

was zeigt fhem, wenn du "version" in die eingabezeile tippst?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Seltsam. Jedenfalls auf meinem Testsystem ist mit diesem RAW das Attribut ".mId" nach dem Start vorhanden, selbst, wenn es nicht in der cfg steht. Das unabhängig davon, ob HMinfo und/oder eine VCCU vorhanden sind.

Ergo wäre meine Schlussfolgerung, dass HMConfig kaputt ist oder die aktualisierten Module nicht geladen werden.

=> Bitte franks Frage beantworten (v.a. im Hinblick auf fhem.pl, DevIo.pm und die drei mit CUL_HM zusammenhängenden Module. Ggf. mal die aktuelle HMConfig aus dem svn holen und vergleichen.

@huntsman: vom diesem Attribut hängt die korrekte Zuweisung der möglichen Befehle ab, ich gehe daher davon aus, dass die (bzw. displayWM) auch lange nach dem Start bei dir nicht in den Kanal-Devices vorhanden/zulässig sind.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

@frank: Bist du auch über das hier gestolpert?
Zitat von: martinp876 am 26 Juni 2020, 13:14:22
Das file löst auch Kommandos aus welche ich zu startup machen will. So wird das zeilendisplay initialisiert..

Martin wollte anscheinend recht ultimativ aus performance-Gründen (?) nicht die ganze Initialisierung in der NotifyFn haben... Damit wäre mein Ansatz "falsch" bzw. genau gegenläufig... Unschön. Und nun?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

huntsman

Zitat von: frank am 05 Oktober 2021, 21:25:14
das device hat nie einen attr check durchlaufen, sage ich.

was zeigt fhem, wenn du "version" in die eingabezeile tippst?

Das hier:
Latest Revision: 25046

File                Rev   Last Change

fhem.pl             25039 2021-10-01 16:21:46Z rudolfkoenig
96_allowed.pm       24751 2021-07-15 12:46:01Z rudolfkoenig
90_at.pm            24129 2021-04-02 16:56:29Z rudolfkoenig
98_autocreate.pm    23727 2021-02-12 20:31:37Z rudolfkoenig
00_CUL.pm           24815 2021-08-01 16:14:02Z rudolfkoenig
# $Id: 10_CUL_HM.pm 24961 2021-10-05 + various Beta-User-Patches + sort II + new initialisation + allow more set commands in startup phase + start before HMinfo  $
98_dummy.pm         20665 2019-12-06 11:05:35Z rudolfkoenig
01_FHEMWEB.pm       25000 2021-09-21 08:58:47Z rudolfkoenig
92_FileLog.pm       24967 2021-09-13 16:09:40Z rudolfkoenig
98_IF.pm            12944 2017-01-03 12:56:17Z Damian
10_IT.pm            20839 2019-12-28 09:41:47Z bjoernh
91_notify.pm        24129 2021-04-02 16:56:29Z rudolfkoenig
33_readingsGroup.pm 23844 2021-02-27 19:43:24Z justme1968
99_SUNRISE_EL.pm    24249 2021-04-14 05:45:49Z rudolfkoenig
98_update.pm        24983 2021-09-16 17:15:44Z rudolfkoenig
99_Utils.pm         24128 2021-04-02 16:29:11Z rudolfkoenig
98_version.pm       15140 2017-09-26 09:20:09Z markusbloch

AttrTemplate.pm     22985 2020-10-18 09:04:19Z rudolfkoenig
Blocking.pm         23268 2020-12-01 11:48:48Z rudolfkoenig
Color.pm            20813 2019-12-22 18:42:10Z justme1968
DevIo.pm            24800 2021-07-26 11:42:33Z rudolfkoenig
HMConfig.pm         24773 2021-07-18 18:18:13Z martinp876
HttpUtils.pm        24750 2021-07-15 06:22:47Z rudolfkoenig
myUtilsTemplate.pm   7570 2015-01-14 18:31:44Z rudolfkoenig
RTypes.pm           10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm    23300 2020-12-06 11:36:24Z rudolfkoenig
TcpServerUtils.pm   23472 2021-01-04 19:56:38Z rudolfkoenig

fhemweb.js                 25022 2021-09-27 07:11:18Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968


huntsman

Zitat von: Beta-User am 05 Oktober 2021, 21:18:00
Kannst du mal "model" auf Großschreibung umstellen (falls das in der Auswahlliste ist).

PS: betr. update in FHEM müssen wir nochmal gesondert diskutieren...

Konnte nur das Attribut modelForce auf Großschreibung setzen, sieht jetzt so aus:
list -r Display

define Display CUL_HM 6D72EC
attr Display .mId 00D3
attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
attr Display autoReadReg 4_reqStatus
attr Display expert defReg,rawReg
attr Display firmware 1.0
attr Display model HM-DIS-WM55
attr Display modelForce HM-DIS-WM55
attr Display msgRepeat 3
attr Display room CUL_HM
attr Display serialNr QEQ0294715
attr Display subType display
attr Display webCmd getConfig:clear msgEvents

setstate Display CMDs_done
setstate Display 2021-10-06 17:01:24 .associatedWith Display,HM_6D72EC_Dis_01,HM_6D72EC_Dis_02,HM_6D72EC_Dis_03,HM_6D72EC_Dis_04,HM_6D72EC_Dis_05,HM_6D72EC_Dis_06,HM_6D72EC_Dis_07,HM_6D72EC_Dis_08,HM_6D72EC_Dis_09,HM_6D72EC_Dis_10,Display
setstate Display 2021-10-06 17:01:53 .protLastRcv 20211006170153
setstate Display 2021-10-06 17:01:53 CommandAccepted yes
setstate Display 2021-09-21 15:42:38 D-firmware 1.0
setstate Display 2021-09-21 15:42:38 D-serialNr QEQ0294715
setstate Display 2021-10-06 17:01:51 IODev CUL_0
setstate Display 2021-10-06 17:01:51 battery ok
setstate Display 2021-10-06 17:01:53 commState CMDs_done
setstate Display 2021-10-06 17:01:53 state CMDs_done


Aber damit geht es jetzt tatsächlich  :) :)
War es dann etwa nur die Großschreibung von "DIS" ?

frank

und wenn du nun einen restart machst, wie sieht dann ein list aus?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Zitat von: huntsman am 06 Oktober 2021, 17:05:43
War es dann etwa nur die Großschreibung von "DIS" ?
Jein. "Eigentlich" wird intern sowieso mit "uc" gearbeitet. Von daher würde ich schlussfolgern, dass da noch irgendwas verstecktes im Namen schlummert. (Sowas zu finden ist schwer und einer der vielen Gründe, warum von direkten cfg-Edits abzuraten ist!)

Zitat von: huntsman am 06 Oktober 2021, 17:05:43
Konnte nur das Attribut modelForce auf Großschreibung setzen, sieht jetzt so aus
Du solltest das modelForce dann auch wieder löschen können.

Grundsätzlich ist die Kette so, dass aus model (überschreibbar durch modelForce) die .mId abgeleitet wird, die dann für alles weitere der Bezugspunkt ist. Fehlt der, geht es halt nicht weiter. qed.



@frank:
U.a. wegen dieses Threads bin ich jetzt nochmal durch den Code und habe weiter keine wirklichen Lücken gefunden. Allerdings ist mir dabei nochmal deutlich geworden, dass CUL_HM_updateConfig() bei der Initialisierung zwar einmal über alle Devices drüberlauft (CUL_HM_updtDeviceModel(), aufgerufen über die Schleife ab #239)  und die Attribute etc. einsammelt. Bei den VIRTUALs wird das aber nur rudimentär gemacht, indem schlicht "model" für alle Kanäle gesetzt wird.
An diese Stelle gehört aber m.E. der Schleifendurchlauf für "welches Schweinderl bin ich denn?" hin (ehemals rund um "test1"-Log) , denn dann können wir auch die Befehle über virtuelle Kanäle ohne Timer weiter hinten direkt in CUL_HM_updateConfig() abfeuern. Wobei das uU. gar keine so gute Idee ist, weil die IO's uU. dazu noch gar nicht bereit sind? Hmm, dann lass ich das mal in den Timern drin, und gefeuert wird erst etwas später, damit die IO's erst fertig sind => "time+10" ?

Melde mich nach dem Testen nochmal, aber abgesehen von eventuellen Performance-Themen finde ich den Ablauf jetzt einigermaßen klar strukturiert...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

@beta-user
warum sind hier beide attribute vorhanden?

attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

huntsman

Zitat(Sowas zu finden ist schwer und einer der vielen Gründe, warum von direkten cfg-Edits abzuraten ist!)
Kann ich verstehen. Die Geräte habe ich natürlich initial mit autocreate erzeugen lassen nur die ganze Logik zur Steuerung habe ich manuell dazugefügt. An den Attributen der Devices habe ich eigentlich nicht manuell rumgespielt, außer z.B die Zuordnung zu Räumen...

huntsman

Zitat
und wenn du nun einen restart machst, wie sieht dann ein list aus?

list -r Display
define Display CUL_HM 6D72EC
attr Display .mId 00D3
attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
attr Display autoReadReg 4_reqStatus
attr Display expert defReg,rawReg
attr Display firmware 1.0
attr Display model HM-DIS-WM55
attr Display modelForce HM-DIS-WM55
attr Display msgRepeat 3
attr Display room CUL_HM
attr Display serialNr QEQ0294715
attr Display subType display
attr Display webCmd getConfig:clear msgEvents

setstate Display CMDs_done
setstate Display 2021-10-06 18:07:01 .associatedWith Display,HM_6D72EC_Dis_01,HM_6D72EC_Dis_02,HM_6D72EC_Dis_03,HM_6D72EC_Dis_04,HM_6D72EC_Dis_05,HM_6D72EC_Dis_06,HM_6D72EC_Dis_07,HM_6D72EC_Dis_08,HM_6D72EC_Dis_09,HM_6D72EC_Dis_10,Display
setstate Display 2021-10-06 17:41:45 .protLastRcv 20211006174145
setstate Display 2021-10-06 17:41:45 CommandAccepted yes
setstate Display 2021-09-21 15:42:38 D-firmware 1.0
setstate Display 2021-09-21 15:42:38 D-serialNr QEQ0294715
setstate Display 2021-10-06 18:07:01 IODev CUL_0
setstate Display 2021-10-06 17:41:43 battery ok
setstate Display 2021-10-06 17:41:45 commState CMDs_done
setstate Display 2021-10-06 17:41:45 state CMDs_done


list Display
Internals:
   DEF        6D72EC
   FUUID      615ca1b9-f33f-9964-da50-fa10e321c8e6b33d
   IODev      CUL_0
   NAME       Display
   NR         220
   NTFY_ORDER 48-Display
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_6D72EC_Dis_01
   channel_02 HM_6D72EC_Dis_02
   channel_03 HM_6D72EC_Dis_03
   channel_04 HM_6D72EC_Dis_04
   channel_05 HM_6D72EC_Dis_05
   channel_06 HM_6D72EC_Dis_06
   channel_07 HM_6D72EC_Dis_07
   channel_08 HM_6D72EC_Dis_08
   channel_09 HM_6D72EC_Dis_09
   channel_0A HM_6D72EC_Dis_10
   disableNotifyFn 1
   READINGS:
     2021-10-06 17:41:45   CommandAccepted yes
     2021-09-21 15:42:38   D-firmware      1.0
     2021-09-21 15:42:38   D-serialNr      QEQ0294715
     2021-10-06 18:07:01   IODev           CUL_0
     2021-10-06 17:41:43   battery         ok
     2021-10-06 17:41:45   commState       CMDs_done
     2021-10-06 17:41:45   state           CMDs_done
   helper:
     HM_CMDNR   153
     mId        00D3
     peerFriend -
     peerOpt    -:display
     regLst     0
     rxType     4
     cmds:
       TmplKey    :no:noAssTs
       TmplTs     1633536421.4518
       cmdKey     0:1:0::Display:00D3:01:
       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-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplDel     
       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
     dispi:
       l:
         l1:
           d          1
         l2:
           d          1
         l3:
           d          1
         l4:
           d          1
         l5:
           d          1
         l6:
           d          1
       s:
         l1:
           d          1
         l2:
           d          1
         l3:
           d          1
         l4:
           d          1
         l5:
           d          1
         l6:
           d          1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +6D72EC,00,00,00
       rxt        0
       vccu       
       p:
         6D72EC
         00
         00
         00
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
     tmpl:
Attributes:
   IODev      CUL_0
   IOgrp      vccu:CUL_0
   autoReadReg 4_reqStatus
   expert     defReg,rawReg
   firmware   1.0
   model      HM-DIS-WM55
   modelForce HM-DIS-WM55
   msgRepeat  3
   room       CUL_HM
   serialNr   QEQ0294715
   subType    display
   webCmd     getConfig:clear msgEvents


Im log sehe ich übrigens noch ein paar Perl warnings:


2021.10.06 18:07:01 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 4965.
2021.10.06 18:07:01 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/10_CUL_HM.pm line 4976.
2021.10.06 18:07:01 1: PERL WARNING: Use of uninitialized value in hash element at fhem.pl line 4521.
2021.10.06 18:07:01 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/10_CUL_HM.pm line 5050.
...
2021.10.06 18:07:01 1: PERL WARNING: Can't exec "lsusb": No such file or directory at ./FHEM/98_autocreate.pm line 587.
..

Beta-User

@huntsman: Kannst du mir noch einfach die Code-Auszüge aus deiner CUL_HM-Version dazupacken? Bei mir ist schon wieder alles anders...

Zitat von: huntsman am 06 Oktober 2021, 18:05:00
[...] nur die ganze Logik zur Steuerung habe ich manuell dazugefügt. An den Attributen der Devices habe ich eigentlich nicht manuell rumgespielt, außer z.B die Zuordnung zu Räumen...
"nur" ist relativ, und es gibt wirklich keinen Grund, direkt in der cfg rumzumalen (ich könnte das auf dem Echt-System nicht mal und vermisse es auch nicht). Geht alles (ggf. via devspec) über FHEMWEB schneller (und bei configdb gibt's dann auch noch einen direkt implementierten search-Befehl).

Neulich hatte ich die commandref in einem Modul überarbeitet. Aus irgendeinem Grund wollte FHEMWEB die aber nicht anzeigen. Der Grund war schlicht: Windows-Zeilenumbruch statt Unix-style. In beiden Editoren (Kate, notepad++) in der normalen Anzeige nicht zu erkennen... Also einfache Regel: Finger weg!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#16
Zitat von: frank am 06 Oktober 2021, 17:49:59
@beta-user
warum sind hier beide attribute vorhanden?

attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0

...du kannst aber Fragen stellen... (woher soll ich das wissen ;D ...)

Vermutlich, weil der Prüfungsmechanismus bei der Attributeingabe nicht greift, wenn man die cfg editiert ;D (oder eben schon eine alte hat, nach der das möglich war).

Die implizite Aufforderung scheint zu sein: IODev-Attribut löschen, wenn IOgrp gesetzt ist?



Wenn wir es grade von Merkwürdigkeiten haben: Im Moment kann man bei allen virtuellen Kanälen ja "alles" setzen, weil .AttrList fehlt. "vermutlich" haben wir die Stelle ja jetzt identifiziert, an der man der Freiheit ein Ende setzen könnte. Mal sehen, erst sollte der in der angehängten Zwischenversion geänderte Ablauf getestet sein - meine virtuellen Sensoren sind überwiegend im Takt geblieben/wieder eingefangen, von daher bin ich optimistisch...

PS:  configCheck -f habe ich nur noch zwei im Log - warum auch immer (es ist aber nachvollziehbar, warum es grade diese Geräte sind die auftauchen) - positives Voodoo, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

Zitatdu kannst aber Fragen stellen
ich dachte, du hattest es nicht bemerkt.  ;)

bei mir wurden alle attr IODev durch den start der ersten cul_hm version mit attrcheck (aktuelle svn version) gelôscht.
wenn du es nicht ausgebaut hast, sollte es noch existieren.
ausnahme: bei meinem device, dass IOgrp mit none besass, wurde attr IODev auch nicht gelöscht. das ist nach reparatur jetzt aber passiert.

huntsman hat auch noch einen erfolglosen restart nachgelegt. vielleicht stört die existenz von modelForce?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

...das mit .AttrList war eher einer der Brücken von denen ich dachte, dass es erst Sinn macht, davon runterspringen zu wollen, wenn man draufsteht ;D ... Bevor ich die codemäßig überhaupt in Sicht bekommen hatte, war das nur was für "merke ich mir für irgendwann" ::) .

Jetzt hat es zumindest in meinen Vorstellungen vom Gesamtablauf einen Ort, wo ich es hinpacken kann - und schon erscheint es lösbar und nicht mehr rätselhaftes Voodoo ;D .



Bzgl. IODev: Ich hatte das manuell gelöscht (zeitnah zu der Änderung von fhem.pl/DevIo) weil ich wissen wollte, ob es Probleme macht und von daher hatte das für mich erst mal keine praktische Relevanz mehr. _Glaube_ nicht, es ausgebaut zu haben, aber IOList bei der VCCU anzufassen nach $init_done könnte schon solche "Nebenwirkungen" (mit Absicht) verursacht haben. Wie auch immer: kommt auf meine Liste ;) .

Da ich komplett den Überblick verloren habe: ist dann noch was offen, wenn die beiden Punkte erledigt wären?



Bestimmt übersehe ich was, aber wo ist der nachgelegte "erfolglose restart"?
Mein Verständnis von modelForce: Wenn es da ist, hilft es, "model" gradezuziehen. Sobald das in model paßt, ist es nicht mehr erforderlich, stört aber auch nicht direkt (außer man ist so ein Extremist wie meinereiner, bei dem weg muss, was man nicht unbedingt braucht und was potentiell zu Mißverstänsnissen oder Fehlern führen könnte :P ...)



Mein "getimerter" Umbau aus dem letzten Post hier hat auch die letzten RT's eingefangen. Von daher würde ich die bei Vorliegen einer qualifizierten Zweitmeinung wieder zur aktuellen Patchversion erklären (vermutlich aber erst morgen Abend, falls ich dazu komme, mind. einen der obigen Punkte abzuhaken). 
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ZitatBestimmt übersehe ich was, aber wo ist der nachgelegte "erfolglose restart"?
antwort #14. da gibt es auch warnings zu sehen.
https://forum.fhem.de/index.php/topic,123257.msg1178290.html#msg1178290
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Das RAW-list hätte ich als erfolgreich gewertet:
attr Display .mId 00D3Im list sieht man die versteckten Internals etc. nicht, attr global showInternalValues dürfte nicht gesetzt sein.

Die "uninitialized" habe ich gesehen und um den passenden Code gebeten, sonst muss ich kramen, was das in welcher Fassung war; würde auf was anders tippen. Eine "unknown argument"-Warnung hätte huntsman doch ausdrücklich erwähnt, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

aber attr IODev existiert weiterhin und sowohl helper/io/vccu als auch helper/io/prefio wurden nicht gefüllt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Vorab: Die Zeilen sind identifiziert, da scheint "CUL_HM_SetList()" zu früh bzw. für ein nicht existierendes Device aufgerufen worden zu sein. Muss auf die "für später"-Liste.

Zitat von: frank am 06 Oktober 2021, 23:04:40
aber attr IODev existiert weiterhin und sowohl helper/io/vccu als auch helper/io/prefio wurden nicht gefüllt.
Jetzt "muss" erst mal IODev weg, falls "doppelt", dann geht's ggf. weiter :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#23
Zitat von: Beta-User am 07 Oktober 2021, 07:30:17
Vorab: Die Zeilen sind identifiziert, da scheint "CUL_HM_SetList()" zu früh bzw. für ein nicht existierendes Device aufgerufen worden zu sein. Muss auf die "für später"-Liste.
Zumindest ein Pflaster hat es gereicht, wobei ich unschlüssig bin, ob das eine gute Idee ist - besser wäre es, die eigentliche Ursache zu finden.

Zitat
Jetzt "muss" erst mal IODev weg, falls "doppelt", dann geht's ggf. weiter .
Das ist jetzt mit der Fassung im Anhang weg, auch wenn die Frage offen bleibt, wieso das ein Problem war. Auf meinem Testsystem wurden helper/io/vccu und helper/io/prefio nämlich auch dann gefunden, wenn beides in der cfg vorhanden war. Evtl. ist an dem System von @huntsman was anders (Perl, OS, ...).

.AttrList ist jetzt auch in den virtuellen Kanälen vorhanden, cmds/cmdList fühlt sich aber jedenfalls bei den virtuellen Channels noch nicht optimal an.

Ad:
Zitat von: frank am 07 Oktober 2021, 12:08:40
only for interest.
"none" ist wieder in der io/prefIO-Liste drin, allerdings ist mir auch unklar, wie das im weiteren Verlauf gehandhabt wird. Den vorhandenen Code würde ich deuten als: notfalls nimm irgendwas, wenn vorher nichts gefunden werden konnte... Müßte man nachfragen, ob das bewußt entfallen ist.

Betr. "restoredIO" finde ich zum einen die Abhängigkeit von einem rechtzeitigen Define des TSCUL-IO-Geräts irritierend, aber das scheint nicht anders zu gehen. Generell wundert sich der Novize, warum das alles unbedingt direkt in DefFn sein muss, aber da haben sich ein paar andere wohl schon mehr als einmal die Köpfe zerbrochen.
Die Frage, die sich m.E. in dem ganzen Zusammenhang noch stellt: Wie wäre es sei denn, man würde die initialen Inhalte wichtiger helper-(usw.-) Elemente anders wegschreiben, z.B. in ein Reading im Rahmen einer ShutdownFn?
Dann bräuchte man nicht "krampfhaft" versuchen, auch noch die Reihenfolge der Defines aufeinander abzustimmen, sondern könnte "ganz bequem" und (ganz oder teilweise) auch auf timer-Basis nach dem ersten Durchlauf dann checken, ob der letzte Zustand jeweils noch gültig wäre und ihn dann (nach und nach?) wiederherstellen (indem sich jede "Stufe" das rauspickt, was es benötigt und dann dort löscht?).

Noch unklar ist mir grade, ob z.B. das Setzen bestimmter Attribute im Rahmen von INITIALITZED dann dazu führt, dass Befehle an IO's gehen, die dazu noch nicht bereit sind. Ggf. müßte man dann ein "set_delayed"-Argument in CUL_HM_Attr() vorsehen, das das verhindert (ich denke v.a. an #255, "CUL_HM_Attr("set",$name,"IOgrp",AttrVal($name,"IOgrp","")) if ...").

Aber wie meistens: vermutlich ist das alles schon 100x überdacht und verworfen worden zugunsten besserer Ideen ::) ...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

meine virtuellen chn haben jetzt auch .AttrList
bisher keine auffälligkeiten.

ZitatEvtl. ist an dem System von @huntsman was anders (Perl, OS, ...).
er hat kein hminfo
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Zitat von: frank am 07 Oktober 2021, 15:58:35
er hat kein hminfo
Das "fehlt" in meinem Testsystem auch ;) . Tippe weiter auf was anderes.

Zitat von: frank am 07 Oktober 2021, 15:58:35
meine virtuellen chn haben jetzt auch .AttrList
bisher keine auffälligkeiten.
Puh, schon mal was!

Grade versuche ich den Patch von noansi auf 24374 auszuwerten. Wie üblich verstehe ich bei einem Teil erst mal nur "Bahnhof", aber auch da läuft einiges darauf hinaus, die wesentlichen Attribute spätestens bei INITIALIZED ausgewertet zu haben - es steht nur jetzt alles woanders...
Mit etwas Glück bekommt man damit aber die "preferedIO"-Zuweisung wieder verbessert (Rückschläge sind aber leider nicht unwahrscheinlich)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ZitatTippe weiter auf was anderes.
was, wenn huntsman nur reload gemacht hat?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

huntsman

Zitatwas, wenn huntsman nur reload gemacht hat?
Nee, hatte neu gebootet

huntsman

modelForce habe ich entfernt und da model jetzt auch in Großschrift ist läuft es weiterhin

define Display CUL_HM 6D72EC
attr Display .mId 00D3
attr Display IODev CUL_0
attr Display IOgrp vccu:CUL_0
attr Display autoReadReg 4_reqStatus
attr Display expert defReg,rawReg
attr Display firmware 1.0
attr Display model HM-DIS-WM55
attr Display msgRepeat 3
attr Display room CUL_HM
attr Display serialNr QEQ0294715
attr Display subType display
attr Display webCmd getConfig:clear msgEvents

setstate Display CMDs_done
setstate Display 2021-10-08 19:38:53 .associatedWith Display,HM_6D72EC_Dis_01,HM_6D72EC_Dis_02,HM_6D72EC_Dis_03,HM_6D72EC_Dis_04,HM_6D72EC_Dis_05,HM_6D72EC_Dis_06,HM_6D72EC_Dis_07,HM_6D72EC_Dis_08,HM_6D72EC_Dis_09,HM_6D72EC_Dis_10,Display
setstate Display 2021-10-12 13:13:49 .protLastRcv 20211012131349
setstate Display 2021-10-12 13:13:49 CommandAccepted yes
setstate Display 2021-09-21 15:42:38 D-firmware 1.0
setstate Display 2021-09-21 15:42:38 D-serialNr QEQ0294715
setstate Display 2021-10-12 13:13:47 IODev CUL_0
setstate Display 2021-10-12 13:13:48 battery ok
setstate Display 2021-10-12 13:13:49 commState CMDs_done
setstate Display 2021-10-12 13:13:49 state CMDs_done

huntsman

@Beta-User
Zitat@huntsman: Kannst du mir noch einfach die Code-Auszüge aus deiner CUL_HM-Version dazupacken? Bei mir ist schon wieder alles anders..

meinst Du das, oder hat sich das schon erledigt?
Internals:
   CMDS       BCFiAZEGMKURTVWXefmltux
   CUL_0_MSGCNT 8917
   CUL_0_TIME 2021-10-12 20:34:58
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         4
   FHTID      1034
   FUUID      615ca1b9-f33f-9964-05e3-3bc9d1b9d52becf6
   NAME       CUL_0
   NR         55
   NR_CMD_LAST_H 5
   PARTIAL   
   RAWMSG     A0C71A64150F153AFFE98017064E9
   RSSI       -85.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.58 CUL868
   devioNoSTATE 1
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2021-10-09 18:39:36   cmds             B C F i A Z E G M K U R T V W X e f m l t u x
     2021-10-12 18:42:30   raw             is00FFFFFF0FF0
     2021-10-12 20:34:58   state           Initialized
   XMIT_TIME:
     1634062023.21297
     1634063697.57771
     1634063697.67797
     1634063698.07548
     1634063698.1757
   helper:
     29CFCE:
       QUEUE:
     29CFE4:
       QUEUE:
     29CFEB:
       QUEUE:
     29CFF0:
       QUEUE:
     2D068E:
       QUEUE:
     3739E9:
       QUEUE:
     379E86:
       QUEUE:
     3BAE3B:
       QUEUE:
     50EE48:
       QUEUE:
     50F014:
       QUEUE:
     50F153:
       QUEUE:
     6D72EC:
       QUEUE:
Attributes:
   hmId       AFFE98
   rfmode     HomeMatic
   verbose    2

Beta-User

Meine Frage hatte sich erledigt. Zwischenzeitlich gibt es auch ein update im svn von Martin, das u.a. auch dieses Problem hier lösen sollte.

Bitte mach' daher ein update und teste  mit der regulären Version. Falls dann erst mal alles klappt, kannst du diesen Thread ja gerne als [gelöst] kennzeichnen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

huntsman

Habe jetzt auf die aktuelle, offizielle FHEM Version aktualisiert und es funktioniert weiterhin. Vielen Dank Euch für Eure Hilfe!! :) :)