von HMLAN auf VCCU

Begonnen von Eddy, 10 November 2017, 08:43:31

Vorheriges Thema - Nächstes Thema

Eddy

Hallo Leute,

ich habe in meinem SmartHome mittlerweile einige HomeMatic Aktoren installiert die auch funktionieren. Ich habe das direkt über HMLAN gemacht. Jetzt habe ich zwischenzeitlich oft gelesen, dass man das über eine VCCU machen soll. Also habe ich das testweise für einen neuen Fensterkontakt aufgesetzt.

Ich habe autocreate=1 und in der fhem.cfg sieht das ganze jetzt so aus:

define VCCU CUL_HM XXXXXX
attr VCCU IODev meinLGW:keepAlive
attr VCCU IOList myLGW
attr VCCU expert 2_raw
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
define HM_XXXXXX CUL_HM XXXXXX
attr HM_XXXXXX IODev meinLGW:keepAlive
attr HM_XXXXXX actCycle 002:50
attr HM_XXXXXX actStatus alive
attr HM_XXXXXX autoReadReg 4_reqStatus
attr HM_XXXXXX expert 2_raw
attr HM_XXXXXX firmware 1.0
attr HM_XXXXXX model HM-SEC-SCo
attr HM_XXXXXX room CUL_HM
attr HM_XXXXXX serialNr XXXXXXXXXX
attr HM_XXXXXX subType threeStateSensor
define FileLog_HM_XXXXXX FileLog ./log/HM_XXXXXX-%Y.log HM_XXXXXX
attr FileLog_HM_XXXXXX logtype text
attr FileLog_HM_XXXXXX room CUL_HM


Ist das so korrekt? Ich kann an dem Fensterkontakt keinen Unterschied zu anderen (HMLAN) Fensterkontakten erkennen, außer
attr HM_XXXXXX IODev meinLGW:keepAlive.

Heißt das dass dieser Fensterkontakt jetzt über die VCCU läuft? Oder woran kann man das erkennen?

Außerdem ist mir gerade folgendes aufgefallen:
attr VCCU IOList myLGW
Müsste das nicht "meinLGW" sein (so heißt mein HMLAN)?

Grüße,
Eddy

Beta-User

Hallo Eddy,

in die IOList sollten die vorhandenen Devices eingetragen werden. Es ist eher seltsam, dass der FK überhaupt angelegt wurde.
Er läuft jedenfalls nicht über die VCCU, sonst müßte dort das attr <dev> IOgrp <vccu>:<preferredIO>korrekt gesetzt sein bzw. überhaupt vorhanden.

Wenn du die VCCU "testen" willst, also erst mal die IOList korrigieren, dann an dem FK die IOgrp ergänzen (VCCU sollte genügen).
Dann sollte am Gerät nach einem Senden ein "(to VCCU)" zu sehen sein.

Wenn das paßt, kannst du das attr direkt mit einem einzigen Befehl für alle CUL_HM-Devices ausrollen. Als Denkanstoß dazu: list TYPE=CUL_HM

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

Hi Eddi,

hier ist alles beschrieben -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
myLGW hat der Pumuckel in deine DEF geschrieben?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Eddy

ZitatmyLGW hat der Pumuckel in deine DEF geschrieben?

Vermutlich nicht. Das muss eher in geistiger Abwesenheit passiert sein. Danke für den Hinweis  :o

Otto123

Es ist übrigens einfach alles auf eine VCCU umzuziehen - man muss nichts neu machen. Wenn Du nicht klar kommst dann fragen :)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Eddy

Zitat von: Beta-User am 10 November 2017, 09:21:11
Wenn du die VCCU "testen" willst, also erst mal die IOList korrigieren, dann an dem FK die IOgrp ergänzen (VCCU sollte genügen).
Dann sollte am Gerät nach einem Senden ein "(to VCCU)" zu sehen sein.

So, jetzt konnte ich das testen. Ich habe einen neuen FK angelernt. Das hat jetzt super geklappt. Jetzt steht das auch "to VCCU". Allerdings habe ich auch versucht einen vorhandenen FK mit der VCCU zu koppeln. Dazu bin ich folgendermaßen vorgegangen.
attr HM_XXXXXX IOgrp VCCU:meinLGW

Ich bekomme im LOG- File allerdings immer noch den Zusatz "to brodcast". Es scheint hier also nicht geklappt zu haben.

define Tuer_Wohnzimmer_Wintergarten_EG CUL_HM XXXXXX
attr Tuer_Wohnzimmer_Wintergarten_EG IODev meinLGW
attr Tuer_Wohnzimmer_Wintergarten_EG IOgrp VCCU:meinLGW
attr Tuer_Wohnzimmer_Wintergarten_EG actCycle 028:00
attr Tuer_Wohnzimmer_Wintergarten_EG actStatus alive
attr Tuer_Wohnzimmer_Wintergarten_EG autoReadReg 4_reqStatus
attr Tuer_Wohnzimmer_Wintergarten_EG expert 2_raw
attr Tuer_Wohnzimmer_Wintergarten_EG firmware 2.4
attr Tuer_Wohnzimmer_Wintergarten_EG model HM-SEC-SC-2
attr Tuer_Wohnzimmer_Wintergarten_EG room EG_Wohnzimmer
attr Tuer_Wohnzimmer_Wintergarten_EG serialNr XXXXXXXXXXX
attr Tuer_Wohnzimmer_Wintergarten_EG subType threeStateSensor


Hat jemand eine Idee woran das noch liegen kann? Würde ungern alle Autoren neu anlernen.

Otto123

mach mal ein list Tuer_Wohnzimmer_Wintergarten_EG

Ich glaube der Eintrag to broadcast ist nicht ungewöhnlich.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Eddy


Internals:
   DEF        XXXXXX
   IODev      meinLGW
   LASTInputDev meinLGW
   MSGCNT     10
   NAME       Tuer_Wohnzimmer_Wintergarten_EG
   NOTIFYDEV  global
   NR         70
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:14 - t:41 s:559BB8 d:000000 010D00
   meinLGW_MSGCNT 10
   meinLGW_RAWMSG 0500003B148441559BB8000000010D00
   meinLGW_RSSI -59
   meinLGW_TIME 2017-11-10 20:30:04
   protCmdPend 3 CMDs_pending
   protLastRcv 2017-11-10 20:30:04
   protState  CMDs_pending
   rssi_at_meinLGW avg:-59.3 max:-56 cnt:10 lst:-59 min:-63
   Readings:
     2017-11-10 15:38:26   Activity        alive
     2017-11-02 21:45:04   D-firmware      2.4
     2017-11-02 21:45:04   D-serialNr      XXXXXXXXXX
     2017-11-02 22:33:23   alive           yes
     2017-11-10 20:30:04   battery         ok
     2017-11-10 20:30:04   contact         closed (to broadcast)
     2017-11-02 22:33:23   recentStateType info
     2017-11-02 22:33:23   sabotageError   on
     2017-11-10 20:30:04   state           closed
     2017-11-10 20:30:04   trigger_cnt     13
   cmdStack:
     ++A001123123559BB800040000000000
     ++A001123123559BB801040000000001
     ++A001123123559BB80103
   Helper:
     HM_CMDNR   20
     getCfgList all
     getCfgListNo ,4
     mId        00B1
     rxType     28
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +559BB8,02,00,00
       nextSend   1510342204.38209
       rxt        2
       vccu       VCCU
       p:
         559BB8
         00
         00
         00
       prefIO:
         meinLGW
     Mrssi:
       mNo        14
       Io:
         meinLGW    -57
     Prt:
       bErr       0
       sProc      2
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_meinlgw:
         avg        -59.3
         cnt        10
         lst        -59
         max        -56
         min        -63
Attributes:
   IODev      meinLGW
   IOgrp      VCCU:meinLGW
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.4
   model      HM-SEC-SC-2
   room       EG_Wohnzimmer
   serialNr   XXXXXXXXXX
   subType    threeStateSensor

Otto123

Der ist nicht gepairt. FHEM kennt ihn zwar und Du siehst  den Status.

protCmdPend 3 CMDs_pending  die musst Du abarbeiten.
Configtaster drücken ohne den Sensor auszulösen, notfalls mehrfach mit Pausen!
Zeit nehmen! Nicht sinnlos reset machen!
Pairing wiederholen.
eventuell msgEvents löschen und wiederholen.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Eddy

Vielen Dank für den Hinweis. Ich habe mittlerweile alle Geräte gelöscht und neu angelernt. Jetzt sieht alles sauber aus.

Ich denke das sollte jetzt so alles passen.