Einrichtung/Umzug auf eine VCCU: was ist VCCU_BtnX?

[Betonklotz]

Hallo,

nachdem ich mit FHEM umgezogen bin (backup erzeugt und das tar auf dem neuen Server entpackt), habe ich auch wie empfohlen eine VCCU eingrichtet, wobei erst einmal nur ein Interface (per socat) dran ist. Nach dem ersten Aussperren (im wahrsten Sinne des Wortes: der AES Key hing an einem Device, nicht der VCCU) läuft es nun scheinbar. Muss nur die ganzen Anbindungen und Hilfsscripte noch umbiegen, da der Server u.a. andere Partitionen und Pfade hat. Aber das nur als Vorgeschichte...
Meine eigentlichen Fragen zur VCCU:
1) Unmittelbar nach dem Anlegen der VCCU werden mir zwei neue Devices VCCU_Btn1 und VCCU_Btn3 angelegt deren Sinn und Zweck ich nicht verstehe. Kann mich nicht erinnern die vorher gesehen zu haben. Es scheint so, als ob da einige HM Geräte aufgelistet sind. Könnt ihr mir da helfen?
2) kurzzeitig hatte ich einen hmusb definiert, wie bekomme ich den wieder aus der VCCU raus (STATE, assigend IOs...)?
3) sollte ich per Hand in der fhem.cfg das (per socat) angebundene Interface nach oben (vor die VCCU Defnition) schieben, das ist aktuell ganz unten?

Code Auswählen Erweitern


define Virtual_HmUART_OG HMUARTLGW /dev/ttyVirtHMLANGW
setuuid Virtual_HmUART_OG 5e10d0ba-f33f-a38a-d70c-190bc6e096151321

Wenn ihr weitere Infos benötigt: fragt kurz nach.

Gruß, Robert

List der VCCU selbst:

Code Auswählen Erweitern


Internals:
   DEF        <HM-ID>
   FUUID      5cb7632a-f33f-a38a-39b0-126bd0d5236b11d2
   IODev      Virtual_HmUART_OG
   NAME       VCCU
   NOTIFYDEV  global
   NR         17
   NTFY_ORDER 50-VCCU
   STATE      hmusb:UAS,Virtual_HmUART_OG:ok
   TYPE       CUL_HM
   assignedIOs Virtual_HmUART_OG,hmusb
   channel_01 VCCU_Btn1
   channel_03 VCCU_Btn3
   READINGS:
     2020-01-04 18:53:37   CommandAccepted yes
     2020-01-04 19:02:34   IOopen          1
     2019-04-17 19:38:31   RegL_00.       
     2020-01-04 19:02:34   state           hmusb:UAS,Virtual_HmUART_OG:ok
   helper:
     HM_CMDNR   2
     mId        FFF0
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         Virtual_HmUART_OG
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      Virtual_HmUART_OG
   IOList     Virtual_HmUART_OG
   IOgrp      VCCU
   expert     2_raw
   hmKey      01:<mein_Key>
   icon       it_wifi
   model      CCU-FHEM
   subType    virtual
   webCmd     virtual:update


List von VCCU_Btn1

Code Auswählen Erweitern


Internals:
   DEF        <HM-ID>01
   FUUID      5cc5e9ca-f33f-a38a-dcbb-2c0fe070556013d4
   NAME       VCCU_Btn1
   NOTIFYDEV  global
   NR         98
   NTFY_ORDER 50-VCCU_Btn1
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     VCCU
   READINGS:
   helper:
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
Attributes:
   model      CCU-FHEM
   peerIDs   
   webCmd     press short:press long


sowie das list zu VCCU_Btn3

Code Auswählen Erweitern


Internals:
   DEF        <HM-ID>03
   FUUID      5cc5e9cd-f33f-a38a-1f5a-0470e527ad6508c0
   NAME       VCCU_Btn3
   NOTIFYDEV  global
   NR         99
   NTFY_ORDER 50-VCCU_Btn3
   STATE      ???
   TYPE       CUL_HM
   chanNo     03
   device     VCCU
   peerList   EG_BadAlette_Heizung_HM2E7C38_WindowRec,EG_Schlafzimmer_Heizung_HM2E7CD7_WindowRec,EG_ArbeitRobert_Heizung_Durchgang_HM2E86F8_WindowRec,EG_ArbeitRobert_Heizung_Eingang_HM2E87BA_WindowRec,EG_BadRobert_Heizung_HM5355FD_WindowRec,EG_Wohnzimmer_Heizung_HM53568B_WindowRec,
   READINGS:
     2020-01-04 19:02:30   peerList        EG_BadAlette_Heizung_HM2E7C38_WindowRec,EG_Schlafzimmer_Heizung_HM2E7CD7_WindowRec,EG_ArbeitRobert_Heizung_Durchgang_HM2E86F8_WindowRec,EG_ArbeitRobert_Heizung_Eingang_HM2E87BA_WindowRec,EG_BadRobert_Heizung_HM5355FD_WindowRec,EG_Wohnzimmer_Heizung_HM53568B_WindowRec,
   helper:
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
Attributes:
   model      CCU-FHEM
   peerIDs    2E7C3803,2E7CD703,2E86F803,2E87BA03,5355FD03,53568B03,
   webCmd     press short:press long


[martinp876]

Die buttons der vccu entsprechen den bis zu 50 kanälen welche es auch in der ccu gibt.
Der nutzen ist begrenzt. Du kannst aktor oder sensor Kanäle deiner devices mit ihnen peeren. Die kanäle sind natürlich virtuell.
Buttons welche damit gepeert sind leuchten bei betätigen grün. Gelb wenn sie gar nicht gepeert sind. Also ein optisches ACK.
Bei aktoren hast du die Möglichkeit einer Programmierung (Register) welche du dann mit press auslösen kannst.

Interessant und sicherlich weitgehend unbeachtet: lazyConfig devices, wenn zur vccu gepeert ( gepairt sowieso) arbeiten die command queue ab. Wenn du also config daten senden oder lesen willst, (peeren, register,,.) Wird es angearbeitet sobald ein trigger kommt. Bei einem bewegungsmelder kann ich somit die Programmierung vorbereiten und dann vorbei laufen.

Ios der vccu stehen i  attr ioList. Das musst du editieren da du entscheidest wer mitspielen soll. Nach einem Update sollte der state korrigiert werden

[Betonklotz]

Hallo Martin,

für mich würde dann gelten, die VCCU_BtnX Teile einfach nicht zu beachten und nach "hidden" zu verschieben. Interessanterweise sind da aber nicht alle HM Geräte drin... Egal, weg damit

Wenn du auf das list der VCCU selbst schaust: da ist als IO nur das virtuelle/per socat angebunden Interface drin. Was meinst du an der Stelel mit dem Update? rereadcfg, neustart, update aller Module auf Perl/Linux Ebene, oder was? Wäre aber (hoffentlich) auch nur kosmetischer Natur, bis jetzt läuft es so wie es soll.

Gruß, Robert

[Pfriemler]

langsam mit die Pferde ...

Die "Teile" haben ihre Berechtigung. Sie gehören default zu jeder VCCU. Man braucht sie nicht zwingend. Aber es lassen sich viele Dinge sehr einfach und nützlich damit realisieren.

Wenn Du sie bisher nicht beachtet hast, kann das so bleiben. Allerdings scheint Btn3 mit einigen Deiner Devices gepeert zu sein, und das wird seine Gründe gehabt haben (vielleicht stammt es von früheren Versuchen). Vielleicht hattest Du mal ein eigenes virtuelles Device mit der gleichen HmID erzeugt.

Jedenfalls dürfte VCCU sich das nicht von allein ausgedacht haben. Vielmehr dürften die betreffenden Geräte bzw. ihre Daten dazu geführt haben, dass VCCU das mit dem Button 3 assoziiert hat.

Wenn die Funktion obsolet ist, kannst Du sie zurückrüsten - dann aber möglichst mit sauberem unpeer etc, damit auch in den betroffenen Geräten die Verknüpfung gelöscht wird.

[Otto123]

Und es gibt einen hmusb

STATE      hmusb:UAS,Virtual_HmUART_OG:ok

Denn sieht die VCCU aber Du willst ihn vorenthalten - warum?

Gruß Otto

[Betonklotz]

Hallo,

wie gesagt: bewusst habe ich kein peering angelegt. Der VCC_Btn1 ist ja z.B. auch komplett leer und hat gar keine peerings.
Habe nun in den WindowRec der betroffenen Heizkörper jeweils ein

Code Auswählen Erweitern


set <device_name>_WindowRec peerBulk <HM-ID>03 unset

gemacht was auch geschluckt wurde und der peer im Gerät selbst verschwunden ist. ABER: im VCCU_Btn3 ist das peering immer noch vorhanden. Dort schlugen all meine Versuche fehl ein "unpeering" durchzuführen. Da ich mir keiner Schuld bewusst war, habe ich dann in der Oberfläche ein "delete this device" durchgeführt.
Sowohl nach einem rereadcfg, als auch restart werden sie nicht mehr neu angelegt (autocreate ist an).

Zum hmusb: ja, den hatte ich testweise mal definert. Soweit ich das verstehe, ist er aber gar nicht mehr zugeordent, vgl. das list der VCCU:

Code Auswählen Erweitern


Internals:
   DEF        <HM-ID>
   FUUID      5cb7632a-f33f-a38a-39b0-126bd0d5236b11d2
   IODev      Virtual_HmUART_OG
[...]
Attributes:
   IODev      Virtual_HmUART_OG
   IOList     Virtual_HmUART_OG
[...]

Wenn ich probiere die assignIO neu zu schreiben

Code Auswählen Erweitern


2020.01.06 08:30:22 3: CUL_HM set VCCU assignIO Virtual_HmUART_OG

passiert aber nichts, der hmusb bleibt weiterhin enthalten. Auch habe ich kein Gerät (mehr) names "hmusb", ein configcheck wirft auch keinen Fehler... In der fhem.cfg gab es noch ein Vorkommen, habe ich per Hand gelöscht und ein Neustart vollzogen: nun ist auch der hmusb weg

So sieht es sauber aus und es funktioniert weiterhin alles wie es soll (Fensterkontakte/_WindowRec habe ich nicht in Betrieb/installiert) und die HM Geräte antworten alle und lassen sich schalten.

Gruß, Robert

[martinp876]

Also was du nach Hidden verschiebst ist deine Sache.
Update: set vccu update. was sonst?

Sicher kannst du einfach erkennen, dass du bs zu 50 Kanäle anlegen kannst.
Wie schon angemerkt hast du einiges mit Btn3 gepeert. Du kannst es immernoch nach hidden verschieben.

wie gesagt: bewusst habe ich kein peering angelegt.

dann prüfe es

Der VCC_Btn1 ist ja z.B. auch komplett leer

ein Kanal wird IMMER angelegt.

ABER: im VCCU_Btn3 ist das peering immer noch vorhanden.

logisch. Warum sollte er automatisch gelöscht werden? Ich weiss nicht, was du vor hast. Lösche ihn manuell, wenn du willst.
Oder nutze

Code Auswählen Erweitern

set vccu virtual 1

So sieht es sauber aus und es funktioniert weiterhin alles wie es soll

ein

Code Auswählen Erweitern

get hm configCheck
wird immer empfohlen.

Übrigens: Das feature lazyConfig geht dir nun verloren.
Ich peere alle (ALLE) Kanäle eines entsprechenden Device mit einen VCCU Kanal - aus diesen Grund. So kann fhem gelegentlich und nebenbei fehlende Config-Daten nach laden - und anderes.

[Betonklotz]

Hallo,

irgendwie verstehe ich das mit der VCCU doch noch nicht so ganz...
Meine simple Denkweise und Anforderung: unter der VCCU werden alle pairings zusammengefasst und alle HWInterfaces. Peering hingegen erfolgt nur zw. Devices (z.B. ein Heizkörperthermostat mit einem Temperatursensor), nicht aber zw. Device und VCCU selbst. ==> die VCCU macht also "nur" eine Verteilung auf die (remote angeschlossenen) HW Interfaces, hat sonst aber keine weitere Funktion.

@Martin:
Warum sollte ich mit

Code Auswählen Erweitern


set vccu virtual 1

einen (virtuellen) Kanal in der VCCU anlegen? Die VCCU soll nichts weiter machen, also was bietet/nützt einem der (virtuelle) Kanal in meinem Fall?
configcheck war wie gesagt komplett sauber (leeres popup mit configCheck done: und OK Schaltfläche).
Was lazyconfig angeht: wird das denn von FHEM unterstützt (https://wiki.fhem.de/wiki/HomeMatic#LazyConfig)? Oder bezieht sich das verwerfen nur auf den Betrieb mit einem CUL? Wie auch immer: wenn ich keine Bewegungsmelder und/oder Fernbedienungen nutze (kommt bei mir nicht zum Einsatz), dann macht das Feature auch keinen Sinn, da es im allgemeinen die Devices nicht unterstützen, korrekt? Für die Zukunft gebe ich dir aber völlig Recht: Geräte die lazy config unterstützen sollten an einen virtuellen Kanal der VCCU gehängt werden (so verstehe ich zumindest die Doku) und man sollte sich das nicht "verbauen". Nun die Preisfrage: sehe ich irgendwo ob lazyconfig (von meinen devices) unterstützt wird und/oder gibt es einen Auflistung?

Gruß, Robert

[Pfriemler]

Also nach meinem Verständnis war ein virtueller Button für lazyConfig nur nötig, wenn es nicht ohnehin ein peering (mit einem anderen Gerät) gibt, was eine bidirektionale Kommunikation hervorruft, in die sich FHEM dann einklinken kann.
Ein Irrglaube?

Welche Gerätetypen lazyConfig unterstützen, zeigt get <hminfo> model (oder so ähnlich).. Eine Auflistung, welche FHEM-Geräte das unterstützen, kenne ich nicht. Prinzipiell sind das ja nur batteriebetriebene Sensoren, die bis zum nächsten physischen Event an ihren Inputs schlafen und die sich auch nicht durch einen Burst aufwecken lassen.
Aber es ist müßig zu diskutieren ob man die virtuals braucht oder nicht. Sie fressen kein Brot und keine Performance, man kann sie auch so ignorieren oder in einen (Abstell)Raum schieben...

[martinp876]

unter der VCCU werden alle pairings zusammengefasst und alle HWInterfaces.

nein - leider nicht. Nicht in form von Daten in FHEM.
Dazu habe ich sie zu spät eingeführt.
Aber ja, faktisch ist die VCCU die Inkarkation der Zentralen HmId. Somit wird de-fakto alles zur VCCU gepairt. Praktisch geht es aber auch ohne VCCU - trotzdem ist pairen über das IO möglich.

Peering hingegen erfolgt nur zw. Devices

korrekt

nicht aber zw. Device und VCCU selbst

zu VCCU "KANÄLEN" ist peering möglich.

Pairen verknüpft "devices" mit der Zentrale.
Peeren verknüpft kanäle mit Kanälen (siehe Wiki)

einen (virtuellen) Kanal in der VCCU anlegen?

Weil es typisch ist. Allerdings ist es mir am Ende egal, wie du es machst. Ich brauche einen Kanal schon für das peeren mit lazy-Config (jetzt schon zig-mal erklärt)

Was lazyconfig angeht: wird das denn von FHEM unterstützt

logisch

Oder bezieht sich das verwerfen nur auf den Betrieb mit einem CUL?

CUL hat nichts damit zu tun.

Wie auch immer: wenn ich keine Bewegungsmelder und/oder Fernbedienungen nutze (kommt bei mir nicht zum Einsatz), dann macht das Feature auch keinen Sinn, da es im allgemeinen die Devices nicht unterstützen, korrekt?

keine Ahnung, was "im Allgemeinen" ist. Einige Remotes nutzen layz config. Ich gehe aber jetzt nicht deine gesamte Deivce.liste durch

Nun die Preisfrage: sehe ich irgendwo ob lazyconfig (von meinen devices) unterstützt wird und/oder gibt es einen Auflistung?

Code Auswählen Erweitern

get hm models
get <device> deviceInfo

[martinp876]

Also nach meinem Verständnis war ein virtueller Button für lazyConfig nur nötig, wenn es nicht ohnehin ein peering (mit einem anderen Gerät) gibt

nein. Nach meinen Tests (Doku von eq3 habe ich keine) geht es nur, wenn der Kanal sich bei der Zentrale meldet.

Eine Auflistung, welche FHEM-Geräte das unterstützen, kenne ich nicht.

nun, einfach das Kommando get hm models ausführen und sortieren.

Aber es ist müßig zu diskutieren ob man die virtuals braucht oder nicht.

ja, ist für mich nun auch beendet. Es ist keiner gezwungen.

[Pfriemler]

Danke für die Aufklärung - ist ja eigentlich auch logisch, dass FHEM in Antwort auf eine gezielte Mitteilung des Gerätes an seine Zentrale überhaupt Gehör für eine Konfigurationsanforderung findet. Nur habe ich etliche Fensterkontakte nicht mit einem virtuellen Button gepeert, sie bekommen aber trotzdem ein ACK vom Interface und m.W. geht auch lazyConfig damit. Ich teste das nochmal.

nun, einfach das Kommando get hm models ausführen und sortieren.

Das liefert die Info, welche HM-Gerätebezeichnungen lazyConfig unterstützen. Die Zuordung, welche Geräte der User als welches FHEM-Device (Name, Alias) einsetzt, muss der User händisch machen.

[Betonklotz]

Hallo,

danke für die Erklärungen und eure Geduld.
Und nein, alle meine Devices (die ich zudem auch gar nicht gepostet hatte) durchgehen erwarte ich nicht. Mit dem hminfo Befehl bin ich mehr als glücklich (s.u.)

Was meine Angaben bzgl. CUL angehen:
Aus dem Wiki https://wiki.fhem.de/wiki/HomeMatic#LazyConfig

LazyConfig

Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung. Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.A. auf ein Config.

Daher die Frage nach Unterstützung.

Generell: ich kann jetzt sagen, dass ich zwei Geräte (zwei mal ein HM-MOD-EM-8) habe die lazyconfig unterstützen, d.h. es wäre für mich auch sinnvoll. Von daher würde ich jetzt, diesmal bewussst, einen virtuellen Kanal

Code Auswählen Erweitern


set vccu virtual 1

in der VCCU anlegen. Mit diesem Kanal würde ich dann die 16 (jedes der beiden HM-MOD-EM-8 hat acht Kanäle) Kanäle

Code Auswählen Erweitern


set Outdoor_ZustandWasser_HM6675AA_Btn_01 peerSmart VCCU_Btn1
set Outdoor_ZustandWasser_HM6675AA_Btn_02 peerSmart VCCU_Btn1
[...]
set Outdoor_ZustandWasser_HM6675AA_Btn_08 peerSmart VCCU_Btn1
und das zweite Device analog

der HM Devices peeren. Passt da mein Verständnis, bzw. habe ich es richtig verstanden? Hintergrund: im Wiki steht

Code Auswählen Erweitern


set <actChan> peerSmart <sensChan>

wobei der HM-MOD-EM-8 aus HW Sicht ein Sensor ist (ein HM Modul das acht digitale Eingänge durchreicht) und somit die VCCU (besser: der virtuelle Kanal der VCCU) der Aktor ist. Somit müsste der Befehl genau andersrum sein, d.h.

Code Auswählen Erweitern


set VCCU_Btn1 peerSmart Outdoor_ZustandWasser_HM6675AA_Btn_01
set VCCU_Btn1 peerSmart Outdoor_ZustandWasser_HM6675AA_Btn_02
[...]
set VCCU_Btn1 peerSmart Outdoor_ZustandWasser_HM6675AA_Btn_08

Oder habe ich es (mal) wieder falsch verstanden?

Gruß, Robert

[Pfriemler]

Moin, in Kurzform:
1. Obacht! set vccu virtual x setzt keine neuen, sondern die Anzahl der virtuellen Kanäle. Hattest Du vorher 10 und setzt jetzt set vccu virtual 1, sind 2-10 gelöscht!

2. hinsichtlich der Rolle Remote/Aktor stellen die vccu-Buttons einen Sonderfall dar. Sie funktionieren als beides.
Gepeert wird normalerweise vom Sensor zum Aktor. Deine ersten Varianten sind also korrekt.

Sonst richtig: alle 16 Kanäle auf einen vccu-Button ist korrekt.

Dass CUL/CUNO nicht lazyConfig unterstützen, ist u.a. eine Hardwarefrage. FHEM erkennt das und versucht es also erst gar nicht.


Nachtrag: mir fällt auf: Es sind nicht alle Kanäle meiner EM-8 mit der vccu gepeert. Dennoch scheint es zu funktionieren, Konfigbefehle auch für andere Kanäle eines Modul zu senden, wenn man den gepeerten Button betätigt. Für den Komfort würde es demnach genügen, nur einen (leicht erreichbaren) Button mit der vccu zu peeren und diesen dann zu betätigen. Logisch nachvollziehbar: Es wird ja immer mit einem Gerät kommuniziert, nicht mit einem Kanal. Martin?