FHEM Forum

Hallo zusammen!

Ich habe einen USB Stick von Busware und einen Homematic WLAN Gateway (die Platine, die es mal hier im Forum gab) bei mir im Einsatz. Bis dato lief alles über den Busware Stick, würde das aber gerne redundant über beide laufen lassen wozu ja auch die VCCU gedacht ist. Die ist soweit bei mir auch eingerichtet, aber ich habe da z.B. ein für mich aktuell nicht nachvollziehbares Problem:

Bis dato hat das Öffnen der Tür (Keymatic) nur funktioniert, wenn der Busware-Stick angeschlossen ist. Ich dachte mir ok, der ist vielleicht noch irgendwie direkt mit der Keymatic verheiratet, versetz ich die VCCU in den Lernmodus und Paire dann nochmal die Keymatic direkt mit der VCCU. Soweit getan, dann hatte ich aber das Phänomen, dass ich nur noch über den Homematic WLAN Gateway schalten konnte, nicht aber über den Busware Stick.

Was ich nicht ganz geblickt habe, aber vielleicht ist das mein Fehler: Muss die hmId von VCCU und den beiden Hardware Devices identisch sein? Schau ich in die VCCU, ist bei DEF der Wert festgelegt, der auch bei der Hardware als hmId angezeigt wird. Hat das evtl. was damit zu tun, dass die Keymatic AES verwendet!?

Hi,

zeig doch bitte ein list deiner VCCU

Den eigene HMKey (falsl vorhanden) bitte rauslöschen

Gruß Otto

Meinst du das hier?
Internals:
   CCD_MSGCNT 7
   CCD_RAWMSG xxxxxxxx....::-102:CCD
   CCD_RSSI   -102
   CCD_TIME   2018-12-31 15:06:00
   DEF        xxxxxx
   HMUARTLGW1_MSGCNT 48
   HMUARTLGW1_RAWMSG xxxxxxxx....
   HMUARTLGW1_RSSI -43
   HMUARTLGW1_TIME 2018-12-31 12:07:23
   IODev      CCD
   IODevName  CCD,HMUARTLGW1
   LASTInputDev CCD
   MSGCNT     55
   NAME       VCCU
   NOTIFYDEV  global
   NR         504
   NTFY_ORDER 50-VCCU
   STATE      CCD:ok,HMUARTLGW1:disconnected,
   TYPE       CUL_HM
   assignedIOs CCD,HMUARTLGW1
   lastMsg    No:20 - t:03 s:xxxxxx d:yyyyyy xxxxxxxx....
   protLastRcv 2018-12-31 12:12:35
   protRcv    49 last_at:2018-12-31 12:12:35
   protRcvB   8 last_at:2018-12-31 12:12:35
   rssi_at_CCD cnt:3 min:-49.5 max:-47 avg:-47.83 lst:-47
   rssi_at_HMUARTLGW1 cnt:46 min:-55 max:-42 avg:-47.54 lst:-43
   READINGS:
     2018-12-31 12:06:54   CommandAccepted yes
     2018-12-31 12:12:35   aesReqTo        Wohnung3.Flur.Device.Eingangstuer1
     2018-12-31 10:41:26   recentStateType ack
     2018-12-31 12:12:59   state           CCD:ok,HMUARTLGW1:disconnected,
     2018-12-30 10:18:50   unknown_12AE7D  received
     2018-12-31 12:43:11   unknown_16D90A  received
     2018-12-31 15:06:00   unknown_B3855F  received
     2018-12-31 11:59:12   unknown_F10000  received
   helper:
     HM_CMDNR   32
     PONtest    1
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1546254756.00151
       prefIO     
       vccu       VCCU
       ioList:
         CCD
         HMUARTLGW1
     mRssi:
       mNo        20
       io:
         CCD:
           -39
           -39
         HMUARTLGW1:
           -43
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     rssi:
       at_CCD:
         avg        -47.8333333333333
         cnt        3
         lst        -47
         max        -47
         min        -49.5
       at_HMUARTLGW1:
         avg        -47.5434782608696
         cnt        46
         lst        -43
         max        -42
         min        -55
Attributes:
   IODev      CCD,HMUARTLGW1
   IOList     CCD,HMUARTLGW1
   IOgrp      VCCU
   expert     2_raw
   icon       cul_usb
   model      CCU-FHEM
   room       FHEM | Hardware
   subType    virtual
   webCmd     virtual:update


Die hmid der vccu wird von allen ihr zugeordneten ios genutzt und dort als attribut eingetragen. Kanst du selbst prüfen.
Ausgrauen brauchst du die ids übrigens nicht. Die werden in klartext gefunkt und jeder in reichweite kann sie sehen. Ich nicht, bin nicht in Reichweite, könnte dein system aber auch nicht beeinflussen. Nicht in Reichweite.

Wenn du von fhem kommandos an das device schicken konntest war es angelernt. Es wäre clever gewesen die vccu mit der hmid der ios anzulegen. Kein anlernen notwendig. Dann das 2. Io anlegen und der vccu zuweisen. Die vccu setzt alle attribute.
Das device nach anleitung der vccu zuordnen.

Natürlich ist aes zu beachten. Bei keymatic ein muss (und sicherheitsrelevant!!)
Was also geht aktuell? Kann fhem irgendwas lesen?

Zitat von: martinp876 am 31 Dezember 2018, 15:26:33
Die hmid der vccu wird von allen ihr zugeordneten ios genutzt und dort als attribut eingetragen. Kanst du selbst prüfen.
Ausgrauen brauchst du die ids übrigens nicht. Die werden in klartext gefunkt und jeder in reichweite kann sie sehen. Ich nicht, bin nicht in Reichweite, könnte dein system aber auch nicht beeinflussen. Nicht in Reichweite.

Okay :)

Zitat von: martinp876 am 31 Dezember 2018, 15:26:33Wenn du von fhem kommandos an das device schicken konntest war es angelernt. Es wäre clever gewesen die vccu mit der hmid der ios anzulegen. Kein anlernen notwendig. Dann das 2. Io anlegen und der vccu zuweisen. Die vccu setzt alle attribute.
Das device nach anleitung der vccu zuordnen.

Ja, bei der Umstellung und meinem "rumgebastel" bin ich wohl nicht den besten Weg gegangen :-/

Zitat von: martinp876 am 31 Dezember 2018, 15:26:33Natürlich ist aes zu beachten. Bei keymatic ein muss (und sicherheitsrelevant!!)
Was also geht aktuell? Kann fhem irgendwas lesen?

Es geht, dass bei der Keymatic der Status ausgelesen wird oder man z.B. auch die Tür öffnen kann. Sobald ich den Busware USB-Stick ziehe, geht nichts mehr. Das meintest du, oder?

Hab auch nochmal nachgeschaut: Bei der Keymatic ist bei R-pairCentral die hmId der VCCU hinterlegt, das sollte also stimmen.

Um es nochmal ganz klar zu betonen (weil ich das in den Antworten so nicht gefunden habe)

Zitat von: prodigy7 am 31 Dezember 2018, 12:23:10
Muss die hmId von VCCU und den beiden Hardware Devices identisch sein?

Definitiv.

Hast Du im Busware einen eigenen Key verwendet? (attr ... hmKey 01:xxxx....)? mit einer VCCU gehören die nämlich in die VCCU, damit alle IOs damit umgehen können.

Gesundes neues Jahr,

die VCCU sieht aus meiner Sicht gut aus.
Hast Du bei den Geräten auch überall das attr <> IOgrp VCCU gesetzt? Sonst klappt quasi die andere Seite der Fehlertoleranz nicht.

Gruß Otto

Leider war mein Start bzw. die Tage danach nicht so gesund, komme jetzt erst wieder mal dazu, mich um das Thema zu kümmern.

Also bei der Keymatic steht derzeit bei IOgrp der Wert VCCU:CCD.
Wenn ich es richtig verstanden habe, ist ja CCD nur das bevorzugte Device, bei nicht Verfügbarkeit springt er aber auf eine Alternative oder?

Vielleicht läuft es auch noch an anderer Stelle nicht rund in meinem Setup? Bin nach Anleitung vorgegangen und habe den Befehlattr TYPE=CUL_HM:FILTER=DEF=xxxxxx:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCU
xxxxxx habe ich durch die hmId der VCCU ersetzt, VCCU heißt bei mir auch tatsächlich VCCU.

Was mich verwirrt in der Wiki-Anleitung zur VCCU:

ZitatIn einer bestehenden FHEM-Installation mit mehreren/vielen Devices, kann das Setzen der IOgrp aufwendig sein. Man kann mit einem Befehl einfach alle HM Geräten mit der sechsstelligen DEF (HMID) filtern (jeder Punkt steht für ein beliebiges Zeichen):

list TYPE=CUL_HM:FILTER=DEF=......

Dass, was DEF bei der VCCU ist, ist die hmId bei den anderen Geräten, richtig? Wenn ich bei DEF aber die der VCCU angebe, bekomme ich doch nur ein Listing wie auch bereits von mir hier gepostet (nicht mehr, nicht weniger). Insofern verstehe ich die Erläuterung/Nutzung des Befehls nicht so ganz in der Anleitung.

Zitat von: Pfriemler am 31 Dezember 2018, 17:58:24
Um es nochmal ganz klar zu betonen (weil ich das in den Antworten so nicht gefunden habe)Definitiv.

Hast Du im Busware einen eigenen Key verwendet? (attr ... hmKey 01:xxxx....)? mit einer VCCU gehören die nämlich in die VCCU, damit alle IOs damit umgehen können.

Da war ich mir die Tage nicht sicher, ob ich einen Key gesetzt hatte. Soweit sieht es wohl aus, als hätte ich noch keinen Key gesetzt gehabt (Siehe https://forum.fhem.de/index.php/topic,94878.msg876583.html#msg876583)

ZitatWas mich verwirrt in der Wiki-Anleitung zur VCCU:
Zitat
In einer bestehenden FHEM-Installation mit mehreren/vielen Devices, kann das Setzen der IOgrp aufwendig sein. Man kann mit einem Befehl einfach alle HM Geräten mit der sechsstelligen DEF (HMID) filtern (jeder Punkt steht für ein beliebiges Zeichen):

list TYPE=CUL_HM:FILTER=DEF=......
Dass, was DEF bei der VCCU ist, ist die hmId bei den anderen Geräten, richtig? Wenn ich bei DEF aber die der VCCU angebe, bekomme ich doch nur ein Listing wie auch bereits von mir hier gepostet (nicht mehr, nicht weniger). Insofern verstehe ich die Erläuterung/Nutzung des Befehls nicht so ganz in der Anleitung.

Mach  mal bitte einen Vorschlag wie man das schreiben soll damit es nicht verwirrend ist? Ich habe es versucht so gut wie möglich zu erklären  :'(

Die HM Geräte haben einen sechstelligen ID,  bei exakt diesen Geräten muss das attr gesetzt werden.
Mach doch einfach den Befehl so wie er dasteht und schaue der Magie zu :)
list TYPE=CUL_HM:FILTER=DEF=......

BTW das hier:  ist Quatsch!!! attr TYPE=CUL_HM:FILTER=DEF=xxxxxx:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCUdas steht so nicht im Wiki!
Im Wiki steht
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector IOgrp VCCU
Und die Punkte sind ein regExp !!!

Gruß Otto

...... ist nicht xxxxxx. Die sechs Punkte stehen nicht für eine beliebige Einsetzung, sondern für einen Begriff mit genau sechs Zeichen. So kann man in HM Geräte mit sechsstelligen hmId, bei denen das IOgrp gesetzt werden soll, von den Kanälen mit achtstelliger hmId, wo kein IOgrp zu setzen ist, unterscheiden.

Also das ...... habe ich auch so interpretiert, dass ich dieser Stelle die hmId eingesetzt habe und es nicht als Regex gesehen habe. Regex hätte anders ausgesehen.
Mich irritiert aber, dass wenn ich ein
list TYPE=CUL_HM:FILTER=DEF=xxxxxx:FILTER=subType!=virtual:FILTER=model!=ActionDetector
ausführe, nichts angezeigt bekomme. Eigentlich müssten da alle Geräte außer der VCCU gelistet werden oder?

Nö da müssten alle Geräte mit der DEF xxxxxx angezeigt werden.  :o

Ja ^^ xxxxxx = meine hmId.

Die Sache ist, der Befehl soll doch bei allen Geräten außer VCCU, ActionDetector und virtual die ioGrp setzen oder? Dann müsste es
list TYPE=CUL_HM:FILTER=DEF!=123456:FILTER=subType!=virtual:FILTER=model!=ActionDetector
heißen (123456 = hmId/DEF der VCCU)?

Sag mal willst Du nicht? Es hat nichts mit Deiner hmID zu tun!
Das hier zeigt Dir alle CUL_HM Geräte mit einer sechstelligen DEF:
list TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=model!=ActionDetector
Oder nimm den (ohne jede Änderung):
list TYPE=CUL_HM:FILTER=DEF=[0-9a-fA-F]{6}:FILTER=DEF!=[0]{6}

Okay, ich glaub der Groschen ist jetzt bei mir gefallen!
Ich hatte das ...... im Wiki als Platzhalter verstanden und entsprechend auf der dicken Leitung gesessen. Hab aber eben gesehen, dass du im Wiki den Befehl nochmal angepasst hast. Ich habe den jetzt ausgeführt und jetzt hat er auch einige Devices aktualisiert.
Sorry, echt auf dem Schlauch gesessen! Ich acker mich mal weiter durch ...

Dein angepasster Befehl in #14 liefert übrigens alle CUL_HM Geräte, also auch die Channels. Und die VCCU wird zweimal gefiltert.
::)
Das war es ja gerade was nicht gewünscht war.  ;)

Ja ich habe das Wiki gestern geändert in der Hoffnung, dass man es jetzt besser versteht. Ist auch weniger Text - den eh keiner lesen will :)

Gruß Otto

SO, endlich wieder Zeit gefunden! Danke für deine Geduld Otto, es war wirklich der unvollständige bzw. von mir falsch interpretierte Befehl. Ich kann jetzt problemlos den Stick abziehen und dennoch läuft alles. Schwere Geburt.... :-P