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

[Otto123]

So ungefähr. 
Nur das es den HMLAN nicht mehr neu gibt 

Gruß Otto

[Benni]

Ich richte mir eine virtuelle CCU ein. Mein HMLAN geht kaputt.
Kann ich diesen dann einfach durch einen neuen ersetzen und muss nicht neu pairen!?

Um genau zu sein würde das auch ohne VCCU funktionieren. Das Ersatz-IO muss von FHEM lediglich die selbe HMId bekommen, die auch der defekte HMLAN hatte.

Nichts desto trotz ist für HM der Einsatz einer VCCU generell zu empfehlen.

[marvin78]

Dafür brauchst du nicht einmal eine VCCU. Das verwenden der gleichen HMID beim neuen HMLAN reicht. Es geht sogar jedes andere HM-IODev. Neu pairen ist nie notwendig, da pairen nur bedeutet, dass die HMID in die Devices geschrieben wird.

Edit: Natürlich mal wieder die neue Seite nicht gesehen

[crazystone]

Hallo,

nachdem ich nun genau in dieser Situation war (bestehendes HM System mit CUL_0 und 2x HMLAN, nachträgliches Einrichten der VCCU), versuche ich mal als Kochbuch die Dinge (am Ende doch viel einfacher) auf den Punkt zu bringen:

Definition der VCCU:

define myVCCU CUL_HM <alte hmID des CUL_0 vermutlich bei vielen die 0xF11034>
attr myVCCU IOList CUL_0,HMLAN_1,HMLAN_2
attr myVCCU IOgrp myVCCU
attr myVCCU model CCU-FHEM
attr myVCCU subType virtual
attr myVCCU webCmd virtual:update

Danach noch:

attr TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6} IOgrp myVCCU

und fertig. Ich sehe, das myVCCU den Status "ok" für alle IODev anzeigt. Da bei mir in der fhem.cfg das Ganze an letzter Stelle gelandet ist, habe ich das an den Anfang, direkt nach define CUL_0, define HMLAN_1, define HMLAN_2 geschoben.

Preferred IODev habe ich nicht festgelegt, gehe jetzt davon aus, dass der VCCU Dispatcher das schon ordentlich macht.

Ich habe die IODev in den Einzelgeräten unverändert gelassen, da ich gelesen habe, dass die durch die IOgrp überschrieben werden. Richtig?

Habe ich was vergessen?

Es funktioniert bei mir immer noch alles einwandfrei, allerdings hatte ich noch gehofft, dass auch die Mehrfachkommandos an alle Geräte aufhören. Da bin ich jetzt nicht sicher, ob ich das richtig prüfe. Ich sehe immer noch, dass über alle IODev (CUL_0, HMLAN_1, HMLAN_2) gesendet wird.

Vielen Dank für kurze knappe Antworten!
Viele Grüße
Thorsten

[Otto123]

Moin Thorsten,
kurz und knapp: klingt gut. Die Sache mit Mehrfachkommandos an alle Geräte verstehe ich nicht, muss ich da irgendwo anders lesen?
Gruß Otto

[LuckyDay]

Es funktioniert bei mir immer noch alles einwandfrei, allerdings hatte ich noch gehofft, dass auch die Mehrfachkommandos an alle Geräte aufhören. Da bin ich jetzt nicht sicher, ob ich das richtig prüfe. Ich sehe immer noch, dass über alle IODev (CUL_0, HMLAN_1, HMLAN_2) gesendet wird.

Vielen Dank für kurze knappe Antworten!

na wenn du Hilfe willst solltest du uns auch zeigen was du siehst, du weißt doch, dass die Glaskugel da recht trübe reagiert!

und was sind dem "Mehrfachkommandos" bei dir?

[crazystone]

Sorry, das habe ich schlecht erklärt und Danke für die schnellen Rückmeldungen!

Ich sehe, wenn ich mir z.B. die Internals von einem HM-LC-Sw1-DR anschaue

Code Auswählen Erweitern


CUL_0_RSSI                 -51.5
CUL_0_TIME                 2019-03-23 09:54:43
HMLAN_1_RSSI             -69
HMLAN_1_TIME             2019-03-23 09:54:43
HMLAN_2_RSSI             -82
HMLAN_2_TIME             2019-03-23 09:54:43
...
IODev                           CUL_0
LASTInputDev                HMLAN_2


Dem entnehme ich, dass alle 3 IODev tatsächlich das Schalt-Kommando in derselben Sekunde gesendet haben (Mehrfachkommando), wo ich erwartet hätte, dass nur das das Kommando sendet, dass beim letzten Schaltvorgang das beste RSSI hatte (VCCU Dispatcher gesteuert).

Zudem überrascht mich hier konkret noch, dass das LASTInputDev tatsächlich das mit dem schlechtesten RSSI ist.

Aber vielleicht habe ich da noch einen Gedankenfehler.

[Otto123]

Das mit dem "Mehrfachkommando" ist bei mir auch oft so, aber nicht generell.
Das LASTInputDev sagt ja bloß, dass er nur als letztes von ihm empfangen hat.
Und immerhin ist ja der mit dem Besten rssi als IODev eingetragen, ist bei mir auch so. 

Ich habe mir darüber noch nicht soviel Gedanken gemacht...

[frank]

die internals daten der gateways waren sicherlich messages vom device an die zentrale (sieht man gut an der message). wahrscheinlich sind hier nur die empfangenen messages zu sehen, bin mir aber nicht sicher.

in der vccu sind wahrscheinlich dann die von der zentrale gesendeten zu sehen.

ausserdem empfangen die nicht sendenden io auch die gesendeten messages des sendenden io. ob gesendet oder empfangen wurde lässt sich schon mal an dieser stelle gar nicht unterscheiden.

sniffe wie im wiki beschrieben und schaue dir die messages in fhem.log an.

unter get hminfo msgStat siehst du die anzahl gesendeter messages pro io. mit geschickter verteilung von prefered io aller devices, kannst du die sendenden io bestimmt schön erkennen.

[crazystone]

Hi,

also hier nochmal alle Internals, inklusive der Messages (sorry für die Formattierung).

Code Auswählen Erweitern


CUL_0_MSGCNT                          8
CUL_0_RAWMSG                         A0E2F8002656A20F110340101000034::-52:CUL_0
CUL_0_RSSI                           -52
CUL_0_TIME                           2019-03-24 09:32:06
DEF                                         656A20
HMLAN_1_MSGCNT                    8
HMLAN_1_RAWMSG                   E656A20,0000,AEB21C47,FF,FFBC,2F8002656A20F110340101000034
HMLAN_1_RSSI                         -68
HMLAN_1_TIME                         2019-03-24 09:32:06
HMLAN_2_MSGCNT                    8
HMLAN_2_RAWMSG                   E656A20,0000,050DFA75,FF,FFB2,2F8002656A20F110340101000034
HMLAN_2_RSSI                         -78
HMLAN_2_TIME                         2019-03-24 09:32:06
IODev                                      CUL_0
LASTInputDev                           HMLAN_2
MSGCNT                                   24
NAME                                       GangLichtSchalter
NOTIFYDEV                               global
NR                                           158
STATE                                      off
TYPE                                       CUL_HM
lastMsg                                   No:2F - t:02 s:656A20 d:F11034 0101000034
protLastRcv                             2019-03-24 09:32:06
protRcv                                  8 last_at:2019-03-24 09:32:06
protSnd                                  8 last_at:2019-03-24 09:32:06
protState                                CMDs_done
rssi_CUL_0                             cnt:7 min:-55 max:-52 avg:-53.14 lst:-52
rssi_at_CUL_0                        cnt:8 min:-52.5 max:-49 avg:-51.06 lst:-52
rssi_at_HMLAN_1                 cnt:8 min:-69 max:-66 avg:-67.75 lst:-68
rssi_at_HMLAN_2                 cnt:8 min:-92 max:-75 avg:-80.75 lst:-78


Wie gesagt, das sind die Internals eines Schalters, also Empfänger der Befehle.

Das mit dem "sniffe wie im wiki beschrieben": könnt ihr mir da nochmal den Link posten? Im VCCU wiki habe ich das nicht gefunden.

Im fhem.log, muss ich da noch irgendein "verbose" level aktivieren? Wonach suche ich?

"get hminfo" teste ich in Ruhe, danke dafür.

Grundsätzlich: ich muss nicht preferred IODev vergeben, um das Aussenden der Befehle über alle IODev zu reduzieren, oder? Das macht der VCCU Dispatcher dynamisch auch, oder?

[Otto123]

Moin,

https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen
Und meine Notizen

Gruß Otto