VCCU schaltet den eigenen IODev nicht um

[Otto123]

Hi,

Ausgangszustand:
Die VCCU hat zwei IODevs myHmUARTLGW und ser2netUart, der eine ist nicht erreichbar -> myHmUARTLGW:disconnected,ser2netUart:ok
Definition:

Code Auswählen Erweitern

attr VCCU IOList myHmUARTLGW,ser2netUartund damit von der VCCU gesetzt

Code Auswählen Erweitern

attr VCCU IODev myHmUARTLGW
ein set Befehl an die VCCU z.B.

Code Auswählen Erweitern

set VCCU hmPairSerial IEQ0017523 wird nicht abgearbeitet und führt nur zu CMDs_pending in der VCCU und irgendwann zum IOerr.

Wird die Definition geändert:

Code Auswählen Erweitern

attr VCCU IOList ser2netUart,myHmUARTLGW führt das zu keiner Veränderung. Außer der Reihenfolge im Status
-> ser2netUart:ok,myHmUARTLGW:disconnected,
Löscht man jetzt das attr VCCU IODev führt das zum Erfolg.
Der nächste set Befehl wie oben ändert sofort das IODev

Code Auswählen Erweitern

attr VCCU IODev ser2netUart
und alles scheint gut. 

Ist das im Sinne des Erfinders? 

Gruß Otto

[marvin78]

Soweit ich weiß, ist doch das IODev an der Stelle irrelevant (für eine Funktionalität).

[Otto123]

Für die Arbeit der VCCU mit den anderen Geräten sicher. Das attr IODev bei den Geräten ja durch die VCCU verwaltet (so beschrieben). Ich habe allerdings auch dort ein Problem entdeckt. Hier im Protokoll zum pairen ersichtlich.

Aber bei sich selbst ist es offenbar ein echtes Problem. Sie verwendet zum Senden offenbar stur das was in ihrem IODev steht und wenn das "defekt" ist passiert nach außen gar nichts. Die VCCU setzt ihr eigens IODev wenn der Eintrag fehlt aber nicht wenn sich etwas ändert.

Das ist sicher nur ein Problem wenn man pairen will.
Würde aber z.B. ein Problem darstellen, wenn man dabei einfach einen bestimmten IO bevorzugen will und die anderen temporär "closed" setzt.

Man kann damit umgehen, aber man muss es wissen 

[marvin78]

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr

Wo siehst du das beschrieben? IOGrp ist das relevante Attribut für eine VCCU.

IODev wird, so weit ich weiß, durch fhem verwaltet, nicht durch HM.

[frank]

normalerweise wird zur kommunikation mit einem device das io genutzt, welches im device festgelegt ist. wenn attr IOgrp existiert wählt die vccu eins aus (das aktuelle ist immer im internal IODev zu sehen). wenn kein IOgrp existiert, dann das io welches im attr IODev gesetzt ist.

wenn nun aber noch kein device existiert, was pasiert dann?
hier stelle ich mir vor, dass dann je nach attr IOgrp/IODev bei der vccu gewählt wird.

wenn otto kein IOgrp in der vccu gesetzt hat, müsste demnach das io in IODev genutzt werden. also so wie otto es erlebt hat.

[marvin78]

Aber das ist der Punkt: Wenn IODev, laut Doku, keine Funktion hat, was offensichtlich nicht ganz stimmt, würde ich immer IOGrp setzen und nicht IODev.

[Otto123]

So ist es aktuell:

Code Auswählen Erweitern

Internals:
   DEF        200DB8
   IODev      ser2netUart
   LASTInputDev myHmUARTLGW
   MSGCNT     9280
   NAME       VCCU
   NOTIFYDEV  global
   NR         57
   NTFY_ORDER 50-VCCU
   STATE      ser2netUart:disconnected,myHmUARTLGW:ok,
   TYPE       CUL_HM
   assignedIOs myHmUARTLGW,ser2netUart
   lastMsg    No:CC - t:02 s:200DB8 d:2B622F 00
   myHmUARTLGW_MSGCNT 784
   myHmUARTLGW_RAWMSG 05000034D584703C6DF000000000E336
   myHmUARTLGW_RSSI -52
   myHmUARTLGW_TIME 2018-06-13 13:11:07
   protLastRcv 2018-06-13 13:10:33
   protSnd    1 last_at:2018-06-12 22:26:08
   protState  CMDs_done
   rssi_at_myHmUARTLGW cnt:219 min:-55 max:-28 avg:-43.78 lst:-37
   rssi_at_ser2netUart cnt:1984 min:-67 max:-36 avg:-46.64 lst:-45
   ser2netUart_MSGCNT 8496
   ser2netUart_RAWMSG 0500003C45847032266700000000EB34
   ser2netUart_RSSI -60
   ser2netUart_TIME 2018-06-13 12:59:32
   READINGS:
     2018-06-13 13:10:33   CommandAccepted yes
     2018-06-13 12:36:23   aesKeyNbr       00
     2017-09-18 12:29:20   aesReqTo        HM_101E78
     2018-06-13 13:08:24   recentStateType ack
     2018-06-13 13:01:16   state           ser2netUart:disconnected,myHmUARTLGW:ok,
   helper:
     HM_CMDNR   204
     PONtest    1
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1528888233.94485
       prefIO     
       vccu       
       ioList:
         ser2netUart
         myHmUARTLGW
     mRssi:
       mNo        CC
       io:
         myHmUARTLGW:
           -37
           -37
         ser2netUart:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_myHmUARTLGW:
         avg        -43.7853881278539
         cnt        219
         lst        -37
         max        -28
         min        -55
       at_ser2netUart:
         avg        -46.6451612903226
         cnt        1984
         lst        -45
         max        -36
         min        -67
Attributes:
   IODev      ser2netUart
   IOList     ser2netUart,myHmUARTLGW
   expert     2_raw
   model      CCU-FHEM
   room       IO,Test
   subType    virtual
   webCmd     virtual:updateMan kann das attr IODev löschen, dann wird es beim nächsten set VCCU ... neu angelegt (und verwendet!).

IOGrp bei der VCCU selbst - gehört da nicht hin - dachte ich immer! 

[marvin78]

Ich weiß tatächlich nicht, ob der von frank beschriebene Weg richtig ist, aber wenn er richtig ist, wäre das Setzen in der VCCU eine logische Folge.

IODev erscheint immer neu, weil FHEM es eben immer setzt (in dem Fall FIFO). Aus meiner Sicht müsste es aber bei gesetztem IOGrp ignoriert werden. Einen Test wäre es Wert.

[Otto123]

Ich fasse es nicht 
Das ist es!!! Setzen von IOgrp bei der VCCU und es funktioniert!?

Ich habe es nochmal hin  und her probiert: ohne attr IOgrp funktioniert das absetzen des Befehles nicht - mit attr IOgrp sofort.

Es bleibt dabei ein Problem, der Pair Vorgang muss quasi abbrechen, weil die VCCU (oder wer auch immer) dem neu angelegten Gerät das IOdev gibt was tot ist.

Wiederholt man den Befehl noch zwei mal, wird zu Ende gepairt. Erst beim letzten wird dann attr IOgrp auch bei dem neuen Gerät erzeugt - leider? mit Vorzug -> VCCU:myHmUARTLGW

Code Auswählen Erweitern

2018.06.13 13:31:31 3: CUL_HM set VCCU hmPairSerial IEQ0017523
2018.06.13 13:31:31 2: CUL_HM Unknown device HM_1526F5 is now defined
2018.06.13 13:31:31 2: autocreate: define HM_1526F5 CUL_HM 1526F5
2018.06.13 13:31:31 2: autocreate: define FileLog_HM_1526F5 FileLog ./log/HM_1526F5-%Y.log HM_1526F5
2018.06.13 13:31:37 0: CUL_HM_assignIO HM_1526F5 AssignIoPort used
2018.06.13 13:35:01 3: CUL_HM set VCCU hmPairSerial IEQ0017523
2018.06.13 13:35:46 3: CUL_HM set VCCU hmPairSerial IEQ0017523
2018.06.13 13:35:46 3: CUL_HM pair: HM_1526F5 blindActuator, model HM-LC-BL1-FM serialNr IEQ0017523
2018.06.13 13:35:46 0: CUL_HM_assignIO HM_1526F5 attr IODev used
2018.06.13 13:35:47 3: CUL_HM set HM_1526F5 statusRequest

Legt die VCCU bei der Anlage das attr IOgrp bei sich selbst wirklich an? Das müsste sie ja!?!

[marvin78]

Ok. Also etwas hakelig. Der Punkt mit "leider" ist schon immer ein Problem (für mich). Ich muss nach dem Pairen jedes Device noch einmal anfassen um hier meinen Vorzug zu setzen oder den Vorzug raus zu nehmen.

[Beta-User]

Danke für das Aufgreifen dieses Punktes, ist für mich zwar nicht mehr relevant, aber jetzt sehr informativ.

Ich hatte vor längerem auch pairSerial mit VCCU versucht - ohne IOGrp und mich gewundert, warum das (teilweise?) nicht ging. Beholfen habe ich mir damals, direkt das Pairen mit Serial bei dem entsprechenden Interface zu veranlassen (was wunderlicherweise zu gehen schien trotz VCCU) bzw. halt mit pairFor... zu arbeiten.
Vielleicht will diesen Weg mal jemand testen? Diese Punkte sollten dann m.E. auch im Wiki zur VCCU zu finden sein.

[Otto123]

Naja, das Wiki war an der Stelle dann schlicht falsch (und mein Speicher im Kopf auch  ). Die VCCU muss ja relativ manuell angelegt werden.

Ich habe diesen Punkt im Wiki angepasst/korrigiert.

Was bleibt ist: Warum wird beim ersten set VCCU hmPairSerial ... ausgerechnet zunächst der IO zugewiesen der tot ist?
Es hat auch nichts mit der Reihenfolge im attr IOList zu tun. Er nimmt (momentan ich bin sicher das ändert sich) bei mir genau den der disconnected ist.
Ich habe ja verstanden: macht "FHEM" nicht CUL_HM

Gruß Otto

[Beta-User]

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).

[frank]

Erst beim letzten wird dann attr IOgrp auch bei dem neuen Gerät erzeugt - leider? mit Vorzug -> VCCU:myHmUARTLGW

wie sah denn attr iogrp der vccu aus? hattest du ein prefered io, oder allgemein nur vccu?
eventuell könnte man so über prefered io der vccu dem zu pairenden device dieses "übergeben".

[Otto123]

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