Hi,
Ausgangszustand:
Die VCCU hat zwei IODevs myHmUARTLGW und ser2netUart, der eine ist nicht erreichbar -> myHmUARTLGW:disconnected,ser2netUart:ok
Definition:
attr VCCU IOList myHmUARTLGW,ser2netUartund damit von der VCCU gesetzt
attr VCCU IODev myHmUARTLGW
ein set Befehl an die VCCU z.B.
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:
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 attr VCCU IODev ser2netUart
und alles scheint gut. :o
Ist das im Sinne des Erfinders? ;)
Gruß Otto
Soweit ich weiß, ist doch das IODev an der Stelle irrelevant (für eine Funktionalität).
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 (https://forum.fhem.de/index.php/topic,87502.msg810917.html#msg810917) 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 ::)
ZitatMit 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.
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.
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.
So ist es aktuell:
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! :o
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.
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
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!?!
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.
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.
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
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).
Zitat von: Otto123 am 13 Juni 2018, 13:38:37
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".
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
Zitat von: Beta-User am 13 Juni 2018, 14:08:56
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).
Zitat von: Otto123 am 13 Juni 2018, 14:12:42
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.
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
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
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.
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 (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.
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.