Autor Thema: VCCU schaltet den eigenen IODev nicht um  (Gelesen 539 mal)

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 9421
    • Otto's Technik Blog
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #15 am: 13 Juni 2018, 14:20:51 »
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). 
Viele Grüße aus Leipzig
RaspberryPi,HMLAN,HMUART,Homematic,Fritz!Box 7490,Sonos,ET9200,Arduino nano,ESP8266

Offline frank

  • Hero Member
  • *****
  • Beiträge: 6565
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #16 am: 13 Juni 2018, 17:05:40 »
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.
FHEM: 5.8(SVN) => Pi3(jessie)
IO: CUL433_V3.3(1.00.01B53)|CUL868_V3.3(1.58)|HMLAN(0.965)|HMUSB2(0.967)|HMUART(1.4.1)
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1573
  • Wuppertaler Wimpelbeauftragter
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #17 am: 14 Juni 2018, 09:37:05 »
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
Jetzt auf nem I3 und primär Homematic

kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Otto123

  • Hero Member
  • *****
  • Beiträge: 9421
    • Otto's Technik Blog
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #18 am: 14 Juni 2018, 09:52:07 »
Hallo Ralf,

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

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
« Letzte Änderung: 14 Juni 2018, 10:41:15 von Otto123 »
Viele Grüße aus Leipzig
RaspberryPi,HMLAN,HMUART,Homematic,Fritz!Box 7490,Sonos,ET9200,Arduino nano,ESP8266
Gefällt mir Gefällt mir x 3 Liste anzeigen

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10178
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #19 am: 14 Juni 2018, 21:02:31 »
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.

Offline yersinia

  • New Member
  • *
  • Beiträge: 45
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #20 am: 15 Juni 2018, 09:26:51 »
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.
viele Grüße, yersinia
----
FHEM 5.8 on RPi 3B with Raspian Jessie (perl 5.20.2-3+deb8u11)  | FTUI
nanoCUL@a-culfw -> 2x 868 (1x ser2net on LEDE) | 1x 433
VCCU -> 7x HM-CC-RT-DN | 5x HM-LC-Bl1PBU-FM | 14x HM-SEC-SCo | 1x HM-PB-2-WM55 | 1x HM-LC-Sw1PBU-FM | 1x HM-ES-PMSw1-Pl

Offline noansi

  • Sr. Member
  • ****
  • Beiträge: 569
Antw:VCCU schaltet den eigenen IODev nicht um
« Antwort #21 am: 15 Juni 2018, 20:42:15 »
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.

    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.
« Letzte Änderung: 16 Juni 2018, 12:57:47 von noansi »