rename von Channel in VCCU funktionert nicht fürs anlegen eines virtuellen Fenst

Begonnen von Ruggy, 26 Januar 2023, 17:52:45

Vorheriges Thema - Nächstes Thema

Ruggy

Hallo,

möchte einen virtuellen Fensterkontakt anlegen um ein Homematic Thermostat HM-CC-RT-DN zu steuern.
Wenn dies klappt, mit einen externen Temperatursensor zusätzlich verbinden.

Hatte vorher noch kein VCCU eingerichtet sondern HmUART.
Habe dann vor einiger Zeit eine VCCU eingerichtet und hiermit bereits zwei virtuelle Fensterkontakte angelegt (Channel_1 und Channel_2 für Küche und Bad).

Jetzt wollte ich noch einen dritten virtuellen Fensterkontakt fürs Schlafzimmer anlegen.
Habe das im Device VCCU ausgewählt um folgenden Befehl auszuführen.
set VCCU virtual 3

"3" habe ich verwendet für den 3. Channel; 1 u. 2 waren ja bereits vergeben.

Es wurde channel_03 angelegt.

Wenn ich jetzt
rename VCCU_Btn3 SCHLAFZIMMER_virt_Fenster
eingebe wird der Name von Channel_03 nicht geändert und bleibt VCCU_Btn3
Außerdem wird der Name  "VCCU_Btn3" dann nicht als "Link" dargestellt, so wie bei den anderen zwei Channel.

Was mache ich falsch?

Ist das richtig, dass ich für jedes Gerät einen extra Channel verwende. Also z.B. für den nächsten virt. Temperatursensor die Nr. 4?

Hier das List von VCCU nach den o.g. rename:
Internals:
   DEF        FA3B12
   FUUID      633dd594-f33f-194f-2aad-21dfef915dc197a4
   IODev      HmUART
   NAME       VCCU
   NR         624
   NTFY_ORDER 48-VCCU
   STATE      HmUART:ok
   TYPE       CUL_HM
   assignedIOs HmUART
   channel_01 KUECHE_virt_Fenster
   channel_02 BAD_virt_Fenster
   channel_03 VCCU_Btn3
   disableNotifyFn 1
   eventCount 9
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1674750616.69116
           VALUE      HmUART:ok
   READINGS:
     2023-01-26 11:41:18   IODev           HmUART
     2023-01-26 17:30:16   IOopen          1
     2022-10-05 21:17:21   RegL_00.       
     2022-10-09 10:11:22   cfgState        ok
     2022-10-05 21:06:23   commState       CMDs_done_Errors:1
     2023-01-26 11:35:20   hmPair          timeout
     2023-01-26 17:30:16   state           HmUART:ok
     2023-01-25 20:06:51   unknown_3A1995  received
     2022-10-05 21:29:41   unknown_5F8DF5  received
   helper:
     HM_CMDNR   47
     mId        FFF0
     peerFriend -
     peerOpt    -:virtual
     regLst     
     rxType     1
     ack:
     bm:
       CUL_HM_Get:
         cnt        16
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 17:21:17
         max        0.00159502029418945
         tot        0.0163390636444092
         mAr:
           HASH(0x5fc9170)
           VCCU
           ?
       CUL_HM_Set:
         cnt        44
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 17:30:11
         max        0.106526851654053
         tot        0.417810678482056
         mAr:
           HASH(0x5fc9170)
           VCCU
           virtual
           3
     cmds:
       TmplKey    :no:1674750616.70874
       TmplTs     1674750616.70874
       cmdKey     0:1:1::VCCU:FFF0:00:
       cmdLst:
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         tplSet_0   -tplChan-
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       vccu       VCCU
       ioList:
         HmUART
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOList     HmUART
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     rawReg
   model      CCU-FHEM
   room       Homematic
   subType    virtual
   webCmd     virtual:update


Ein Device von SCHLAFZIMMER_virt_Fenster ist vorhanden:

Internals:
   CFGFN     
   DEF        FA3B1203
   FUUID      63d2aa93-f33f-194f-c622-01fd000cbca516a1
   NAME       SCHLAFZIMMER_virt_Fenster
   NR         1600
   NTFY_ORDER 48-VCCU_Btn3
   STATE      ???
   TYPE       CUL_HM
   chanNo     03
   device     VCCU
   disableNotifyFn 1
   READINGS:
   helper:
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     bm:
       CUL_HM_Define:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 17:30:11
         max        0.0328080654144287
         tot        0.0328080654144287
         mAr:
           HASH(0x2485d88)
           VCCU_Btn3 CUL_HM FA3B1203
     cmds:
       TmplKey    :no:1674750616.70866
       TmplTs     1674750616.81516
       cmdKey     1:0:0::VCCU::03:
       cmdLst:
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     peerIDsH:
     role:
       chn        1
       vrt        1
     tmpl:
Attributes:
   model      CCU-FHEM
   webCmd     press short:press long

Beta-User

Vermutlich handelt es sich bei der Anzeige in der VCCU selbst um ein Darstellungsthema, reload der Seite könnte helfen.

ABER: Jeder Raum sollte sein Stammdevice haben, mehr wie einen Fensterkontakt und einen Temp-Sensor sollte man nicht auf ein Hauptdevice legen. (Falls du es wissen willst warum: selber testen...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy


Beta-User

Vermutlich müßtest du die DEF anfassen oder einen FHEM-Neustart durchführen, damit das akualisiert wird.

Aber nochmal: So wie du das im Moment angehst, wird es effektiv aus anderen Gründen nicht funktionieren. Mach mal das "Badfenster" auf und schau nach, was in den RT's in der Küche passiert...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Nach einem Neustart wurde der Name geändert.

Wenn ich das Badfenster aufmacht, macht das RT in der Küche nichts. Das RT im Bad erkennt die Fensteröffnung und regelt die Temperatur herunter.
Genauso ist es, wenn ich das Küchenfenster aufmache. RT im Bad bleibt unverändert nur der RT in der Küche reagiert.

Was wäre z.B. das Stammdevice in der Küche. Meinst du das im Bezug auf das RT?
Hier habe ich schon für jeden Raum ein RT.

Hier z.B. das von der Küche:

Internals:
   DEF        5F8DF5
   FUUID      633ddba4-f33f-194f-5cb6-acb8f02d4f0ff73d
   HmUART_MSGCNT 19
   HmUART_RAWMSG 0500003C6C86105F8DF50000000A8CAB0D0900
   HmUART_RSSI -60
   HmUART_TIME 2023-01-26 20:59:01
   IODev      HmUART
   LASTInputDev HmUART
   MSGCNT     19
   NAME       KUECHE_HEIZUNG
   NR         625
   NTFY_ORDER 48-KUECHE_HEIZUNG
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 KUECHE_HEIZUNG_Weather
   channel_02 KUECHE_HEIZUNG_Climate
   channel_03 KUECHE_HEIZUNG_WindowRec
   channel_04 KUECHE_HEIZUNG_Clima
   channel_05 KUECHE_HEIZUNG_ClimaTeam
   channel_06 KUECHE_HEIZUNG_remote
   disableNotifyFn 1
   eventCount 25
   lastMsg    No:6C - t:10 s:5F8DF5 d:000000 0A8CAB0D0900
   protLastRcv 2023-01-26 20:59:01
   protRcv    19 last_at:2023-01-26 20:59:01
   protSnd    4 last_at:2023-01-26 20:33:36
   protSndB   2 last_at:2023-01-26 20:33:35
   protState  CMDs_done
   rssi_at_HmUART cnt:19 min:-62 max:-58 avg:-59.57 lst:-60
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1674761616.80875
           VALUE      CMDs_done
   READINGS:
     2023-01-26 20:33:36   CommandAccepted yes
     2023-01-26 16:33:46   D-firmware      1.5
     2023-01-26 16:33:46   D-serialNr      OEQ1702075
     2023-01-26 20:33:35   IODev           HmUART
     2023-01-26 16:33:46   PairedTo        0xFA3B12
     2023-01-26 16:33:46   RegL_00.        00:00 01:01 02:01 09:01 0A:FA 0B:3B 0C:12 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00
     2023-01-26 16:41:37   RegL_07.       
     2023-01-26 20:59:01   actuator        9
     2022-10-06 22:04:11   aesCommToDev    ok
     2022-10-06 22:04:11   aesKeyNbr       00
     2023-01-26 20:59:01   battery         ok
     2023-01-26 20:59:01   batteryLevel    2.8
     2023-01-26 16:34:54   cfgState        ok
     2023-01-26 20:33:36   commState       CMDs_done
     2023-01-26 20:59:01   desired-temp    17.5
     2023-01-26 16:31:17   fwUpdate        done
     2023-01-26 20:59:01   measured-temp   17.1
     2023-01-26 20:59:01   motorErr        ok
     2023-01-26 16:32:22   powerOn         2023-01-26 16:32:22
     2023-01-26 16:32:22   recentStateType info
     2023-01-26 20:33:36   state           CMDs_done
     2023-01-26 16:32:25   time-request    -
   helper:
     HM_CMDNR   108
     lastMsgTm  1674763141.71234
     mId        0095
     peerFriend -
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     bm:
       CUL_HM_Get:
         cnt        2
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 21:00:43
         max        0.0015721321105957
         tot        0.00289702415466309
         mAr:
           HASH(0x5eb7770)
           KUECHE_HEIZUNG
           ?
       CUL_HM_Set:
         cnt        78
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 20:24:59
         max        0.0457000732421875
         tot        0.11537504196167
         mAr:
           HASH(0x5eb7770)
           KUECHE_HEIZUNG
           ?
     cmds:
       TmplKey    :no:1674761003.27712
       TmplTs     1674761003.27712
       cmdKey     0:1:0::KUECHE_HEIZUNG:0095:00:
       cmdLst:
         assignHmKey noArg
         burstXmit  noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         inhibit    [(on|{off})]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sysTime    noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +5F8DF5,00,00,00
       nextSend   1674763141.77331
       rxt        2
       vccu       VCCU
       p:
         5F8DF5
         00
         00
         00
       prefIO:
     mRssi:
       mNo        6C
       io:
         HmUART:
           -56
           -56
     peerIDsH:
     prt:
       awake      0
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_HmUART:
         avg        -59.5789473684211
         cnt        19
         lst        -60
         max        -58
         min        -62
     shRegW:
       07         04
     tmpl:
Attributes:
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   commStInCh off
   expert     rawReg
   firmware   1.5
   model      HM-CC-RT-DN
   room       CUL_HM,Heizung,Homematic,Kueche
   serialNr   OEQ1702075
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Hier nochmal von der VCCU wie es jetzt aussieht:

Internals:
   DEF        FA3B12
   FUUID      633dd594-f33f-194f-2aad-21dfef915dc197a4
   IODev      HmUART
   NAME       VCCU
   NR         624
   NTFY_ORDER 48-VCCU
   STATE      HmUART:ok
   TYPE       CUL_HM
   assignedIOs HmUART
   channel_01 KUECHE_virt_Fenster
   channel_02 BAD_virt_Fenster
   channel_03 SCHLAFZIMMER_virt_Fenster
   disableNotifyFn 1
   eventCount 4
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1674761006.97093
           VALUE      HmUART:ok
   READINGS:
     2023-01-26 20:23:21   IODev           HmUART
     2023-01-26 20:23:26   IOopen          1
     2022-10-05 21:17:21   RegL_00.       
     2022-10-09 10:11:22   cfgState        ok
     2022-10-05 21:06:23   commState       CMDs_done_Errors:1
     2023-01-26 11:35:20   hmPair          timeout
     2023-01-26 20:23:26   state           HmUART:ok
     2023-01-25 20:06:51   unknown_3A1995  received
     2022-10-05 21:29:41   unknown_5F8DF5  received
   helper:
     HM_CMDNR   64
     peerFriend -
     peerOpt    -:virtual
     regLst     0
     rxType     1
     ack:
     bm:
       CUL_HM_Get:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 21:02:19
         max        0.000952005386352539
         tot        0.000952005386352539
         mAr:
           HASH(0x5f14cb8)
           VCCU
           ?
       CUL_HM_Set:
         cnt        2
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        26.01. 21:02:19
         max        0.00170516967773438
         tot        0.0026850700378418
         mAr:
           HASH(0x5f14cb8)
           VCCU
           ?
     cmds:
       TmplKey    :no:1674761003.49753
       TmplTs     1674761003.49753
       cmdKey     0:1:1::VCCU::00:
       cmdLst:
         assignHmKey noArg
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getDevInfo noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         raw        -data- [...]
         reset      noArg
         tplSet_0   -tplChan-
         unpair     noArg
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       vccu       VCCU
       ioList:
         HmUART
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOList     HmUART
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     rawReg
   model      CCU-FHEM
   room       Homematic
   subType    virtual
   webCmd     virtual:update

Beta-User

Hmm, kann sein, dass das mit den Kontakten (evtl. auch firmwareabhängig) sogar klappt, aber nach meiner Erfahrung funktioniert das spätestens  mit virtuellen Temperatursensoren nicht mehr.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Wie könnte ich es besser machen?
So ganz habe ich es leider noch nicht verstanden.

Zitat von: Beta-User am 26 Januar 2023, 17:56:54
Jeder Raum sollte sein Stammdevice haben, mehr wie einen Fensterkontakt und einen Temp-Sensor sollte man nicht auf ein Hauptdevice legen.

Meinst Du mit Stammdevice das "Hauptdevice" vom RT?

Beta-User

Nein, einfach eine neue CUL_HM-Hauptinstanz (model VIRTUAL) mit beliebiger 6-Stelliger HmId.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Vielleich liegt hier mein grundsätzlicher Fehler.

Bisher (also bevor ich auf VCCU umgestellt hatte) habe ich virtuelle Temperatursensoren folgendermaßen angelegt. Die 518794 (als Beispiel) habe ich mir für jeden virtuellen Temperatursensor ausgedacht.
Fenstersensoren hatte ich damals noch nicht mit eingebunden sondern nur die Temperatursensoren.

define WOH_virt_Temperatur_1 CUL_HM 518794
set WOH_virt_Temperatur_1 virtual 1
rename WOH_virt_Temperatur_1_Btn1 WOH_virt_Temperatur_1_Sensor1
attr WOH_virt_Temperatur_1 IODev HmUART
set WOH_virt_Temperatur_1_Sensor1 peerChan 0 WOH_HEIZUNG_1_Weather single set



Nach der Umstellung auf VCCU habe ich dann die Fensterkontakte folgendermaßen hinzugefügt


set VCCU virtual 1 (oder 2 oder 3; wobei ich mir hier von anfang an nicht sicher war, ob ich immer einen anderen Kanal verwenden muß)
rename VCCU_Btn1 KUECHE_virt_Fenster
attr KUECHE_virt_Fenster webCmd postEvent open:postEvent closed
set KUECHE_virt_Fenster peerChan 0 KUECHE_HEIZUNG_WindowRec single set
set KUECHE_HEIZUNG_WindowRec regSet  winOpnTemp 5 KUECHE_virt_Fenster        (um die Temperatur auf 5 Grad einzustellen, wenn das Fenster geöffnet wird
set KUECHE_HEIZUNG_Clima regSet winOpnMode off            (um die interne "Fenster-auf" Erkennung auszuschalten)

define notify_KUECHE_virt_Fenster notify HUESensor57:(open|closed) set KUECHE_virt_Fenster postEvent $EVENT



Beta-User

Das bisherige Vorgehen war m.E. korrekt, ich hätte halt die jeweils zugehörigen Fensterkontakte noch an das jeweilige "Zimmer-Hauptdevice" angehängt, damit "alles beieinander" ist.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ruggy

Meinst du mit bisherigen, die Vorgehensweise bevor ich die VCCU hatte?
Das mit den anlegen der Temperatursensoren hatte dann nämlich relativ unproblematisch funktioniert.

Zitat von: Beta-User am 26 Januar 2023, 22:10:22
" ich hätte halt die jeweils zugehörigen Fensterkontakte noch an das jeweilige Zimmer-Hauptdevice" angehängt


Also nicht über die VCCU?

Könntest du evlt. sagen mit welchen Befehl.

Sorry wegen der Frage. Aber "ich stehe anscheinen wirklich auf dem Schlauch"

Beta-User

Zitat von: Ruggy am 26 Januar 2023, 22:22:15
Meinst du mit bisherigen, die Vorgehensweise bevor ich die VCCU hatte?
Das mit den anlegen der Temperatursensoren hatte dann nämlich relativ unproblematisch funktioniert.
Ja, bei mir auch ("schon immer" mit VCCU) - deswegen sehe ich auch keinen Grund, da was zu ändern.

ZitatAlso nicht über die VCCU?
Nein, die VCCU ist auch nur ein virtuelles CUL_HM-Haupdevice, du kannst "normale" model=VIRTUAL-Haupt-Instanzen genauso mit dem virtual-setter um weitere Kanäle ergänzen (braucht derzeit einen restart nach dem Anlegen des Hauptdevices bzw. der Model-Zuweisung, wenn ich das richtig im Kopf habe).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Darf ich mal den Link einwerfen https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Virtuelle_Kan.C3.A4le_der_VCCU
Bitte den roten Kasten lesen. Zumindest war das mal der Stand  2019 ::)

Ich verwende Kanäle der VCCU als virtuelle Aktoren - das funktioniert prima.
Was Ruggy hier machen will, funktioniert mW nicht.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Der "rote Kasten" war afaik schon immer im Detail nicht 100% korrekt - das macht aber eigentlich auch nichts, weil der "Verstoß" gegen die einfache Regel, für spezielle Zwecke eigene (Haupt-) Devices zu nutzen in der Regel halt (irgendwann) zu komischen Effekten führt, woran auch immer das im Detail liegt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ist doch eigentlich ganz einfach.  :)

wer folgende "regel" beherzigt, wird dauerhaft keine probleme haben:
1. jedes reale non-homematic-gerät bekommt in fhem ein eigenes virtuelles homematic hauptdevice mit einem channel.
2. grundsätzlich muss jedes homematic hauptdevice eine individuelle, unverwechselbare, 6-stellige hmid besitzen.

wer spass am risiko hat und viel zeit zum tüfteln mitbringt, kann ja gerne anfangen, virtuelle devices zu "sparen".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
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
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html