VCCU schaltet den eigenen IODev nicht um

[Otto123]

Ohne das näher geprüft zu haben würde ich mal davon ausgehen, dass es das letzte in der cfg stehende IO für das Modul (hier CUL_HM) ist - so funktioniert jedenfalls der DevIO-Mechanismus (wenn ich das richtig aus dem Quelltext im Zusammenhang mit MySensors entnommen habe - da wird auch scheinbar willkürlich irgendein IO bei neu angelegten Devices ins IODev-Attribut geschrieben).

Das kann ich so bestätigen! Hab es getestet!

Was bleibt: trotz dem funktionierenden IODev beim ersten set VCCU hmPairSerial ... Man muss den Befehl zweimal absetzen und dazwischen einige Zeit warten (sonst macht man es dreimal). 

[frank]

Hallo Frank,

ich hatte nur attr VCCU IOgrp VCCU drin. Er nimmt dort scheinbar den, mit dem der Pairing Vorgang am Ende erfolgte.

Gruß Otto

ok, danke.

[Wuppi68]

Hallo in die Runde,

trotz zweimal lesen ist mir die Lösung nicht so wirklich klar geworden ;-)

Meine Bitt: Wenn die finale Lösung gefunden worden ist, bitte die 3? IO Atrribute von der VCCU noch einmal explizit mit dem benötigten Inhalt benennen :-)

Danke

Ralf

[Otto123]

Hallo Ralf,

gern  dokumentiert -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Einrichten

Code: [Auswählen]

define VCCU CUL_HM <hmId>
 attr VCCU model CCU-FHEM
 attr VCCU IOList <Name des io1>[,<io2>,...]
 attr VCCU IOgrp <Name der vccu>
Edit: Ich hoffe mal, dass der Chef noch sein ok zu dieser Erkenntnis gibt 

Gruß Otto

[martinp876]

Iodef hat auch mit vccu eine funktion. Allerdings wird das io durch einen Algorithmus errechnet und iodev verändert sich automatisch.
Typisch sendet die zentrale ( stellvertretend vccu) an bekannte devices. Fuer diese liegt eine entscheidungsliste vor (rssi werte und eine prio liste). Abstrakt sieht die vccu also im empfanger nach, wo am besten gesendet werden soll.
Nun gibt es in der tat ein paar befehle welche nicht an einen bekannten empfänger gehen ( broadcast).
Dazu gehört pairserial. Pairforsec gibt eine antwort auf eine message. Ok, das device ist noch nicht eingerichtet. Muss ich nachsehen, könnte ein problem sein.
Aber das sollte es auch schon gewesen sein.

Das pairen sehe ich noch einmal daraufhin durch.

[yersinia]

Hallo zusammen,
interessante Diskussion. Danke Otto für die Aktualisierung des Wikis.
Mir ist das mit dem IOGrp der VCCU schon beim hmconfig check aufgefallen
-> https://forum.fhem.de/index.php/topic,66088.msg800923.html#msg800923
Die VCCU als IOGrp bei sich selbst zu setzen brachte die Lösung bezgl. der Meldung. Allerdings funktioniert meine VCCU vorher wie nachher ganz gut.
(natürlich muss ich in den Devices die IOGrp als VCCU mit preferred IODev setzen)
Aber ich werde zuhause dann mal prüfen, was meine VCCU macht.

[noansi]

Hallo Martin,

es ist so, wie berichtet.

Bei der IO Zuweisung für die VCCU wird die IOList in CUL_HM_assignIO($) nicht berücksichtigt, da für die VCCU ohne Setzen von IOgrp $hash->{helper}{io}{vccu} nicht gesetzt ist.
Es wird aber das attribut IODev berücksichtigt.
Zum Tragen sollte das kommen, wenn das IO im laufenden Betrieb ausfällt. Nur beim FHEM Start findet eine IO Zuweisung nach IOList über CUL_HM_UpdtCentral statt.

Einfach zu lösen, respektive IOgrp nicht zwingend zu setzen, wäre es wohl durch setzen von $hash->{helper}{io}{vccu} auf dem eigenen Namen in CUL_HM_updateConfig($) im Abschnitt elsif ($md =~ m/^CCU-FHEM/), wenn es ein device ist.

Code: [Auswählen]

    elsif ($md =~ m/^CCU-FHEM/){
      $hash->{helper}{role}{vrt} = 1;
      if($hash->{helper}{role}{dev}){
        $hash->{helper}{io}{vccu} = $hash->{NAME} if (!$hash->{helper}{io}{vccu});

Ein VCCU Broadcast in MultiIO Umgebung ist schwieriger abzubilden.
Wenn MultiIO aus Redundanzgründen verwendent wird, dann würde es reichen, nur auf einem IO den Broadcast zu senden.
Wenn MultiIO zur besseren Abdeckung verwendet wird, müsste auf er auf allen IOs nacheinander mal gesendet werden (ggf. bis eine erwartete Antwort empfangen wird), damit in "jeder Ecke" der Broadcast empfangen werden kann.

Gruß, Ansgar.