[Geklärt] Vorteile/Nachteile und Umsetzung einer VCCU

[kvo1]

Hallo Zusammen,
obwohl hier "geklärt" steht und der Thread schn einige Wochen nicht benutzt wurde, hätte ich dennoch einige Frage in die Runde.

Leider habe ich damals beim Anlegen meines CUL die hmId nicht ganz sauer definiert , also nicht explizit nochmal angegeben.
Läuft aber seit Jahren tadellos 

Code Auswählen Erweitern

define CUL_HM CUL /dev/ttyACM0@38400 2222
attr CUL_HM addvaltrigger 1
attr CUL_HM icon usb
attr CUL_HM model CUL
attr CUL_HM rfmode HomeMatic
attr CUL_HM room System

Außerdem ist diese nicht 6-stellig , aber es wird ja automatisch F1 vorangestellt == F12222

Vermute aber mal das bei Anlegen der vCCU jetzt die hmId komplett angegeben werden muss , also so ..

d

Code Auswählen Erweitern

efine vCCU CUL_HM [b]F12222[/b]
attr vCCU IODev CUL_HM
attr vCCU IOList CUL_HM
attr vCCU model CCU-FHEM
attr vCCU room Homematic
attr vCCU subType virtual
attr vCCU webCmd virtual:update

Weiterhin möchte ich dann (u.a. zur Reichweiterverbesserung) einen HM_LAN_Adapter (eine Etage tiefer) integrieren.
Der hat (derzeit im testsystem) aber eine andere hmId !
Im Wiki haben aber der CUL und der HM_LAN_Adapter die gleiche hmId !  Ist das Zufall oder muss das so eingestellt werden ?

Macht es Sinn (z.B. Performance) bei den  Devices das Preferd IO Device zu setzen..... (steht zwar so im WIKI), wie ist Eure Erfahrung ?
Bei neue stationären Devices könnte man dann nach dem Anlernen nachsehen (IOgrp) und dann ggf. ergänzen ?

Danke für jeden Hinweis / jede Idee!

kvo1

[frank]

Außerdem ist diese nicht 6-stellig , aber es wird ja automatisch F1 vorangestellt == F12222

diese "automatische" generierung einer hmid wird durchgeführt, wenn man nicht das attribut hmId benutzt.

Im Wiki haben aber der CUL und der HM_LAN_Adapter die gleiche hmId !  Ist das Zufall oder muss das so eingestellt werden ?

die vccu stellt das automatisch ein, bei allen io's in der IOList.

Bei neue stationären Devices könnte man dann nach dem Anlernen nachsehen (IOgrp) und dann ggf. ergänzen ?

genau.

[kvo1]

Hallo Frank,
Danke für Deine Antworten.
Ja das Attribut hmid hatte ich damals (aus Unwissenheit) nicht benutzt 😔

Dennoch wäre demnach für die vCCU ......

Define vCCU CUL_HM F12222

Anzugeben ? Oder ?

[frank]

Dennoch wäre demnach für die vCCU ......

Define vCCU CUL_HM F12222

Anzugeben ? Oder ?

genau. andernfalls müsstest du neu pairen.

[Zrrronggg!]

Im Wiki haben aber der CUL und der HM_LAN_Adapter die gleiche hmId !  Ist das Zufall oder muss das so eingestellt werden ?

Es ist im Grunde schon gesagt, aber sicherheitshalber:

Alle einer VCCU zugewiesene I/Os bekommen die hmID der VCCU "übergeholfen". Wenn du an das I/O, das dann einen andere hmID  bekommen wird, schon Geräte gepairt hast, dann musst du die hinterher neu pairen.

[kvo1]

Es ist im Grunde schon gesagt, aber sicherheitshalber:

Alle einer VCCU zugewiesene I/Os bekommen die hmID der VCCU "übergeholfen". Wenn du an das I/O, das dann einen andere hmID  bekommen wird, schon Geräte gepairt hast, dann musst du die hinterher neu pairen.

Verstanden, danke 😎

[kvo1]

Hallo Zusammen,
ich habe mein System auf VCCU umgestellt , hat auch soweit alles gut funktioniert. Alle Devices sind ergänzt um ..

attr <DEVICE> IOgrp VCCU

Das IODev bleibt aber auf CUL_HM !?
bzw. wenn mann das Attribute löscht wird das nach einen reboot (oder rereadcfg) wieder so angelegt ?

Ist das okay

Jetzt habe ich aus einem Testsystem einen HMLAN-Adpater dazu definiert.

Code Auswählen Erweitern

define HMLAN1 HMLAN 192.xxx.xxx.xxx:1000
attr HMLAN1 hmId F12222
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 icon hm_lan@orange
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room OG_Arbeitszimmer


die hmId war im Testsystem 25751B , hier mal ein list

Readings:
     2016-06-11 00:59:39   D-HMIdAssigned  F11234
     2016-06-11 00:59:39   D-HMIdOriginal  25751B
     2016-06-11 00:59:39   D-firmware      0.964
     2016-06-11 00:59:39   D-serialNr      KEQ1023208
     2016-06-11 00:59:41   Xmit-Events     ok:1 disconnected:1 init:1
     2016-06-11 00:59:41   cond            ok
     2016-06-11 01:19:46   loadLvl         low
     2016-06-11 00:59:13   prot_disconnected last
     2016-06-11 00:59:13   prot_init       last
     2016-06-11 00:59:41   prot_ok         last
     2016-06-11 00:59:13   state           opened
   Helper:
     assIdCnt   0
     assIdRep   0
     info       03C4,KEQ1023208,25751B,F12222
     setTime    44726
     Cnd:
       0          1
       253        1
       255        1
     Dly:
       cnt        211
       lst        177
       max        4406
       min        5
     Ids:
     K:
       BufMin     1
       DlyMax     3.983
       Next       1465600811.23935
       Start      1465600786.23935
     Loadlvl:
       bl         40
       a:
         99
         90
         40
         0
       H:
         0          low
         40         batchLevel
         90         high
         99         suspended
     Log:
       all        0
       sys        0
       ids:
         ARRAY(0x309e7a8)
     Q:
       HMcndN     0
       answerPend 0
       hmLanQlen  1
       keepAliveRec 1
       keepAliveRpt 0
       loadLast   1
       loadNo     3
       scnt       1
       apIDs:
     Ref:
       drft       -0.000600120024004801
       hmtL       1815742
       kTs        0
       offL       1465598970505
       sysL       1465600786247
Attributes:
   hmId       F12222
   hmLanQlen  1_min
   icon       hm_lan@orange
   loadLevel  0:low,40:batchLevel,90:high,99:suspended
   room       OG_Arbeitszimmer

Leider connected sich keines der Devices mit dem HMLAN-Adapter !

ein get hm param -d IODev IOgrp zeigt für alle das gleiche Ergebnis

AZ3fachSchalter        : CUL_HM            |VCCU
    AZ_HKT                 : CUL_HM            |VCCU
    AZ_Licht               : CUL_HM            |VCCU
    AZ_Rollladen           : CUL_HM            |VCCU
    BZ_HKT                 : CUL_HM            |VCCU
    BZ_Licht_D             : CUL_HM            |VCCU
    BZ_Rollladen           : CUL_HM            |VCCU
    BZ_Sensor_THPL         : CUL_HM            |VCCU
    Brunnen                : CUL_HM            |VCCU
    EG_Tuer                : CUL_HM            |VCCU
    EZ1_HKT                : CUL_HM            |VCCU
    EZ2_HKT                : CUL_HM            |VCCU
    FL_HKT                 : CUL_HM            |VCCU
    G1_Sensor_THPL         : CUL_HM            |VCCU
    G2_Sensor_TUPL         : CUL_HM            |VCCU
    GW_HKT                 : CUL_HM            |VCCU
    GW_Rollladen           : CUL_HM            |VCCU
    KU_HKT                 : CUL_HM            |VCCU
    KU_Rollladen           : CUL_HM            |VCCU
    KZ1_HKT                : CUL_HM            |VCCU
    KZ2_HKT                : CUL_HM            |VCCU
    KZ_Rollladen           : CUL_HM            |VCCU

liegt das an der "D-HMIdOriginal  25751B"

oder habe ich hier etwas übersehen ??

Danke für jeden Hinweis 

[LuckyDay]

Zeig bitte mal ein List von deiner vccu

bevor ich jetzt dir eine Antwort schreibe zu deinen Fragen

[Benni]

Zeig bitte mal ein List von deiner vccu

bevor ich jetzt dir eine Antwort schreibe zu deinen Fragen

Ich tippe ja mal, dass der VCCU gar kein IO (der HMLAN1) zugeordnet ist.

[kvo1]

Hallo Hary,

bittschön ...

Internals:
   CUL_HM_MSGCNT 61
   CUL_HM_RAWMSG A0B4EA2403AF27725751B431E::-66.5:CUL_HM
   CUL_HM_RSSI -66.5
   CUL_HM_TIME 2016-06-11 12:03:23
   DEF        F11234
   HMLAN1_MSGCNT 1093
   HMLAN1_RAWMSG EF11234,0000,0284B9C7,FF,FFBD,128002F1123486C40D00
   HMLAN1_RSSI -67
   HMLAN1_TIME 2016-06-11 12:33:36
   IODev      CUL_HM
   LASTInputDev HMLAN1
   MSGCNT     1154
   NAME       VCCU
   NR         1532
   STATE      CUL_HM:ok,HMLAN1:ok,
   TYPE       CUL_HM
   assignedIOs CUL_HM,HMLAN1
   lastMsg    No:12 - t:02 s:F11234 d:86C40D 00
   protLastRcv 2016-06-11 12:33:36
   rssi_at_CUL_HM avg:-74.75 min:-86.5 max:-71.5 lst:-78.5 cnt:43
   rssi_at_HMLAN1 avg:-69.62 min:-83 max:-66 lst:-67 cnt:1076
   Readings:
     2016-06-11 12:33:36   CommandAccepted yes
     2016-06-11 11:31:38   recentStateType ack
     2016-06-11 05:36:33   state           CUL_HM:ok,HMLAN1:ok,
     2016-06-11 12:03:23   unknown_3AF277  received
     2016-06-11 01:37:37   unknown_999999  received
   Helper:
     HM_CMDNR   18
     PONtest    1
     mId        FFF0
     rxType     1
     Io:
       nextSend   1465641163.66484
       vccu       VCCU
       ioList:
         CUL_HM
         HMLAN1
     Mrssi:
       mNo        12
       Io:
         HMLAN1     -67
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_hm:
         avg        -74.7558139534884
         cnt        43
         lst        -78.5
         max        -71.5
         min        -86.5
       At_hmlan1:
         avg        -69.6236059479556
         cnt        1076
         lst        -67
         max        -66
         min        -83
Attributes:
   IODev      CUL_HM
   IOList     CUL_HM,HMLAN1
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     2_full
   model      CCU-FHEM
   room       OG_Arbeitszimmer
   subType    virtual
   webCmd     virtual:update

HINWEIS:
die id (F12222) aus meinem vorherigen Beiträgen hatte ich geändert , richtig ist F11234 ........!

Woran erkennt man an welchem I/O (hier CUL_HM oder LANHM1) ein Device sendet

Danke für die Hlife

Klaus

[kvo1]

könnte es erkennbar an...

Internals
LASTInputDev        HMLAN1   festzumachen sein ?

[Benni]

Was ist den CUL_HM bei dir für ein device?
Steht in der vccu ja in der IOList.

[LuckyDay]

Woran erkennt man an welchem I/O (hier CUL_HM oder LANHM1) ein Device sendet

Ein device sendet , wenn wir dein Bsp. nehmen an die Zentrale F11234, du hast 2 Empfänger Cul und Hmlan1, beide empfangen, beide geben es an fhem.pl ,
und hier werden doppelte Nachrichten Inhalte standardmäßig (0,5 Sekunden ) aussortiert !
attr global dupTimeout <sekunden>

hat erstmal garnichts mit der vccu zu tun

die vccu entscheidet aber , wenn nur am Device attr IOgrp  VCCU gesetzt ist, nach der besten rssi Empfang und sendet dann über dieses I/O

[LuckyDay]

CUL_HM ist sein Cul , hat er schlecht benannt, steht doch weiter oben in den Beiträgen

[kvo1]

CUL_HM ist sein Cul , hat er schlecht benannt, steht doch weiter oben in den Beiträgen

Ja das stimmt, hatte ich damals wirklich schlecht benannt aber funktioniert ja 

Hary, danke für die super Beschreibung. Dennoch würde ich gern wissen wollen mit welchem I/O  das jeweilige Device kommuniziert
um hier dann eine feste Zuordnung vornehmen zu können, also ....
am Device attr IOgrp  VCCU:CUL_HM  bzw. attr IOgrp  VCCU:HMLAN1! oder ist das nicht notwendig / nicht sinnvoll ?
Da ich nur feste Devices habe würde ich je Device den mit dem besten rssi Empfang eintragen. Steht ja auch so als Tipp im WIKI

"Gefühlt" ist die Reaktion einiger Devices derzeit jetzt langsamer als ohne VCCU !

Ahhhh, noch was. Ich habe bei der VCCU ein attr IODev CUL_HM..... ist das überhaupt richtig / notwendig

Gruss Klaus