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

[LuckyDay]

am Device attr IOgrp  VCCU:CUL_HM  bzw. attr IOgrp  VCCU:HMLAN1

betrifft nur das senden von Fhem, ich habe bei mir auch entsprechend die bevorzugten I/O s eingetragen,
aber nur wegen der Lastverteilung 1% Regel,
bei dir mit dem Cul, könnte es nocht interessant sein , wenn du Zicken hast, die lieber mit dem Hmlan reden wollen , sofern im sende Bereich

attr IODev CUL_HM.

das bekommt man automatisch von fhem , ohne Bedeutung

[kvo1]

Hallo Hary,
Danke nochmal, das sieht soweit ganz gut aus, zumindest schalten alle Devices jetzt zuverlässig.

Was ich noch nicht herausgefunden habe , warum bei einigen Devices bei den Internals nur nur der
HMLAN1 auftaucht und nicht auch der CUL_HM ?

Klaus

[LuckyDay]

wenn nur der HMLAN1 auftaucht  --> dann wurde von deinem Cul auch nichts empfangen

[kvo1]

Hallo Hary,
muss nochmal eine kurze Frage loswerden. Das mit der VCCU läuft wunderbar.

Ich habe aber jetzt für das angelegt Device VCCU jede Menge Readings ........

Sind das Devices die die VCCU erkennt, die aber nicht gepairt sind/wurden ?

Kann man diese readings wieder löschen

Gruss
klaus

[Benni]

Klar kann man:

http://fhem.de/commandref_DE.html#deletereading

Die werden aber, so lange es wirklich unbekannte devices sind, die senden, wahrscheinlich bald wieder auftauchen.

[kvo1]

Hallo Benni,
Stimmt, die tauchen wieder auf , das sind Devices aus
meinem Livesystem und die Readings wurden im Testsystem angelegt.

Demnach lässt man die einfach , oder...
Oder über Attr .....ignore.....

[Benni]

Ja, wenn die devices vom autocreate angelegt sind kannst du das Attribute Ignore setzen. Und anschließend die Readings löschen. Sie sollten dann nicht mehr auftauchen, da die devices ja jetzt bekannt sind, aber eben ignoriert werden.

[kvo1]

eigenartiger Weise waren die devices nicht angelegt, obwohl autocreate aktiv ist !
Ich habe diese mal per Hand angelegt und auf  "ignore 1" gesetzt !

[frank]

Ich habe diese mal per Hand angelegt und auf  "ignore 1" gesetzt !

das funktioniert eleganter mit "set vccu defIgnUnknown". 

[Benni]

das funktioniert eleganter mit "set vccu defIgnUnknown". 

Danke! Kannte ich auch noch nicht!   

[LuckyDay]

bei HM bzw. vccu würde ich die readings nicht mit dem Befehl deletereading löschen, sondern mit

set vccu clear readings

da sind sie in einem rutsch weg

[kvo1]

das funktioniert eleganter mit "set vccu defIgnUnknown". 

Danke, kannte ich so auch nicht 

@hary, auch dafür DANKE, man lernt nie aus !

[Ma_Bo]

Hallo Leute,
ich habe eine vccu definiert und alles funktioniert prima, ist es möglich, wenn man das so definiert hat

Code Auswählen Erweitern

attr <device> IOgrp VCCU:HMLAN1

ein zweites IO festzulegen, wenn das erste nicht erreichbar ist, dass dann das zweite IO verwendet wird (ggfs. auch ein drittes und viertes) und dann erst das IO mit dem besten RSSI?

Grüße Marcel

[frank]

man kann auch mehrere prefered io's definieren, die in der angegebenen reihenfolge genutzt werden, wenn sie verfügbar sind. wenn nicht, dann alle restlichen io's nach rssi.

[Ma_Bo]

Werden die dann durch ein Komma oder ein Leerzeichen getrennt?
Muss dann nochmals VCCU davor

1.

Code Auswählen Erweitern

attr <device> IOgrp VCCU:HMLAN1,VCCU:HMLAN2

2.

Code Auswählen Erweitern

attr <device> IOgrp VCCU:HMLAN1 VCCU:HMLAN2

3.

Code Auswählen Erweitern

attr <device> IOgrp VCCU:HMLAN1,HMLAN2

4.

Code Auswählen Erweitern

attr <device> IOgrp VCCU:HMLAN1 HMLAN2

Grüße Marcel