HM virtual CCU

[martinp876]

da dieser hmlan1 nicht mehr im empfangsbereich des device positioniert ist,

nein, so ist es nicht gedacht.
wenn du ein prefered hast wird dies genutzt, so lange es verfügbar ist. Das ist es ja noch.
Wenn du kein prefered definierst wird nach Empfangspegel entschieden.
Bei feststehenden Devices würde ich prefered nutzen, bei protablen eher nicht.

und falls keine kommunikation möglich ist

falls das IO nicht verfügbar ist.

oder wird nur ein anderer IO genommen wenn der prefIO overload oder disconnect ist?

korrekt

[Ralli]

Hier hätte ich noch etwas .

Etwas mit dem preferred IO zu nutzen, ist super. Aber dann ist es grundsätzlich auf genau eines beschränkt und alle Vorteile wie Redundanz und eigene Wahl nach RSSI sind definitiv weg. Ich hätte folgenden Vorschlag und erkläre zunächst die Situation:

Ich habe einen CUL und zwei HMLAN, ich nutze einige Sensoren und auch Aktoren ohne AES und manche mit AES. Bei denen, bei denen AES nicht genutzt wird, habe ich kein preferred IO eingestellt. Bei denen, bei denen AES genutzt wird, habe ich/musste ich einen bestimmten HMLAN definieren.

Super wäre nun die Möglichkeit, nicht nur ein preferred IO angeben zu können, sondern wiederum eine Liste. So könnte ich auch bei den AES nutzenden Sensoren/Aktoren eine Redundanz erwirken (bzw. eigene Wahl des IO anhand von RSSI), indem ich beide HMLAN als preferred IOs definiere.

Wäre das was, Martin?

[martinp876]

na gut. Wollte ich anfangs nicht.
du kannst jetzt
attr <device> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>,....
eingeben. das erste aktive io wird als sender ausgewählt

[Ralli]

  Das ist ja super! Danke !!

Warum wolltest Du es zunächst nicht?

[martinp876]

die Funktion wird sehr häufig aufgerufen. Sie soll "schlank" sein - wegen der Performance

[marvin78]

Ehrlich gesagt halte ich es auch für Blödsinn, mehrere Preferred IOs zu haben. Wofür soll das in sicher 90% der Installationen gut sein? Mann kann nicht jeden Wunsch in Einzelszenarien erfüllen. Wenn es Performance kostet, bin ich dafür, es wieder auszubauen!

[Ralli]

Ok - danke nochmals, dass Du es eingebaut hast.

Denkbar wäre ansonsten noch folgende Alternative gewesen:

In der vCCU-Definition mehrere IOList zulassen. So könnte man in meinem konkreten Fall die IOList0 mit CUL0,HMLAN0,HMLAN1 definieren und die IOList1 nur mit HMLAN0 und HMLAN1.

In den jeweiligen Devices könnte man dann die IOgrp nur mit vCCU (dann nimmt er die IOList0) oder mit z.B. IOgrp vCCU:IOList1 definieren. Man würde also kein preferred IO angeben sondern eine preferred IO-Liste.

Würde das noch mehr aufblasen oder wäre dieser Ansatz performanter?

@Marvin:
Nein, definitiv kein Blödsinn - wenn man AES einsetzt und mehrere IOs hat, die das unterstützen und manche, die es eben NICHT unterstützen. So kann man bei den AES-Aktoren auch wenn das preferred IO ausfällt weiterhin Schaltbefehle absetzen, weil sie dann über das nächste AES-Device abgesetzt werden.

[marvin78]

Da wäre es doch eher angebracht, den CUL zu veäußern und einen günstigeren HMUSB zu kaufen. Dann hast du AES. Man muss sich nicht auf jeden Sonderszenario einstellen und wenn es dann auch noch Performance kostet, das doch zu tun, dann wird es schnell zu Blödsinn!

[Ralli]

Nein. Und es ist auch kein Sonderszenario sondern die logische Erweiterung des Redundanz-Gesichtspunktes.

Und Du musst das Feature ja nicht nutzen.

[marvin78]

Ist es nicht, wenn es Performance kostet und es eine (sogar kostengünstigere - in Preis und eben Performance) Alternative gibt! Sorry, davon überzeugst du mich nicht. Es bleibt ein Szenario, das nicht notwendig ist und dehalb kann das wieder raus.

EDIT: Wenn ich AES machen will, habe ich keinen CUL im System. Das ist eigentlich einfach umzusetzen und klar.

[Ralli]

Nein - mich überzeugst Du von Deinem Standpunkt nicht. Gerade ein HM-USB ist eher ein Kandidat für Timing-Probleme.

Ich bin dankbar für die neue Möglichkeit.

Davon abgesehen hat Martin nur geschrieben, dass die Funktion aus Performanz-Gründen schlank sein soll. Dass es jetzt zu Performanz-Einbussen kommen könnte bzw. kommt, hat er nicht geschrieben. Das wäre also zunächst mal zu testen.

Normalerweise machst Du aus Gründen der Funklast nicht alles mit AES sondern bei mir bspw. nur die "sicherheitskritischen" Aktoren. Die Masse läuft ohne AES. Und dann macht das sehr wohl Sinn mit einem CUL statt HM-USB (Update-Möglichkeiten, externe Antenne, keine Timingprobleme usw.).

Sei es drum - wir haben einfach verschiedene Ansätze.

[marvin78]

Es gibt eine Alternativen zum HMUSB und die heißt, bei Verwendung von AES, NICHT CUL.

Und dass es Perfornance kostet, ist schon logisch. Es gibt mindestens eine Überpürung mehr.

[martinp876]

die Performancekosten halten sich aktuell sicher in Grenzen. Ich knausere hier immer etwas (versuche es zumindet). Aktuelle Probleme kommen eher durch exzessive logs und notifies, web-applikationen, graphiken u.ä. Wie man das handhabt ist nicht mehr Sache von CUL_HM

man könnte verschiedene Listen generieren - hier sehe ich aber Probleme, es noch warten zu können. Aktuell ist es für User recht einfach - mit der Liste der preferred ios sollte es fast alles abdecken. einzig kann man eine preferred-liste nicht dynamisch nach RSSI abarbeiten lassen, alles andere sollte gehen.
Einen Ausfall eines oder mehrer IOs kann man problemlos handeln.

[Ralli]

Daumen hoch! Und nochmal danke.

[Ralli]

Hallo Martin,

scheint so weit zu funktionieren wie geplant!

Nur kleine kosmetische Dinge: Bei einem Device zeigt er als IODev komischerweise in den Attributen CUL0 an, obwohl in der IOgrp nur HMLAN0 und HMLAN1 definiert - wahrscheinlich ist das noch ein Überbleibsel, als das Device noch ohne AES über den CUL lief. Wenn ich mit get CCU listDevice nachschaue, ist es richtig. Wenn mehrere IODevs angegeben, liegt der Link bei der Detailseite des Devices nur auf einem. In get CCU listDevice ist keiner der IODevs dann mit einem Link unterlegt.

Und der configCheck von hminfo meckert das neue Feature noch an.