HMLan und VCCU

[Stril]

Hallo!

Nach diversen Enocean Komponenten, ist bei mir jetzt HM dran.
Wo ich absolut hänge ist die Definition der VCCU:

Ich habe die Adapter-Adresse ausgelesen aus C:\ProgramData\Bidcos-Service\ids --> AABBCC

Jetzt muss ich den HM-Lan-Adaper definieren:

Code Auswählen Erweitern


define HMLAN1 HMLAN 192.168.178.9:1000
attr HMLAN1 hmId XXXXXX

define VCCU CUL_HM YYYYYY
attr VCCU model CCU_FHEM
attr VCCU IOList HMLAN1


Zur eigentlichen Frage:
Was muss XXXXXX sein und was YYYYYY? Ist eines davon die "echte Hardwareadresse" oder beides ausgedachte Werte?

Vielen Dank für euere Hilfe!

Gruß
Phil

[franky08]

Mus beides gleich sein, die ID der vccu muss die gleiche ID sein wie der HMLAN hat!
Die ID des HMLAN kannst du frei vergeben, wobei 000000 und FFFFFF ungültig ist! Siehe WIKI

Der Name (im obigen Beispiel HMLAN1) kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.

HMLAN kennt mehrere Attribute (commandref). Wichtig ist es, die hmId zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit eine 6-stellige Zeichenfolge in Großbuchstaben. 000000 und FFFFFF sind ungültig. Wenn HM-Geräte mit der Zentrale gepairt werden, wird ihnen diese hmId eingetragen. Wechselt man die hmId müssen alle damit gepairten Geräte neu gepairt werden.

Die Adresse wird in Grossbuchstaben eingegeben, siehe "Bekannte Probleme".

[Stril]

Hallo!

Danke für die Hilfe!
Spricht etwas dagegen, die Hardware-ID eines der HMLAN-Adapter für die VCCU zu nutzen?

Gruß
Phil

[frank]

Hallo!

Danke für die Hilfe!
Spricht etwas dagegen, die Hardware-ID eines der HMLAN-Adapter für die VCCU zu nutzen?

Gruß
Phil

nee. musst dann nur alles neu pairen.

[goerdi]

Hallo !

Ich muss mal hier einsteigen...
Ich hab eine HMLAN und eine HM-CFG-USB zu einem vccu zusammengefasst.

Jetzt steht im Wiki dazu das man mit

Code Auswählen Erweitern

attr LichtFlur IOgrp vccu:HMLAN1 quasi eine bevorzugte Sende/Empfangs IO vorgegeben werden soll und man bei Ausfall dann erst wechselt

Ist das bindend ? Oder kann man generell alles auf IOgrp vccu stellen damit er dahin sendet und empfaengt wo er "lust" dazu hat ?

BTW: ich finde die Anzeige etwas unguentig gewaehlt

Code Auswählen Erweitern

rssi_at_HMCFGUSB  lst:-74 max:-69 avg:-72.03 cnt:200 min:-77
rssi_at_HMLAN1    max:-73 avg:-75.2 lst:-73 min:-76 cnt:5


also wenn dann sollte die passenden Werte auch untereinander stehen

Gruss Gerd

[dev0]

Oder kann man generell alles auf IOgrp vccu stellen damit er dahin sendet und empfaengt wo er "lust" dazu hat ?

Empfangen wird immer mit beiden, es geht nur um das senden. Ich habe damit aber keine guten Erfahrungen gemacht:
Ein HM-RC-4-2 wurde dadurch sehr unzuverläsig, häufig wurde das drücken einer Taste nicht grün quittiert und das eigentliche Event wurde dann verzögert und mehrfach ausgeführt.
Vielleicht ist/war es ein Bug oder ich war zu dusselig

[martinp876]

es ist - insbesondere bei HMLAN - nicht nur das senden, sondern auch das ACK. Das sendet HMLAN selbständig (im Gegensatz zu CUL).
=> FHEM muss ein (in Worten: ein) IO definieren, welches das ack senden soll.
Bei "Dynamik" wird das IO genutzt, welches das Signal am Besten empfängt. Bei einem Wechsel des IO muss dies erst "instruiert" werden, die ID muss im HMLAN aktiviert werden und im alten HMLAN gelöscht.
Dynamik erzeugt daher Aufwand (logisch). Macht sinn, wenn man wirklich weit entfernte IOs nutzen will - Funkbereiche die sich mit unter nicht "berühren".

Ansonsten würde ich immer IOGrp mit preferedIO nutzen. So lange das prefered aktiv ist wird dies genutzt. Umschalten findet nur statt, wenn das prefered nicht senden kann und ein 2. IO zu Verfügung steht. Sollte für 98% der Devices die beste Wahl sein - nur bewegliche Handsender und Funklandschaften mit wirklichen toten Winkeln benötigen eine volle Dynamik mit rssi.

Noch einmal: prefered-io wird auchgenutzt, wenn das IO funktioniert, das Device aber ausserhalb der Reichweite ist (RSSI wird nicht geprüft!)