Hallo
Beim Einbinden eines HMLAN bin ich bezüglich VCCU etwas verunsichert. In http://www.fhemwiki.de/wiki/Homematic-fhem.cfg-Neuinstallation steht (http://www.fhemwiki.de/wiki/Homematic-fhem.cfg-Neuinstallation%20steht)
ZitatDa eine Homematic-fhem-Installation immer eine VCCU nutzen sollte, wird keine Zentralen-ID (hmId) spezifiert.
.
In http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen (http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen) steht jedoch
ZitatEs ist daher dringen zu empfehlen, die HMID vor dem Pairing der HM-Geräte mit: attr <CUL> hmId <6-stellige Hexadresse> zu individualisieren.
.
Ist es wirklich sinnvoll für einen Anfänger eine VCCU zu verwenden ?
Danke
Jürgen
Zitat von: jove01 am 06 März 2015, 02:44:21
Ist es wirklich sinnvoll für einen Anfänger eine VCCU zu verwenden ?
Ja, so kompliziert ist es ja auch gar nicht :) !
Du vergibst einfach für deinen HMLAN und die VCCU ein und die selbe HMID und gut.
Wenn du nun später einen zweiten HMLAN, zwecks Ausfallsicherheit, Sendekapazitätserweiterung oder zur Reichweitenerhöhung hinzufügen willst, bekommt der i.d.R. auch genau diese HMID. So sind immer alle HM-Geräte mit der selben HMID (über die zentrale VCCU) gepairt und nicht nur mit einem bestimmten IO (HMLAN).
Wie gesagt, das Pairing sollte dann über die VCCU stattfinden und nicht über das HMLAN-Device. Der Vorgang an sich ist aber identisch.
Gruß Benni.
ZitatWie gesagt, das Pairing sollte dann über die VCCU stattfinden und nicht über das HMLAN-Device. Der Vorgang an sich ist aber identisch.
An sich bedeutet was? Könnte das mal einer 'für Dumme' erklären?
Vielen Dank,
Thomas
set VCCU hmPairForSec 60
statt
set HMLAN hmPairForSec 60
Und vielleicht ergänzend im fhem-Wiki mal noch diesen kurzen Artikel zu vccu lesen:
http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU)
Da steht das im Endeffekt alles schon so drin.
Ich habe jetzt alle HM Komponenten schon gepairt (teilweise auch gepeert) und eine Struktur in FHEM angelegt.
Nutze den HM-CFG-USB mit hmland.
Wenn man nun auf VCCU umstellen möchte, muss man dann wieder ganz von vorne beginnen und hat lauter neue Geräte, oder gibt es einen Trick um möglichst viel der Einstellungen zu erhalten...
Frage2: Wenn mir mal der HM-CFG-USB stirbt, hätte ich dann den gleichen Aufwand dass wieder alles neu gepairt werden muss und dann alle Geräte für FHEM "neu" wären ?
Man muss nichts neu peeren oder pairen. Die Geräte sind NICHT mit dem HMLAN oder dem HMUSB gepairt sondern über die HMID mit der Zentrale. Man legt einfach eine VCCU mit der HMID des HMLAN an (wie beschrieben) und man hat nichts weiter zu tun. Das steht aber auch alles im Wiki und an gefühlt 100 Stellen hier im Forum.
Auch ein Austausch des IO-Devices ist einfach. Einfach den neuen HM-CFG-USB anstecken und alles läuft wieder. Das habe ich gerade vor 2 Wochen erst praktiziert. Es muss nichts neu gepairt werden.
Vielen Dank für die Unterstützung
Jürgen :)
Im Wiki steht unter Einrichten:
define vccu CUL_HM <HMId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]
meine 6-stellige HM-ID kenne ich: die steht im Attribut und in Readings meines "hmusb".
Aber zu IO kann ich mir noch keinen Reim machen. Laut Doku ist das hmusb ja ein IO, mus also in dem Attribut unter <io1> der von mir definierte Name des hmusb stehen?
ZitatAber zu IO kann ich mir noch keinen Reim machen. Laut Doku ist das hmusb ja ein IO, mus also in dem Attribut unter <io1> der von mir definierte Name des hmusb stehen?
genau. wenn du mehrere (cul, hmlan, hmusb, ...) hast, dann am besten alle. mit komma getrennt und ohne leerzeichen.
Aktuell habe ich nur einen, ich hoffe der reicht auch für das ganze Haus.
wenn ich aber zukünftig in der Garage noch etwas benötige, dann kann ich ja über LAN dort noch einen HMLAN installieren.
Wie sieht es denn eigentlich mit wiredHM aus: die Kopfstation hängt am Ethernet und ist dann auch eine weitere anzuhängende IO?
wiredHM läuft sicherlich getrennt. habe ich nichts gegenteiliges gehört.
In der Regel maule ich nicht einfach nur, sondern verbessere die Sachen dann auch.
Allerdings bin ich zeitlich dazu im Moment nicht in der Lage, bitte deshalb um Nachsicht, wenn ich mal nur kritisiere:
Die Wiki-Seite zu VCCU erklärt - leider - wirklich fast gar nichts und ist aus didaktischer Sicht eher katastrophal.
Beispielsweise beginnt das Kapitel "Wann ist eine VCCU sinnvoll ?" mit dem Satz "Eine vccu sollte immer angelegt werden".,
Mein Vorschlag: Vielleicht könnte sich einer der hier Diskutierenden der Seit emal annehmen ?
LG
pah
OT: wer darf im Wiki schreiben? Selbst wenn ich das nötige Fachwissen hatte, habe ich mich noch nie getraut etwas zu schreiben, weil ich didaktisch sicherlich nicht gut genug bin.
Zitat von: ujaudio am 28 Mai 2015, 21:43:01
OT: wer darf im Wiki schreiben?
Jeder, der wie hier beschrieben (http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren) einen "Antrag" stellt.
Zitat von: ujaudio am 28 Mai 2015, 21:43:01
Selbst wenn ich das nötige Fachwissen hatte, habe ich mich noch nie getraut etwas zu schreiben, weil ich didaktisch sicherlich nicht gut genug bin.
Versuch macht klug... trau Dich, Dir wird geholfen werden.
Peter
hm - ich finde die Einleitung nicht schlecht. Eine vccu ist nicht notwendig, daher stellt sich Usern m.E. die frage ob und warum man eine einrichten sollte.
Schade, dass du nicht alles selbst machen kannst.
Hallo Martin,
die Aussage "Eine VCCU ist nicht notwendig" ist vollkommen korrekt. Sie steht aber für den unvoreingenommenen Leser in klarem Widerspruch zu dem Satz "Eine vccu sollte immer angelegt werden."
Kaum ein Paar von Sätzen könnte meine Aussage zu dem Artikel besser untermalen. Dass diese begriffliche Unklarheit sich auch an anderer Stelle im Artikel findet, wird m.E. auch durch die zahlreichen Rückfragen belegt.
Ich bin übrigens nicht der Meinung, dass Sachen nur gut werden, wenn ich sie mache. Oder prinzipiell schlecht sind, wenn sie von anderen gemacht werden. Also lästere _bitte_ diesmal nicht.
LG
pah
das ist kein Läster - jedenfalls nicht meinerseits.
die Sätze stehe auch nicht im Widerspruch. Die VCCU ist nicht notwendig, sollte aber angelegt werden. Somit ist es eine Empfehlung - was hier sehr deutlich gemacht werden soll. Ich zumindest verstehe es genau so - Imperativ, Konjunktiv.
Wäre das System "korrekt" gebaut wäre einen VCCU Pflicht - würde automatisch angelegt. Stand jetzt ist, dass sie optional ist, man das System ohne betreiben kann, es aber nicht (von mir) empfohlen wird.
Ich hatte auch mit dem Gedanken gespielt, die vccu automatisch zu erstellen und zu verlinken. Einige Funktionen die in HMInfo realisiert sind wären hier anzubringen - auch z.B. ActionDetector.
Wenn ich das nun automatisiere - und die vccu zur Pflicht mache - wären einige User .... zumindest überrascht.
Wäre der 2. Satz also Pflicht wäre er nicht notwendig, da ich eine vccu einfach anlegen würde - Punkt. Der erste dann auch nicht.
Zusammenfassend: evtl. sollte ich eine vccu automatisch anlegen, wenn ich ein IO finde, das in HM genutzt wird. Dann wäre die Einleitung im Wiki nicht notwendig. Würde dem alt-User aber ein paar gewohnte Vorgehensweisen verweigern.
ZitatWürde dem alt-User aber ein paar gewohnte Vorgehensweisen verweigern.
Da ich nun eine vccu angelegt habe, würde mich interessieren, was an altgewohnten Vorgehensweisen mir nun verweigert wird? Mak sehen, was ich selbst feststellen werde...
Einen lieben Gruß
Jürgen
Prinzipiell wäre ein top-down vorgehen sinnvoll. Man legt eine vccu an und legt IOs an. dann verlinkt man die vccu mit IOs.
Attribut IODev geht den User nichts mehr an.
die HMId des IO und dessen Konfig (homematic mode) kann der User nicht mehr ändern
Devices müssen einer vccu zugewiesen werden um senden zu können - da die vccu die IOs verwalten.
Somit kommt es zu Problemen bei bestehenden Installationen... insofern, das ich Attribute automatisch setzen und ignorieren würde. Im speziellen eben IODev und IOgrp. Zuweisungen des User, welches IODev er gewählt hat wären hinfällig, wenn es nicht über IOgrp eingestellt ist. Ich könnte/würde versuchen die Konfig zu übernehmen... ändert aber die Gewohnheiten.
Ausserdem hätten die User eine vccu neu, falls nicht schon vorhanden. Änderungen der HMId im IO sind damit nicht mehr erlaubt (so lange es der VCCU zugewiesen ist).
ein aus meiner sicht gut organisiertes System würde so arbeiten - mehr automatisch, weniger optionen.
Hallo Martin,
ich habe mir gerade mal das Wiki und diese Diskussion durchgelesen.
Und ich muss pah recht geben weder das Wiki noch deine Aussagen hier sind für mich wirklich verständlich :-\
Den letzten Beitrag habe ich mindestens 5x gelesen.
Ich versuche mal das ganze so zusammen zu fassen wie ich die VCCU verstanden habe, bitte korrigieren falls ich falsch liege ;D
1. vccu verwaltet Homematic IO's
2. sollte benutzt werden (spätestens wenn mehr als 1x IO)
Welchen Vorteil eine VCCU bei 1x IO hat habe ich noch nicht verstanden :-[
Gruß Rolf
abfangen und melden von Ereignissen die CUL_HM zugeordnet sind.
Zitatvccu verwaltet Homematic IO's
sowie nicht zugeordnete Ereignisse im Bereich der IOs
Zitatsollte benutzt werden (spätestens wenn mehr als 1x IO)
sollte
immer benutzt werden
was ist am ersten Satz nicht verständlich? "immer" ist bold. "Sollte" ist eine Empfehlung, es ist und bleibt ein soll.
Alles Andere sind weitergehende Hinweise.
Aber: warum wird hier darüber diskutiert, dass man es ändern
sollte. Warum schreibt es einer nicht einfach besser? Ist so üblich. Befasse dich damit, mache es richtig.
ich habe den Eintrag etwas überarbeitet. Nicht viel.
Inhaltlich ist immer noch alles korrekt. Es sind nicht alle Readings erwähnt, wie das Empfangen von Nachrichten unbekannter Devices.
Der erste Satz sollte die klare Empfehlung nun ein-eindeutig darstellen, wenn auch nicht begründen.
Zitat von: martinp876 am 30 Mai 2015, 08:31:02
Ich hatte auch mit dem Gedanken gespielt, die vccu automatisch zu erstellen und zu verlinken. Einige Funktionen die in HMInfo realisiert sind wären hier anzubringen - auch z.B. ActionDetector.
Wenn ich das nun automatisiere - und die vccu zur Pflicht mache - wären einige User .... zumindest überrascht.
ich behaupte mal, dass mehr user überrascht sind, wenn sie keine vccu haben und "help me"-einträge im log finden:
2015.03.01 12:56:14 3: CUL_0: Unknown code A0F9B8610319C3F0000000A24880F0040::-106.5:CUL_0, help me!oder hminfo entsprechende fehlermeldungen wirft. oder eben "verunsichert" und/oder über eine entscheidung zur nutzung der vccu "unschlüssig/überfordert" sind. insgesamt wahrscheinlich weniger trubel mit automatischer definition.
einfach mal ein datum setzen für zb weihnachten 2015, und eine nichtnutzung als "deprecatet" bezeichnen.
ZitatPrinzipiell wäre ein top-down vorgehen sinnvoll. Man legt eine vccu an und legt IOs an. dann verlinkt man die vccu mit IOs.
Attribut IODev geht den User nichts mehr an.
die HMId des IO und dessen Konfig (homematic mode) kann der User nicht mehr ändern
bei cul-nutzung müsste man aber beachten, dass einige/viele die cul hauptsächlich im homematic-modus nutzen
und zum schalten von zb intertechno kurzzeitig den modus/frequenz wechseln.
Zitateinfach mal ein datum setzen für zb weihnachten 2015, und eine nichtnutzung als "deprecatet" bezeichnen.
könnte man. Eine automatische Erstellung der VCCU könnte ich einbauen...
Zitatbei cul-nutzung müsste man aber beachten, dass einige/viele die cul hauptsächlich im homematic-modus nutzen und zum schalten von zb intertechno kurzzeitig den modus/frequenz wechseln.
00_CUL macht Rudi. Ich blockiere hier demnach nichts. Das Vorgehen ist natürlich ein Problem. Schaltet der User den mode um und die vccu will über dieses Device senden klappt es nicht. Der User sollte also das Device aus der vccu Liste nehmen - in jeden Fall. Damit hat er alle Rechte - und kein HM-IO mehr. Das könnte er auch mit HMLAN (man kann es nur nicht umschalten).
das umschalten in den it modus ist glaube ich kein problem. das passiert transparent und automatisch nur für die sende dauer eines kommandos. danach wird direkt wieder zurück geschaltet. die hm seite bekommt davon nichts mit und es behindert auch die vccu nicht wirklich.
das es fast immer sinnvoller ist für jedes protokoll ein eigenes io zu haben ist natürlich unabhängig davon trotzdem richtig.
gruss
andre
Noch ein konkretes Thema:
Meine vccu hat gibt mir folgende Infos:
DEF 2CC699
IODev hmusb
NAME xx_Zentrale
NR 163
STATE hmusb:ok
TYPE CUL_HM
assignedIOs hmusb
channel_01 xx_Zentrale_Btn1
Die letzte Zeile zerbreitet mir Kopfzerbrechen, weil ich immer wieder mal eine Meldung bekomme "define xx_Zentrale_Btn1 first" - und ich weiß nicht, was ich definieren soll.
Das gab es übrigens anfangs gar nicht, sondern ist erst durch "herumspielen, in der Hoffnung meine Sprachausgabe hinzubekommen, entstanden. Zumindest hatte ich es anangs nicht bemerkt und auch keine Fehlermeldungen.
da bin ich jetzt auch ziemlich ratlos. Es gibt im Code nur eine Meldung mit define...first
"please define a device with hmId:".$devHmId." first"
was sich auf ein Device bezieht welches fehlt. Wenn man einen Kanal definieren will es aber kein Device dazu gibt wird dies verweigert. Kann es sein, dass die gepostete Meldung nicht nicht korrekt wiedergegeben ist? Wär schade - macht arbeit.
Hallo Martin,
die Meldung ist absolut richtig wiedergegeben. Aber sie kommt möglicherweise nicht von der vccu!? Ich glaube mittlerweile sogar, dass es gar nichts mit der vccu zu tun hat --> hatte. Ich habe mal die vccu komplett entfernt, FHEM neu gestartet und dann die vccu wieder neu definiert. Seitdem tritt die Meldung nicht mehr auf.
Gruß
Jürgen
Zitat von: ujaudio am 30 Mai 2015, 22:30:12
Die letzte Zeile zerbreitet mir Kopfzerbrechen, weil ich immer wieder mal eine Meldung bekomme "define xx_Zentrale_Btn1 first" - und ich weiß nicht, was ich definieren soll.
Das gab es übrigens anfangs gar nicht, sondern ist erst durch herumspielen...
Bist du vielleicht mal in der Weboberfläche bei deiner vccu an den Slider gekommen (set vccu virtual 1)?
Ich finde den etwas unglücklich, da man so recht schnell channels definieren kann, die nicht jeder braucht.
Nun. Man kann den Slider ja leicht über das Attribut webCmd entfernen.
Ich sollte im webcmd besser update als default anbieten
was macht eigentlich "update"?
Prueft welche ios genutzt werden, welche die id der vccu nutzen, .....
In zukunft wird es wohl auch die ioliste fuellen. Dann wird es ein kommando geben mit dem man ios von der vccu trennen kann... und addieren. Der weg implizit ueber das setzen des attributs wird nach dem booten nicht mehr nutzbar.
I.a. geht dies implizit.
Ausserdem werden die decives geprueft, die ueber die vccu betrieben werden.