Hallo zusammen,
ich habe hier ein sehr schräges Phänomen mit dem WM-EU und einem Fenster Sensor, und bräuchte dringend Unterstützung bei der Fehlersuche. Ist etwas kompliziert, hoffe es kommt verständlich rüber.
Kurz:
HM-TC-IT-WM-EU: kueche_WandThermostat
HM-CC-RT-DN: kueche_Thermostat, wz_Thermostat, sz_Thermostat, ...
virtueller Fenster Sensor über vccu: kuecheFensterSensor, wz_FensterSensor, sz_FensterSensor ...
kuecheWandThermostat und kuecheThermostat Kanäle _Clima und _Weather gepaired, wie im Wiki angegeben.
Erster Versuch:
kueche_FensterSensor mit kueche_Wandthermostat_WindowRec gepaired (d.h. der Fenstersensor ist nur mit dem Wandthermostat verbunden)
=>Wenn ich in der Küche das Fenster öffne, werden _alle_ RT-DN runtergeregelt, obwohl kein Pairing zwischen kuecheFensterSensor und den anderen RT-DN existiert. Das ist für mich absolut unerklärlich.
Zweiter Versuch:
kueche_FensterSensor mit kueche_WindowRec gepaired (d.h. der Fenstersensor ist nur mit dem Heizkörperthermostat verbunden)
=>Wenn ich in der Küche das Fenster öffne, wird nur der Thermostat in der Küche runtergeregelt. Nach kurzer Zeit überschreibt aber der Wandthermostat wieder die Zieltemperatur (er weiss ja nicht, dass das Fenster auf ist).
Dritter Versuch:
kueche_FensterSensor mit Wand- und Heizkörperthermostat verbunden.
=>Gleiches Ergebnis wie beim ersten Versuch.
Da ich leider kein Profi im Debugger bin, wäre es nett, wenn Ihr mir helfen könntet, den Fehler zu finden.
was genau soll denn passieren?
Ich habe meine Ventile (RT-DN) mit dem WandThermostat (WM-EU) gepeert.
Der Fensterkontakt (oder Kontakte) sind mit dem Wandthermostat gepeert.
Geht ein Fenster auf, regelt der Thermostat die Ventile runter.
Man muss die Kontakte nicht mit den Thermostaten peeren.
Bitte den Unterschied zwishen Pairing -> mit Zentrale und peering -> zwischen Geräten beachten :-)
Hallo slor,
Ok, ich meinte natürlich gepeert, nicht gepaired.
Was passieren soll:
Wenn ich in der Küche das Fenster aufmache, dann soll der Thermostat in der Küche runtergeregelt werden. Und nicht gleichzeitig alle anderen Thermostate in der Wohnung. Leider passiert das aber, wenn ich den Fenster Sensor mit dem WM-EU peere. Das macht so ja keinen Sinn.
Was mir noch aufgefallen ist: Im Bad habe ich keinen Fenster Sensor - der Thermostat wird auch nicht runtergeregelt.
zeig mal die ausgabe von "get hminfo peerXref" für deinen 1. fall. zusätzlich "get hminfo configCheck".
get hminfo peerXref
peerXref done:
x-ref list
ez_WindowRec => v_ez_FensterSensor
flur_Deckenlampe => self01
kueche_Climate => kueche_Wandthermostat_Climate
kueche_Wandthermostat_Climate => kueche_Climate
kueche_Wandthermostat_Weather => kueche_Weather
kueche_Wandthermostat_WindowRec => v_kueche_FensterSensor
kueche_Weather => kueche_Wandthermostat_Weather
kz_WindowRec => v_kz_FensterSensor
sz_WindowRec => v_sz_FensterSensor
v_ez_FensterSensor => ez_WindowRec
v_kueche_FensterSensor => kueche_Wandthermostat_WindowRec
v_kz_FensterSensor => kz_WindowRec
v_sz_FensterSensor => sz_WindowRec
v_wz_FensterSensor => wz_WindowRec
vccu_wz_vT_1 => wz_Weather
wz_Weather => vccu_wz_vT_1
wz_WindowRec => v_wz_FensterSensor
get hminfo configCheckResult
configCheck done:-ret--ret- missing register list-ret- klingel: RegL_00.,RegL_01.-ret- kz_Taster1: RegL_01.-ret- kz_Taster2: RegL_01.-ret- kz_Taster3: RegL_01.-ret- kz_Taster4: RegL_01.-ret- kz_Taster: RegL_00.-ret- wz_Taster2: RegL_01.-ret--ret- peer list incomplete. Use getConfig to read it.-ret- incomplete: klingel:-ret- incomplete: kz_Taster1:-ret- incomplete: kz_Taster2:-ret- incomplete: kz_Taster3:-ret- incomplete: kz_Taster4:-ret--ret- PairedTo missing/unknown-ret- klingel
Die Fehler mit den Tastern und dem Klingelsensor sind wohl hier nicht relevant, und das Peering scheint zu stimmen, oder?
Die virtuellen sensoren sind Kanäle des gleichen device? Vccu?
Trenne das einmal. Evtl lauschen die anderen rts und filtern den kanal nicht
Zitat von: martinp876 am 29 Oktober 2018, 21:00:29
Die virtuellen sensoren sind Kanäle des gleichen device? Vccu?
Trenne das einmal. Evtl lauschen die anderen rts und filtern den kanal nicht
Die Beobachtung habe ich auch gemacht: Bei mir haben 2 HM-TC-IT-WM-EU auch jeweils kreuzweise auf das andere virtuelle Fenster reagiert, solange das nur unterschiedliche Kanäle des gleichen Device waren. Seit ich da unterschiedliche Devices verwende, funktioniert alles wie geplant.
Turo
Zitat von: martinp876 am 29 Oktober 2018, 21:00:29
Die virtuellen sensoren sind Kanäle des gleichen device? Vccu?
Trenne das einmal. Evtl lauschen die anderen rts und filtern den kanal nicht
Genau.
Ob Fenster- oder Temperatursensoren... wenn es das selbe virtuelle Device ist, geht es meist schief weil der Thermostat nur auf den 1. kanal des Devices guckt.
Siehe hier... https://forum.fhem.de/index.php/topic,19686.msg773977.html#msg773977 (https://forum.fhem.de/index.php/topic,19686.msg773977.html#msg773977)
Hallo zusammen,
Danke für eure Ratschläge. Ja, die Fenstersensoren sind als Channels einer VCCU implementiert.
Ich habe mal einiges ausprobiert, komme aber nicht zum Ziel:
Ich würde ja gerne getrennte Devices für die unterschiedlichen virtuellen Fenstersensoren anlegen, aber wie geht das? Wenn ich eine weitere VCCU mit der gleichen HMID anlegen will, geht das nicht ("HMid DEF already used by vccu"). Wenn ich eine andere HMID verwende, schlägt das Peeren fehl.
Die Wiki-Artikel https://wiki.fhem.de/wiki/HomeMatic#Besondere_Entities und https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU helfen hier nur bedingt, denn es ist nirgendwo beschrieben, wie man mehrere Devices mit der selben HMID anlegt.
Könnt ihr vielleicht mal kurz skizzieren, wie das geht?
Vielen Dank!
Hallo,
also mit der selben HMID wird das nix - das muss jeweils eine neue sein. Denk Dir eine neue 6-stellige HMID aus und mach es genau so, wie in dem von Dir verlinkten Wiki-Artikel unter "Virtuelle Entities" beschrieben ist! Das erzeugt dann (mindestens) noch einen Kanal (mit 8-stelliger HMID), den Du dann peeren kannst. Oder was genau geht da beim peeren schief?
Gruss,
Turo
Neues Device:
Internals:
CFGFN
DEF AFFE00
IODev
NAME vhm_kueche_Fenster
NOTIFYDEV global
NR 501
STATE ???
TYPE CUL_HM
channel_01 vhm_kueche_Fenster_Sensor
READINGS:
helper:
HM_CMDNR 217
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +AFFE00,00,00,00
prefIO
rxt 0
vccu
p:
AFFE00
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
expert 2_raw
model virtual_1
subType virtual
webCmd virtual
Neuer Channel:
Internals:
CFGFN
DEF AFFE0001
NAME vhm_kueche_Fenster_Sensor
NOTIFYDEV global
NR 504
STATE set_postEvent open
TYPE CUL_HM
chanNo 01
device vhm_kueche_Fenster
peerList kueche_Wandthermostat_WindowRec,
READINGS:
2018-11-06 14:13:50 peerList kueche_Wandthermostat_WindowRec,
2018-11-06 13:49:04 state set_postEvent open
helper:
count 5
expert:
def 1
det 1
raw 0
tpl 0
role:
chn 1
vrt 1
Attributes:
expert 1_allReg
model virtual_1
peerIDs 3879CD03,
webCmd postEvent open:postEvent closed
Nach Ausführen von
set vhm_kueche_Fenster_Sensor peerChan 0 kueche_Wandthermostat_WindowRec single set
steht folgendes im Event-Log:
2018-11-06 14:18:27 CUL_HM kueche_Wandthermostat CMDs_pending
2018-11-06 14:18:36 CUL_HM kueche_Wandthermostat ResndFail
2018-11-06 14:18:36 CUL_HM kueche_Wandthermostat CMDs_done_Errors:1
2018-11-06 14:18:36 CUL_HM kueche_Wandthermostat MISSING ACK
Und das Peering taucht niemals in kueche_Wandthermostat_WindowRec auf.
Klingt eigentlich richtig. Ich habe noch IOgrp gesetzt beim Device. Manchmal braucht das Peeren nach meiner Erfahrung auch mehrere Versuche (und immer schön mit Ruhe und jedes Mal die Anlerntaste drücken...).
Ich poste mal schnell meine funktionierende Konfiguration: Vielleicht findest Du noch einen wichtigen Unterschied.
Device:
Internals:
DEF A6A00E
IODev hmusb
LASTInputDev hmusb
MSGCNT 29
NAME Virtual_Contacts1
NOTIFYDEV global
NR 455
NTFY_ORDER 50-Virtual_Contacts1
STATE Info_Cleared
TYPE CUL_HM
channel_01 virtual_Fenster_Leo
hmusb_MSGCNT 29
hmusb_RAWMSG EA6A00E,0000,4ACDE9C7,FF,FFBE,C7A441A6A00E354975011E00
hmusb_RSSI -66
hmusb_TIME 2018-11-06 08:23:41
lastMsg No:C7 - t:41 s:A6A00E d:354975 011E00
protLastRcv 2018-11-06 08:23:41
protRcv 29 last_at:2018-11-06 08:23:41
rssi_at_hmusb cnt:29 min:-79 max:-59 avg:-68.03 lst:-66
READINGS:
helper:
HM_CMDNR 199
mId
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
nextSend 1541489021.48404
prefIO
vccu VCCU
mRssi:
mNo C7
io:
hmusb:
-62
-62
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_hmusb:
avg -68.0344827586207
cnt 29
lst -66
max -59
min -79
shadowReg:
Attributes:
IODev hmusb
IOgrp VCCU
expert 2_full
model virtual_1
room Homematic
subType virtual
webCmd virtual
Kanal:
Internals:
DEF A6A00E01
NAME virtual_Fenster_Leo
NOTIFYDEV global
NR 456
NTFY_ORDER 50-virtual_Fenster_Leo
STATE set_postEvent closed
TYPE CUL_HM
chanNo 01
device Virtual_Contacts1
peerList Heizung_Leo_WindowRec,
Helper:
DBLOG:
state:
logdb:
TIME 1541489019.46386
VALUE set_postEvent closed
trigger_cnt:
logdb:
TIME 1541489021.44212
VALUE 30
READINGS:
2018-10-22 20:18:10 peerList Heizung_Leo_WindowRec,
2018-11-06 08:23:39 state set_postEvent closed
2018-11-06 08:23:41 trigger_cnt 30
helper:
count 30
expert:
def 1
det 1
raw 0
tpl 0
role:
chn 1
vrt 1
shadowReg:
Attributes:
devStateIcon set_postEvent.closed:shutter_closed set_postEvent.open:shutter_open
expert 1
group Virtual
model virtual_1
peerIDs 36497503,
room Heizung,Homematic
webCmd postEvent closed:postEvent open
Gruss,
Turo
Hallo,
manchmal kann die Welt so einfach sein - ein
attr vhm_kueche_Fenster IODev CUL_0
und anschließendes erneutes Peeren hat zum Erfolg geführt! :)
Und jetzt spielen die Thermostate auch nicht mehr verrückt.
Vielen Dank an alle die geholfen haben!