Hallo zusammen,
ich habe mich zum Thema VCCU eingelesen und wollte die Tage mit der Einrichtung beginnen. Bei der Vorbereitung habe ich festgestellt dass bei meinem Busware CUL keine HMID gesetzt ist. An Informationen habe ich folgendes gefunden:
hmId
Setzt die HomeMatic ID des Gerätes. Wenn dieses Attribut fehlt, wird die ID zu F1<FHTID> gesetzt. Bemerkung 1: Nach dem Setzen bzw. Verändern dieses Attributes müssen alle HomeMatic Geräte neu angelernt werden. Bemerkung 2: Der Wert muss eine 6-stellige Hexadezimalzahl sein, 000000 ist ungültig. FHEM überprüft nicht, ob die ID korrekt ist, im Zweifelsfall funktioniert die Kommunikation nicht.
Mein CUL hat jetzt quasi "nur" eine vierstellige FHTID. Hier für das Beispiel ist die FHTID
1234
Meine Homematic Devices sind gepaired mit
0xF11234
Das ich keine HMID habe finde ich vorsichtig ausgedrückt "suboptimal". Warum ich das nicht eingerichtet habe weiss ich nicht. Ist ja schon ein paar Jahre her.
Ist das hinsichtlich meines Vorhabens ein k.O. Kriterium oder was wäre denn in meinem Fall für die Definition der VCCU die "HMID" ?
F11234
Vielen Dank für eure Hilfe im Voraus.
Grüße
Steven
Hallo Steven,
die F11234 ist deine HMID. Nimm also dies zur Definition Deiner VCCU
Gruß Otto
Hallo Otto
danke für die Info. Dann werde ich das die Tage mal angehen :-)
Grüße
Steven
Hallole nochmal,
wie sollte es anders sein ich hab noch Fragen. Ich habe die VCCU eingerichtet nach folgendem Beispiel:
define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU IOgrp VCCU
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Ich kann die Attribute
attr VCCU IOgrp VCCU
attr VCCU model CCU-FHEM
nicht setzen diese gibt es nicht. Das Attribut:
attr VCCU subType virtual
wurde automatisch gesetzt. Ist das korekt so ?
Grüße
Steven
du musst das attr modelForce auf CCU-FHEM setzen.
Das ist schon mal falsch !
define VCCU CUL_HM 123456
@Frank muss jetzt immer modelForce gemacht werden? Soll ich das im Wiki ändern?
OT
Ist der Modulautor nicht für die Doku verantwortlich? In CUL_HM ist zur VCCU (CCU-FHEM) gar nichts dokumentiert :'( Es gibt jedoch einen verwaisten Eintrag auf CCU_FHEM
CUL_HM ist nur 4nerds?
Hallo Otto,
warum ist das define falsch ? Ich hab das natürlich mit meiner ID gemacht
F11234
Grüße
Steven
na dann ist es richtig :)
Sorry für den scharfen Einwand, aber es gibt wirklich viele die einfach diese Zeilen eins zu eins kopieren. Und dann wäre die VCCU wirklich nicht im Sinne des Erfinders gewesen.
IOgrp konntest Du auch nicht setzen? ???
Hallole
kein Problem :-) Doch das konnte ich alles setzen nach dem Hinweis mit dem
modeForce
In meinem HomeMatic Devices habe ich jetzt bei den Attributen IOGRP
VCUU
stehen. Insofern sollte ja alles passen oder ?
Lediglich im VCCU selbst habe ich komische Meldungen stehen. Hab mal einen Screenshot beigefügt.
Grüße
Steven
Grüße
Steven
Zitat von: Otto123 am 20 Dezember 2022, 12:02:08
@Frank muss jetzt immer modelForce gemacht werden? Soll ich das im Wiki ändern?
Muss man nicht!
Diese Reihenfolge wie im Wiki funktioniert, ich sollte nur hinschreiben: Die muss exakt eingehalten werden! Man darf nicht das praktische Beispiel in Raw Definition darunter einfach kopieren.
Zitatdefine <Name der vccu> CUL_HM <hmId>
attr <Name der vccu> model CCU-FHEM
attr <Name der vccu> IOList <Name des io1>[,<Name des io2>,...]
attr <Name der vccu> IOgrp <Name der vccu>
Zitat von: sxx128 am 20 Dezember 2022, 12:32:31
VCUU
stehen. Insofern sollte ja alles passen oder ?
Lediglich im VCCU selbst habe ich komische Meldungen stehen. Hab mal einen Screenshot beigefügt.
passt nicht! Da muss VCCU stehen - sorry ich bin kleinlich!
Die Meldungen kommen von Hm Geräten, die die VCCU bzw. Dein System nicht kennt.
Hallole
ja du hast natürlich recht. War ein Fehler von mir ..richtig ist:
VCCU
stehen. Ist bei mir auch so....
Vielen Dank für die Hilfe
Grüße
Steven
Zitat von: Otto123 am 20 Dezember 2022, 12:02:08
Das ist schon mal falsch !
@Frank muss jetzt immer modelForce gemacht werden? Soll ich das im Wiki ändern?
OT
Ist der Modulautor nicht für die Doku verantwortlich? In CUL_HM ist zur VCCU (CCU-FHEM) gar nichts dokumentiert :'( Es gibt jedoch einen verwaisten Eintrag auf CCU_FHEM
CUL_HM ist nur 4nerds?
die philosophie reime ich mir so zusammen:
die 3 attribute .mID, model und subType müssen zusammenpassen und sind deswegen unter kontrolle von cul_hm. sollen also nicht durch den user verändert werden können. (cul_hm for users?)
über das frontend (user) soll also eine änderung nur über attr modelForce möglich sein.
aussnahmen bestätigen die regel. ;)
Naja im falle der CCU-FHEM ist es offenbar anders:
nach dem define weiß ja CUL_HM kein model, die "redet" ja nicht.
deswegen geht einmalig ein attr model unmittelbar nach define
danach muss IOList gefüllt werden, denn ansonsten geht kein
attr IOgrp - das wirft sonst einen Fehler, dass kein IOList in der CCU-FHEM definiert ist.
Zitatnach dem define weiß ja CUL_HM kein model, die "redet" ja nicht.
das kann nur ein bug sein, behaupte ich mal.
maximal ein ganz schlechter "taschenspielertrick". ;)
ein define in der cmdline erzeugt mir:
defmod bla CUL_HM 987654
attr bla autoReadReg 4_reqStatus
attr bla expert rawReg
attr bla subType no
setstate bla 2022-12-20 14:23:41 .associatedWith bla,bla
setstate bla 2022-12-20 14:23:45 IODev cul868
setstate bla 2022-12-20 14:23:57 RegL_00.
setstate bla 2022-12-20 14:23:45 cfgState updating
setstate bla 2022-12-20 14:23:45 commState CMDs_processing...da wurde schon fleissig über cul versucht register zu lesen, obwohl nicht einmal feststeht, ob das device mal virtuell oder real sein soll.
wahrscheinlich sendet der jetzt sogar regelmässig.
sauberer wäre eine default festlegung zb auf ein generelles virtuelles device.
1. mit .mId, model und subType
2. ohne autoReadReg, expert
Zitat von: frank am 20 Dezember 2022, 14:53:24
maximal ein ganz schlechter "taschenspielertrick". ;)
Naja ich gebe zu: Ich habe auf einem System probiert wo kein funktionierender CUL_HM IO aktiv war.
Aber egal, die unten erwähnte Abfolge funktioniert und ich finde die auch relativ logisch. Die restlichen Attribute entstehen dabei durch CUL_HM anschließend ist die VCCU in Ordnung.
Ich finde es nach wie vor blöd, dass CUL_HM den FHEM Standard Raw Definition nicht beherrscht. Aber wie sagt eq3: alles hat ein Ende...