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

Ruggy

Stimmt, im roten Kasten steht ausdrücklich, dass es mit den virtueller Fensterkontakt und virtueller Temperaturfühler über die VCCU nciht funktioniert.
Bei mir haben zumindest zwei virt. Fensterkontakte trotzdem funktioniert. Evlt. war dies aber auch Zufall und ich möchte es jetzt so umstellen, wie es sich gehört.

Habe ich es jetzt so richtig verstanden, dass z.B. BAD_virt_Sensoren das "Hauptdevice" ist in welchen ich dann virtual 1 (z.B. für Fenster) und virtual 2 (z.B. für Temperatursensor) anlege?


Also sollte ich beim Anlegen jetzt so vorgehen?

virt. Fenstersensor:

define BAD_virt_Sensoren CUL_HM 123456
attr BAD_virt_Sensoren model VIRTUAL
set BAD_virt_Sensoren virtual 1
rename BAD_virt_Sensoren_Btn1 BAD_virt_Fenster
attr BAD_virt_Fenster webCmd postEvent open:postEvent closed
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single set
set BAD_HEIZUNG_Window_Rec regSet winOpnTemp 5 BAD_virt_Fenster
set BAD_HEIZUNG_Clima regSet winOpnMode off



Benötige ich folgendes oder kann ich es weg lassen. Im Wiki ist es nicht erwähnt.
Ich hatte es mir aber damals so notiert. oder muss ich hier VCCU anstatt HmUART schreiben?
attr BAD_virt_Sensoren IODev HmUART


Danach Einrichtung virt Temperatursensor:

set BAD_virt_Sensoren virtual 2
rename BAD_virt_Sensoren_Btn2 BAD_virt_Temperatur
set BAD_virt_Temperatur peerChan 0 BAD_HEIZUNG_Weather single set



Vorher müsste ich aber wahrscheinlich das bisherige löschen bzw. rückgängig machen.
Bei den Channels in VCCU in den jeweiligen Channel gehen und unten device löschen?

Wie kann ich den peerChan rückgängig machen?
Muss ich das als erstes Machen?

Beta-User

Zitat von: Ruggy am 27 Januar 2023, 11:06:18
Wie kann ich den peerChan rückgängig machen?
Muss ich das als erstes Machen?
Korrekt, das solltest du als erstes tun.

ZitatHabe ich es jetzt so richtig verstanden, dass z.B. BAD_virt_Sensoren das "Hauptdevice" ist in welchen ich dann virtual 1 (z.B. für Fenster) und virtual 2 (z.B. für Temperatursensor) anlege?
Das kann man so machen (läuft bei mir so seit Jahren), franks Empfehlung ist etwas weitergehend.

ZitatAlso sollte ich beim Anlegen jetzt so vorgehen?

virt. Fenstersensor:

define BAD_virt_Sensoren CUL_HM 123456
attr BAD_virt_Sensoren model VIRTUAL
set BAD_virt_Sensoren virtual 1
rename BAD_virt_Sensoren_Btn1 BAD_virt_Fenster
attr BAD_virt_Fenster webCmd postEvent open:postEvent closed
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single set
set BAD_HEIZUNG_Window_Rec regSet winOpnTemp 5 BAD_virt_Fenster
set BAD_HEIZUNG_Clima regSet winOpnMode off

Du kannst auch gleich 2 virtuelle Kanäle anlegen, wenn du die am Ende brauchst/haben willst, aber sollst müßte es passen.

ZitatBenötige ich folgendes oder kann ich es weg lassen. Im Wiki ist es nicht erwähnt.
Ich hatte es mir aber damals so notiert. oder muss ich hier VCCU anstatt HmUART schreiben?
attr BAD_virt_Sensoren IODev HmUART
Da du eine VCCU hast, solltest du stattdessen m.E. mit IOGrp arbeiten (und damit auf die VCCU zeigen).

Ansonsten paßt m.E. die Richtung.
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

Zitat von: frank am 27 Januar 2023, 10:44:28
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.

Ich glaube so langsam lichtet sich der Horizont. Aber ein paar Wölkchen sind schon noch da  ;)

Mit dem Hinweis 1. ist jetzt wieder ein kleines Wölchken mehr aufgetaucht.
Jedes reale Homematic Gerät (das ich in der Hand halten kann ;-) bekommt ein virtuelles Hauptdevice.
Aber wieso nur mit einen Channel? Wohin gehört der Channel 2. Ich habe ja zwei Geräte, welche ich mit den Homematic Gerät verbinden will (Temperatursensor und Fenstersensor)?

Zitat von: Beta-User am 27 Januar 2023, 11:35:35
Ansonsten paßt m.E. die Richtung.

Das freut mich. Hat meine grauen Gehirnzellen in Schwung gebracht.


Das Peering müsste ich so aufheben können?
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single unset

Beta-User

Zitat von: Ruggy am 27 Januar 2023, 11:55:19
Das Peering müsste ich so aufheben können?
set BAD_virt_Fenster peerChan 0 BAD_HEIZUNG_Window_Rec single unset
Sowas steht doch in der Doku?

ZitatJedes reale Homematic Gerät (das ich in der Hand halten kann ;-) bekommt ein virtuelles Hauptdevice.
Das ist m.E. eine falsche Schlussfolgerung! Einen HM-Fenstersensor kann man doch auch mit 2 oder 3 RTs bzw. WTs peeren! Das geht mit einem virtualisierten Fenstersensor doch genauso! dto. für einen Temp-Sensor (da sind sich frank und ich uneinig, ob man dafür einen extra Hauptkanal "verschwenden" muss).

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

Zitat von: Beta-User am 27 Januar 2023, 10:22:16
Der "rote Kasten" war afaik schon immer im Detail nicht 100% korrekt -
Danke, der ist von mir :) aber seinerzeit geschrieben aus einer Kombination von eigenen Erfahrungen und Erfahrungen in verschiedenen Threads hier im Forum.
Frank hat es kürzer und knackiger formuliert: da könnte ich jetzt noch den Umkehrschluss anfügen: Die virtuellen Kanäle der VCCU taugen eigentlich nur als Peer Endpunkte für Homematic Fernbedienungen, die selbst keinen anderen echten Peer haben, damit diese "grünes Licht" bei der Betätigung erzeugen. Richtig?

Zitat von: Ruggy am 27 Januar 2023, 11:06:18
Bei mir haben zumindest zwei virt. Fensterkontakte trotzdem funktioniert. Evlt. war dies aber auch Zufall und ich möchte es jetzt so umstellen, wie es sich gehört.
Wie hat mein Kollege mal gesagt: Es besteht kein Rechtsanspruch auf die Beibehaltung von Fehlern  ;D ;D ;D
Oder allgemeiner: Kann gehen - muss aber nicht (immer).
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

Zitat von: Otto123 am 27 Januar 2023, 12:52:17
Richtig?
...das ist ein bißchen wie bei den diversen Atommodellen: Für den Einstieg ist es "richtig", im Detail komplett falsch ;D ...

Anders gesagt: Ich stehe 100% hinter der dringenden Empfehlung an alle, die keine Experten sind, die Kanäle der VCCU nur zu Zwecken des "grünen Lichts" zu verwenden. (Inhaltlich) nichts wesentlich anderes war übrigens der dringlichen Empfehlung in meinem ersten Beitrag hier zu entnehmen...

Alles andere führt nur in irgendwelche Untiefen aus firmware-Versionen, Hardware-Varianten und CUL_HM-Versions-Ständen (ggf. noch gemixt mit IO-Spezifika...)

PS: Ich habe durchaus Fälle hier, bei denen zur Frage der Öffnung eines virtuellen Kontakts mehrere reale Geräte ausgewertet werden (falls überhaut "Heizzeit" ist; ähnlich für's Schließen).
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

Werde mir später noch anschauen, wie ich die bisherigen Geräte angelegt habe. Kann sein, dass hier dann auch was nicht stimmt.
Vor allem habe ich hier bisher die Fenster noch gar nicht eingebunden. Wollte mich erst mal an die Räume mit einem Fenster und einen Sensor wagen.

Hierzu noch eine Frage, weil ich in einem Raum drei reale_Thermostate habe, einen Temperatursensor (= TS) und zwei Fenster (Fenster 1 = F1, Fenster 2 = F2) , welche ich mit einbeziehen möchte.
Ich wage es jetzt mal zu schreiben, wie ich es machen würde:


- Zu jedem realen Thermostat (T1, T2, T3) ein virtuelles Hauptdevice anlegen (vT1, vT2, vT3)
- In jeden virtuellen Hauptdevice jeweils zwei Channel (z.B. C1 = Temperatur, C2 = Fenster)



dann peere ich:

Temperatursensor:
vT1-C1 mit TS
vT2-C1 mit TS
vT3-C1 mit TS

Fenster:
vT1-C2 mit F1
vT1-C2 mit F2
vT2-C2 mit F1
vT2-C2 mit F2
vT3-C2 mit F1
vT3-C2 mit F2

Kann man das so machen und funktioniert dann auch?
Sorry der Nachfrage, aber ich möchte in meinen FHEM nicht noch mehr durcheinander bringen, als es wahrscheinlich schon ist.

frank

ich würde 2x virtuelle fensterkontakte und 1x virtuellen temperaturfühler definieren, mit jeweils einem channel.
virtuelle homematic-devices braucht man nur für die nicht-homematic-geräte!!
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

Beta-User

(auch, frank war schneller) M.E. viel zu kompliziert:

Ein virtueller Kanal für den TS reicht, an den werden alle RT's gepeert.

Bei mir gäbe es dann auch nur einen virtuellen F, der den konsolidierten Zustand von F1 und F2 enthält. Ein entsprechendes notify steht im Wiki.

Bei mir ist das übrigens für alle Fensterkontakte (hausweit!) ein einziges notify, was wie zusammengehört, steht in Attributen, und geöffnet wird auch erst, wenn eine kurze (einstellbare) Zeit vergangen 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

Werde es mal versuchen. Weiß jetzt noch nicht genau nach welcher Methode.

Die Methode mit notify hört sich auch recht komfortabel an.
Hierbei kann ich persönlich mit dem notify aber wieder einigies durcheinander bringen ;-)

Macht es dir was aus das notify mit den (hausweiten) Fensterkontakten zu zeigen?
Habe für jedes Fenster ein notify.

Beta-User

Zitat von: Ruggy am 27 Januar 2023, 14:17:19
Macht es dir was aus das notify mit den (hausweiten) Fensterkontakten zu zeigen?
Nö, ist immer mal wieder aktualisiert worden, hier (vermutlich) die aktuellste Fassung; Code ist im ersten Post:
https://forum.fhem.de/index.php/topic,97430.msg1223653.html#msg1223653

Zitat von: Ruggy am 27 Januar 2023, 14:17:19
Habe für jedes Fenster ein notify.
Am Ende ist es halt wichtig, dass du selbst überblicken kannst, warum was passiert. Ich finde weniger Geräte - ggf. in Verbindung mit besserem/universellerem Code - halt übersichtlicher, darum "will" ich auch nicht mehr Stammdevices anlegen wie "nötig"...
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

...der Vollständigkeit halber: Auch die Übertragung der gemessenen Temperaturen an die virtuellen Kanäle erfolgt "hausweit" mit nur einem notify. Das sieht so aus:

define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.*  {\
my %tsensorsmap = (\
  Raumfuehler_Buero => 'Fake_Fenster_Buero_Temp',\
  Raumfuehler_Kind1 => 'Fake_Fenster_Kind1_Temp',\
[...]
  Temperatur_Schlafzimmer => 'Fake_Fenster_SZ_Temp',\
  Raumfuehler_Wohnzimmer => 'Fake_Tuere_WZ_Temp',\
  );;\
  return if !defined $tsensorsmap{$NAME};;\
  if( $EVTPART1 eq '0.000' ) {\
    fhem("msg $NAME scheint ausgefallen zu sein (readingsWatcher)");;\
    return CommandDeleteReading(undef, "$tsensorsmap{$NAME} temperature");;\
  }\
  return CommandSet(undef, "$tsensorsmap{$NAME} virtTemp $EVTPART1")\
}

Vorbedingungen:
Falls ein Sensor zu lange keine Infos liefert, schlägt im Hintergrund ein readingsWatcher zu und stellt eine eher ungewöhnliche "0" ein.
"msg" funktioniert nur, wenn msgConfig entsprechend vorbereitet ist.

(Ich gebe zu, dass ich heute die Benennungen der Devices anders strukturieren würde...).
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

Beim folgenden Befehl kommt nachfolgende Meldung:

set SCHLAFZIMMER_virt_Fenster peerChan 0 SCHLAFZIMMER_HEIZUNG_Window_Rec single set


please enter peer

Habe noch das virtuelle Hauptdevice "SCHLAFZIMMER_virt_Sensoren" mit folgenden Attribut ergänzg; funktionierte aber auch nicht.
attr SCHLAFZIMMER_virt_Sensoren IOgrp VCCU

Habe mal versucht hmPairForSec mit dem VCCU auszuführen und auch von HmUART aus.
Beide mal der selbe Fehler.

Bei den Temperatursensor und Fenstersensor handelt es sich um Xiaomi. Aber das dürfte hier doch noch keine Rolle spielen.


List vom virtuellen Schlafzimmer Hauptdevice:
Internals:
   DEF        62FAB4
   FUUID      63d3fe31-f33f-194f-9f82-a89000fa0ea91192
   IODev      HmUART
   NAME       SCHLAFZIMMER_virt_Sensoren
   NR         763
   NTFY_ORDER 48-SCHLAFZIMMER_virt_Sensoren
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   channel_01 SCHLAFZIMMER_virt_Fenster
   channel_02 SCHLAFZIMMER_virt_Temperatur
   disableNotifyFn 1
   READINGS:
     2023-01-27 17:55:34   IODev           HmUART
     2023-01-27 17:41:07   RegL_00.       
     2023-01-27 17:39:22   cfgState        updating
     2023-01-27 17:39:44   commState       CMDs_done_Errors:1
     2023-01-27 17:39:44   state           RESPONSE TIMEOUT:RegisterRead
   helper:
     HM_CMDNR   37
     mId        FFF1
     peerFriend -
     peerOpt    -:virtual
     regLst     0
     rxType     1
     cmds:
       TmplKey    :no:1674837860.84256
       TmplTs     1674837860.84256
       cmdKey     0:1:1::SCHLAFZIMMER_virt_Sensoren:FFF1:00:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getDevInfo noArg
         raw        -data- [...]
         reset      noArg
         tplSet_0   -tplChan-
         unpair     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)]
         param      -param-
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       vccu       VCCU
       prefIO:
     mRssi:
       mNo       
       io:
         HmUART:
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     rawReg
   model      VIRTUAL
   room       Schlafzimmer
   subType    virtual
   webCmd     virtual

Ruggy

Sorry, der Fehler sitzt vorm Computer

es war ein "_" zuviel im Namen SCHLAFZIMMER_HEIZUNG_Window_Rec

Falsche Schreibweise:
set SCHLAFZIMMER_virt_Fenster peerChan 0 SCHLAFZIMMER_HEIZUNG_Window_Rec single set

richtige Schreibweise:
set SCHLAFZIMMER_virt_Fenster peerChan 0 SCHLAFZIMMER_HEIZUNG_WindowRec single set

Ruggy

Habe es jetzt u.a. mit der Heizung im Kinderzimmer versucht. Dort sind zwei HM-CC-RT-DN, ein Fenster mit Xiaomi-Öffner und ein Xiaomi-Temperatur Sensor

Das mit dem Fenster funktioniert meiner Meinung nach. Beim Öffnen des Fensters wird durch beide HM-CC-RT-DN das Öffnen sofort erkannt.

Das mit der Temperatur funktioniert anscheinend nicht bzw. nicht so richtig.
Die _Weather beider Thermostate werden nicht mit der selben Temperatur gleichzeitig aktualisiert;
wenn sich die Temperatur am Xiaomi Sensor ändert, dauert es ein paar Minuten, bis sich an dem _Weather etwas ändert. Hierbei ist nicht unbedingt gesagt, dass beide die selbe Temperatur haben.
Das virtuelle Device ändert ziemlich zügig die Temperaturänderungen.

Ich habe "virt_Hauptdevice" angelegt und dieses mit zwei Kanälen (für Fenster und Temperatur); das virt. Fenster mit dem Fenstersensor gepeert und der virt. Temperatursensor mit den _Weather der zwei HM-CC-RT-DN gepeert.
Wenn ich es richtig verstanden habe sollte das gehen?

Durch den Befehl set hm peerXref wird folgendes angezeigt
(kann das so stimmen? Insbesondere wegen den Abschnitt mit "undef":

peerXref done:
x-ref list
  actor
       BAD_HEIZUNG_WindowRec  =>  BAD_virt_Fenster
       KIND_HEIZUNG_1_WindowRec  =>  KIND_virt_Fenster
       KIND_HEIZUNG_2_WindowRec  =>  KIND_virt_Fenster
       KUECHE_HEIZUNG_WindowRec  =>  KUECHE_virt_Fenster
       SCHLAFZIMMER_HEIZUNG_WindowRec  =>  SCHLAFZIMMER_virt_Fenster
  receive
       BAD_HEIZUNG_Weather   =>  BAD_virt_Temperatur
       KIND_HEIZUNG_1_Weather  =>  KIND_virt_Temperatur
       KIND_HEIZUNG_2_Weather  =>  KIND_virt_Temperatur
       KUECHE_HEIZUNG_Weather  =>  KUECHE_virt_Temperatur
       SCHLAFZIMMER_HEIZUNG_Weather  =>  SCHLAFZIMMER_virt_Temperatur
       WOH_HEIZUNG_1_Weather  =>  WOH_virt_Temperatur_Sensor1
       WOH_HEIZUNG_2_Weather  =>  WOH_virt_Temperatur_2_Sensor1
       WOH_HEIZUNG_3_Weather  =>  WOH_virt_Temperatur_3_Sensor1
  undef
       BAD_virt_Fenster      =>  BAD_HEIZUNG_WindowRec
       BAD_virt_Temperatur   =>  BAD_HEIZUNG_Weather
       KIND_virt_Fenster     =>  KIND_HEIZUNG_1_WindowRec KIND_HEIZUNG_2_WindowRec
       KIND_virt_Temperatur  =>  KIND_HEIZUNG_1_Weather KIND_HEIZUNG_2_Weather
       KUECHE_virt_Fenster   =>  KUECHE_HEIZUNG_WindowRec
       KUECHE_virt_Temperatur  =>  KUECHE_HEIZUNG_Weather
       SCHLAFZIMMER_virt_Fenster  =>  SCHLAFZIMMER_HEIZUNG_WindowRec
       SCHLAFZIMMER_virt_Temperatur  =>  SCHLAFZIMMER_HEIZUNG_Weather
       WOH_virt_Temperatur_2_Sensor1  =>  WOH_HEIZUNG_2_Weather
       WOH_virt_Temperatur_3_Sensor1  =>  WOH_HEIZUNG_3_Weather
       WOH_virt_Temperatur_Sensor1  =>  WOH_HEIZUNG_1_Weather



Hier der gesamte Vorgang, wie ich es eingerichtet habe:

define KIND_virt_Sensoren CUL_HM F54AB1
attr KIND_virt_Sensoren model VIRTUAL

- (Neustart von FHEM damit nächste Befehle verfügbar werden) shutdown restart

set KIND_virt_Sensoren virtual 1
set KIND_virt_Sensoren virtual 2

rename KIND_virt_Sensoren_Btn1 KIND_virt_Fenster
rename KIND_virt_Sensoren_Btn2 KIND_virt_Temperatur

- (Neustart von FHEM falls Btn nicht umbenannt wurden) shutdown restart

attr KIND_virt_Fenster webCmd postEvent open:postEvent closed

set KIND_virt_Fenster peerChan 0 KIND_HEIZUNG_1_WindowRec single set
set KIND_virt_Fenster peerChan 0 KIND_HEIZUNG_2_WindowRec single set

set KIND_HEIZUNG_1_WindowRec regSet winOpnTemp 5 KIND_virt_Fenster
set KIND_HEIZUNG_2_WindowRec regSet winOpnTemp 5 KIND_virt_Fenster

set KIND_HEIZUNG_1_Clima regSet winOpnMode off
set KIND_HEIZUNG_2_Clima regSet winOpnMode off


set KIND_virt_Temperatur peerChan 0 KIND_HEIZUNG_1_Weather single set
set KIND_virt_Temperatur peerChan 0 KIND_HEIZUNG_2_Weather single set

define notify_KIND_virt_Fenster notify KINDERZIMMER_FENSTER_L:(open|closed) set KIND_virt_Fenster postEvent $EVENT

define notify_KIND_virt_Temperatur notify KIND_LUFTFEUCHTE:temperature:.* set KIND_virt_Temperatur virtTemp $EVTPART1


Hier das List vom virt. Hauptdevice:

Internals:
   DEF        F54AB102
   FUUID      63dc2376-f33f-194f-8b0a-8ab94765f6c24a87
   NAME       KIND_virt_Temperatur
   NR         770
   NTFY_ORDER 48-KIND_virt_Temperatur
   STATE      set_virtTemp 20.26
   TYPE       CUL_HM
   chanNo     02
   device     KIND_virt_Sensoren
   disableNotifyFn 1
   eventCount 482
   peerList   KIND_HEIZUNG_1_Weather,KIND_HEIZUNG_2_Weather
   Helper:
     DBLOG:
       state:
         DbLog:
           TIME       1675375276.38491
           VALUE      set_virtTemp 20.26
       temperature:
         DbLog:
           TIME       1675375276.35092
           VALUE      20.26
   READINGS:
     2023-02-02 23:01:50   commState       CMDs_done
     2023-02-02 22:18:47   peerList        KIND_HEIZUNG_1_Weather,KIND_HEIZUNG_2_Weather
     2023-02-02 23:01:16   state           set_virtTemp 20.26
     2023-02-02 23:01:16   temperature     20.26
   helper:
     fkt        virtThSens
     peerFriend peerSens,peerAct
     peerIDsState incomplete
     peerOpt    -:virtual
     regLst     
     virtTC     00
     bm:
       CUL_HM_Get:
         cnt        15
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        02.02. 22:58:01
         max        0.00111293792724609
         tot        0.00801229476928711
         mAr:
           HASH(0x5c43a90)
           KIND_virt_Temperatur
           ?
       CUL_HM_Set:
         cnt        803
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        02.02. 22:42:18
         max        0.166764974594116
         tot        31.9938004016876
         mAr:
           HASH(0x5c43a90)
           KIND_virt_Temperatur
           virtTemp
           24.25
     cmds:
       TmplKey    KIND_HEIZUNG_1_Weather,KIND_HEIZUNG_2_Weather:no:1675371555.31676
       TmplTs     1675371555.31676
       cmdKey     1:0:1:virtThSens:KIND_virt_Sensoren:FFF1:02:KIND_HEIZUNG_1_Weather,KIND_HEIZUNG_2_Weather
       cmdLst:
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         tplSet_KIND_HEIZUNG_1_Weather -tplPeer-
         tplSet_KIND_HEIZUNG_2_Weather -tplPeer-
         virtHum    (off|0.0..99.0;0.1)
         virtTemp   (off|-20.0..50.0;0.1)
       lst:
         condition  slider,0,1,255
         peer       KIND_HEIZUNG_1_Weather,KIND_HEIZUNG_2_Weather
         peerOpt    remove_KIND_HEIZUNG_1_Weather,remove_KIND_HEIZUNG_2_Weather,BAD_HEIZUNG_WindowRec,BAD_HEIZUNG_remote,GONG_FLUR,HM_70FFF4_Rain,KIND_HEIZUNG_1_WindowRec,KIND_HEIZUNG_1_remote,KIND_HEIZUNG_2_WindowRec,KIND_HEIZUNG_2_remote,KUECHE_HEIZUNG_WindowRec,KUECHE_HEIZUNG_remote,SCHLAFZIMMER_HEIZUNG_WindowRec,SCHLAFZIMMER_HEIZUNG_remote,Steckdose_PC,WOH_HEIZUNG_1_WindowRec,WOH_HEIZUNG_1_remote,WOH_HEIZUNG_2_WindowRec,WOH_HEIZUNG_2_remote,WOH_HEIZUNG_3_WindowRec,WOH_HEIZUNG_3_remote,WOH_SCHALTER_1_Btn_01,WOH_SCHALTER_1_Btn_02
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     peerIDsH:
       62FAC801   KIND_HEIZUNG_2_Weather
       62FB6A01   KIND_HEIZUNG_1_Weather
     role:
       chn        1
       vrt        1
     tmpl:
     vd:
       ackT       
       cmd        8470F54AB1000000
       idh        1485698
       idl        45312
       miss       0
       msgCnt     17
       msgRed     0
       next       1675375488.06729
       nextM      1675375488.06729
       typ        2
       val        00CA
       vin        20.26
Attributes:
   model      VIRTUAL
   peerIDs    62FAC801,62FB6A01
   webCmd     press short:press long

Beta-User

Zitat von: Ruggy am 02 Februar 2023, 23:03:12
Das mit der Temperatur funktioniert anscheinend nicht bzw. nicht so richtig.
Die _Weather beider Thermostate werden nicht mit der selben Temperatur gleichzeitig aktualisiert;
wenn sich die Temperatur am Xiaomi Sensor ändert, dauert es ein paar Minuten, bis sich an dem _Weather etwas ändert. Hierbei ist nicht unbedingt gesagt, dass beide die selbe Temperatur haben.
Wo genau siehst du das Problem?

Die "Ist-Temperatur" aus dem virtuellen Kanal wird nur jeweils alle 2,5 Minuten oder so an den RT versandt, dabei hat jeder RT "seinen" slot, wann er empfangsbereit ist. Versendet wird dabei jeweils das, was halt grade "da" ist.

Daher kommt auch die Empfehlung aus dem Wiki, den Wert zu LÖSCHEN, wenn er veraltet ist. Besser der RT arbeitet mit dem intern gemessenen Wert wie mit einem veralteten ;) ...
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 Deiner Erklärung sehe ich jetzt hierbei kein Problem mehr.  :)
Es ist somit normal und wie es sein soll.

Ich würde es gerne bei einem Fenster (bzw. ist eigentlich in dem Fall eine Balkontüre) so einstellen, dass das Öffnen erst nach z.B. 5 Minuten an das Thermostat gemeldet wird. Wenn ich das Fenster in der Zwischenzeit wieder geschlossen wird, soll das Thermostat unverändert weiter heizen.

Könnte das notify folgendermaßen funktionieren. Habe in einem anderen Thread gelesen, dass das sleep u.U. FHEM blockieren könnte.

define notify_WOHNZIMMER_virt_Fenster notify WOH_TUERSENSOR:(open|closed) sleep 5;;{fhem(,,set WOHNZIMMER_virt_Fenster postEvent $EVENT")}

Falls dies so grundsätzlich funktioniert.
Was passiert, wenn ich das Fenster innerhalb der sleep-Zeit wieder schließe. Erfolgt dann trotzdem die Meldung nach 5 Minuten?

Beta-User

Zitat von: Ruggy am 03 Februar 2023, 13:01:41
Nach Deiner Erklärung sehe ich jetzt hierbei kein Problem mehr.  :)
Es ist somit normal und wie es sein soll.
:)

ZitatIch würde es gerne bei einem Fenster (bzw. ist eigentlich in dem Fall eine Balkontüre) so einstellen, dass das Öffnen erst nach z.B. 5 Minuten an das Thermostat gemeldet wird. Wenn ich das Fenster in der Zwischenzeit wieder geschlossen wird, soll das Thermostat unverändert weiter heizen.

Könnte das notify folgendermaßen funktionieren. Habe in einem anderen Thread gelesen, dass das sleep u.U. FHEM blockieren könnte.

define notify_WOHNZIMMER_virt_Fenster notify WOH_TUERSENSOR:(open|closed) sleep 5;;{fhem(,,set WOHNZIMMER_virt_Fenster postEvent $EVENT")}

Falls dies so grundsätzlich funktioniert.
Was passiert, wenn ich das Fenster innerhalb der sleep-Zeit wieder schließe. Erfolgt dann trotzdem die Meldung nach 5 Minuten?
Das sleep ist nicht das Problem, das ist ein "FHEM-sleep", das einfach einen "InternalTimer" anlegt.
Das Problem ist letzteres, das muss eigentlich auch wieder gelöscht werden, sonst kommen beide Events verzögert am RT an. Eine mögliche Lösung für das Problem sollte eigentlich hier in diesem Thread bereits stehen ;) .
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