HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

[The-Holgi]

Hallo,
Modul ist installiert und funktioniert soweit, wenn ich den HMLAN vom Netzt trenne kann ich weiterhin alles schalten.
Habe es in die vccu zusammen mit meinem HMLAN eingetragen. Unter State in der vccu steht allerdings:

Code Auswählen Erweitern

myHmUART:UAS,HMLAN1:ok
Was hat das "UAS" zu bedeuten?
Hier mal ein list vom HM-MOD:

Code Auswählen Erweitern

Internals:
   AssignedPeerCnt 2
   CNT        120
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     120
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         38
   LastOpen   1516981240.33798
   NAME       myHmUART
   NR         398
   PARTIAL   
   RAWMSG     040200
   RSSI       -44
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      29A0F1
   Helper:
     CreditTimer 13
     FW         66561
     Initialized 1
     AckPending:
     DBLOG:
       D-HMIdAssigned:
         myDbLog:
           TIME       1516981245.38515
           VALUE      29A0F1
       D-HMIdOriginal:
         myDbLog:
           TIME       1516981245.41387
           VALUE      59D76C
       D-firmware:
         myDbLog:
           TIME       1516981245.44747
           VALUE      1.4.1
       D-serialNr:
         myDbLog:
           TIME       1516981245.48148
           VALUE      OEQ0606802
       cond:
         myDbLog:
           TIME       1516981245.54306
           VALUE      ok
       loadLvl:
         myDbLog:
           TIME       1516981245.54306
           VALUE      low
     LastSendLen:
       3
       3
     Log:
       IDs:
     PeerQueue:
     RoundTrip:
       Delay      0.00302481651306152
     loadLvl:
       lastHistory 1516981245.51295
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     19082D     +19082D,00,00,00
     5F8845     +5F8845,00,00,00
   READINGS:
     2018-01-26 16:40:45   D-HMIdAssigned  29A0F1
     2018-01-26 16:40:45   D-HMIdOriginal  59D76C
     2018-01-26 16:40:45   D-firmware      1.4.1
     2018-01-26 16:40:45   D-serialNr      OEQ0606802
     2018-01-26 16:40:40   D-type          HM-MOD-UART
     2018-01-26 16:40:45   cond            ok
     2018-01-26 16:40:45   load            0
     2018-01-26 16:40:45   loadLvl         low
     2018-01-26 16:40:40   state           opened
   helper:
Attributes:
   hmId       29A0F1
   room       CUL_HM

.und von der vccu:

Code Auswählen Erweitern

Internals:
   DEF        29A0F1
   HMLAN1_MSGCNT 3
   HMLAN1_RAWMSG E29A0F1,0000,0002B5E0,FF,FFCC,97800229A0F116FC8800
   HMLAN1_RSSI -52
   HMLAN1_TIME 2018-01-26 16:42:56
   IODev      HMLAN1
   LASTInputDev myHmUART
   MSGCNT     21
   NAME       vccu
   NOTIFYDEV  global
   NR         200
   NTFY_ORDER 50-vccu
   STATE      myHmUART:UAS,HMLAN1:ok,
   TYPE       CUL_HM
   assignedIOs HMLAN1,myHmUART
   channel_01 vccu_Btn1
   channel_02 vccu_Btn2
   channel_03 vccu_Btn3
   channel_04 vccu_Btn4
   channel_05 vccu_Btn5
   channel_06 vccu_Btn6
   channel_07 vccu_Btn7
   channel_08 vccu_Btn8
   channel_09 vccu_Btn9
   channel_0A vccu_Btn10
   channel_0B vccu_Btn11
   channel_0C vccu_Btn12
   lastMsg    No:A7 - t:02 s:29A0F1 d:339D5D 00
   myHmUART_MSGCNT 18
   myHmUART_RAWMSG 0500002FA7800229A0F1339D5D00
   myHmUART_RSSI -47
   myHmUART_TIME 2018-01-26 16:44:06
   protLastRcv 2018-01-26 16:44:06
   rssi_at_HMLAN1 max:-52 avg:-52 lst:-52 cnt:3 min:-52
   rssi_at_myHmUART cnt:18 lst:-47 max:-46 avg:-46.05 min:-47
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1516981243.96915
           VALUE      myHmUART:UAS,HMLAN1:ok,
   READINGS:
     2018-01-26 16:44:06   CommandAccepted yes
     2018-01-26 16:40:43   state           myHmUART:UAS,HMLAN1:ok,
   helper:
     HM_CMDNR   167
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1516981446.41459
       prefIO     
       vccu       
       ioList:
         HMLAN1
     mRssi:
       mNo        A7
       io:
         myHmUART   -47
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_HMLAN1:
         avg        -52
         cnt        3
         lst        -52
         max        -52
         min        -52
       at_myHmUART:
         avg        -46.0555555555556
         cnt        18
         lst        -47
         max        -46
         min        -47
     tmpl:
Attributes:
   IODev      HMLAN1
   IOList     HMLAN1,myHMUART
   expert     2_full
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update

Hoffe jemand kann mir weiter helfen.

Gruß Holgi

[Otto123]

Fällt Dir was auf!?
STATE      myHmUART:UAS,HMLAN1:ok,
IOList     HMLAN1,myHMUART

Was hat das "UAS" zu bedeuten?

Heisst wohl: unassigend

Gruß Otto

[The-Holgi]

Au nein! Ich trottel, danke für den Hinweis.

Noch eine Frage: Habe in allen devices als IOgrp vccu angegeben, wenn ich es richtig verstanden habe regelt die vccu so selbst, welches io Gerät benutzt wird abhängig
von der Signalstärke, oder?

Gruß Holgi

[Otto123]

so sollte es sein 

[cseuss]

Hallo Freunde,

ich habe bis dato einen HM-CFG-LAN LAN Konfigurations-Adapter unter FHEM auf einem PI im Einsatz.

Ich möchte mir gerne eine Redundanz/Ausfall-Sicherheit schaffen. Statt nun einen zweiten HM-CFG-LAN LAN Konfigurations-Adapter zum Einsatz zu bringen, denke ich darüber nach, nun statt dessen das "neue" HM-LGW-O-TW-W-EU Funk-LAN Gateway einzusetzen.

Meine Frage nun:

Kann ich statt zwei HM-CFG-LAN LAN Konfigurations-Adapter parallel auch einen HM-CFG-LAN LAN Konfigurations-Adapter und ein HM-LGW-O-TW-W-EU Funk-LAN Gateway einsetzen, so dass alle Homematic-Komponenten von beiden Gateways angesprochen werden?
Mit zwei HM-CFG-LAN LAN geht das ja wohl.

Ich würde mich über eine Rückmeldung sehr freuen.

Vielen Dank und Gruß

Christian

[Otto123]

Hallo Christian,

das geht, Du brauchst eine VCCU.
Welche konkreten HM IOs Du darin gruppierst ist egal.

Gruß Otto

[cseuss]

Hallo Otto,
danke für die schnelle Rückmeldung.

Bis dato habe ich eine VCCU im Einsatz um herrenlose Komponenten, die per autocreate erkannt werden und nicht auf meinem Gebäude stammen, dort "zu sammeln".
Dazu läuft die VCCU bis jetzt unter der ID des HMLANs.

Dann muss ich das umbauen und dem VCCU eine eigene ID geben oder nur noch die ID des HMLANs, damit das Pairing der Komponenten weiter klappt.
Den HMLAN hänge ich dann unter die VCCU mit neuer ID?

Gruß

Christian

[Otto123]

NEIN!
Du musst nichts umbauen.

Dazu läuft die VCCU bis jetzt unter der ID des HMLANs.

Mag sein, dass Du das so siehst, es ist aber genau anders herum.
Die VCCU gibt die ID (auch wenn die mal dem HMLAN gehörte) an alle unter ihr gruppierten IOs.

Alles gut so, es muss so sein. Du musst Deine ID behalten sonst müsstest Du alles neu machen.

Gruß Otto

[cseuss]

ok, hört sich gut an.

Bis jetzt sieht meine VCCU-Config so aus:

Code Auswählen Erweitern

defmod vccu CUL_HM 37A0AF
attr vccu IODev HMLAN1
attr vccu IOList HMLAN1
attr vccu model CCU-FHEM
attr vccu room Zentral
attr vccu subType virtual
attr vccu webCmd virtual:update

setstate vccu HMLAN1:ok,
setstate vccu 2018-03-11 13:41:32 state HMLAN1:ok,
setstate vccu 2018-03-13 19:11:21 unknown_24E293 received
setstate vccu 2018-03-13 19:11:07 unknown_4C59A6 received
setstate vccu 2018-03-13 19:11:07 unknown_4C5A27 received
setstate vccu 2018-03-11 14:09:07 unknown_597E7B received
setstate vccu 2018-03-12 19:44:51 unknown_5BC6B1 received
setstate vccu 2018-03-11 14:12:35 unknown_6464D0 received


37A0AF ist die ID des HMLAN.

Die "unknown"-Einträge fangen ja bewusst die unbekannten Komponenten aus dem autocreate ab, die nicht mir "gehören".

und hier die Definition des HMLANs:

Code Auswählen Erweitern


defmod HMLAN1 HMLAN 192.168.10.66:1000
attr HMLAN1 hmId 37A0AF
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room Zentral

setstate HMLAN1 opened
setstate HMLAN1 2018-01-30 09:04:33 D-HMIdAssigned 37A0AF
setstate HMLAN1 2018-01-30 09:04:33 D-HMIdOriginal 37A0AF
setstate HMLAN1 2018-01-30 09:04:33 D-firmware 0.964
setstate HMLAN1 2018-01-30 09:04:33 D-serialNr MEQxyzxyz
setstate HMLAN1 2018-03-11 13:41:32 Xmit-Events disconnected:12 ok:12 Warning-HighLoad:1 init:11 
setstate HMLAN1 2018-03-11 13:41:32 cond ok
setstate HMLAN1 2018-03-14 16:01:49 loadLvl low
setstate HMLAN1 2018-03-11 13:41:21 prot_Warning-HighLoad last
setstate HMLAN1 2018-03-09 09:05:12 prot_disconnected last
setstate HMLAN1 2018-03-09 09:05:12 prot_init last
setstate HMLAN1 2018-03-05 16:45:30 prot_keepAlive last
setstate HMLAN1 2018-03-11 13:41:32 prot_ok last
setstate HMLAN1 2017-03-11 10:37:24 prot_timeout last
setstate HMLAN1 2018-03-09 09:05:12 state opened


Ist das dann soweit richtig?

Wenn ich mein neues Gateway habe, richte ich das mit der alten ID erst mal selbst ein und hänge es dann in der VCCU-Definition an die IO-Liste.
Also überall (VCCU, HMLAN und HMLAN<Neu>) wir die gleiche ID eingesetzt?!

Gruß

Christian

[Otto123]

Du richtest das neue Gateway ein, HMId brauchst Du gar nicht, macht später die VCCU
Du änderst in der VCCU das attr IOList
Das war es, alles andere sollte automatisch passieren.

Das attr IOgrp bei deinen HM Komponenten hast Du schon gesetzt?

Gruß Otto

[cseuss]

hier einmal ein Auszug:

Code Auswählen Erweitern

attr Ku.Fenster.Contact.Links IODev HMLAN1
attr Ku.Fenster.Contact.Links IOgrp vccu:HMLAN1

wobei

Code Auswählen Erweitern

attr Ku.Fenster.Contact.Links IOgrp vccu:HMLAN1

anscheinend nicht überall gesetzt ist.

Das geschah wohl stellenweise "automatisch"....

[LuckyDay]

@cseuss

Code Auswählen Erweitern

setstate HMLAN1 2018-01-30 09:04:33 D-firmware 0.964

mach mal dringend ein Update des Hmlans auf 0.965

sonst rebootet er bei Empfang von HMIP Messages , die Firmware gibts bestimmt schon seit 2,5 Jahren !

[cseuss]

Hallo,

Ok. Firmware-Update auf dem HLAN ist eingespielt.

Könnt Ihr noch auf den Beitrag #205 eingehen?
Muss ich das Attribut dann noch bei allen Komponenten setzen?

Danke für Eure Rückmeldung.
Gruß
Christian

[Otto123]

Hallo Christian,

naja stand doch im Prinzip in #204

IOgrp vccu sollte überall gesetzt sein. mit deinem Zusatz :HMLAN1 wäre der dann bevorzugt.

Das attr wird von der VCCU automatisch gesetzt wenn das Gerät mit  der VCCU gepairt wird.
Für alle Alten musst Du es setze.
Damit würde es automatisch gehen:

Code Auswählen Erweitern

attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCU
Aber das würde Deine gesetzten mit bevorzugtem IO überschreiben!
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#IOgrp_bei_nachtr.C3.A4glicher_Einrichtung_einer_VCCU

Gruß Otto

[cseuss]

Danke für die Rückmeldung.

Nun ist mein neues LAN-Gateway heute angekommen und ich habe nun die nachfolgende Config:

Code Auswählen Erweitern

define HMLAN1 HMLAN 192.168.10.66:1000
attr HMLAN1 hmId 37A0AF
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 loadLevel 0:low,40:batchLevel,90:high,99:suspended
attr HMLAN1 room Zentral

define HMLANGWOG HMUARTLGW 192.168.10.36
attr HMLANGWOG hmId 37A0AF
attr HMLANGWOG lgwPw def6h+wS7S
attr HMLANGWOG room Zentral

define VCCU CUL_HM 37A0AF
attr VCCU IODev HMLAN1
attr VCCU IOList HMLAN1,HMLANGWOG
attr VCCU model CCU-FHEM
attr VCCU room Zentral
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Danach kommen die HM-Devices:
Beispiel:

Code Auswählen Erweitern

define Bd.Heizung.Wand CUL_HM 3098E2
attr Bd.Heizung.Wand IODev HMLAN1
attr Bd.Heizung.Wand IOgrp VCCU

Passt das jetzt so?

Ist es richtig, dass die HM-Devices und die VCCU das Attribut:  "IODev HMLAN1" haben?

Vielen Dank für Eure Unterstützung.

Gruß

Christian