virtual CCU (Homematic)

[Bennemannc]

Hallo,

ich habe zwischendurch immer mal wieder den Thread der vccu mitgelesen. Was ich noch nicht so wirklich verstanden habe ist ...
Wofür kann / soll man eine vccu definieren ? Wo sind die Vorteile oder wofür ist die vccu gut ?
Ich setze derzeit nur HM Produkte ein und arbeite (noch) ohne vccu.
Über die vccu ist in der Commanref nicht viel zu finden. Dort taucht sie nur in Zusammenhang mit den IOGrp auf. Im Wiki habe ich auch nichts darüber gefunden. Gibt es irgendwo eine Doku über die vccu ?

Gruß Christoph

[martinp876]

Hallo Christoph,

Fange ich einmal an mit dem Teil Systematik: Diesem muss man nicht folgen - und werden auch nicht alle. Dennoch
- eigentlich hat man eine Zentrale und mehrere IOs. Man kann auch mehrere Zentrale ein oder mehreren IOs haben. In FHEM war dies nicht gegeben - jedenfalls nicht explizit.
- HMIDs werden eigentlich in CUL_HM verwaltet - LEIDER werden sie aber auch in den IOs gesetzt - manchmal sogar implizit. Das macht das handling unschön und unsauber
- zusammenhänge zwischen mehreren IOs sind nicht zu sehen - auch keine Fehler (tipfehler in der HMId...)
- eine Zentrale kann nach HM 50 virtuelle Buttons simulieren. Wenn man mehrere IOs hat - mit gleicher oder gemischter HMId rächt sich die Unsauberheit schon wieder - man kann die Namen schlecht auflösen (welchen IO?) schlecht peeren und auch weitere Kommandos machen Probleme.

=> schon aus den Gründen einer "korrekten" und sauberen Installation würde ich immer eine vccu erstellen.

So - zu den handfesten Anwendungen
Virtuelle Buttons der Zentrale
Du kannst bis zu 50 Buttons der vccu anlegen, peeren und verwalten. Ohne die vccu ist die Verwaltung, trigger und logging kaum sinnvoll möglich
multi IO
Wenn du mehrere IOs betreibst macht ein Ersatzschalten sinn. Aktuell wird unterstützt, dass einer vccu manuell einige IO devices zugeordnet werden. Jedem HM-device kannst du dann der vccu zuordnen - und diese wird dann das passende IO aussuchen. Du kannst ein preferred IO eingeben (macht sinn). Sollte dies ausfallen wird das nächste operationale gesucht - und zwar das mit dem besten Empfangspegel (repeater werden berücksichtigt). Auch ein HMLAN in overload kann somit ersatzgeschaltet werden.

Labling der Messages

In einigen Readings werden quell oder Ziel devices namentlich aufgelöst. Der Namen eines IO devices ist insbesondere wenn man mehrere hat nicht korrekt. Hat man die vccu definiert wird diese eingetragen. Das vermeidet ggf. doppelte readings.

[betateilchen]

@martin: ist eigentlich die peerList bei einem virtuellen Button der vccu in ihrem Umfang begrenzt oder kann man beliebig viele peers auf einen einzelnen Button peeren?

[martinp876]

Ich habe keine Grenze eingebaut -die Liste kann endlos sein. Das gilt auch für virtuelle Aktoren/buttons.
Ob man irgendwann an timig-grenzen stösst hängt sicher auch davon ab, was für Aktionen man ausführen will.

[betateilchen]

Ich will den virtuellen Button nie benutzen, mir geht es nur darum, Fernbedienungsbuttons mit irgendwas zu peeren, damit ich eine grüne Rückmeldung bekomme. Insofern erwarte ich da keine Timingprobleme.

[martinp876]

Dass du keine virtuellen Aktoren nutzt ist mir klar - der Hinweis war für die Mitleser und zur Vollständigkeit.
Die PeerListen müssen auch bei VCCU durchsucht werden. Hat man eine CUL, muss CUL_HM das Ack senden.
Es kostet also dennoch Zeit.  Ich habe aber nie gemessen. Da du aber evtl von wirklich größen Listen redest (so habe ich es verstanden) habe ich es erwähnt.
Eine VCCU kann 50 Kanäle (von HM abgeschrieben). ggf könnte man aufteilen - aber wahrscheinlich nicht notwendig.

[betateilchen]

Da du aber evtl von wirklich größen Listen redest

aktuell: 4 * 4 + 1 * 8 + 1 * 6 = 30

[martinp876]

habe es einmal durchgesehen - ich denke, der Code ist robust genug um auch 300 IDs zu verkraften

[Jojo11]

Hallo,

ich habe jetzt auch mal eine VCCU eingerichtet, da es ja beim Einsatz mehrere IOs empfohlen wird. Ich betreibe einen HMLAN, der eigentlich auch alle HM-Geräte erreicht. Zusätzlich habe ich jetzt einen HM-CFG-USB2 in Betrieb genommen, der aber nur bei 3-4 HM-Devices eine bessere Empfangs-/Sendeleistung hat.
Ist es richtig, die HMid bei allen drei devices zu setzen (VCCU, HMLAN, HMUSB)?
Bei der VCCU habe ich folgendes definiert:

Code Auswählen Erweitern


attr vccu IOList HMLAN1,HMUSB1
attr vccu IODev HMLAN1

Bei den Geräten habe ich folgenden code eingefügt:

Code Auswählen Erweitern


attr wzR IODev HMLAN1
attr wzR IOgrp vccu


Wenn ich das richtig verstanden habe, ist HMLAN1 jetzt das bevorzugte IO-Device. Kann ich irgendwo sehen, ob der HMUSB auch mal eingesetzt wird? Es funktioniert hier zwar alles, aber so ganz ist mir nicht ersichtlich, ob der USB-Adapter überhaupt zum Einsatz kommt.
Danke!

schöne Grüße
Jo

[martinp876]

Hi Jo

Ist es richtig, die HMid bei allen drei devices zu setzen (VCCU, HMLAN, HMUSB)?

das macht die vccu automatisch, wenn du das IO ihr zuweist, was mit attr vccu IOList HMLAN1,HMUSB1 passiert ist.

IODev bei der vccu ist egal, an die senden wir nicht
IODev bei den Devices ist "variable", da das IO device (besser das O-Device, also sende-device) durch die vccu festgelegt wird. Das hast du erreicht mit attr wzR IOgrp vccu.

Wenn ich das richtig verstanden habe, ist HMLAN1 jetzt das bevorzugte IO-Device.

nein.
wenn IOgrp gesetzt ist, wird IODev von der vccu automatisch geändert. Eigentlich sollte es nicht zu sehen sein, ich kann es aber nicht löschen, da es vom Kernal genutzt wird.
Also: wenn attr IOgrp gesetzt ist, wird IODev zum "Reading": es wird kontinuierlich "geprüft"

ein default bekommst du mit
attr wz IOgrp vccu:HMLAN1

Kann ich irgendwo sehen, ob der HMUSB auch mal eingesetzt wird?

ja, das attribut IODev zeigt nun an, über welches IO das letzte mal gesendet wurde.

Code Auswählen Erweitern

get vccu listDevice
zeigt die devices, die das IO von der vccu bestimmen lassen. ausserdem das preffered und das last (current) io

Es funktioniert hier zwar alles, aber so ganz ist mir nicht ersichtlich, ob der USB-Adapter überhaupt zum Einsatz kommt.

in deinem Fall (ohne prefered IO) wird das IO mit dem besten RSSI gesucht.
Du kannst einfach einmal das HMLAN abschalten (dauert bis zu 30sec, bis FHEM es merkt) und dann etwas senden. Jetzt sollten alle das USB device nutzen (hoffentlich auch erreichbar, versucht wird es jedenfalls)

Gruss Martin

[Jojo11]

Super, danke. ListDevice war schon sehr aufschlussreich. Jetzt steht dem Einsatz von noch mehr HMLANs nichts mehr im Weg

schöne Grüße
Jo

[strauch]

@martin
Hat die vccu auch folgenden Effekt?

Ich habe einiges an Aktoren um Licht an und auszuschalten. Wenn ich Abends den "ich geh schlafen"-Knopf drücke, dann gehen die Lichter der reihe nach aus. Habe ich die Aktoren mit einer HM-Fernbedienung gepeert dann gehen alle Lampen gleichzeitig aus. Peere ich nun die Lampen alle mit der vccu gehen dann auch alle gleichzeitig aus wenn ich von FHEM aus sende?

[martinp876]

sie gehen der reihe nach aus. Aber du kannst das ändern.

Wenn du mit einer FB einen trigger sendest wird eine message gesendet und alle reagieren auf diese. Die FB fragt danach noch alle einzeln ab, ob sie es verstanden haben.

Sendest du "off" an mehrere Lampen werden die messages der reihen nach gesendet - wie schnell das geht könnte man testen und evtl. optimieren.

Wenn du eine Verzögerung bei der FB willt kannst du dies in jeder Lampe individuell programmieren (delayOff Zeit setzen, wenn der trigger dieser FB kommt). das geht dann sehr präuize.

Das verhalten einer FB kannst du auch in der Zentrale nachbauen. Du erstellst einen Kanal der vccu (oder ein virtuelles Device) und peerst diesen mit den Aktoren - wie du es mit der FB gemacht hast. Dann kannst du von Kanal ein "press" short oder long ausführen. Es passiert das gleiche, wie bei einer FB, also alles gleichzeitig - oder eben verzögert wie eingestellt.