vccu nachträglich einrichten und mit vorhandenen Peerings verbinden

[raspklaus]

Hallo zusammen,

ich hatte nachträglich eine vccu eingerichtet. Nun habe ich noch einige Devices die sich direkt mit den CULs bzw HMLAN unterhalten. Diese sollen aber auch über die vccu laufen. Wie ist es möglich die Peerings umzubiegen, dass sie sauber von der vccu bedient werden ?

Ein Zuordnen des IODEV reicht anscheinend nicht, da auch durch einen Neustart keine IOGrp angelegt wird.

Muss ich die betroffenen Devices alle löschen und neu anlegen lassen ?

Danke für eure Hilfe

[LuckyDay]

Nun habe ich noch einige Devices die sich direkt mit den CULs bzw HMLAN unterhalten. Diese sollen aber auch über die vccu laufen. Wie ist es möglich die Peerings umzubiegen, dass sie sauber von der vccu bedient werden ?

Erkläre dies an einem vorhanden Beispiel deiner configuration

[Benni]

Ein Zuordnen des IODEV reicht anscheinend nicht, da auch durch einen Neustart keine IOGrp angelegt wird.

IODEV ist dafür ja auch erst mal irrelevant.
Du musst in deinen Devices die zuordnung zur vccu über IOGrp vornehmen.
Optional unter Angabe eines preferred IO.

Das hat mit peering rein gar nichts zu tun.
Ein (direktes) Peering gibt es nur zwischen Sensoren und Aktoren und nicht mit den IOs.

Was es noch gibt, sind virtuelle Aktoren, bzw. Kanäle mit denen gepeert werden kann.
Die kannst du entweder direkt über CUL_HM definieren, oder aber über die Kanäle der vccu.
Aber auch das hat primär erst mal nichts mit deiner nachträgliIchen vccu Einrichtung zu tun.

[betateilchen]

Ein (direktes) Peering gibt es nur zwischen Sensoren und Aktoren und nicht mit den IOs.

Das stimmt nicht.

[raspklaus]

Hier ein Beispiel:

Code Auswählen Erweitern

Internals:
   CUL_800HM_MSGCNT 2
   CUL_800HM_RAWMSG A0CD5844126B50D00000001D500::-63.5:CUL_800HM
   CUL_800HM_RSSI -63.5
   CUL_800HM_TIME 2016-07-10 18:21:45
   DEF        26B50D
   HMLAN1_MSGCNT 2
   HMLAN1_RAWMSG E26B50D,0000,062AE793,FF,FFAC,D5844126B50D00000001D500
   HMLAN1_RSSI -84
   HMLAN1_TIME 2016-07-10 18:21:46
   IODev      CUL_800HM
   LASTInputDev hmusb
   MSGCNT     6
   NAME       Garagentor146a_offen
   NR         354
   NTFY_ORDER 50-Garagentor146a_offen
   STATE      closed
   TYPE       CUL_HM
   hmusb_MSGCNT 2
   hmusb_RAWMSG E26B50D,0000,5D62A84D,FF,FFC6,D5844126B50D00000001D500
   hmusb_RSSI -58
   hmusb_TIME 2016-07-10 18:21:46
   lastMsg    No:D5 - t:41 s:26B50D d:000000 01D500
   protLastRcv 2016-07-10 18:21:46
   rssi_at_CUL_800HM avg:-68 min:-72.5 max:-63.5 lst:-63.5 cnt:2
   rssi_at_HMLAN1 avg:-82.5 min:-84 max:-81 lst:-84 cnt:2
   rssi_at_hmusb avg:-61 min:-64 max:-58 lst:-58 cnt:2
   Readings:
     2016-07-10 17:30:46   Activity        alive
     2015-09-02 21:39:51   D-firmware      2.4
     2015-09-02 21:39:51   D-serialNr      LEQ0138267
     2016-05-22 20:05:12   alive           yes
     2016-07-10 18:21:45   battery         ok
     2016-07-10 18:21:45   contact         closed (to broadcast)
     2016-05-22 20:05:12   powerOn         2016-05-22 20:05:11
     2016-05-22 20:05:12   recentStateType info
     2016-05-22 20:05:12   sabotageError   off
     2016-07-10 18:21:45   state           closed
     2016-07-10 18:21:45   trigger_cnt     213
   Helper:
     HM_CMDNR   213
     mId        00B1
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +26B50D,00,00,00
       nextSend   1468167706.15367
       prefIO
       rxt        2
       vccu
       p:
         26B50D
         00
         00

Unter IODev ist der CUL, sollte dann doch aber die vccu sein

[Benni]

Das stimmt nicht.

Ok! Klär mich auf!

[betateilchen]

Ok! Klär mich auf!

Darüber solltest Du mit Deinen Eltern reden 

Bei mir sind sämtliche Fernbedienungen (deren Channels) direkt mit dem Homematic USB Stick gepeert, das in meinem fhem definiert ist. Das sorgt dafür, dass ich beim Taste-Drücken eine grüne Rückmeldung bekommen und nicht nur eine orange. Was letztendlich mein fhem ausführt, wenn ich eine Fernbedienungstaste drücke, ist ein völlig anderes Thema und wird per notify bzw. Auswertungsfunktion in der 99_myUtils.pm gesteuert. Mit einem Aktor ist keine meiner Fernbedienung direkt verbunden.

[Otto123]

Bei mir sind sämtliche Fernbedienungen (deren Channels) direkt mit dem Homematic USB Stick gepeert, das in meinem fhem definiert ist.

Mag sein, dass ich bisher alles falsch verstanden habe - aber:
Der USB Stick ist doch Dein IO?
Und peering wie Du es beschreibst läuft doch über einen virtuellen Channel, oder VCCU Channel?

Gruß Otto

[betateilchen]

Bei mir gibt es keine vccu.

Jedes IO stellt selbst (und automatisch) virtuelle Kanäle bereit, um die man sich als Anwender überhaupt nicht kümmern muss (im Sinne von "man muss sie per CUL_HM definieren"). Insofern habe ich schon ein direktes peering mit meinem IO, denn genau so wird das peering auch hergestellt: direkt mit der HmId des IO ohne Angabe eines channels. Funktioniert seit Jahren völlig streßfrei.

Genau deswegen habe ich den Sinn einer vccu, wenn man nur ein einzelnes echtes IO hat, noch nie verstanden.

[Otto123]

Danke für die Erklärung, da hab ich doch wieder was gelernt 

Schönen Abend
Otto

[Benni]

Danke für die Erklärung, da hab ich doch wieder was gelernt 

Ich auch! Vielen Dank!

Darüber solltest Du mit Deinen Eltern reden 

Das ist übrigens längst erledigt!

[raspklaus]

Es ist immer wieder nett hier im Forum, dass man eine Frage stellt und dann einige solange über Ihre Meinungsverschiedenheiten diskutieren bis sich niemend mehr an die eigentliche Frage erinnern kann 

Deshalb hier meine konkrete Frage:

Ich habe die vccu angelegt:

Code Auswählen Erweitern

# Virtuelle HM CCU
define vccu CUL_HM 353143
attr vccu IODev CUL_800HM
attr vccu IOList CUL_800HM,hmusb,HMLAN1
attr vccu model CCU-FHEM
attr vccu room CUL_HM
attr vccu subType virtual
attr vccu webCmd virtual:update


Hoffentlich richtig so ? Die IODevices haben die gleiche HMID

Verschiedene HM Komponenten wurden vorher nur mit dem CUL_800HM gepaired.

Reicht es nun aus die einzelnen Devieces mit den Attributen

IODev vccu
IOGrp vccu:CUL_800HM

zu definieren ?  oder reicht die IOgrp aus und man kann IODev löschen ?

Ein Device hat sich bei mir nun schon verabschiedet und ist nicht mehr erreichbar. Muss ich wahrscheinlich neu pairen aber dann mit der vccu, oder ?

Ein list devies der vccu ergibt:

Code Auswählen Erweitern

devices using vccu
current IO / preferred
  CUL_800HM / CUL_800HM Garagentor_146
  CUL_800HM / CUL_800HM Garagentor_146a
  CUL_800HM / CUL_800HM Heizung
  CUL_800HM / CUL_800HM Wandbild
  vccu / CUL_800HM Alarmgong
  vccu / CUL_800HM BM_Bewegungsmelder_1
  vccu / CUL_800HM Garagentor146_offen
  vccu / CUL_800HM Garagentor146a_offen
  vccu / CUL_800HM Tueroeffner
  vccu / CUL_800HM Vordereingang
  vccu / CUL_800HM openDoor

Wenn alle Devices die gleichen Attribute haben verstehe ich diese Auswertung nicht.

[marvin78]

IODev nicht löschen aber ignorieren.

Man pairt nicht mit einem IODev sondern mit einer zentrale. Also: gleiche HMID verwenden und alles ist und bleibt gepairt.

lists sind im Übrigen sinnvoller als defines.

[raspklaus]

Hier das list:

Code Auswählen Erweitern

Internals:
   CUL_800HM_MSGCNT 98
   CUL_800HM_RAWMSG A0F1986102B8DD60000000A24F70C0040::-61.5:CUL_800HM
   CUL_800HM_RSSI -61.5
   CUL_800HM_TIME 2016-07-11 12:59:10
   DEF        353143
   HMLAN1_MSGCNT 37
   HMLAN1_RAWMSG E2B8DD6,0000,00261F1A,FF,FFDE,1986102B8DD60000000A24F70C0040
   HMLAN1_RSSI -34
   HMLAN1_TIME 2016-07-11 12:59:10
   IODev      CUL_800HM
   LASTInputDev hmusb
   MSGCNT     249
   NAME       vccu
   NR         72
   NTFY_ORDER 50-vccu
   STATE      CUL_800HM:ok,hmusb:ok,HMLAN1:ok,
   TYPE       CUL_HM
   assignedIOs CUL_800HM,HMLAN1,hmusb
   hmusb_MSGCNT 114
   hmusb_RAWMSG E2B8DD6,0000,6161A97D,FF,FFC0,1986102B8DD60000000A24F70C0040
   hmusb_RSSI -64
   hmusb_TIME 2016-07-11 12:59:10
   lastMsg    No:06 - t:02 s:353143 d:1DD868 00
   protLastRcv 2016-07-11 12:25:46
   rssi_at_CUL_800HM avg:-74.5 min:-74.5 max:-74.5 lst:-74.5 cnt:1
   rssi_at_HMLAN1 avg:-74.4 min:-75 max:-74 lst:-74 cnt:5
   rssi_at_hmusb avg:-70 min:-70 max:-70 lst:-70 cnt:1
   Readings:
     2016-07-11 12:25:46   CommandAccepted yes
     2016-07-02 05:45:46   recentStateType ack
     2016-07-11 12:18:28   state           CUL_800HM:ok,hmusb:ok,HMLAN1:ok,
     2015-11-18 17:13:00   unknown_091BA9  received
     2015-12-18 17:14:48   unknown_157B39  received
     2015-12-01 15:27:01   unknown_218339  received
     2015-09-27 10:57:57   unknown_23F885  received
     2015-09-20 11:02:51   unknown_24F44A  received
     2016-06-29 04:05:04   unknown_2539FB  received
     2015-11-07 16:32:27   unknown_27813A  received
     2016-06-14 17:13:50   unknown_293B79  received
     2015-10-09 15:12:29   unknown_293BF9  received
     2016-04-11 10:23:13   unknown_297331  received
     2015-12-03 18:07:04   unknown_297B19  received
     2016-07-10 07:56:07   unknown_297B39  received
     2015-11-19 17:53:56   unknown_297B79  received
     2015-12-15 00:44:13   unknown_29BE0D  received
     2015-11-11 11:18:45   unknown_29FBB9  received
     2015-12-08 09:05:35   unknown_29FBBB  received
     2016-07-11 12:59:10   unknown_2B8DD6  received
     2016-07-11 12:58:56   unknown_2BBE0D  received
     2015-09-29 20:44:49   unknown_2BBF0C  received
     2015-10-03 12:00:51   unknown_2C9918  received
     2016-02-12 00:18:18   unknown_2D7739  received
     2016-07-11 11:46:01   unknown_2DD611  received
     2016-05-28 14:36:33   unknown_2E190B  received
     2016-05-23 04:02:34   unknown_2E1974  received
     2015-09-20 11:33:42   unknown_2E198B  received
     2015-09-29 19:42:00   unknown_2EC25A  received
     2016-07-09 23:19:36   unknown_2F02C2  received
     2015-11-15 16:51:26   unknown_3051D6  received
     2015-10-10 20:08:14   unknown_3071B2  received
     2016-07-11 12:58:20   unknown_3071B6  received
     2016-04-19 16:42:37   unknown_3116EE  received
     2016-07-11 12:59:01   unknown_3133D2  received
     2016-07-11 12:58:48   unknown_31340C  received
     2016-07-11 12:57:05   unknown_31377A  received
     2016-03-31 09:32:19   unknown_3137FE  received
     2016-04-27 15:20:38   unknown_313BFC  received
     2016-07-11 12:39:56   unknown_3141C0  received
     2015-11-16 09:59:32   unknown_31C140  received
     2016-07-11 12:58:46   unknown_31DAA5  received
     2015-12-12 20:04:46   unknown_322DE3  received
     2016-05-29 15:28:59   unknown_322F44  received
     2016-03-05 13:52:10   unknown_3C9934  received
     2016-07-10 09:56:31   unknown_449330  received
     2016-02-25 09:01:37   unknown_49FBB9  received
     2016-02-11 16:49:17   unknown_6522E1  received
     2015-10-06 22:13:56   unknown_69B93B  received
     2016-07-11 12:18:15   unknown_999999  received
     2016-07-02 15:10:38   unknown_A97AB8  received
     2016-07-11 12:18:45   unknown_F10000  received
   Helper:
     HM_CMDNR   6
     mId        FFF0
     rxType     1
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       nextSend   1468232746.676
       prefIO
       vccu
       ioList:
         CUL_800HM
         hmusb
         HMLAN1
     Mrssi:
       mNo        06
       Io:
         HMLAN1     -74
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1

Also reicht dann die Angabe der beiden Attribute ?

[Otto123]

Sorry, aber Benni hatte doch eigentlich alles gesagt?

Einfach wie hier machen. Beachte besonders diesen Abschnitt

Und Du hast in der Einleitung von peerings gesprochen, das hat glaube ich alle verwirrt - Du meintest pairing?

Gruß Otto