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
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...).
Ein reload hat auch nicht weiter geholfen.
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...
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
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.
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?
Nein, einfach eine neue CUL_HM-Hauptinstanz (model VIRTUAL) mit beliebiger 6-Stelliger HmId.
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
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.
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"
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).
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.
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...
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".
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?
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.
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
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).
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).
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).
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.
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!!
(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...
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.
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"...
Danke.
Das muss ich mir ein paar Mal erst durchlesen ;)
...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...).
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
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
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
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 ;) ...
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?
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 ;) .