[CUL_HM] patches Oktober 2021 - die Zweite

[frank]

ich sag erstmal entwarnung.

meine logmeldungen zum reading iodev erfolgen nur noch einmal pro device. 40% weniger, prima.
leider immer noch auch für alle ignored devices.
das muss an den attributen/iodev,iogrp liegen, denke ich.
mit einem attr ".ignored" könnte man das wahrscheinlich umgehen, da dieses das jeweils erste attr wäre. 

[Beta-User]

...wenn man die Abfrage nach dem Richtigen IsXyz() macht, kommt hoffentlich auch bei ignore was richtiges raus ... (ohne dass man weitere versteckte Attribute benötigt).

Da es bisher auch keine Prüfung auf "unnütz" bei Änderung der IOList der VCCU gab, habe ich das auch gleich noch ergänzt.

Damit sollten wir dann auch an der Stelle einen deutlichen Schritt nach vorne gekommen sein.

Danke für die Rückmeldung/Entwarnung!

Falls jemand einen diff -u zum svn Stand beisteuern könnte, würde ich gleich zu der jetzt in #1 zu findenden Version packen! Ist m.E. im Moment die deutlich beste, die wir haben...

[frank]

wo sind die zusätzlichen ignore änderungen.
cul_hm im ersten post zeigt weiterhin io zuweisung bei ignored devices

dummy bleibt auch bei restart ok

[Beta-User]

Hmm, gg. dem ersten Stand ist Zeile 263 geändert:

Code: [Auswählen]

CUL_HM_assignIO($h) if !IsDummy($name) && !IsIgnored($name);Die sollte eigentlich beim Start die ignored rausfiltern. Wenn das nicht klappt, habe ich grade keine Idee, v.a. weil es ja in der Hinsicht keine Unterschiede zwischen beiden Varianten geben sollte und dummy (weiter) greift.

Dazu #1650 (neu)

Code: [Auswählen]

next if IsDummy($HMdef) || IsIgnored($HMdef);Die greift aber nur, wenn IODev-Attr gesetzt war. Vermutlich ist dann noch eine Lücke bei irgendeiner Indirektion via VCCU. Die bekomme ich aber vermutlich (schon allein aus Zeitgründen) selbst nicht aufgelöst.

[MadMax-FHEM]

So, nachdem hier alle pm-Dateien "verschwunden" sind hab ich die aus dem ersten Post eingespielt (die HMUARTLGW aus dem verlinkten Thread ist ja schon lange im Einsatz / auf den Testsystemen habe ich ja HMOD-PCB direkt und 1x per USB).

Schon vorher, also mit den "Patches" von so vor einer guten Woche habe ich immer wieder diese Einträge:

Code: [Auswählen]

2021.10.29 17:05:39 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:44 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:49 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:54 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:59 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:04 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:09 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:14 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:19 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:24 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:29 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:34 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:39 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:44 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:49 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:54 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:59 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:04 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:09 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:14 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:19 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:24 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:29 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:34 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:39 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:44 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:49 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:54 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:59 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:04 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:09 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:14 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:19 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:24 3: HMinfo hminfo get:loadConfig :

Ob das direkt nach dem Einspielen der Patches war kann ich leider nicht sagen (müsste mal das Log analysieren).
Bislang nur auf einem der Testsysteme...

Allerdings ist auf diesem Testsystem leider (aktuell) kein Homematic Gerät angelernt/vorhanden...
Nur eben wegen Test (für den Fall, dass mein HM-USB-CFG2 mal kaputt geht) das HMOD-PCB dran.
HMINFO und vccu sind definiert...

Hier mal das list nach dem Einspielen der aktuellen Module und neustart:

Code: [Auswählen]

Internals:
   DEF        AFFE22
   FUUID      5e2de7e7-f33f-19f1-6e71-a8d8db1feaefb06d
   FVERSION   10_CUL_HM.pm:?/2021-10-29 UNSTABLE
   HM_UART_MSGCNT 96
   HM_UART_RAWMSG 0500003CEF865A3229B500000098DB38
   HM_UART_RSSI -60
   HM_UART_TIME 2021-10-29 19:15:18
   IODev      HM_UART
   LASTInputDev HM_UART
   MSGCNT     96
   NAME       vccu
   NR         154
   NTFY_ORDER 48-vccu
   STATE      HM_UART:ok
   TYPE       CUL_HM
   assignedIOs HM_UART
   chanNo     01
   disableNotifyFn 1
   READINGS:
     2021-10-29 19:06:32   IODev           HM_UART
     2021-10-29 19:06:38   IOopen          1
     2021-10-29 19:06:38   state           HM_UART:ok
     2021-10-28 10:01:57   unknown_2ACA30  received
     2021-10-27 11:02:45   unknown_2AD943  received
     2021-10-27 11:56:43   unknown_2ADD14  received
     2021-10-28 07:38:42   unknown_2ADD32  received
     2021-10-27 16:23:50   unknown_2ADEB9  received
     2021-10-29 19:13:41   unknown_2B1A82  received
     2021-10-29 19:15:10   unknown_2B8E86  received
     2021-10-29 19:13:27   unknown_2BA56B  received
     2021-10-29 19:14:41   unknown_2BBF72  received
     2021-10-29 19:10:59   unknown_2C8BFC  received
     2021-10-29 19:14:58   unknown_2D9B77  received
     2021-10-29 19:13:33   unknown_31D1FE  received
     2021-10-29 19:14:41   unknown_31D958  received
     2021-10-29 19:15:14   unknown_32185B  received
     2021-10-29 19:14:10   unknown_32279A  received
     2021-10-29 19:13:33   unknown_3227F4  received
     2021-10-29 19:15:09   unknown_322927  received
     2021-10-29 19:15:18   unknown_3229B5  received
     2021-10-28 07:46:36   unknown_48EA96  received
     2021-10-29 19:13:10   unknown_4A32A4  received
     2021-10-29 19:15:12   unknown_4A347F  received
     2021-10-29 19:14:01   unknown_4A7D5F  received
     2021-10-28 10:16:29   unknown_4A7FC7  received
     2021-10-28 10:15:47   unknown_4A8036  received
     2021-10-29 19:13:00   unknown_4AA97C  received
     2021-10-29 19:14:14   unknown_4B443D  received
     2021-10-29 19:13:05   unknown_4BDE84  received
     2021-10-28 10:04:43   unknown_524FE3  received
     2021-10-28 10:04:23   unknown_56A4B4  received
     2021-10-28 09:57:31   unknown_56A660  received
     2021-10-28 09:45:32   unknown_56B85B  received
     2021-10-28 10:07:27   unknown_577DA0  received
     2021-10-28 09:24:05   unknown_577DA1  received
     2021-10-29 19:14:22   unknown_5C29F8  received
     2021-10-27 11:56:44   unknown_614B9A  received
     2021-10-29 19:13:59   unknown_62FD74  received
     2021-10-28 08:39:00   unknown_68DFA3  received
     2020-07-23 17:08:46   unknown_697334  received
     2021-10-23 10:40:51   unknown_999999  received
     2021-10-28 10:17:43   unknown_AFFE11  received
     2021-10-29 19:13:43   unknown_AFFE33  received
   helper:
     HM_CMDNR   8
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     cmds:
       TmplKey    :no:1635527192.71655
       TmplTs     1635527192.71655
       cmdKey     1:1:1::vccu::01:
       cmdLst:
         assignHmKey noArg
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getDevInfo noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         raw        -data- [...]
         reset      noArg
         tplSet_0   -tplChan-
         unpair     noArg
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       vccu       vccu
       ioList:
         HM_UART
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOList     HM_UART
   IOgrp      vccu
   expert     defReg,rawReg
   model      CCU-FHEM
   room       System
   subType    virtual
   webCmd     virtual:update


Das andere Testsystem war bzgl. genannter Meldungen unauffällig...
...bis ich eben nach dem Einspielen der aktuellen "Patches" neu gestartet habe...

Seit dem habe ich auf dem 2ten Testsystem auch diese Meldungen

Code: [Auswählen]

2021.10.29 19:09:20 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:25 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:30 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:36 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:41 3: HMinfo hm get:loadConfig :

Auf dem System sind ein paar HM-Geräte angelernt, bin aber grad nicht sicher, ob die aktuell auch laufen...

Auch hier mal ein lst der vccu nach Einspielen und Neustart:

Code: [Auswählen]

Internals:
   DEF        AFFE33
   FUUID      5c4779b1-f33f-ff8d-8884-fa763b450bea5038
   FVERSION   10_CUL_HM.pm:?/2021-10-29 UNSTABLE
   HMUART_USB_MSGCNT 112
   HMUART_USB_RAWMSG 0500002F08865A32279A000000A4DC38
   HMUART_USB_RSSI -47
   HMUART_USB_TIME 2021-10-29 19:18:30
   IODev      HMUART_USB
   LASTInputDev HMUART_USB
   MSGCNT     112
   NAME       vccu
   NR         19
   NTFY_ORDER 48-vccu
   STATE      HMUART_USB:ok
   TYPE       CUL_HM
   assignedIOs HMUART_USB
   chanNo     01
   disableNotifyFn 1
   READINGS:
     2021-10-29 19:08:27   IODev           HMUART_USB
     2021-10-29 19:08:46   IOopen          1
     2021-10-23 14:01:19   cfgState        ok
     2021-10-29 19:08:46   state           HMUART_USB:ok
     2021-10-29 10:10:03   unknown_2ACA30  received
     2021-10-29 00:22:49   unknown_2AD943  received
     2021-10-29 00:20:56   unknown_2ADD14  received
     2021-10-29 11:19:59   unknown_2ADD32  received
     2021-10-29 16:05:57   unknown_2ADEB9  received
     2021-10-29 19:16:40   unknown_2B1A82  received
     2021-10-29 19:17:12   unknown_2B8E86  received
     2021-10-29 19:17:48   unknown_2BA56B  received
     2021-10-29 19:17:04   unknown_2BBF72  received
     2021-10-29 19:17:42   unknown_2C8BFC  received
     2021-10-29 19:17:23   unknown_2D9B77  received
     2021-10-29 19:16:28   unknown_31D1FE  received
     2021-10-29 19:17:41   unknown_31D958  received
     2021-10-29 19:17:41   unknown_32185B  received
     2021-10-29 19:18:30   unknown_32279A  received
     2021-10-29 19:16:28   unknown_3227F4  received
     2021-10-29 19:17:49   unknown_322927  received
     2021-10-29 19:17:41   unknown_3229B5  received
     2019-04-18 18:03:19   unknown_453732  received
     2021-10-29 15:14:18   unknown_48EA96  received
     2021-10-29 19:16:07   unknown_4A32A4  received
     2021-10-29 19:17:37   unknown_4A347F  received
     2021-10-29 19:16:06   unknown_4A7D5F  received
     2021-10-28 15:32:41   unknown_4A7FC7  received
     2021-10-28 15:32:38   unknown_4A8036  received
     2021-10-29 19:17:53   unknown_4AA97C  received
     2021-10-29 19:16:25   unknown_4B443D  received
     2021-10-29 19:17:38   unknown_4BDE84  received
     2019-04-18 18:03:23   unknown_4E97A4  received
     2019-10-12 12:16:48   unknown_51954D  received
     2021-10-29 19:04:48   unknown_524FE3  received
     2019-07-21 16:14:18   unknown_55F0B6  received
     2021-10-29 18:37:21   unknown_56A4B4  received
     2021-10-29 19:15:27   unknown_56A660  received
     2021-10-29 18:43:52   unknown_56B85B  received
     2021-10-29 18:25:02   unknown_577DA0  received
     2021-10-29 18:52:16   unknown_577DA1  received
     2021-10-29 19:17:04   unknown_5C29F8  received
     2019-10-03 11:11:43   unknown_5F2959  received
     2021-10-29 00:20:57   unknown_614B9A  received
     2021-10-29 19:16:09   unknown_62FD74  received
     2021-10-29 08:30:09   unknown_68DFA3  received
     2020-07-23 17:08:46   unknown_697334  received
     2019-08-07 19:31:32   unknown_69B087  received
     2019-07-14 23:24:12   unknown_69E542  received
     2019-08-07 19:32:59   unknown_6C7538  received
     2021-10-23 10:40:51   unknown_999999  received
     2021-10-29 19:15:27   unknown_AFFE11  received
     2021-10-29 19:11:35   unknown_AFFE22  received
   helper:
     HM_CMDNR   42
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     cmds:
       TmplKey    :no:1635527307.44012
       TmplTs     1635527307.44012
       cmdKey     1:1:1::vccu::01:
       cmdLst:
         assignHmKey noArg
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getDevInfo noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         raw        -data- [...]
         reset      noArg
         tplSet_0   -tplChan-
         unpair     noArg
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt    HM_69B087,HM_6C7538_Btn_01,HM_6C7538_Btn_02,HM_6C7538_Btn_03,HM_6C7538_Btn_04
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       vccu       vccu
       ioList:
         HMUART_USB
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOList     HMUART_USB
   IOgrp      vccu
   expert     defReg,allReg
   model      CCU-FHEM
   room       System
   subType    virtual
   webCmd     virtual:update

Habe jetzt auf beiden Systemen verbose bei hminfo auf 2 stehen...
...damit erst mal Ruhe ist.

Wenn noch was benötigt wird, dann einfach melden...

Ich beobachte noch ein wenig und dann spiele ich das mal ins Hauptsystem...
...und dann mal sehen

EDIT: auf dem Hauptsystem habe ich diese Einträge (noch   ) nicht. Aber da sind auch noch nicht die neuesten "Patches" drin... Aber gleich

EDIT: so nun auch auf dem Hauptsystem eingespielt, bislang alles i.O. Und hier (immer noch) keine Logeinträge von HMINFO... Auch hier mal das list der vccu.

Code: [Auswählen]

Internals:
   DEF        AFFE11
   FUUID      5c573a68-f33f-753d-dbdd-2769098533cc0e47
   IODev      hmusb
   NAME       vccu
   NOTIFYDEV  global
   NR         31
   NTFY_ORDER 48-vccu
   STATE      hmusb:ok
   TYPE       CUL_HM
   assignedIOs hmusb
   channel_01 vccu_Btn1
   READINGS:
     2021-10-29 19:30:06   IODev           hmusb
     2021-10-29 19:30:10   IOopen          1
     2021-10-23 14:09:45   cfgState        ok
     2021-10-23 10:44:10   hmPair          name:HM_614B9A SN: model:HM-SEC-RHS
     2021-10-29 19:30:10   state           hmusb:ok
     2021-10-28 12:32:05   unknown_189A3D  received
     2021-07-08 12:42:22   unknown_322598  received
     2021-10-29 18:39:21   unknown_3DA48A  received
     2020-12-03 18:11:04   unknown_4AA97C  received
     2021-07-09 11:07:20   unknown_5207F4  received
     2021-10-29 19:04:48   unknown_524FE3  received
     2021-10-23 10:41:40   unknown_614B9A  received
     2021-10-29 19:20:40   unknown_719ADF  received
     2021-10-29 19:11:35   unknown_AFFE22  received
     2021-10-29 19:13:43   unknown_AFFE33  received
     2021-10-29 18:39:22   unknown_B92AFC  received
   helper:
     HM_CMDNR   156
     mId        FFF0
     peerFriend -
     peerOpt    -:virtual
     regLst     
     rxType     1
     cmds:
       TmplKey    :no:1635528606.83408
       TmplTs     1635528606.83408
       cmdKey     0:1:1::vccu:FFF0:01:
       cmdLst:
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         tplSet_0   -tplChan-
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     io:
       vccu       vccu
       ioList:
         hmusb
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOList     hmusb
   IOgrp      vccu
   expert     defReg,allReg
   group      IO-Module
   model      CCU-FHEM
   room       System
   subType    virtual
   webCmd     virtual:update

Und wie immer: wenn ich noch was tun kann/testen soll einfach Bescheid geben...

Gruß, Joachim

[frank]

hminfo sucht wohl die datei, wo die gespeicherten konfigurationen sein müssen.
beim installieren von hm.js hast du sicher das attr zum automatischen speichern gesetzt.
attr wieder löschen, oder datei erzeugen.

 

[MadMax-FHEM]

Ok, beide Attribute gelöscht:

autoArchive
autoLoadArchive

Ok, autoLoadArchive hätte wohl gereicht...

Stand halt so in der Anleitung

Jetzt scheint Ruhe

Gruß, Joachim

[frank]

zum speichern von selbst definierten templates nötig/ratsam.
steht glaube ich dabei.

[Beta-User]

So, die "29a" läuft jetzt auch hier seit einiger Zeit im Echtsystem.

Hatte noch eine "Hardwareleiche" in der Konfiguration stehen, die bekam "ignore" verpaßt - auch die scheint kein IO mehr zugewiesen zu bekommen.

Auch der Rest läuft - soweit auf die Schnelle erkennbar - stressfrei .

Testen müßte man noch die diversen "autocreate"-Varianten, das wird mir aber zumindest heute nicht reichen (eher dieses (lange) WE gar nicht).

Martin hatte ich angepingt, mal sehen, wann er sich ggf. meldet.

[frank]

Hatte noch eine "Hardwareleiche" in der Konfiguration stehen, die bekam "ignore" verpaßt - auch die scheint kein IO mehr zugewiesen zu bekommen.

meine 12 ignored devices bekommen mit v29a alle ein io durch fhem restart zugewiesen.
11 davon vor dem einlesen von fhem.save und eins kurz danach.
die 11 besitzen die attribute IODev und IOgrp, also eigentlich falsch. das andere nur IOgrp.


ps:
es geht voran.
michael hat vorhin den 00_hmuart patch einegecheckt. 

[Pfriemler]

Ich wollte mal nur einwerfen, dass ich Euch allen hier EXTREMST dankbar bin dafür, dass Ihr den "Laden" CUL_HM so signifikat vorantreibt. Als beta-Tester wollte/konnte ich mich nicht zur Verfügung stellen, weil es bei mir noch nicht zu einem Testsystem gereicht hat und ich derzeit auf ein wartungsarmes Haupt-FHEM angewiesen bin (und meines läuft gerade so schön stabil).
Ich warte nur noch auf den Weckruf: "Jetzt lüppt's, ihr könnte bitte mal updaten!"

[fhem-challenge]

Kurz aus dem Off:

https://forum.fhem.de/index.php?topic=123771.msg1183420#msg1183420

ein Problem mit HM und mit den neuen Modulen läufts wieder.


Viele Grüße!

Andreas

[Beta-User]

meine 12 ignored devices bekommen mit v29a alle ein io durch fhem restart zugewiesen.
11 davon vor dem einlesen von fhem.save und eins kurz danach.
die 11 besitzen die attribute IODev und IOgrp, also eigentlich falsch. das andere nur IOgrp.

Muss ich mal drüber nachdenken...

Mein Testdevice habe ich erst unter 29a auf ignore gesetzt => das Reading wird in dem Fall ja gelöscht. Es hatte vorher kein IODev-Attribut mehr, nur IOGrp. Evtl. haben wir ein Übergangsproblem? Evtl. könnte man in "init" aktiv löschen (und einen Hinweis ins Log schreiben, dass da noch was nicht gepaßt hatte?)?

Falls jemand kurzfristig Zeit/Lust hätte, das zu vercoden: es ist mir recht, wenn ich auch einfach "konsumieren" und/oder mittesten darf .

@frank: Was deine Liste angeht: falls du Ideen hast, was ggf. noch mit erledigt werden könnte... (s.o.). Bin zwar die Tage kurz nochmal drübergeflogen, aber das sah' mir - bis auf die jetzt miterledigten (?) - nicht nach "nebenbei" aus (so nicht sowieso schon Teil der Vorschläge hier).

michael hat vorhin den 00_hmuart patch einegecheckt. 

Ich weiß , "jemand" hatte per pm nachgefragt, und wohl den richtigen Zeitpunkt erwischt...

https://forum.fhem.de/index.php?topic=123771.msg1183420#msg1183420

ein Problem mit HM und mit den neuen Modulen läufts wieder.

Danke für die Rückmeldung an dieser Stelle hier!
 

[Beta-User]

Zur Info: das schlechte Wetter war dazu gut, mal den CUL auf TSCUL umzustellen .

Völlig anleitungswidrig habe ich jetzt mal "nur" die firmware sowie "00_TSCUL.pm", "DevIoTS.pm" und "ReadingUtil.pm" aus der zip-file geholt. Zumindest scheint damit der CUL als IO in der VCCU eingebunden zu werden und liefert auch RSSI-Werte usw..

An sich würde mich interessieren, ob das (iVm. den aktuellen Modulfassungen) ggf. schon ausreicht für einen ordnungsgemäßen Betrieb, aber im Moment traue ich mich noch nicht, einfach mal die anderen IO's abzuschalten/aus der VCCU zu nehmen. Für einen "geht problemlos"-Erfahrungsbericht (oder eine entsprechende Äußerung eines Wissenden zur theoretischen Seite) wäre ich daher dankbar...
Wenn das nämlich ausreicht, kann man das auch einem fortgeschrittenen Anfänger noch vermitteln, der ggf. sonst Angst hat, bei jedem update wieder auf die Nase zu fallen und irgendwas wieder manuell ersetzen zu müssen .

[MadMax-FHEM]

Also ich hab mal "alte Spielzeuge" ausgepackt/reaktiviert: HM-DIS-WM55 und HM-DIS-EP

Zum einen damit ich an den/an dem Testsystem auch mal was hängen hab
Und auch um mal zu testen: anlernen...

Also folgender Test verlief wie ich es mir vorgstellt habe/vorstellen/wünschen würde:

Hauptsystem autocreate disabled
Testsystem autocreate enabled

Testsystem: set vccu hmPairForSec 60 -> Anlernen am Display

-> Device wurde im Testsystem angelegt, auf dem Hauptsystem ist nichts passiert (naja zumindest nichts was man "offensichtlich" merkt   )
Auch kein unknown_ bei der vccu des Hauptsystems...
Ok, ich hatte übersehen, dass das Display dort noch angelegt war (dachte ich hätte das schon längst rausgenommen   habe das Display bestimmt schon seit 4 Jahren oder so nicht mehr im Einsatz / wobei im Einsatz war es so richtig noch nie...)

Gut daher dann einige wilde "ATTACK-Meldungen" im Log des Hauptsystems...
Werde das Display dort mal auf "ignore" setzen...

Nach ein paar Schwierigkeiten beim Lesen aller Register ist das Device nun vollständig und funktionabel vorhanden
(die Schwierigkeiten ließen sich aber mittels Wiki lösen: attr HM-Dis-WM55 msgRepeat 3 und hartnäckig bleiben   )

Wenn ich irgendwelche speziellen Szenarios testen soll: jetzt hab ich "Spielzeug-HW"   (und vielleicht auch ab und an Zeit)

EDIT: @frank: hm.js ist echt klasse!!   Wird demnächst auch auf dem Hauptsystem einziehen

Danke noch mal, Joachim