HM_CC_RT_DN Fensterkontakt simulieren?

[strauch]

Da war wirklich noch ein notify, dann hats noch eine Weile gedauert inzwischen hat sich alles wieder beruhigt. Sobald ich wieder Zeit habe werde ich das noch mal testen und meine definition hier Posten ohne es mit dem TC zu peeren, vielleicht entdeckst du da schon einen Fehler.

[Thomas X]

Ich habe diese Anleitung versucht, jedoch blinkt nach dem peeren das Funksymbol auf dem Thermostat. Sobald ich das virtuelle Fenster wieder aus dem Peering raus nehme (unset) blinkt es nicht mehr. Da scheint wohl die Kommunikation nicht zu funktionieren.

Muss ich dem virtuellen Fenster im FHEM noch eine ID des Thermostates mitgeben? Ich habe die Zeilen aus diesem Thread so in die Config kopiert.


Edit: Eine Frage: Muss ich zum HM-CC-RT-DN nicht den peerchan 3 angeben anstatt 0? Auf Channel 3 hat er doch den Peer zu einem Fensterkontakt, oder nicht?

Edit2: Jetzt hat's geklappt. Da aber vielleicht einige andere die gleichen Verständnisprobleme haben wie ich, hier mal meine Fehler:

1. Ich habe immer set virtualFensterWz peerChan 0 Heizung_Wz_gr single set zum Peeren eingegeben. Das war falsch.  Hinter "Heizung_Wz_gr" muss nämlich noch der Name des Channels 3, also _WindowRec folgen.

2. Nachdem man den Befehl eingegeben hat, muss man das Peering starten. Beim HM-CC-RT-DN also drei Sekunden lang die Boosttaste drücken. Dann klappt das Peeren sofort.

3. Zusätzlich habe ich in der FHEM-Config beim virtualFensterWz noch die Peering-ID des Thermostaten im WindowRec-Channel eingetragen. Also so: attr virtualFensterWz peerIDs 3AA3AA03 . Wichtig hier hier auch die "03" am Ende für den WindowRec-Channel.

Ist alles nicht sehr transparent am Anfang. Aber nach und nach findet man sich dann zurecht.

[RaspiCOC]

Sorry, dass ich diesen Thread wieder hoch hole. Das Thema gehört aber IMHO durchaus hier rein.

Wenn ich das alles korrekt verstanden habe bezieht sich die Simulation des Fensterkontaktes auf das Zusammenspiel von HM_CC_RT_DN bzw. in ähnlicher Weise auf HM_HM_TC_IT_WM_W_EU, wobei die vorgenannten Geräte beispielsweise über den HM_LAN Konfigurationsadapter gepairt sind.

Gibt es hier eigentlich auch die Möglichkeit das Pairing des virtuellen Fensterkontaktes mit den vorgenannten Geräten durchzuführen, wenn diese über eine CCU2 mit FHEM verbunden sind?
(Ich frage dies, weil ich sowohl eine CCU2 als auch den HM_LAN habe, letzterer aber abgekündigt ist und ich damit auf längere Sicht komplett auf CCU2 umsteigen möchte)

Wie würde ich hier vorgehen?

[Yokurt]

Hallo,

auch ich benutze den alten Thread, vor allem weil darauf auch im Wiki verwiesen wird.

Ich habe einen virtuelles Device und einen Kanal erstellt. Wenn ich den Kanal mit

Code Auswählen Erweitern

rename OG.bz.T.virt_Btn1 OG.bz.T.virt_Temp
umbenne wird der Kanal zu

OG.bz.T.virt_Temp

umbenannt, aber der Eintrag im Device für den Kanal behält den Namen

OG.bz.T.virt_Btn1

.
Wenn ich es wieder zurück benenne wird es wieder erkannt. Mit den weiteren Schritten wird auch ein Wert gesetzt und es scheint zu funktionieren. Es hat halt nur den Schönheitsfehler mit dem Standardnamen. Hat jemand das selbe Problem oder eine Lösung?

Code Auswählen Erweitern

define OG.bz.T.virt_Temp CUL_HM E3B43A01
attr OG.bz.T.virt_Temp model VIRTUAL
attr OG.bz.T.virt_Temp webCmd press short:press long
#   CFGFN     
#   DEF        E3B43A01
#   FUUID      63a4aa61-f33f-ce91-39d3-541bcc9387530f8f
#   NAME       OG.bz.T.virt_Temp
#   NR         14803
#   NTFY_ORDER 48-OG.bz.T.virt_Btn1
#   STATE      ???
#   TYPE       CUL_HM
#   chanNo     01
#   device     OG.bz.T.virt
#   disableNotifyFn 1
#   eventCount 1
#   READINGS:
#     2022-12-22 20:05:21   commState       CMDs_done_Errors:1
#   helper:
#     peerFriend peerSD,peerSens,peerAct
#     peerIDsState peerUnread
#     peerOpt    -:virtual
#     regLst     
#     cmds:
#       TmplKey    :no:1671735910.35426
#       TmplTs     1671735910.35426
#       cmdKey     1:0:1::OG.bz.T.virt:FFF1:01:
#       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-
#       lst:
#         condition  slider,0,1,255
#         peer       
#         peerOpt    DG.kz.HZ_WindowRec,DG.kz.HZ_remote,DG.kz.SA_04,DG.kz.SA_auf,DG.kz.SA_stop,DG.kz.SA_zu,DG.sz.HZ.Ost_WindowRec,DG.sz.HZ.Ost_remote,DG.sz.HZ.West_WindowRec,DG.sz.HZ.West_remote,DG.wc.HZ_WindowRec,DG.wc.HZ_remote,EG.az.HZ_WindowRec,EG.az.HZ_remote,EG.az.T.virt_Btn1,EG.eg.BM,EG.eg.HZ_WindowRec,EG.eg.HZ_remote,EG.eg.SA,EG.gd.HZ_WindowRec,EG.gd.HZ_remote,EG.gz.HZ_WindowRec,EG.gz.HZ_remote,EG.th.HZ_WindowRec,EG.th.HZ_remote,EG.wc.FK,EG.wc.HZ_WindowRec,EG.wc.HZ_remote,EG.ws.HZ_WindowRec,EG.ws.HZ_remote,OG.bz.HZ_WindowRec,OG.bz.HZ_remote,OG.bz.T.virt_Btn1,OG.ez.HZ_WindowRec,OG.ez.HZ_remote,OG.ku.FK,OG.ku.HZ_WindowRec,OG.ku.HZ_remote,OG.wc.FK,OG.wc.HZ_WindowRec,OG.wc.HZ_remote,OG.wz.HZ.Ost_WindowRec,OG.wz.HZ.Ost_remote,OG.wz.HZ.West_WindowRec,OG.wz.HZ.West_remote,UG.rr.HZ_WindowRec,UG.rr.HZ_remote,UG.wk.HZ_WindowRec,UG.wk.HZ_remote
#         tplChan   
#         tplDel     
#         tplPeer   
#       rtrvLst:
#         cmdList    [({short}|long)]
#         deviceInfo [({short}|long)]
#         list       [({normal}|full)]
#         param      -param-
#     expert:
#       def        0
#       det        0
#       raw        1
#       tpl        0
#     peerIDsH:
#     role:
#       chn        1
#       vrt        1
#     tmpl:
#
setstate OG.bz.T.virt_Temp 2022-12-22 20:05:10 .associatedWith OG.bz.T.virt,OG.bz.T.virt_Btn1,OG.bz.T.virt
setstate OG.bz.T.virt_Temp 2022-12-22 20:05:21 commState CMDs_done_Errors:1



Code Auswählen Erweitern

define OG.bz.T.virt CUL_HM E3B43A
attr OG.bz.T.virt .mId FFF1
attr OG.bz.T.virt autoReadReg 4_reqStatus
attr OG.bz.T.virt expert rawReg
attr OG.bz.T.virt model VIRTUAL
attr OG.bz.T.virt subType virtual
attr OG.bz.T.virt webCmd virtual
#   CFGFN     
#   DEF        E3B43A
#   FUUID      63a4aa54-f33f-ce91-6498-e64c16d6db1c8d23
#   IODev      myHmUARTLGW
#   NAME       OG.bz.T.virt
#   NR         14796
#   NTFY_ORDER 48-OG.bz.T.virt
#   STATE      RESPONSE TIMEOUT:RegisterRead
#   TYPE       CUL_HM
#   channel_01 OG.bz.T.virt_Btn1
#   disableNotifyFn 1
#   eventCount 9
#   protCmdDel 1
#   protResnd  3 last_at:2022-12-22 20:05:16
#   protResndFail 1 last_at:2022-12-22 20:05:21
#   protSnd    1 last_at:2022-12-22 20:05:01
#   protState  CMDs_done_Errors:1
#   READINGS:
#     2022-12-22 20:05:01   IODev           myHmUARTLGW
#     2022-12-22 20:22:06   RegL_00.       
#     2022-12-22 20:05:01   cfgState        updating
#     2022-12-22 20:05:21   commState       CMDs_done_Errors:1
#     2022-12-22 20:05:21   state           RESPONSE TIMEOUT:RegisterRead
#   helper:
#     HM_CMDNR   145
#     cSnd       ,01210614E3B43A00040000000000
#     cfgStateUpdt 0
#     mId        FFF1
#     peerFriend -
#     peerOpt    -:virtual
#     regLst     0
#     rxType     1
#     cfgChk:
#       idPc00     fail
#       idRc01     RegL_00.
#     cmds:
#       TmplKey    :no:1671735910.35094
#       TmplTs     1671735910.35094
#       cmdKey     0:1:1::OG.bz.T.virt: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:
#       flgs       0
#       newChn     +E3B43A,00,00,00
#       rxt        0
#       vccu       
#       p:
#         E3B43A
#         00
#         00
#         00
#       prefIO:
#     mRssi:
#       mNo       
#     peerIDsH:
#     prt:
#       bErr       0
#       sProc      0
#     q:
#       qReqConf   
#       qReqStat   
#     role:
#       dev        1
#       vrt        1
#     tmpl:
#
setstate OG.bz.T.virt RESPONSE TIMEOUT:RegisterRead
setstate OG.bz.T.virt 2022-12-22 20:05:10 .associatedWith OG.bz.T.virt,OG.bz.T.virt_Btn1,OG.bz.T.virt
setstate OG.bz.T.virt 2022-12-22 20:05:01 IODev myHmUARTLGW
setstate OG.bz.T.virt 2022-12-22 20:22:06 RegL_00.
setstate OG.bz.T.virt 2022-12-22 20:05:01 cfgState updating
setstate OG.bz.T.virt 2022-12-22 20:05:21 commState CMDs_done_Errors:1
setstate OG.bz.T.virt 2022-12-22 20:05:21 state RESPONSE TIMEOUT:RegisterRead



[wmr72]

umbenne wird der Kanal zu  umbenannt, aber der Eintrag im Device für den Kanal behält den Namen .

Ja, das Problem kann ich so bestätigen, ist bei mir genauso. Auch wenn man eine vccu für die virtuellen Devices nutzt, die zumindest bei mir entgegen der Aussage im Wiki (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Virtuelle_Kan.C3.A4le_der_VCCU) auch problemlos als virtueller Fensterkontakt funktioniert, das scheint veraltet. Kann das auch jemand bestätigen?

[Yokurt]

Auch wenn man eine vccu für die virtuellen Devices nutzt, die zumindest bei mir entgegen der Aussage im Wiki (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Virtuelle_Kan.C3.A4le_der_VCCU) auch problemlos als virtueller Fensterkontakt funktioniert, das scheint veraltet. Kann das auch jemand bestätigen?

Das mit den virtuellen Kanälen der VCCU hatte ich gar nicht auf dem Schirm. Ich teste es die nächsten Tage, wenn der Weihnachtsstress es zulässt

[Beta-User]

Das mit den virtuellen Kanälen der VCCU hatte ich gar nicht auf dem Schirm. Ich teste es die nächsten Tage, wenn der Weihnachtsstress es zulässt

Auch da gilt: pro "geleiteter Gruppe" (an Heizgeräten) braucht es ein eigenes Stammdevice. Daher sollte man das einfach lassen. Man spart ja nur ein einziges Device ein...

[wmr72]

Auch da gilt: pro "geleiteter Gruppe" (an Heizgeräten) braucht es ein eigenes Stammdevice. Daher sollte man das einfach lassen. Man spart ja nur ein einziges Device ein...

Ich hatte das im Wiki so verstanden, dass die virtuellen Kanäle der VCCU (wovon ich sowieso schon einige habe) nicht als Fensterkontakt funktionieren würden und das kann ich so nicht bestätigen. Warum sollte man das lassen, gibt es irgendwelche Nachteile? 

[Beta-User]

Ich würde das unter Hygiene verbuchen. Eine VCCU hat einfach eine besondere Funktion, und mit der sollte man m.E. nur peeren, was wirklich sauber zwischen den Kanälen unterscheiden kann. RT-DN sind in der Hinsicht halt komisch.
Nur meine 2ct.