und ich dachte, die Kopplung zweier HM Komponenten wäre einfacher als die Kopplung von Kontakten und Thermostatventilen unterschiedlicher Systeme ...
Mein Thermostat reagiert nicht auf den Fensterkontakt, hier mal die Listings:
Internals:
DEF 3F3098
HMLAN1_MSGCNT 14
HMLAN1_RAWMSG E3F3098,0000,1141BB73,FF,FFBA,0C84413F309800000001E500
HMLAN1_RSSI -70
HMLAN1_TIME 2016-10-04 23:01:07
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 14
NAME bd_fenster
NR 330
NTFY_ORDER 50-bd_fenster
STATE closed
TYPE CUL_HM
lastMsg No:0C - t:41 s:3F3098 d:000000 01E500
protCmdDel 14
protLastRcv 2016-10-04 23:01:07
protNack 2 last_at:2016-10-04 22:54:27
protSnd 3 last_at:2016-10-04 22:54:27
protState CMDs_done_Errors:1
rssi_at_HMLAN1 avg:-71.78 min:-78 max:-64 lst:-70 cnt:14
Readings:
2016-10-04 21:07:43 Activity alive
2016-10-04 22:54:27 CommandAccepted no
2015-11-06 15:30:57 D-firmware 1.0
2015-11-06 15:30:57 D-serialNr MEQ0888125
2015-11-06 15:30:02 PairedTo 0x000000
2015-11-06 15:30:02 R-cyclicInfoMsg on
2015-11-06 15:30:02 R-eventDlyTime 0 s
2015-11-06 15:30:02 R-pairCentral 0x000000
2016-10-04 18:59:31 R-rt_bd_og_WindowRec-expectAES set_off
2016-10-04 18:59:31 R-rt_bd_og_WindowRec-peerNeedsBurst set_on
2015-11-06 15:30:02 R-sabotageMsg on
2015-11-06 15:30:02 R-sign on
2016-10-04 22:54:26 alive yes
2016-10-04 23:01:07 battery ok
2016-10-04 23:01:07 contact closed (to broadcast)
2016-10-04 22:54:26 recentStateType info
2016-10-04 22:54:26 sabotageError off
2016-10-04 23:01:07 state closed
2016-10-04 23:01:07 trigger_cnt 229
Helper:
HM_CMDNR 12
cSnd ,012CD7B93F30980101440A160300
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +3F3098,00,00,00
nextSend 1475614867.14188
prefIO
rxt 2
vccu
p:
3F3098
00
00
00
Mrssi:
mNo 0C
Io:
HMLAN1 -68
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -71.7857142857143
cnt 14
lst -70
max -64
min -78
Shadowreg:
RegL_04.rt_bd_og_WindowRec 01:01
Tmpl:
Nb:
cnt 1
Attributes:
IODev HMLAN1
actCycle 000:50
actStatus alive
autoReadReg 4_reqStatus
devStateIcon .*open:fts_window_1w_tilt .*closed:fts_window_1w
expert 2_full
firmware 1.0
fp_Obergeschoss 415,1105,0,,
model HM-SEC-SCo
og_fenster_type og_fenster
peerIDs 00000000,
room CUL_HM,Fenster
serialNr MEQ0888125
subType threeStateSensor
userattr og_fenster_type og_fenster_type_map structexclude xg_fenster_type xg_fenster_type_map
xg_fenster_type xg_fenster
Internals:
CFGFN
CHANGED
DEF 440A1603
NAME rt_bd_og_WindowRec
NR 639
STATE last:trigLast
TYPE CUL_HM
chanNo 03
device rt_bd_og
peerList bd_fenster,
Readings:
2016-10-04 21:34:34 R-sign off
2016-10-04 22:50:47 RegL_01. 08:00 00:00
2016-10-04 22:50:47 RegL_03.bd_fenster_chn-01 04:32 00:00
2016-10-04 22:50:48 RegL_07.bd_fenster_chn-01 05:0A 00:00
2016-10-04 22:50:46 peerList bd_fenster,
2016-10-04 22:50:46 state unknown
Helper:
peerIDsRaw ,3F309801,00000000
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Shadowreg:
Tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,3F309801,
stateFormat last:trigLast
Laut deinem List hat der Fensterkontakt kein Pairing und auch kein Peering mit dem Thermostat.
2015-11-06 15:30:02 PairedTo 0x000000
peerIDs 00000000,
ja, Danke ...
nach dem Befehl set bd_fenster peerChan 0 rt_bd_og_WindowRec single
muss man noch den Fensterkontakt und den Thermostat direkt koppeln, schon klappts ... ;)
Zitat von: grappa24 am 05 Oktober 2016, 00:46:48
muss man noch den Fensterkontakt und den Thermostat direkt koppeln, schon klappts ... ;)
Blöde Frage, habe als FHEM-Neuling gerade das gleiche Problem. Was meinst Du mit direkt koppeln?
Zitat von: DanBu am 05 Oktober 2016, 13:05:41
Blöde Frage, habe als FHEM-Neuling gerade das gleiche Problem. Was meinst Du mit direkt koppeln?
Direkt koppeln (auch peeren genannt) bedeutet, dass der Aktor beim Empfang eines Funk-Telegrams/Kommandos dieses ausführt ohne dass eine Zentrale oder Fhem oder oder dazwischen ist...
Beispiel mit peering: Fensterkontakt meldet "Fenster offen" und der Heizkörpterthermostat (Aktor) schaltet darauf die Soll-Temp runter.
D.h. das funktioniert solange Sensor und Aktor funktionieren (und keine Funkstörungen da sind)
Ohne peering:
Fentserkontakt meldet "Fenster auf", Zentrale/fhem "hört" das und sendet nun eine neue niedrigere Soll-Temp an das Heizkörperthermostat...
Funktioniert nur solange die Zentrale/fhem funktioniert (und keine Funkstörungen da sind)
Weil ich grad dabei bin: Pairing hingegen ist das "Verbinden" mit einer Zentrale...
Aktor, Sensor, ... -> Zentrale: Pairing
Sensor -> Aktor: Peering
Gruß, Joachim
Schau mal DanBu, hier ist es ganz gut beschrieben:
http://www.meintechblog.de/2014/10/smarthome-fenstergesteuerte-heizungsregelung/
Hallo zusammen,
muss hier in das Thema einmal mit einsteigen. Ich komme soweit das der Fensterkontakt und Thermostat sich finden, es funktioniert auch kurzzeitig, aber nach ca. 30 Sekunden klappt es nicht mehr. Sobald ich am Thermostat die Boosttaste wieder drücke funktioniert es wieder und bricht dann kurz darauf wieder ab :(
Thermostat = HM-CC-RT-DN [1.4]
Fensterkontakt = HM-SEC-SCo [1.0]
FHEM = 5.7
Sollte ein neuer Thread besser sein, erstelle ich den gerne, aber vielleicht hilft das dann hier auch weiter dachte ich mir.
Gruß
Gerhard
Hallo Gerhard,
hilf uns mal ein bißchen weiter:
- Wie finden die sich? Was meinst du damit?
- Was funktioniert für 30 Sekunden und was funktioniert denn nicht?
- Kannst du mal ein List von den beiden Geräten machen und hier in Code-Tag posten?
Gruß Cobra
Grüß euch
Habe das ganz gleiche Problem wie STING333. Zwei Fensterkontakt mit Stellantrieb gepeert und Firmware auf 1.4.
Fenstererkennung funktioniert nicht. Halte ich aber die Boosttaste am Stellantrieb gedrückt wo der Countdown 30s runterzählt, erlischt der Counter nach 2-3Sekunden und dann klappt die Fenstererkennung auch "einige Zeit". Vielleicht ein paar Minuten. Eine halbe Stunde später wieder nicht mehr. Anbei die Internals.
Internals:
DEF 269BFF
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 77
NAME wz0_sta00
NOTIFYDEV global
NR 83
STATE CMDs_pending
TYPE CUL_HM
channel_01 wz0_sta00_Weather
channel_02 wz0_sta00_Climate
channel_03 wz0_sta00_WindowRec
channel_04 wz0_sta00_Clima
lastMsg No:0A - t:10 s:269BFF d:000000 0AC0ED894E00
protCmdDel 50
protCmdPend 22 CMDs_pending
protLastRcv 2016-12-19 01:33:52
protResnd 16 last_at:2016-12-19 01:33:56
protResndFail 2 last_at:2016-12-19 01:10:43
protSnd 71 last_at:2016-12-19 01:33:52
protState CMDs_pending
rssi_ActionDetector lst:-59 cnt:35 min:-59 avg:-59 max:-59
rssi_at_wz0_cul00 min:-58 avg:-57.55 max:-57 cnt:77 lst:-57.5
wz0_cul00_MSGCNT 77
wz0_cul00_RAWMSG A0F0A8610269BFF0000000AC0ED894E00::-57.5:wz0_cul00
wz0_cul00_RSSI -57.5
wz0_cul00_TIME 2016-12-19 01:33:52
Readings:
2016-12-19 01:26:52 CommandAccepted yes
2016-12-18 14:10:37 D-firmware 1.4
2016-12-18 14:10:37 D-serialNr LEQ0105862
2016-12-12 22:30:02 PairedTo 0x000001
2016-12-12 22:30:02 R-backOnTime 10 s
2016-12-12 22:30:02 R-burstRx on
2016-12-12 22:30:02 R-cyclicInfoMsg on
2016-12-12 22:30:02 R-cyclicInfoMsgDis 0
2016-12-12 22:30:02 R-pairCentral 0x000001
2016-12-12 22:30:02 RegL_00. 01:01 02:01 09:01 0A:00 0B:00 0C:01 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2016-12-19 01:33:52 actuator 78
2016-12-19 01:26:57 battery ok
2016-12-19 01:33:52 batteryLevel 2.4
2016-12-18 14:20:00 controlMode auto
2016-12-19 01:33:52 desired-temp 24.0
2016-12-19 01:33:52 measured-temp 23.7
2016-12-19 01:33:52 motorErr communicationERR
2016-12-15 00:39:27 sabotageAttackId_ErrIoId_26043E cnt:34
2016-12-15 00:39:27 sabotageAttack_ErrIoAttack cnt 34
2016-12-19 01:34:44 state CMDs_pending
2016-12-18 10:06:10 time-request -
Regl_07.:
VAL
cmdStack:
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
++A011000001269BFF860430
Helper:
HM_CMDNR 11
PONtest 1
cSnd 11000001269BFF860430,11000001269BFF860430
mId 0095
rxType 140
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +269BFF,02,00,00
nextSend 1482107632.37709
prefIO
rxt 2
vccu
p:
269BFF
00
00
00
Mrssi:
mNo 0A
Io:
wz0_cul00 -55.5
Prt:
bErr 0
sProc 2
wuReSent 4
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
Actiondetector:
avg -59
cnt 35
lst -59
max -59
min -59
At_wz0_cul00:
avg -57.5519480519481
cnt 77
lst -57.5
max -57
min -58
Shregw:
07 04
Attributes:
IODev wz0_cul00
actCycle 000:10
actStatus
alias Stellantrieb Wohnzimmer
autoReadReg 4_reqStatus
expert 2_full
firmware 1.4
group [Homematic] Stellantriebe
model HM-CC-RT-DN
room Geräte
serialNr LEQ0105862
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Moin,
poste doch mal noch ein List von den beiden Fensterkontakten, im Liste des Thermostaten finde ich von den beiden nichts.
Dafür aber 22 CMD die noch zum Thermostaten sollten. Drücke doch mal in der Device Übersicht den BurstXmit Button.
Hast du schon einmal versucht mit
set fensterkontakt peerChan 0 Thermostat_WindowRec single
zu peeren?
Grüße
Achim
PeerChan habe ich schon mehrfach versucht. Nach jedem Peerchan funktioniert die Abschaltung genau einmal und das war es dann wieder. Anbei die List der Kontakte
wz0_kon00
Internals:
DEF 359B02
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 10
NAME wz0_kon00
NOTIFYDEV global
NR 127
STATE closed
TYPE CUL_HM
lastMsg No:34 - t:41 s:359B02 d:000000 017500
protCmdPend 4 CMDs pending
protLastRcv 2016-12-19 22:14:23
protResnd 1 last_at:2016-12-19 22:11:45
protSnd 5 last_at:2016-12-19 22:11:44
protState CMDs_pending
rssi_at_wz0_cul00 cnt:10 avg:-69.9 max:-59.5 min:-90 lst:-64
wz0_cul00_MSGCNT 10
wz0_cul00_RAWMSG A0C348441359B02000000017500::-64:wz0_cul00
wz0_cul00_RSSI -64
wz0_cul00_TIME 2016-12-19 22:14:23
Readings:
2016-12-19 22:11:43 D-firmware 1.0
2016-12-19 22:11:43 D-serialNr LEQ1510020
2016-12-19 21:51:35 R-wz0_sta00_WindowRec-expectAES set_off
2016-12-19 21:51:35 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2016-12-19 22:11:44 aesKeyNbr 00
2016-12-19 21:26:53 alive yes
2016-12-19 22:14:23 battery ok
2016-12-19 22:14:23 batteryLevel ok
2016-12-19 22:14:23 contact closed (to broadcast)
2016-12-19 21:26:53 recentStateType info
2016-12-19 21:26:53 sabotageError off
2016-12-19 22:14:23 state closed
2016-12-19 22:14:23 trigger_cnt 117
cmdStack:
++A001000001359B0201080101
++A001000001359B020106
++A001000001359B0200040000000000
++A001000001359B0201040000000001
++A001000001359B020103
Helper:
HM_CMDNR 52
cSnd 01000001359B020105269BFF0304,01000001359B0201080101
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +359B02,02,00,00
nextSend 1482182063.4575
prefIO
rxt 2
vccu
p:
359B02
00
00
00
Mrssi:
mNo 34
Io:
wz0_cul00 -62
Prt:
bErr 0
sProc 2
wuReSent 2
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_wz0_cul00:
avg -69.9
cnt 10
lst -64
max -59.5
min -90
Shadowreg:
RegL_04.wz0_sta00_WindowRec 01:01
Attributes:
IODev wz0_cul00
actCycle 001:05
actStatus
alias Fensterkontakt Wohnzimmer links
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
group [Homematic] Kontakte
model HM-SEC-SCo
peerIDs 00000000,
room Geräte,Kontakte
serialNr LEQ1510020
subType threeStateSensor
userReadings batteryLevel { ReadingsVal("wz0_kon00","battery",0); }
wz0_kon01
nternals:
DEF 359B3E
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 13
NAME wz0_kon01
NOTIFYDEV global
NR 131
STATE closed
TYPE CUL_HM
lastMsg No:8C - t:41 s:359B3E d:000000 018F00
protCmdPend 4 CMDs pending
protLastRcv 2016-12-19 22:14:15
protResnd 1 last_at:2016-12-19 22:11:33
protSnd 5 last_at:2016-12-19 22:11:29
protState CMDs_pending
rssi_at_wz0_cul00 min:-75.5 avg:-71.88 max:-60 cnt:13 lst:-75.5
wz0_cul00_MSGCNT 13
wz0_cul00_RAWMSG A0C8C8441359B3E000000018F00::-75.5:wz0_cul00
wz0_cul00_RSSI -75.5
wz0_cul00_TIME 2016-12-19 22:14:15
Readings:
2016-12-19 22:11:29 D-firmware 1.0
2016-12-19 22:11:29 D-serialNr LEQ1510062
2016-12-19 21:52:01 R-wz0_sta00_WindowRec-expectAES set_off
2016-12-19 21:52:01 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2016-12-19 22:11:29 aesKeyNbr 00
2016-12-19 21:28:04 alive yes
2016-12-19 22:14:15 battery ok
2016-12-19 22:14:15 batteryLevel ok
2016-12-19 22:14:15 contact closed (to broadcast)
2016-12-17 01:45:12 powerOn 2016-12-17 01:45:12
2016-12-19 21:28:04 recentStateType info
2016-12-19 21:28:04 sabotageError off
2016-12-19 22:14:15 state closed
2016-12-19 22:14:15 trigger_cnt 143
cmdStack:
++A001000001359B3E01080101
++A001000001359B3E0106
++A001000001359B3E00040000000000
++A001000001359B3E01040000000001
++A001000001359B3E0103
Helper:
HM_CMDNR 140
cSnd 01000001359B3E0105269BFF0304,01000001359B3E01080101
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +359B3E,02,00,00
nextSend 1482182055.66034
prefIO
rxt 2
vccu
p:
359B3E
00
00
00
Mrssi:
mNo 8C
Io:
wz0_cul00 -73.5
Prt:
bErr 0
sProc 2
wuReSent 2
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_wz0_cul00:
avg -71.8846153846154
cnt 13
lst -75.5
max -60
min -75.5
Shadowreg:
RegL_04.wz0_sta00_WindowRec 01:01
Attributes:
IODev wz0_cul00
actCycle 001:05
actStatus
alias Fensterkontakt Wohnzimmer rechts
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
group [Homematic] Kontakte
model HM-SEC-SCo
peerIDs 00000000,
room Geräte,Kontakte
serialNr LEQ1510062
subType threeStateSensor
userReadings batteryLevel { ReadingsVal("wz0_kon01","battery",0); }
Es sind noch Commands pending und keine Peers eingetragen...
Ich sehe auch nicht, ob die schon komplett gepaired sind (übersehen?)...
Also erst mal die anstehenden Kommandos abarbeiten lassen: ab und an mal den Config-Knopf am Fenstersensor drücken...
Dann schauen, ob die Fenstersensoren richtig angelernt sind: R-PairCentral / PairedTo da müsste deine (gewählte) HMID stehen.
Ebenso bei den Heizkörperthermostaten...
Dann noch mal den Peer-Befehl absetzen und wieder (sowohl beim Thermostaten als auch beim Fensterkontakt) immer mal wieder den Config-Taster drücken oder einfach warten.
Es sind "wakeup-Devices", sie brauchen bis die Kommandos abgearbeitet sind!
Hektik ist kontraproduktiv.
Und dann schauen was bei peerIDs steht...
...da muss der jeweilige Kanal des anderen Gerätes stehen...
Es hilft auch: set hm configCheck:
https://wiki.fhem.de/wiki/HomeMatic_HMInfo (https://wiki.fhem.de/wiki/HomeMatic_HMInfo)
Gruß, Joachim
P.S.: evtl. auch mal ein list des/der (Heizkörper)thermostate
Hatte noch einen Bug mit den Stellantrieben, der jetzt behoben ist. Fensterkontakte soeben wieder mit: set wz0_kon00 peerChan 0 wz0_sta00_WindowRec single set, Configknopf gedrückt. Ich öffne das Fenster, Stellantrieb regelt runter.
list wz0_kon00
Internals:
DEF 359B02
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 17
NAME wz0_kon00
NOTIFYDEV global
NR 131
STATE closed
TYPE CUL_HM
lastMsg No:8B - t:41 s:359B02 d:000000 017F00
protCmdPend 13 CMDs_pending
protLastRcv 2016-12-22 00:36:03
protResnd 2 last_at:2016-12-22 00:14:18
protSnd 6 last_at:2016-12-22 00:14:15
protState CMDs_pending
rssi_at_wz0_cul00 lst:-65.5 cnt:17 avg:-68.26 max:-60.5 min:-81.5
wz0_cul00_MSGCNT 17
wz0_cul00_RAWMSG A0C8B8441359B02000000017F00::-65.5:wz0_cul00
wz0_cul00_RSSI -65.5
wz0_cul00_TIME 2016-12-22 00:36:03
Readings:
2016-12-22 00:14:13 D-firmware 1.0
2016-12-22 00:14:13 D-serialNr LEQ1510020
2016-12-22 00:14:14 PairedTo 0x000000
2016-12-22 00:14:14 R-cyclicInfoMsg on
2016-12-22 00:14:14 R-pairCentral 0x000000
2016-12-22 00:14:14 R-sabotageMsg on
2016-12-19 21:51:35 R-wz0_sta00_WindowRec-expectAES set_off
2016-12-19 21:51:35 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2016-12-22 00:14:14 RegL_00. 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00
2016-12-22 00:34:28 RegL_01.
2016-12-19 22:11:44 aesKeyNbr 00
2016-12-22 00:07:59 alive yes
2016-12-22 00:36:03 battery ok
2016-12-22 00:36:03 batteryLevel ok
2016-12-22 00:36:03 contact closed (to broadcast)
2016-12-22 00:07:59 recentStateType info
2016-12-22 00:07:59 sabotageError off
2016-12-22 00:36:03 state closed
2016-12-22 00:36:03 trigger_cnt 127
cmdStack:
++A001000001359B0201040000000001
++A001000001359B020103
++A001000001359B020101269BFF0300
++A001000001359B020105269BFF0304
++A001000001359B0201080101
++A001000001359B020106
++A001000001359B0200040000000000
++A001000001359B0201040000000001
++A001000001359B020103
++A001000001359B020101269BFF0300
++A001000001359B020105269BFF0304
++A001000001359B0201080101
++A001000001359B020106
Helper:
HM_CMDNR 139
cSnd 01000001359B0200040000000000,01000001359B0201040000000001
getCfgList all
getCfgListNo ,4
mId 00C7
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +359B02,02,00,00
nextSend 1482363363.49963
prefIO
rxt 2
vccu
p:
359B02
00
00
00
Mrssi:
mNo 8B
Io:
wz0_cul00 -63.5
Prt:
bErr 0
sProc 2
wuReSent 2
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rssi:
At_wz0_cul00:
avg -68.2647058823529
cnt 17
lst -65.5
max -60.5
min -81.5
Shadowreg:
RegL_04.wz0_sta00_WindowRec 01:01
Attributes:
IODev wz0_cul00
actCycle 001:05
actStatus
alias Fensterkontakt Wohnzimmer links
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
group [Homematic] Kontakte
model HM-SEC-SCo
peerIDs 00000000,
room Geräte,Kontakte
serialNr LEQ1510020
subType threeStateSensor
userReadings batteryLevel { ReadingsVal("wz0_kon00","battery",0); }
list wz0_sta00
Internals:
DEF 269BFF
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 73
NAME wz0_sta00
NOTIFYDEV global
NR 87
STATE CMDs_pending
TYPE CUL_HM
channel_01 wz0_sta00_Weather
channel_02 wz0_sta00_Climate
channel_03 wz0_sta00_WindowRec
channel_04 wz0_sta00_Clima
channel_05 wz0_sta00_ClimaTeam
channel_06 wz0_sta00_remote
lastMsg No:A5 - t:10 s:269BFF d:000000 0AA0DF890000
protCmdPend 12 CMDs pending
protLastRcv 2016-12-22 00:40:57
protResnd 18 last_at:2016-12-22 00:41:02
protSnd 60 last_at:2016-12-22 00:40:57
protState CMDs_pending
rssi_at_wz0_cul00 max:-61.5 avg:-64.3 min:-78 cnt:73 lst:-63
wz0_cul00_MSGCNT 73
wz0_cul00_RAWMSG A0FA58610269BFF0000000AA0DF890000::-63:wz0_cul00
wz0_cul00_RSSI -63
wz0_cul00_TIME 2016-12-22 00:40:57
Readings:
2016-12-22 00:38:48 CommandAccepted yes
2016-12-22 00:35:40 D-firmware 1.4
2016-12-22 00:35:40 D-serialNr LEQ0105862
2016-12-12 22:30:02 PairedTo 0x000001
2016-12-12 22:30:02 R-backOnTime 10 s
2016-12-12 22:30:02 R-burstRx on
2016-12-12 22:30:02 R-cyclicInfoMsg on
2016-12-12 22:30:02 R-cyclicInfoMsgDis 0
2016-12-12 22:30:02 R-pairCentral 0x000001
2016-12-12 22:30:02 RegL_00. 01:01 02:01 09:01 0A:00 0B:00 0C:01 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2016-12-22 00:40:57 actuator 0
2016-12-21 22:39:49 battery ok
2016-12-22 00:40:57 batteryLevel 2.4
2016-12-19 22:12:23 controlMode auto
2016-12-22 00:40:57 desired-temp 20.0
2016-12-22 00:40:57 measured-temp 22.3
2016-12-22 00:40:57 motorErr communicationERR
2016-12-15 00:39:27 sabotageAttackId_ErrIoId_26043E cnt:34
2016-12-15 00:39:27 sabotageAttack_ErrIoAttack cnt 34
2016-12-22 00:41:02 state CMDs_pending
2016-12-21 06:22:05 time-request -
Regl_07.:
VAL
cmdStack:
++A001000001269BFF00040000000007
++A001000001269BFF0301359B020101
++A001000001269BFF0301359B3E0101
++A001000001269BFF0303
++A001000001269BFF03040000000001
++A001000001269BFF0503
++A001000001269BFF05040000000001
++A001000001269BFF0603
++A001000001269BFF06040000000001
++A001000001269BFF0301359B020101
++A001000001269BFF0303
++A001000001269BFF03040000000001
Helper:
HM_CMDNR 166
cSnd 01000001269BFF00040000000007,01000001269BFF00040000000007
mId 0095
rxType 140
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +269BFF,02,00,00
nextSend 1482363657.79995
prefIO
rxt 2
vccu
p:
269BFF
00
00
00
Mrssi:
mNo A5
Io:
wz0_cul00 -61
Prt:
bErr 0
sProc 2
wuReSent 3
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
At_wz0_cul00:
avg -64.3082191780822
cnt 73
lst -63
max -61.5
min -78
Shregw:
07 04
Shadowreg:
RegL_00. 01:01 02:01 09:01 0A:00 0B:00 0C:01 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
Attributes:
IODev wz0_cul00
actCycle 000:10
actStatus
alias Stellantrieb Wohnzimmer
autoReadReg 4_reqStatus
expert 2_full
firmware 1.4
group [Homematic] Stellantriebe
model HM-CC-RT-DN
room Geräte
serialNr LEQ0105862
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Nach ca. einer Minute klappt es wieder nicht mehr.
Erst mal das Pairing abschließen, ansonsten nix mit Peering-Aufrufen:
Zitat
2016-12-22 00:14:14 PairedTo 0x000000
2016-12-22 00:14:14 R-cyclicInfoMsg on
2016-12-22 00:14:14 R-pairCentral 0x000000
Weil die HMID ist ja hoffentlich nicht 000000!??
Nein, sie ist wohl 000001...
Und es sind auch noch cmds pending, also ist noch nicht alles abgeschlossen...
Gruß, Joachim
Hallo Joachim
Danke für deine Tipps. Die HMID des CUL ist 000001.
Es waren auch schon keine Commands Pending und es klappte nicht.
Was mich stutzig macht ist, dass es ja unmittelbar nach dem peerChan ja klappt. Sprich: peerChan Fensterkontakt 0, Fensterkontakt 1, Anlerntaste Fensterkontakt 0, Fensterkontakt 1, Configtaste Stellantrieb. Öffne Fenster 0, der Stellantrieb regelt hinunter, schließe, er regelt hoch. Öffne Fenster 1, wieder das gleiche. Warte ca 1min. plötzlich klappt es weder bei Fenster 0 noch 1. So als ob im Stellantrieb irgendwas in den Standby geht und nicht mehr geweckt wird.
Was mich wundert ist dass die Kontakte mit peerID 00000000 und der Windowrec allerdings mit: 359B0201,359B3E01 gepeert ist.
define wz0_cul00 CUL com1@9600 0000
attr wz0_cul00 hmId 000001
attr wz0_cul00 rfmode HomeMatic
define wz0_sta00 CUL_HM 269BFF
attr wz0_sta00 IODev wz0_cul00
attr wz0_sta00 actCycle 000:10
attr wz0_sta00 actStatus
attr wz0_sta00 alias Stellantrieb Wohnzimmer
attr wz0_sta00 autoReadReg 4_reqStatus
attr wz0_sta00 expert 2_full
attr wz0_sta00 firmware 1.4
attr wz0_sta00 group [Homematic] Stellantriebe
attr wz0_sta00 model HM-CC-RT-DN
attr wz0_sta00 room Geräte
attr wz0_sta00 serialNr LEQ0105862
attr wz0_sta00 subType thermostat
attr wz0_sta00 webCmd getConfig:clear msgEvents:burstXmit
define wz0_sta00_Weather CUL_HM 269BFF01
attr wz0_sta00_Weather model HM-CC-RT-DN
attr wz0_sta00_Weather peerIDs 00000000,
define wz0_sta00_Climate CUL_HM 269BFF02
attr wz0_sta00_Climate model HM-CC-RT-DN
attr wz0_sta00_Climate peerIDs 00000000,26043E02,
define wz0_sta00_WindowRec CUL_HM 269BFF03
attr wz0_sta00_WindowRec model HM-CC-RT-DN
attr wz0_sta00_WindowRec peerIDs 00000000,359B0201,359B3E01,
attr wz0_sta00_WindowRec stateFormat last:trigLast
define wz0_sta00_Clima CUL_HM 269BFF04
attr wz0_sta00_Clima alias Stellantriebsetup Wohnzimmer
attr wz0_sta00_Clima group [Homematic] Stellantriebe
attr wz0_sta00_Clima model HM-CC-RT-DN
attr wz0_sta00_Clima peerIDs 00000000,
attr wz0_sta00_Clima room Stellantriebe
define wz0_sta00_ClimaTeam CUL_HM 269BFF05
attr wz0_sta00_ClimaTeam model HM-CC-RT-DN
attr wz0_sta00_ClimaTeam peerIDs 00000000,
define wz0_sta00_remote CUL_HM 269BFF06
attr wz0_sta00_remote model HM-CC-RT-DN
attr wz0_sta00_remote peerIDs 00000000,
define wz0_sta00_log FileLog ./log/wz0_sta00-%Y.log wz0_sta00
attr wz0_sta00_log logtype text
attr wz0_sta00_log room X_Logs
define wz0_kon00 CUL_HM 359B02
attr wz0_kon00 IODev wz0_cul00
attr wz0_kon00 actCycle 001:05
attr wz0_kon00 actStatus
attr wz0_kon00 alias Fensterkontakt Wohnzimmer links
attr wz0_kon00 autoReadReg 4_reqStatus
attr wz0_kon00 expert 2_full
attr wz0_kon00 firmware 1.0
attr wz0_kon00 group [Homematic] Kontakte
attr wz0_kon00 model HM-SEC-SCo
attr wz0_kon00 peerIDs 00000000,
attr wz0_kon00 room Geräte,Kontakte
attr wz0_kon00 serialNr LEQ1510020
attr wz0_kon00 subType threeStateSensor
attr wz0_kon00 userReadings batteryLevel { ReadingsVal("wz0_kon00","battery",0);; }
define wz0_kon00_log FileLog ./log/wz0_kon00-%Y-%m-%d.log wz0_kon00
attr wz0_kon00_log logtype text
attr wz0_kon00_log room X_Logs
define wz0_kon01 CUL_HM 359B3E
attr wz0_kon01 IODev wz0_cul00
attr wz0_kon01 actCycle 001:05
attr wz0_kon01 actStatus
attr wz0_kon01 alias Fensterkontakt Wohnzimmer rechts
attr wz0_kon01 autoReadReg 4_reqStatus
attr wz0_kon01 expert 2_full
attr wz0_kon01 firmware 1.0
attr wz0_kon01 group [Homematic] Kontakte
attr wz0_kon01 model HM-SEC-SCo
attr wz0_kon01 peerIDs 00000000,
attr wz0_kon01 room Geräte,Kontakte
attr wz0_kon01 serialNr LEQ1510062
attr wz0_kon01 subType threeStateSensor
attr wz0_kon01 userReadings batteryLevel { ReadingsVal("wz0_kon01","battery",0);; }
define wz0_kon01_log FileLog ./log/wz0_kon01-%Y-%m-%d.log wz0_kon01
attr wz0_kon01_log logtype text
attr wz0_kon01_log room X_Logs
Die Einträge PeerIDs mit 00000000 passen schon.
Allerdings fehlen beim Fensterkontakt die Einträge des Thermostaten.
Ein "set hm configCheck" würde dir wohl alles sagen was noch fehlt...
Vorher natürlich HMINFO definieren:
https://wiki.fhem.de/wiki/HomeMatic_HMInfo (https://wiki.fhem.de/wiki/HomeMatic_HMInfo)
Und solange das
2016-12-22 00:14:14 PairedTo 0x000000
2016-12-22 00:14:14 R-cyclicInfoMsg on
2016-12-22 00:14:14 R-pairCentral 0x000000
nicht richtig GEPAIRED ist wird es auch mit dem PEERING nichts werden.
Wenn du die Peer-Befehle absetzt (vorher mal sicherstellen, dass keine cmds mehr pending sind) auch mal beim Fensterkontakt die "Config-Taste" drücken damit die anstehenden Kommandos (z.B. Peering-Befehl) abgearbeitet werden.
Am Ende dann (wenn alle cmds pending weg sind) noch mal einen getConfig (ebenfalls ab und an mal die Config-Taste drücken).
Dann sollte es eigentlich passen.
Ist mit den "wake-up" Geräten nicht immer einfach, die brauchen einfach Zeit bis die Kommandos abgearbeitet sind.
Hektik bringt nichts...
Gruß, Joachim
Moin,
die Fensterkontakte brauchen den Parameter peerNeedsBurst für den entsprechenden Peer gesetzt, sonst wachen die RTs nicht auf, wenn sie wieder im Ruhemodus sind. Das es direkt nach em drücken der Boost-Taste geht, dürfte daran liegen, dass die RTs dann noch wach sind und auf einfache Funk-Telegramme reagieren.
Du müsstest im List des Kontakts sowas stehen haben:
R-Heizung_Whz_Flur_WindowRec-peerNeedsBurst on
habe ich aber nicht im Listing gesehen. Das müsste dir auch hminfo anzeigen, wenn du einen configCheck machst...
Gruß,
Stephan
Anbei einmal die Configcheck configCheck done:
missing register list
ba0_sta00_Clima: RegL_01.,RegL_07.
ba0_sta00_ClimaTeam: RegL_01.
ba0_sta00_Climate: RegL_01.
ba0_sta00_Weather: RegL_01.
ba0_sta00_WindowRec: RegL_01.
ba0_sta00_remote: RegL_01.
wz0_kon00: RegL_00.,RegL_01.
wz0_kon01: RegL_00.,RegL_01.
wz0_sta00_Clima: RegL_01.,RegL_07.
wz0_sta00_ClimaTeam: RegL_01.
wz0_sta00_Climate: RegL_01.
wz0_sta00_Weather: RegL_01.
wz0_sta00_WindowRec: RegL_03.wz0_kon00_chn-01,RegL_03.wz0_kon01_chn-01,RegL_01.,RegL_07.wz0_kon00_chn-01,RegL_07.wz0_kon01_chn-01
wz0_sta00_remote: RegL_01.
wz0_the00_Climate: RegL_01.,RegL_07.,RegL_08.,RegL_09.
wz0_the00_SwitchTr: RegL_01.
wz0_the00_Weather: RegL_01.
wz0_the00_WindowRec: RegL_01.
wz0_the00_remote: RegL_01.
Register changes pending
wz0_kon00
wz0_kon01
peer list incomplete. Use getConfig to read it.
incomplete: wz0_the00_WindowRec:
peer not verified. Check that peer is set on both sides
wz0_sta00_WindowRec p:wz0_kon00
wz0_sta00_WindowRec p:wz0_kon01
boost or template differ in team
wz0_the00_Climate team:wz0_sta00_Clima boost differ Value not captured:wz0_the00_Climate - boostPeriod / Value not captured:wz0_sta00_Clima - boostPeriod
PairedTo missing/unknown
ActionDetector
PairedTo mismatch to IODev
wz0_kon00 paired:0x000000 IO attr: 000001.
wz0_kon01 paired:0x000000 IO attr: 000001.
templist mismatch
ba0_sta00_Clima: file: ././tempList.cfg for ba0_sta00_Clima does not exist
wz0_sta00_Clima: file: ././tempList.cfg for wz0_sta00_Clima does not exist
wz0_the00_Climate: file: ././tempList.cfg for wz0_the00_Climate does not exist
Ich hatte heute keine Zeit mich einzulesen, was ich aus dieser Configcheck herauslesen kann, aber das mache ich noch. Für Tipps bin ich natürlich dankbar. Firmwareupdate auf das Wandthermostat habe ich auch raufgespielt, obwohl das mit Sicherheit keinen Einfluss hat.
Wie du sehen kannst ist schon noch einiges zu tun bevor das mit dem Peering sauber klappen kann:
getConfig bei:
ba0_sta00
wz0_sta00
wz0_kon00
Aber zuvor erst mal warten bis evtl. cmds_Pending weg sind.
Bei den getConfig halt entweder viel Zeit mitbringen oder ab und an mal den "Config-Taster" des jeweiligen Gerätes drücken.
Am besten immer langsam ein Gerät nach dem anderen und immer bis cmds_pending weg ist.
(ab und zu auch mal Browser refreshen, manchmal bleiben die cmds_pending auch "nur" in der Anzeige)
Ich nehme dazu meistens ein Tablet/Notebook und "setze" mich neben das Gerät und mache dann in Ruhe den getConfig...
...und dann das nächste...
Danach noch mal ein "set hm configCheck" um zu sehen was danach noch nicht passt...
Zitat
Register changes pending
wz0_kon00
wz0_kon01
Könnten auch die noch ausstehenden Peering-Kommandos sein...
...könnte also nach dem getConfig schon weg sein.
Zitat
peer list incomplete. Use getConfig to read it.
incomplete: wz0_the00_WindowRec:
peer not verified. Check that peer is set on both sides
wz0_sta00_WindowRec p:wz0_kon00
wz0_sta00_WindowRec p:wz0_kon01
Und hier steht ja explizit: getConfig...
Wenn die getConfig alle sauber durch sind, dann ist vielleicht auch "peer not verified" weg.
Das heißt, dass anhand der noch ausstehenden Kommandos bzw. fehlenden Register nicht wirklich geprüft werden kann, ob das Peering passt...
Zitat
boost or template differ in team
wz0_the00_Climate team:wz0_sta00_Clima boost differ Value not captured:wz0_the00_Climate - boostPeriod / Value not captured:wz0_sta00_Clima - boostPeriod
Da sind wohl Geräte eines Teams unterschiedlich konfiguriert, ob das stört kann ich nicht sagen, ist aber wenn eher ein kleineres Problem (oder vielleicht so gewollt)
Zitat
PairedTo mismatch to IODev
wz0_kon00 paired:0x000000 IO attr: 000001.
wz0_kon01 paired:0x000000 IO attr: 000001.
Da ist wohl noch nicht (fertig) Gepaired.
Also erst mal die getConfigs sauber durch fahren und dann noch mal "set hm configCheck" um zu sehen was dann besser ist/noch fehlt.
Bzw. mal in "R-PairCentral / PairedTo" schauen. Da muss die HMID stehen (000000 ist keine gültige HMID eines IODev).
Wenn da nicht die HMID steht muss das Pairing erst mal glatt gezogen werden!
Zitat
templist mismatch
ba0_sta00_Clima: file: ././tempList.cfg for ba0_sta00_Clima does not exist
wz0_sta00_Clima: file: ././tempList.cfg for wz0_sta00_Clima does not exist
wz0_the00_Climate: file: ././tempList.cfg for wz0_the00_Climate does not exist
Kannst du (erst mal) ignorieren, es bedeutet nur, dass noch keine Templist-Templates angelegt wurden, siehe HMINFO/Templates...
Wenn man mit den Templates nicht arbeitet, kann man die Meldung auch immer ignorieren bzw. einmal welche speichern, dann ist die Meldung weg...
Gruß, Joachim
Vielen Dank schon einmal für die ausführliche Beschreibung. Ich werde mich über Weihnachten erstmal mit einer Tasse Tee hinsetzen und die Sache abarbeiten und wenn etwas nicht klappt zum Tee mit Schuss und am Ende nur mehr zum Schuss greifen ;D
Ich glaube mein ständiger Aktionismus: klappt nicht -->neupeeren, klappt nicht -->neupairen, klappt nicht -->Firmware flash ist da ein Bisschen fehl am Platz.
Frage: Wenn ich die Sache einfach einmal eine Woche nicht angreife müsste er die Befehle ja irgendwann einmal abgearbeitet haben oder?
Zitat von: theophilou85 am 23 Dezember 2016, 09:54:19
Vielen Dank schon einmal für die ausführliche Beschreibung. Ich werde mich über Weihnachten erstmal mit einer Tasse Tee hinsetzen und die Sache abarbeiten und wenn etwas nicht klappt zum Tee mit Schuss und am Ende nur mehr zum Schuss greifen ;D
Gerne!
Solange du dann bei zu viel Schuss nur mehr die Geräte anschaust und nichts mehr drückst... ;-)
Zitat von: theophilou85 am 23 Dezember 2016, 09:54:19
Ich glaube mein ständiger Aktionismus: klappt nicht -->neupeeren, klappt nicht -->neupairen, klappt nicht -->Firmware flash ist da ein Bisschen fehl am Platz.
Frage: Wenn ich die Sache einfach einmal eine Woche nicht angreife müsste er die Befehle ja irgendwann einmal abgearbeitet haben oder?
Theoretisch: ja.
Praktisch ausprobieren...
(Bei den Fensterkontakten weiß ich nicht / ich nehme mir halt immer ein Gerät nach dem anderen vor / wenn dann alle sauber gepaired sind [R-PairCetral / PairedTo], dann mache ich mich an die Peerings)
Aber vielleicht mal ein "clear all" absetzen und dann ein getConfig anstoßen und über Weinachten mal machen lassen...
...wenn nicht jetzt wann ist dann die Zeit für Wunder ;-)
Danach noch mal configCheck und sehen was noch zu tun ist.
Die noch fehlenden Register sollten dann eigentlich gelesen sein...
Wenn das Pairing noch nicht richtig durch ist, dann wird es wohl noch was zu tun geben...
Was mir halt nicht gefällt ist der Eintrag "PairedTo / R-PairCentral 000000"!
Sieht so aus als hättest du mal die HMID 000000 gehabt???!!
Wenn das der Fall war und die/das Gerät(e) tatsächlich damit Gepaired sind, dann musst du die wahrscheinlich erst mal zurücksetzen und neu Pairen...
...mit einer HMID die nicht 000000 sein darf!!!
Gruß und (trotzdem) frohe Weihnachten, Joachim
Wieder korrekt. Ich hatte ganz am Anfang einmal die HMID 000000, hatte Probleme, schob diese auf die ID und änderte sie auf 000001. Ich werde die Geräte einfach einmal alle zurücksetzen und dann nochmal vom Start.
Probleme mit HMID 000000 wundert mich nicht.
Steht aber in der Anfänger-Doku...
Alles zurücksetzen...
...hmmm, zumindest die welche mit 000000 gepaired wurden...
Aber über Weihnachten ist ja Zeit... ;-)
Viel Spaß und Erfolg!
Frosch Fescht! Joachim
Sodala, habe jetzt alle Geräte nochmal mit FHEM gepaired, GetConfig geklickt, einen Tag gewartet.
configCheck done:
missing register list
ba0_sta00_Clima: RegL_01.,RegL_07.
ba0_sta00_ClimaTeam: RegL_01.
ba0_sta00_Climate: RegL_01.
ba0_sta00_Weather: RegL_01.
ba0_sta00_WindowRec: RegL_01.
ba0_sta00_remote: RegL_01.
ba0_the00_Climate: RegL_08.,RegL_09.
ba0_the00_SwitchTr: RegL_01.
ba0_the00_WindowRec: RegL_01.
ba0_the00_remote: RegL_01.
wz0_kon00: RegL_00.,RegL_01.
wz0_kon01: RegL_00.,RegL_01.
wz0_sta00_ClimaTeam: RegL_01.
wz0_sta00_remote: RegL_01.
wz0_the00_Climate: RegL_01.,RegL_07.,RegL_08.,RegL_09.
wz0_the00_SwitchTr: RegL_01.
wz0_the00_Weather: RegL_01.
wz0_the00_WindowRec: RegL_01.
wz0_the00_remote: RegL_01.
incomplete register list
ba0_the00_Climate: RegL_07.
wz0_sta00_Clima: RegL_07.
peer list incomplete. Use getConfig to read it.
incomplete: ba0_sta00_ClimaTeam:
incomplete: ba0_sta00_remote:
incomplete: ba0_the00_SwitchTr:
incomplete: ba0_the00_WindowRec:
incomplete: ba0_the00_remote:
incomplete: wz0_kon00:
incomplete: wz0_kon01:
incomplete: wz0_sta00_ClimaTeam:
incomplete: wz0_sta00_remote:
incomplete: wz0_the00_SwitchTr:
incomplete: wz0_the00_WindowRec:
incomplete: wz0_the00_remote:
PairedTo missing/unknown
ActionDetector
templist mismatch
ba0_sta00_Clima: file: ././tempList.cfg for ba0_sta00_Clima does not exist
ba0_the00_Climate: file: ././tempList.cfg for ba0_the00_Climate does not exist
wz0_sta00_Clima: file: ././tempList.cfg for wz0_sta00_Clima does not exist
wz0_the00_Climate: file: ././tempList.cfg for wz0_the00_Climate does not exist
Ich würde um weitere Instruktionen bitten, damit ich mir das nicht nochmal antun muss ;D
Situation: Wohnzimmer: 2 Fensterkontakte, 1 Stellantrieb, 1 Wandthermostat
Bad: 1 Stellantrieb, 1 Wandthermostat
P.S: Die Incomplete-Registerlist macht mir irgendwie Bauchweh...
Hattest du die Geräte zurückgesetzt (wenigstens die, die bereits mit der HMID 000000 gepaired waren) bevor du neu begonnen hast?
Nach dem Pairing (und getConfig) gewartet bis alle cmds_pending weg waren?
Hast du bereits mit dem Peering begonnen oder sind das noch unvollständige Peerings von früher (z.B. Geräte nicht zurückgesetzt und nicht in fhem gelöscht)?
Bei den Wandthermostaten sollten die cmds ohne Config-Taste zu drücken abgearbeitet werden...
Bei den Heizkörperthermostaten und Fensterkontakten drücke ich immer wieder mal den Config-Taster wie beim Anlernen...
...dadurch werden die Kommandos schneller abgearbeitet...
Aber wie bereits geschrieben, immer ein Gerät nach dem anderen!
Und ich mache auch erst weiter, wenn das eine Gerät vollständig gepaired ist und mache dann mit dem nächsten weiter etc.
Es wird auch immer nur ein Gerät angelernt pro PairForSecs...
Wenn dann alle mit fhem sauber gepaired sind kümmere ich mich um Einstellungen von Registern (z.B. beim Fensterkontakt AES ausschalten [mache ich so, wenn du AES verwendest, dann entsprechend anders] bzw. cyclicMessage aktivieren, steht aber im jeweiligen wiki zum Gerät / evtl. auch mal beim magnetischen Fensterkontakt schauen) und eben auch um das Peering.
Und auch da: immer ganz langsam. Ein bzw. halt 2 Kanäle nacheinander, bis die Geräte/Kanäle sauber gepeert sind (laut configCheck). also beispielsweise einen Fensterkontakt mit einem Wand/Heizkörperthermostat bis alle cmds_pending weg sind und configCheck sagt: ok. Wenn nicht, dann etwas warten und noch mal den Peeringbefehl absetzen usw. Wenn das Peering zwischen Fensterkontakt und Thermostat dann passt, geht es zu den nächsten Geräten/Kanälen. solange bis alles passt.
Und wie mehrfach geschrieben drücke ich immer wieder mal den Config Knopf bei dem (peering den) Gerät(en).
Gruß, Joachim
Sorry da habe ich mich wohl ein wenig zu undetalliert ausgedrückt.
Habe alle Geräte mit set <device> reset gelöscht, dann den kompletten Code der Device aus der FHEM.cfg. Save. Ein Gerät nach dem anderen mit hmpair gepaired, bis wieder alle drinnen waren. danach bei jedem Getconfig und 24h gewartet. Laufe jetzt nochmal die Runde und drücke bei jedem nocheinmal bevor ich schlafen gehe. Gepeered habe ich bis jetzt noch gar nichts, nur alle mit FHEM gepaired.
Deshalb wundert es mich auch so, dass ich jetzt schon eine Incomplete Registerlist habe.
Hmmm...
Weil noch "incomplete" Peerings kommen.
Wenn du noch nicht begonnen hattest zu peeren, sind das wohl "Überbleibsel" von früher...
EDIT2: oder halt evtl. configCheck Klarheit hat, wenn die fehlenden Register gelesen sind...
Du musst immer bevor du mit weiteren Kommandos (reset, getConfig, set peer, ...) anfängst erst mal sicherstellen, dass die "alten" (das letzte) Kommando abgearbeitet ist.
Ich mache ja lieber einen Reset direkt am Gerät, da kann ich sicher sein.
Nicht dass der reset noch nicht überall durch war und du schon wieder mit dem Pairen begonnen hast...
Und wie schon so oft geschrieben: LANGSAM! Immer ein Gerät nach dem anderen und warten bis das EINE Gerät sauber und vollständig in fhem OHNE cmds_pending und fehlender Register angelegt ist.
EDIT: nach dem Pairen auch schon mal per configCheck prüfen, meist kommt dann was noch fehlt, wenn... Und oft auch ein Hinweis wie das behoben werden kann (z.B. getConfig). Aber auch hier: warten bis cmds_done (bzw. kein cmds_pending)...
Erst dann das nächste Gerät usw.
Und wie ebenfalls geschrieben: bei manchen Geräten (z.B. wenn cmds_pending länger als 5min ansteht) immer wieder mal den "Config-Knopf"/"Anlernknopf" drücken warten wieder mal drücken bis eben KEIN cmds_pending bei dem Gerät mehr zu sehen ist, also bis cmds_done steht.
Mit Hektik, wildem Anlernen und Löschen und viele Geräte gleichzeitig anlernen wird das nichts werden.
Es sind batteriebetriebene Funk-Geräte.
Also sie sollen ziehmlich viel schlafen um lange zu halten (daher dauert das mit den Kommandos auch mal und ein getConfig liest u.U. ziehmlich viel aus) und zum anderen dürfen sie auch nicht sooo viel Funken (Funkregularien)...
Also: Geduld...
Ist doof ich weiß aber wenn die Geräte sauber angelernt sind, dann flutscht der Rest eigentlich...
...und Anlernen macht man ja (normalerweise) nur einmal.
Das mit der Ruhe und dem Warten gilt nat. für alle (größeren) Änderungen:
Peeren, Templisten anpassen, Register ändern, ...
Gruß, Joachim
Das mit der Funkregulierung ist mir bekannt und dass diese Geräte nur sporadisch aus ihrem Schlaf aufwachen um es abzuarbeiten auch. Aber 24h?! Ich ging schon davon aus, dass nach 24h, wenn die Geräte gerade frisch gepaired worden und ich 1,2 vl. 3 Mal in meiner Hektik getConfig geklickt habe, alles abgearbeitet ist. Wenn ich heute heimkomme hatten sie weitere 20h, hoffe das reicht dann. Mal sehen ob die CMD's dann alle "done" sind. Vorher beginne ich auf jeden Fall nicht mit dem peering.
Kann ich diese "Überbleibsel"/alten Peers eigentlich irgendwie manuell löschen?
guten morgen,
nach dem ich gestern 2 Stunden versucht hatte meine Fensterkontakte mit meinen HM-CC-RT-DN zu peeren und es nicht funktioniert hat.
Hatte ich es für gestern aufgegeben :D
Heute morgen habe ich mich nochmal daran gemacht und folgende Anleitung gefunden
http://www.meintechblog.de/2014/10/smarthome-fenstergesteuerte-heizungsregelung/ (http://www.meintechblog.de/2014/10/smarthome-fenstergesteuerte-heizungsregelung/)
Diese Anleitung habe ich abgearbeitet und nach 5 Min. erfolgreich drei Fensterkontakte gepeert.
Jetzt bei Fenster auf Temp auf 12° C runter,Fenster zu Temp 20°, wird sofort am HM-CC-RT-DN angezeigt.
Gruß Werner
Ja, ist so wie immer geschrieben hab: den Config-Knopf/Anlernknopf drücken...
Allerdings trotzdem erst mit dem Peering beginnen, wenn das Pairing (Anlernen Zentrale) vollständig abgeschlossen ist...
Aber dort ist es sehr detailliert beschrieben, nur die Fenterkontakte sind andere, das mit der Büroklammer ist hier unnötig...
Gruß, Joachim
Ich habe mich gestern Abend noch einmal an die Sache rangesetzt, aber ich glaube bei mir liegt der Hund irgendwo anders begraben.
Gestern Abend waren die CMD's irgendwann endlich einmal "done", aber der Configcheck zeigte das gleiche Bild wie bereits gepostet. Daraufhin habe ich an einen Stellantrieb ein getConfig geschickt und dort die Configtaste für 4s gedrückt. Der meldete sich mit einem ResponseTimeOut nach wenigen Sekunden.
Das gleiche habe ich mit einem der Stellantriebe versucht, der auch auf CMD's done stand. Bei dem kam CMD's pending, processing, pending und der verblieb dort mind. 15min. Habe nach ca. 5min abermals die Configtaste für 4s gedrückt, keine Änderung.
Aus irgend einem Grund bekomme ich nicht einmal alle Register korrekt ausgelesen, geschweige den, könnte ich mit dem Peering beginnen.
Die ganze Sache ist ja vom logischen Aufbau nicht schwer zu kapieren und die Geduld habe ich mittlerweile.
Ich habe mir jetzt einmal die HMInfo im wiki durchgelesen, da fiel mir auf: "set dev01Ch01 getConfig". Ist es notwendig die Config channelweise und nicht geräteweise abzuarbeiten?
Des weiteren bin ich über das "Expert" Attribut gestolpert. Sollte ich dieses vielleicht einmal auf einen anderen Wert setzen?
Kanalweise macht die zu übertragenden Pakete kleiner...
Kann helfen...
Aber evtl. brauchst du dann doch die Spezial-FW, wenn du immer noch Timeout RegisterRead bekommst...
War beu mir auch so als ich den Klingelsensor verwenden wollte...
Zuvor war alles ok mit dem CUL...
Gänzlich Abhilfe schafft wohl bei Homematic nur die Verwendung eines echten HM IODev...
Expert ist nur die Anzeige wieviel Information/Register du sehen willst.
Das attr autoreadreg sagt wann und wie Register gelesen werden sollen...
Aber das wirkt erst, wenn der getConfig (Gerät bzw. alle Kanäle) abgeschlossen ist...
Also wirken nur bildlich, weil nat ein "gar nicht lesen" natürlich das Auslesen unterbindet dich aber nicht weiter bringt, da ja erst mal alles gelesen sein muss...
Eventuell hilft Geduld und Auslesen der einzelnen Kanäle nacheinander...
Wenn nicht, dann wohl nur "Spezial-FW" oder "echtes" HM IODev...
Viel Erfolg, Joachim
Um welche Spezial-FW geht es da? Ich habe das Problem dass ich auch Intertechno im Einsatz habe und der SlowRF-Mode funktioniert dort super. Auf den möchte ich mit dieser SpezialFW nicht verzichten.
Bzgl der Commands: Die Wandthermostate melden CMD's done mit 1 Error. Ich weiß nicht ob mit diesem Error der RESPONSE TIMEOUT:RegisterRead gemeint ist, oder irgend ein anderer Error. Kann man diesen Error irgendwie auslesen?
Die Stellantriebe arbeiten ihre Commands bis auf 4 CMD's ab und kommen dann mit einem: motorErr: communicationERR // state: MISSING ACK.
Mir fällt ein, dass ich als ich die Geräte gepaired habe und ein "rename" gemacht habe, die Kanäle nicht umbenannt wurden. Das habe ich dann manuell in der fhem.cfg gemacht --> save.
Kann es womöglich damit zusammenhängen?
Hi,
die Spezial-FW und Module in diesem Thread:
https://forum.fhem.de/index.php/topic,24436.msg175466.html (https://forum.fhem.de/index.php/topic,24436.msg175466.html)
Hast du nur einen CUL für slowrf und HM?
(Geht das? Ich weiß dass man zu "irgendwas" umschalten kann und so quasi "Parallelbetrieb" fahren kann)
Das ist eh ganz schlecht!
Wenn der CUL slowrf (oder etwas anderes) sendet (empfängt) dann ist er ja für HM "gesperrt" d.h. es gehen Telegramme verloren!
Immer mind. ein IODev pro Protokoll(familie)!
Fehler stehen entweder im Log oder meist auch im STATE/state eventuell auch über hminfo protostate (oder so ähnlich).
Rename sollte (wenn richtig gemacht) keinen Einfluss haben die Zuordnung geht über die IDs.
Es gibt (bei HM) auch ein set-commando beim Gerät/Device für rename, da werden die Kanäle und Logfiles umbenannt...
Gruß, Joachim
Ich nutze meinen 868er CUL für beides und das mit dem SlowRF funktioniert wirklich gut, da ich ja nur sende und nicht empfange.
Jetzt aber einmal eine andere Frage: Ich habe meinen CUL kürzlich auf die 1.67iger geflashed, um ein AC Protokoll, als IT String abzusenden. Muss ich bei einem Firmwareupdate des CUL's auch irgendwas im FHEM machen? da gibt es ja gewisse CULxxx.pm Dateien. Vielleicht ist dort der Hund begraben. Langsam glaube ich nämlich nicht mehr an Problem des Peerings/Pairings.
Normalerweise nur ganz normal per update auf den neuesten Stand bringen/halten.
Aber nochmal: es sieht so aus als würde Parallelbetrieb funktionieren aber während du sendest gehen evtl. Telegramme von HM verloren.
Ein Parallelbetrieb ist nicht ratsam (gibt es tausend Threads zu dem Thema)...
Und wie ebenfalls mehrfach gesagt/geschrieben: bei mir (und auch bei anderen wenn du den verlinkten Thread mal überfliegst [gerade gegen "Ende"]) war alles gut dachte ich, bis ich mit dem Klingelsensor losgelegt habe.
Erst ein Umstieg auf die genannte FW brachte Abhilfe.
Noch besser ist die Verwendung eines "echten" HM-IODev...
Gruß, Joachim
Ich habe mir den Thread jetzt einmal durchgelesen.
Du meinst all meine Peeringprobleme können mit dem felenden Timestamp zusammenhängen? Das MissingACK kann ich mir dadurch schon erklären.
Ich müsste also die Firmware des Threads flashen, den CUL neu als TSCUL anlegen und die IODevices-Attribute bei allen Sensoren/Aktoren ändern. Wie das mit den *.pm abläuft hab ich noch nicht ganz überlauert, aber ich lese mir das Sonntag oder Montag nochmal in Ruhe durch. Einen guten Rutsch darf ich wünschen und danke für dein Engagement.
Zitat von: theophilou85 am 31 Dezember 2016, 02:01:57
Ich habe mir den Thread jetzt einmal durchgelesen.
Du meinst all meine Peeringprobleme können mit dem felenden Timestamp zusammenhängen? Das MissingACK kann ich mir dadurch schon erklären.
War zumindest bei mir (und vielen anderen) so.
Aber trotzdem nochmal der Hinweis: Parallelbetrieb ist nicht gut!!!
Zitat von: theophilou85 am 31 Dezember 2016, 02:01:57
Ich müsste also die Firmware des Threads flashen, den CUL neu als TSCUL anlegen und die IODevices-Attribute bei allen Sensoren/Aktoren ändern.
Ja, aber halt die passende für deine HW!
Ja, einfach aus dem CUL ein TSCUL in der Config machen.
NEIN: an den IODevices-Attributen musst du nichts ändern, da sollte ja der Name des IODev stehen und der bleibt ja!
also aus:
define meinCUL CUL /dev/...
wird:
define meinCUL TSCUL /dev/...
und bei den Geräten steht ja (also bei mir):
attr HM_GERÄT IODev meinCUL
Zitat von: theophilou85 am 31 Dezember 2016, 02:01:57
Wie das mit den *.pm abläuft hab ich noch nicht ganz überlauert, aber ich lese mir das Sonntag oder Montag nochmal in Ruhe durch.
Einfach die *.pm Dateien (zumindest die relevanten, dazu musst du wissen was du nutzt und welche Datei für was ist / daher einfacher: alle) nach /opt/fhem/FHEM/ kopieren (vors. deine Installation von fhem ist unter /opt/fhem/).
Nicht vergessen den "exclude from update" Eintrag zu machen, sonst werden die *.pm Dateien aus dem ZIP wieder überschrieben!!
Das ist der (noch) nicht schöne Teil an der Geschichte...
...da einiges vom Update "ausgeschlossen" wird und (falls es etwas neues gibt) von Hand neu eingespielt werden muss...
Ansgar ist da dran aber bislang leider ohne Erfolg...
Daher bleibt das (selbstbau)CUL für HM nur auf meinem Testsystem.
Auf meinem "echten" System kommen mir nur "echte" HM-IODevs zum Einsatz!
Zitat von: theophilou85 am 31 Dezember 2016, 02:01:57
Einen guten Rutsch darf ich wünschen und danke für dein Engagement.
Danke!
Gerne!
Ebenso!
Und viel Erfolg!
Und weiter geht's im neuen Jahr. Da im alten in meinem Kellerabteil eingebrochen wurde (und diese verrückten meine alten Sommerreifen+Felgen geklaut haben, Wert: 20€, bin aber versichert) benötige ich jetzt für das Kellerabteil einen weiteren Fensterkontakt. Bevor ich mich ans CUL-update mache noch ein paar Fragen:
2 optische Fensterkontakte, 1 Stellantrieb, 1 Wandthermostat: Fensterkontakt mit Wandthermostat richtig?
Ist es eigentlich korrekt dass die Fensterkontakte, wenn Sie beide mit einem Wandthermostat gepeert werden, sich gegenseitig zweimal in der Peerlist haben? kon00: 00000000,359B3E00,359B3E01; kon01: 00000000,359B0200,359B0201. Einem Kontakt kann doch egal sein, was das andere macht. Ich habe auch nie ein peer zwischen den beiden "befohlen".
Zitat von: theophilou85 am 01 Januar 2017, 12:52:58
Und weiter geht's im neuen Jahr. Da im alten in meinem Kellerabteil eingebrochen wurde (und diese verrückten meine alten Sommerreifen+Felgen geklaut haben, Wert: 20€, bin aber versichert) benötige ich jetzt für das Kellerabteil einen weiteren Fensterkontakt.
Wie weit ist denn der Keller weg?
Nicht dass dann neben den Timing-Problemen auch noch Probleme mit der Entfernung (schlechte Funkverbindung) dazukommen...
Zitat von: theophilou85 am 01 Januar 2017, 12:52:58
Bevor ich mich ans CUL-update mache noch ein paar Fragen:
2 optische Fensterkontakte, 1 Stellantrieb, 1 Wandthermostat: Fensterkontakt mit Wandthermostat richtig?
Ist es eigentlich korrekt dass die Fensterkontakte, wenn Sie beide mit einem Wandthermostat gepeert werden, sich gegenseitig zweimal in der Peerlist haben? kon00: 00000000,359B3E00,359B3E01; kon01: 00000000,359B0200,359B0201. Einem Kontakt kann doch egal sein, was das andere macht. Ich habe auch nie ein peer zwischen den beiden "befohlen".
Da ich jetzt die IDs deiner einzelnen Geräte nicht kenne (vielleicht mal ein list von allen beteiligten Geräten posten), kann ich nicht sagen, ob das so stimmt.
Allerdings sollte in den Peer-Lists (neben der 00000000) halt immer der jeweilige Kanal des Gerätes stehen, mit dem gepeert ist.
Vielleicht ist es passiert, weil du "gleichzeitig" (oder ausreichend schnell hintereinander) beide Fensterkontakte in "peering/pairing" Modus versetzt hast.
Die Geräte/Kanäle lassen sich ja auch ohne "Befehle" von fhem (Zentrale) peeren, sofern sie noch nicht an eine Zentrale angelernt sind: dann durch entsprechendes Drücken von den Anlern/Config-Knöpfen...
Wenn ich Wandthermostat und Heizkörperthermostat (nur mal zur Sicherheit: es sind schon die "normalen" Homematic, nicht die mit IP im Namen!? Zumindest laut den Auszügen die hier gepostet wurden scheint es so zu sein) und Fensterkontakt einsetze, dann mache ich folgendes (nach erfolgreichem PAIREN von ALLEN Geräten):
Peering von Wandthermostat_Weather mit Heizkörperthermostat_Weather und Wandthermostat_Climate und Heizkörperthermostat_Climate
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_01_Weather (https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_01_Weather)
Dadurch steuert der Wandthermostat den Heizkörperthermostaten, d.h. er gibt die Soll- und die Ist-Temperatur vor.
Der Heizkörperthermostat übernimmt dann die Regelung...
Den Fensterkontakt peere ich daher auch mit dem Wandthermostaten:
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_03_WindowRec (https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_03_WindowRec)
D.h. beim Wandthermostat_Climate steht unter Peerlist der Heizkörperthermostat_Climate und andersrum.
Genauso bei Weather.
Bei WindowRec steht dann der Fensterkontakt und beim Fensterkontakt (hat nur einen Kanal bzw. nur "sich selbst") steht dann der Wandthermostat_WindowRec drin...
...und andersrum.
Alles andere ist nicht richtig/unnötig!
(Also abgesehen von 00000000)
Wenn die Peers so (falsch) in den Geräten (Registern) stehen, dann wirst du wohl über ein Zurücksetzen nicht rumkommen...
Aber vielleicht ist es ein guter Anfang im neuen Jahr:
Alle Geräte in fhem löschen, die Geräte "hart" zurücksetzen (also mittels Rücksetzprozedur laut Anleitung) und dann noch mal langsam von vorne.
Also wirklich ein Gerät nach dem anderen VOLLSTÄNDIG PAIREN (bis hminfo zufrieden ist und keine cmds_pending und keine MissingAcks etc und bei R-PairCentral /PairedTo die HMID steht und diese darf NICHT 000000 sein!).
Nachdem alle sauber gepaired sind halt ums PEERING kümmern.
Sowohl beim PAIREN also auch beim PEEREN zumindest bei den Heizkörperthermostaten und Fensterkontakten unter Zuhilfenahme des Anlern/Config-Knopfs.
Also pairForSecs absetzen, Anlernknopf wie laut Anleitung Beschrieben.
Dann sollten cmds_pending sein (oder processing).
Beim Wandthermostaten kommt meist sofort processing bei den anderen beiden Heizkörperthermostat/Fensterkontakt bleibt meist cmds_pending.
Dann erneut den Anlern-/Configtaster drücken (beim Fensterkontakt kurz und beim Heizkörperthermostat lang, bis die 30 runterzählen anfängt, ist manchmal auch ganz schnell wieder weg, dann sollte cmds_processing erscheinen / drum mach ich das immer mit Laptop neben dem Gerät).
Wie schon vielfach gesagt: immer langsam, ein Gerät nach dem anderen und immer wieder pro Gerät-Pairing-Vorgang das pairForSecs setzen (es geht nur einmal pro set, egal wie lange du die Zeit einstellst).
EDIT: und ab und an (wenn das Fragezeichen kommt) die config speichern...
Viel Erfolg im neuen Jahr!
Gruß, Joachim
Es sind keine HM IP Geräte, sondern normale. Bisher habe ich immer zuerst Gepaired und dann über FHEM gepeert. Das klappte bei Wandthermostat und Stellantrieb auch problemlos, für Weather und Climate. Nur die Fensterkontakte liesen sich bisher nicht durch den FHEM-Befehl peeren.
Ich habe das Problem jetzt anders gelöst, vl hilft es wem:
Fhem runtergefahren, stromlos.
Hardreset auf allen Devices (Kontakt 1,2 Wandthermostat, Funkstellantrieb)
Ohne Fhem: Stellantrieb mit Wandthermostat gepeert - Beide Fensterkontakte mit Wandthermostat - Beide Fensterkontakte mit Stellantrieb. Getestet.
Interessanterweise wurde das Fenstersymbol dann bei Stellantrieb und Wandthermostat korrekt angezeigt und der Stellantrieb hat auch heruntergeregelt, aber bei verschwinden des Fenstersymbols nicht mehr hinauf und blieb bei 12°C. Habe daraufhin manuell auf 24°C gestellt und seit dem hat er korrekt hochgestellt, als ob man eine "Hochstelltemperatur" vorgeben müsste. Als er bei Kontakt 1 dann korrekt zwischen 12 und 24 rauf und runtersprang, hatte ich beim zweiten auch noch das Problem, dass er korrekt auf 12 runter aber nicht mehr hochregelgt. Hier also auch einmal die 24 eingestellt und dann klappte das auch. Inzwischen ist die Vorgabe vom Wandthermostat 20 und er springt korrekt zwischen 12 und 20 . Für dieses Phänomen habe ich gar keine Erklärung.
Dann FHEM wieder gebootet und Stellantrieb und Wandthermostat gepaired. Die Fensterkontakte musste ich interessanterweise danach gar nicht mit FHEM pairen, als ob das Wandthermostat oder der Stellantrieb das "miterledigt" hätten. Phänomen oder normal?
Was ich aus der Sache mitgenommen habe:
- IODev besser ein echtes HM Gerät (deine Worte)
- hat man keines: am besten alles was außerhalb von FHEM gepeert werden kann, auch machen, weil dann FHEM+IODev als Fehlerquelle nicht involviert sein können
- Zeit lassen (deine Worte)
- StepByStep (deine Worte)
- alles nah zusammenstellen, damit man Funkprobleme ausschließen kann --> (Alle Device nahe zum Stellantrieb)
- bei mir laufen die Geräte mit Eneloopakkus, würde beim Einrichten aber frische Batterien nehmen
Ich lasse jetzt einmal alles ruhen und abarbeiten.
Was noch an "Unschönheit" übergeblieben ist: Öffne ich das Fenster leuchtet der Fensterkontakt erst Orange und blinkt dann am Ende rot. Korrekt ist, glaube ich: Orange dann grün und beim Schließen das gleiche. Irgend eine Idee woran das liegt?
Das Kellerabteil erreiche ich bei weitem nicht. Nach der Wohnungstüre habe ich vl 5m, dann ist Schluss. Diese Position hat Luftlinie zum CUL max 10m.
Gibt es irgendwelche Kontakte (devolo Wifi oder was ganz anderes) die eine extrem hohe Reichweite haben? Wifi mit dem Handy bekomme ich mit ach und krach rein.
Wenn das alles funktioniert, spiele ich einmal die anders CUL-Firmware drauf, befürchte aber, dass ich damit die AC-Telegramme ("Intertechno") zu meiner Lampe nicht mehr hinausbekomme. Das klappte erst mit der 1.67iger vom König und mit den Versionen davor nicht.
Na dann erst mal: Gratulation!
Hier noch ein paar Erläuterungen:
jep, wie bereits geschrieben und in der Doku: die Sensoren/Aktoren lassen sich auch direkt peeren. Allerdings (soweit ich weiß und meist auch laut Doku) nur, wenn sie noch nicht mit einer Zentrale verbunden (gepaired) sind...
Dadurch spart man sich die Peering-Aufrufe und da sich das ja auch ohne fhem (Zentrale) verwenden lässt muss es ja auch so gehen...
Hmmm, eigentlich hättest du die Fensterkontakte mit dem Stellantrieb gar nicht mehr verbinden müssen, da das ja bereits durch den Wandthermostaten erledigt sein sollte.
Durch das Verbinden von Wandthermostat und Stellantrieb werden die Tempvorgaben ja vom Wandthermostaten vorgegeben...
Evtl. ist jetzt dadurch der Stellantrieb auf "burst umgeschaltet" worden.
Kann zu (etwas) höherem Batterieverbrauch führen.
Ich habe es bei einigen Stellantrieben auch gemacht (andere Gründe) und bislang noch keine gravierenden Unterschiede bzgl. Batterieverbrauch bemerkt (im Vergleich zu welchen ohne burst-Aktivierung / allerdings laufen die alle erst ein knappes Jahr).
Zitat von: theophilou85 am 01 Januar 2017, 17:26:11
Interessanterweise wurde das Fenstersymbol dann bei Stellantrieb und Wandthermostat korrekt angezeigt und der Stellantrieb hat auch heruntergeregelt, aber bei verschwinden des Fenstersymbols nicht mehr hinauf und blieb bei 12°C. Habe daraufhin manuell auf 24°C gestellt und seit dem hat er korrekt hochgestellt, als ob man eine "Hochstelltemperatur" vorgeben müsste. Als er bei Kontakt 1 dann korrekt zwischen 12 und 24 rauf und runtersprang, hatte ich beim zweiten auch noch das Problem, dass er korrekt auf 12 runter aber nicht mehr hochregelgt. Hier also auch einmal die 24 eingestellt und dann klappte das auch. Inzwischen ist die Vorgabe vom Wandthermostat 20 und er springt korrekt zwischen 12 und 20 . Für dieses Phänomen habe ich gar keine Erklärung.
Dafür habe ich auch keine Erklärung. Sollte eigentlich nicht so sein.
Bzw.: der Heizkörperthermostat ist kein "Burst-Device", d.h. er schläft richtig tief und wacht nur zu bestimmten Zeiten auf (ca. alle 3min). Nur dann nimmt er neue Werte/Kommandos etc. an (daher dauert ein Pairing/Peering etc. hier auch "länger" bzw. ist nicht so einfach).
Der Wandthermostat sollte eigentlich sofort das Fenstersymbol haben und auch die Temp wieder hochregeln und dann beim Aufwachen an den Heizkörperthermostaten weitergeben...
Zitat von: theophilou85 am 01 Januar 2017, 17:26:11
Dann FHEM wieder gebootet und Stellantrieb und Wandthermostat gepaired. Die Fensterkontakte musste ich interessanterweise danach gar nicht mit FHEM pairen, als ob das Wandthermostat oder der Stellantrieb das "miterledigt" hätten. Phänomen oder normal?
...
Was noch an "Unschönheit" übergeblieben ist: Öffne ich das Fenster leuchtet der Fensterkontakt erst Orange und blinkt dann am Ende rot. Korrekt ist, glaube ich: Orange dann grün und beim Schließen das gleiche. Irgend eine Idee woran das liegt?
Das mit automatisch übernommen etc. sieht nur so aus, daher evtl. auch die Leuchtorgie des Fensterkontaktes.
fhem empfängt die Funksignale/Meldungen des Fensterkontaktes und legt diesen auch an (autocreate aktiv) und bekommt auch die Aktivitäten (auf/zu) mit und trägt sie entsprechend beim angelegten Gerät ein.
Allerdings ist der Fensterkontakt nicht gepaired und bekommt kein ACK bzw. versteht das ACK von fhem evtl. nicht (weil er ja keines erwartet).
Allerdings denke ich eher es hat mit AES zu tun.
Der Fensterkontakt ist ein "sicherheitsrelevantes" Gerät, da für Alarmanlagen verwendbar und daher automatisch mit Signatur/AES ausgeliefert.
Die Wand/Heizkörperthermostate haben das nicht aktiviert.
Fensterkontakt erwartet nun ein AES-signiertes ACK was aber nicht kommt: rot.
Schau mal hier:
https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt (https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt)
und hier:
https://wiki.fhem.de/wiki/HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch (https://wiki.fhem.de/wiki/HM-Sec-SCo_T%C3%BCr-Fensterkontakt,_optisch)
Der magnetische ist etwas ausführlicher beschrieben, im Prinzip (aus fhem) sind sie aber gleich...
AES macht eigentlich bei einem Sensor keinen (großen) Sinn, da man da ja keine Aktion auslösen kann...
...was anderes wäre es bei einem Aktor, da macht es durchaus Sinn AES zu aktivieren, da sonst der Nachbar oder jemand anders eingreifen und verstellen kann.
Er braucht dazu nur die HMID wissen...
Denn die Funksignale kannst du nicht verhindern die jemand anders rausschickt und wenn die Geräte darauf "hören" weil sie glauben sie kommen von "ihrer" Zentrale (HMID) dann machen die auch brav was "gesagt" wird... ;-)
Zitat von: theophilou85 am 01 Januar 2017, 17:26:11
Das Kellerabteil erreiche ich bei weitem nicht. Nach der Wohnungstüre habe ich vl 5m, dann ist Schluss. Diese Position hat Luftlinie zum CUL max 10m.
Gibt es irgendwelche Kontakte (devolo Wifi oder was ganz anderes) die eine extrem hohe Reichweite haben? Wifi mit dem Handy bekomme ich mit ach und krach rein.
Wenn dort Strom vorhanden ist, kannst du mal bzgl. ESP8266 im Forum oder Internet kucken.
Das ist ein WLAN-Käfer a la Arduino, damit kann man alles mögliche machen.
Ich habe einen für die Füllstandsmessung meines Wassertanks auf dem Balkon.
Allerdings ist der Käfer nichts für Batteriebetrieb.
Es wurde viel versucht (ich selbst auch) aber so richtig weit gekommen ist noch keiner (soweit ich weiß).
Da ich Strom auf dem Balkon habe ist das kein Problem...
Gruß und weiterhin viel Erfolg! Joachim
Danke für die ausführliche Erklärung. Einige Fragen hätte ich dazu noch:
ZitatDurch das Verbinden von Wandthermostat und Stellantrieb werden die Tempvorgaben ja vom Wandthermostaten vorgegeben...
Evtl. ist jetzt dadurch der Stellantrieb auf "burst umgeschaltet" worden.
Wie soll denn die Fensterauferkennung ohne Burst funktionieren. Wäre ja total unbrauchbar, wenn ich 5 Minuten Stoßlüfte und das Ding erst nach 3 Minuten die Temperatur runterregelt.
ZitatAllerdings ist der Fensterkontakt nicht gepaired und bekommt kein ACK bzw. versteht das ACK von fhem evtl. nicht (weil er ja keines erwartet).
Das scheint definitiv so zu sein. Ich habe den Code der Fensterkontakte im FHEM dringelassen und die States (offen/zu) wurden richtig übergeben, obwohl ich noch nicht gepaired habe. Allerdings (wobei ich es heute nochmal versuche) liesen sich die Fensterkontakte nach dem peering nicht mehr mit dem CUL/FHEM pairen. Das erscheint mir ein wenig unlogisch. Welche/r Kanal/äle auch immer fürs peering benutzt worden sind, können doch keinen Einfluss auf den Kanal für das Pairing mit einer Zentrale haben, oder?
Wikiquote:
ZitatMindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch den Abschnitt über AES-Encryption zwischen IO-Device und Gerät.
Wäre vermutlich nicht schlecht, wenn ich das installiere?!
Kann ich irgendwo überprüfen ob AES bei den Geräten aktiviert ist und bei Bedarf rausnehmen? Mein Nachbar kann ruhig wissen, wann bei mir ein Fenster offen ist, er hört mich sowieso fluchen, wenn es offen ist.
Strom im Keller ist problematisch, deshalb bräuchte ich irgend ein Wifi Device. Dachte schon an einen Mod. des Dashbutton, aber die ARP-Telegramme sind nicht besonders zuverlässig und es wäre selbst für ein Kellerabteil, keine "schöne" Lösung.
ZitatWie soll denn die Fensterauferkennung ohne Burst funktionieren. Wäre ja total unbrauchbar, wenn ich 5 Minuten Stoßlüfte und das Ding erst nach 3 Minuten die Temperatur runterregelt.
Bei nur Peering mit dem Wandthermostaten ist das definitiv so.
Fenster-auf geht an den Wandthermostaten (burst device), dieser erkennt das sofort und gibt dann bei der nächsten Kommunikation zum Heizkörperthermostaten die Fenster-auf-Temp als desired-temp vor...
Ist bei mir so und kein Problem, auch Stoßlüften nicht.
Vorteil (gegenüber dem Nachteil ;-) ): es wird die Temp auch verzögert wieder hoch gedreht, somit hat sich der Raum wieder etwas "erholt" nach dem Öffnen und der Heizkörper dreht nicht sofort (unnötigerweise) auf.
Bei direktem Peering auch mit dem Heizkörperthermostat wird bei diesem (denke ich) burst aktiviert, sonst würde er nicht sofort reagieren...
ZitatDas scheint definitiv so zu sein. Ich habe den Code der Fensterkontakte im FHEM dringelassen und die States (offen/zu) wurden richtig übergeben, obwohl ich noch nicht gepaired habe. Allerdings (wobei ich es heute nochmal versuche) liesen sich die Fensterkontakte nach dem peering nicht mehr mit dem CUL/FHEM pairen. Das erscheint mir ein wenig unlogisch. Welche/r Kanal/äle auch immer fürs peering benutzt worden sind, können doch keinen Einfluss auf den Kanal für das Pairing mit einer Zentrale haben, oder?
Bei Sensoren geht es wohl auch ohne Pairing, allerdings lassen sich dann keine Register (Einstellungen) verändern!
Der Status wird natürlich nachverfolgt, die Telegramme werden ja unweigerlich empfangen...
...und ausgewertet.
Bei einem Aktor geht ohne Pairing auch nur die Statusverfolgung, ein Steuern ist nicht möglich!
ZitatWäre vermutlich nicht schlecht, wenn ich das installiere?!
Kann ich irgendwo überprüfen ob AES bei den Geräten aktiviert ist und bei Bedarf rausnehmen? Mein Nachbar kann ruhig wissen, wann bei mir ein Fenster offen ist, er hört mich sowieso fluchen, wenn es offen ist.
Wenn es fehlen würde, sollte eine Meldung im Log zu finden sein.
Zu sehen ist es an den entsprechenden Registern bei den Geräten, z.B. beim Fensterkontakt:
R-sign off/on
https://wiki.fhem.de/wiki/AES_Encryption (https://wiki.fhem.de/wiki/AES_Encryption)
ZitatStrom im Keller ist problematisch, deshalb bräuchte ich irgend ein Wifi Device. Dachte schon an einen Mod. des Dashbutton, aber die ARP-Telegramme sind nicht besonders zuverlässig und es wäre selbst für ein Kellerabteil, keine "schöne" Lösung.
Was wie gesagt ginge: ESP8266 selbst einen "Fensterkontakt" basteln und per WLAN (onboard beim ESP) in fhem integrieren (z.B. per HTTP-GET ein setreading auszulösen: http://<IP-von-fhem>:8083/fhem?cmd=setreading%20DUMMY_NAME%20READING_NAME%20VALUE und in fhem einen entsprechenden dummy DUMMY_NAME anlegen)
Oder: ESP8266 und HMUART-Modul (lässt sich im Forum finden) und damit sozusagen einen WLAN-HM-IODev zu haben. Der kommuniziert dann mit einem normalen HM-Fensterkontakt im Keller per HM-UART-Modul und ist dann per WLAN als weiteres HM-IODev in fhem eingebunden. Dazu bietet sich die Nutzung einer vccu an.
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)
Gruß, Joachim
Hallo Joachim
Hier mal ein wenig weiter:
Internals:
DEF 359B02
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 105
NAME wz0_kon00
NOTIFYDEV global
NR 160
STATE closed
TYPE CUL_HM
lastMsg No:7D - t:10 s:359B02 d:000001 06010000
protCmdPend 4 CMDs pending
protLastRcv 2017-01-06 00:51:57
protSnd 12 last_at:2017-01-06 00:51:57
protState CMDs_pending
rssi_at_wz0_cul00 min:-72 max:-58 lst:-58 cnt:105 avg:-61.05
wz0_cul00_MSGCNT 105
wz0_cul00_RAWMSG A0D7DA610359B0200000106010000::-58:wz0_cul00
wz0_cul00_RSSI -58
wz0_cul00_TIME 2017-01-06 00:51:57
Readings:
2017-01-05 01:06:53 CommandAccepted yes
2017-01-05 01:06:51 D-firmware 1.0
2017-01-05 01:06:51 D-serialNr LEQ1510020
2017-01-05 00:51:02 PairedTo 0x000001
2016-12-30 02:32:04 R-cyclicInfoMsg on
2016-12-30 02:32:05 R-eventDlyTime 0 s
2017-01-05 01:06:51 R-pairCentral set_0x000001
2016-12-30 02:32:04 R-sabotageMsg on
2016-12-30 02:32:05 R-sign on
2016-12-30 03:07:35 R-wz0_kon01-expectAES on
2016-12-30 03:07:35 R-wz0_kon01-peerNeedsBurst off
2017-01-01 12:35:29 R-wz0_kon01_chn-01-expectAES on
2017-01-01 12:35:29 R-wz0_kon01_chn-01-peerNeedsBurst off
2017-01-05 19:48:12 R-wz0_sta00_WindowRec-expectAES set_off
2017-01-05 19:48:12 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2017-01-05 00:50:38 R-wz0_the00_WindowRec-expectAES set_off
2017-01-05 00:50:38 R-wz0_the00_WindowRec-peerNeedsBurst set_on
2017-01-05 01:06:53 aesKeyNbr 00
2017-01-06 00:51:57 alive yes
2017-01-06 00:51:57 battery ok
2017-01-06 00:51:57 contact closed (to ActionDetector)
2017-01-05 01:01:54 powerOn 2017-01-05 01:01:54
2017-01-06 00:51:57 recentStateType info
2017-01-06 00:51:57 sabotageError off
2017-01-06 00:51:57 state closed
2017-01-05 19:49:03 trigDst_ActionDetector noConfig
2017-01-05 19:49:17 trigDst_wz0_kon01 noConfig
2017-01-05 19:49:03 trigDst_wz0_sta00 noConfig
2017-01-05 19:49:03 trigDst_wz0_the00 noConfig
2017-01-05 19:49:17 trigger_cnt 15
cmdStack:
++A001000001359B020101269BFF0300
++A001000001359B020105269BFF0304
++A001000001359B0201080101
++A001000001359B020106
Helper:
HM_CMDNR 125
mId 00C7
rxType 28
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 1
tpl 0
Io:
dwoCAA 116
lRcTm 93427304
lstRecType 10
lstSnd 1483660317.08425
lstSndTgd 120
newChn +359B02,02,00,00
nextSend 1483660317.08425
nxtSndMcnt 7D
prefIO
rxt 2
tgtDly 120
vccu
p:
359B02
00
00
00
Mrssi:
mNo 7D
Io:
wz0_cul00 -56
Prt:
bErr 0
sProc 2
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rpt:
IO wz0_cul00
flg A
ts 1483660317.01192
ack:
HASH(0x3db2dec)
7D8002000001359B0200
Rssi:
At_wz0_cul00:
avg -61.052380952381
cnt 105
lst -58
max -58
min -72
Shadowreg:
Tmpl:
Attributes:
IODev wz0_cul00
actCycle 002:50
actStatus
alias Fensterkontakt Wohnzimmer links
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group [Homematic] Kontakte
model HM-SEC-SCo
peerIDs
room X_Geräte,Kontakte
serialNr LEQ1510020
subType threeStateSensor
Fensterkontakt sieht jetzt weit besser aus, dank neuer FW und schaltet auch alles soweit richtig. Aber das Blinkkonzert ist mittlerweile auf "öffnen" -->Dauerorange fast 30s, dann kurz rot.
PeerID's immer noch leer, aber:
2016-12-30 03:07:35 R-wz0_kon01-expectAES on
2016-12-30 03:07:35 R-wz0_kon01-peerNeedsBurst off
2017-01-01 12:35:29 R-wz0_kon01_chn-01-expectAES on
2017-01-01 12:35:29 R-wz0_kon01_chn-01-peerNeedsBurst off
2017-01-05 19:48:12 R-wz0_sta00_WindowRec-expectAES set_off
2017-01-05 19:48:12 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2017-01-05 00:50:38 R-wz0_the00_WindowRec-expectAES set_off
2017-01-05 00:50:38 R-wz0_the00_WindowRec-peerNeedsBurst set_on
irgendwie anscheinend doch gepeert?! Interessanterweise wiedereinmal auch mit dem anderen Kontakt (kon01). Ich würde Ansgar gerne ein Bisschen Feedback zum HM geben und habe mir dafür einen neuen Fensterkontakt bestellt, den ich frisch aufbaue und blanko nach Wiki, StepbyStep anlerne. Ich lasse mir ja einreden, dass einer meiner beiden Fensterkontakt irgendwie aus der Reihe tanzt, aber nicht beide mit dem gleichen Verhalten.
Sie liesen sich pairen und peeren, aber die LED leuchtet meiner Meinung nach falsch und die peerID's sind leer. Nach dem Update auf die neue FW und der *.pm-Files funktioniert auch der HMInfo Configcheck nicht mehr.
get hm configcheck lässt mein komplettes FHEM abschmieren...
Ich bin hier drauf gestoßen, weil auch ich mich gerade frage, ob ich den Fensterkontakt mit dem HK, dem WT oder mit beiden peeren soll... laut MadMax-FHEM reicht WT, mit dem Nachteil der Zeitverzögerung, aber...
Zitat von: MadMax-FHEM am 02 Januar 2017, 17:27:16
ZitatWie soll denn die Fensterauferkennung ohne Burst funktionieren. Wäre ja total unbrauchbar, wenn ich 5 Minuten Stoßlüfte und das Ding erst nach 3 Minuten die Temperatur runterregelt.
Bei nur Peering mit dem Wandthermostaten ist das definitiv so.
Fenster-auf geht an den Wandthermostaten (burst device), dieser erkennt das sofort und gibt dann bei der nächsten Kommunikation zum Heizkörperthermostaten die Fenster-auf-Temp als desired-temp vor...
Fragt mich nicht, wie ich das hinbekommen habe, aber bei mir sind auch Wand- und Heizkörperthermostat in _Weather und _Climate gepeert. Stelle ich am Wandthermostaten die Temperatur anders, weiß das der Heizkörper nach <10 Sekunden.
@theophiloui85: Wundert mich sehr, deine Leuchtorgien. Hängt sicher mit dem AES zusammen. FHEM kennt zudem die Register nicht, Dir fehlen noch getConfigs auf die FKs.
Internals:
DEF 359B02
...
NAME wz0_kon00
...
protCmdPend 4 CMDs pending
...
Readings:
...
2017-01-05 01:06:51 R-pairCentral set_0x000001
Und, ja, sehe ich auch so:
Internals:
NAME wz0_kon00
...
2016-12-30 03:07:35 R-wz0_kon01-expectAES on
2016-12-30 03:07:35 R-wz0_kon01-peerNeedsBurst off
2017-01-01 12:35:29 R-wz0_kon01_chn-01-expectAES on
2017-01-01 12:35:29 R-wz0_kon01_chn-01-peerNeedsBurst off
Willst Du den Fensterkontakt mit dem anderen peeren? Dat wird nix... weil jeht nich ...
Mach mal n set wz0_kon00 clear readings, und dann erst getConfig.
Zitat von: Pfriemler am 06 Januar 2017, 12:42:30
Ich bin hier drauf gestoßen, weil auch ich mich gerade frage, ob ich den Fensterkontakt mit dem HK, dem WT oder mit beiden peeren soll... laut MadMax-FHEM reicht WT, mit dem Nachteil der Zeitverzögerung, aber...
Bei nur Peering mit dem Wandthermostaten ist das definitiv so.
Fenster-auf geht an den Wandthermostaten (burst device), dieser erkennt das sofort und gibt dann bei der nächsten Kommunikation zum Heizkörperthermostaten die Fenster-auf-Temp als desired-temp vor...
Fragt mich nicht, wie ich das hinbekommen habe, aber bei mir sind auch Wand- und Heizkörperthermostat in _Weather und _Climate gepeert. Stelle ich am Wandthermostaten die Temperatur anders, weiß das der Heizkörper nach <10 Sekunden.
Also ich muss gestehen, dass ich noch nicht (selten / vielleicht anfangs mal) direkt auf die Heizkörperthermostate schaue, wenn ich an den Wandthermostaten rumstelle...
Ab und an, wenn ich das Fenster öffne sehe ich, dass der Wandthermostat bereits erkannt und umgestellt hat (ich habe eine ReadingsGroup-Übersicht dafür) und auf dem Heizkörperthermostaten dauert es ein Weilchen.
Ich habe mir das hal einfach mit dem Schlafen/Aufwachen erklärt und nach spät. dieser Zeit (3min) war er auch umgestellt und das hat mir so gereicht.
Tiefere Analysen habe ich nicht durchgeführt.
Ich habe aber Heizkörperthermostate die ich nicht direkt über den Fensterkontakt schalte (peering) sondern den Heizkörperthermostat per Notify schalte weil ich ihn bewusst später wieder hochdrehen will (also erst wenn das Fenster bereits 5-10 min wieder zu ist, da hat sich der Raum "erholt" und das Thermostat muss dann nicht gleich voll hochschalten).
Da habe ich beim Heizkörperthermostaten dann aber Burst aktiviert damit das sofort geht.
Wie gesagt: keine größeren Analysen vorgenommen ;)
Zitat von: Pfriemler am 06 Januar 2017, 12:42:30
@theophiloui85: Wundert mich sehr, deine Leuchtorgien. Hängt sicher mit dem AES zusammen. FHEM kennt zudem die Register nicht, Dir fehlen noch getConfigs auf die FKs.
Internals:
DEF 359B02
...
NAME wz0_kon00
...
protCmdPend 4 CMDs pending
...
Readings:
...
2017-01-05 01:06:51 R-pairCentral set_0x000001
Und, ja, sehe ich auch so:
Internals:
NAME wz0_kon00
...
2016-12-30 03:07:35 R-wz0_kon01-expectAES on
2016-12-30 03:07:35 R-wz0_kon01-peerNeedsBurst off
2017-01-01 12:35:29 R-wz0_kon01_chn-01-expectAES on
2017-01-01 12:35:29 R-wz0_kon01_chn-01-peerNeedsBurst off
Willst Du den Fensterkontakt mit dem anderen peeren? Dat wird nix... weil jeht nich ...
Mach mal n set wz0_kon00 clear readings, und dann erst getConfig.
Ähnliches wollte ich heute Nacht schon schreiben aber da es schon sehr spät war wollte ich vermeiden irgendwas zusammenzuschreiben was dann nicht weiter führt...
Gruß, Joachim
Joachim, es ist nicht so einfach ... Ich habe gerade experimentiert:
Zuerst den FK mit dem WT gepeert. Dabei ist mir aufgefallen, dass das sofort zu einem Problem führt, weil bei diesem Peervorgang beim Fensterkontakt nicht automatisch "peerNeedsBurst" gesetzt wird. Ich werde mal Martin nochmal darauf anschreiben, ich glaube nicht dass er alles hier mitliest. Das Ergebnis ist jedenfalls eine rote LED nach der Fensterbetätigung. Aber ich wusste um die Problematik und habe peerNeedsBurst von Hand auf on gesetzt. Und schon klappt die Verbindung einwandfrei: praktisch in der nächsten Sekunde ist das Fenstersymbol auf dem Display des WT da oder weg. Ein Druck auf die Tag/Nacht-Taste liefert als Solltempertatur auch sofort die zuletzt gewählte oder die winOpenTemp (12° default). Aber der Heizkörperthermostat bekommt dies erst sehr verzögert mitgeteilt! Ändre ich hingegen die Solltemperatur am WT, weiß der Heizkörper das zuverlässig in wenigen Sekunden. Das klappt übrigens auch umgekehrt - eine Änderung der Solltemp am Heizkörper weiß der WT ebenfalls in Sekunden.
Ich nehme an, dass die Solltemp hier jeweils verzögert übertragen wird, es wird sicher gewartet, bis man nicht mehr am Rad dreht.
Was nicht klappt, ist dass der WT die wegen des betätigten Fensters geänderte Temperatur sofort an den Heizkörper übermittelt. Das funktioniert wohl erst im Rahmen der normalen zyklischen Meldung, also sogar mit ungewisser Verzögerung.
Also habe ich den Fensterkontakt zusätzlich mit dem Heizkörper gepeert. Hier wird übrigens peerNeedsBurst sofort richtig gesetzt. Und seither ist auch die Fenstererkennung (logischerweise) am Heizkörper praktisch sofort.
Noch ein Ding am Rande: Im betreffenden Raum konkurrieren mein HMLAN und mein HMUART im -75..-85 dB-Bereich (rssi). peerChans und getConfigs waren anfangs Glückssache, bis ich mit "set HMUART close" den (schwächeren) in die Mittagspause geschickt habe. Ab da liefen alle Configs im ersten Rutsch. Das regelt die vccu offenbar nicht sauber.
Hi Pfriemler,
vielleicht nicht klar ausgedrückt bzw. ist es ja so wie du schreibst!?
Also der Wandthermostat erkennt bei mir (ohne komische Lichtorgel und ohne zusätzliches Setzen von needs burst) sofort das offene Fenster nach erfolgtem Peering...
Da hatte ich noch nie Probleme, außer evtl. das öftere Absetzen des Befehls bevor es alle beteiligten Parteien "gefressen" hatten bzw. seit ich halt immer langsam mit Config-Knopf drücken beim Fensterkontakt mache auch nicht mehr...
Das mit der Temperaturübertragung zwischen Wand- und Heizkörperthermostat bei "am Rad drehen" habe ich noch nicht so verfolgt, drehe immer nur über die ReadingsGroupÜbersicht "am Rad" ;)
Und schaue selten am Heizkörperthermostat, ob er das dann auch so sieht ;)
Allerdings das mit der Übertragung bei Fenster auf ist mir halt zu Beginn aufgefallen, weil der Heizköperthermostat ja direkt beim Fensteröffnen in Sicht ist...
...und da ist mir halt aufgefallen, dass er nicht "sofort" umschaltet, wenn ich das Fenster öffne.
Hab dann mal gekuckt, ob er das dann noch macht, um einen Fehler auszuschließen: ja. Damit war das für mich ok (also mit der Verzögerung kann ich gut leben).
Was ich immer sofort beim Fensterkontakt deaktiviert habe ist AES und die zyklischen Meldungen aktiviert.
Gibt es nicht auch ein attr preferedIODev?? Da kannst du selbst entscheiden welches besser geeignet ist (soweit ich das verstanden habe)...
Gruß, Joachim
P.S.: ich werde es weiterhin so machen: Wandthermostat_Weather mit Heizkörperthermostat_Weather, Wandthermostat_Climate mit Wandthermostat_Climate und Wandthermostat_WindowRec mit Fensterkontakt...
Ja. Aneinander vorbei. Also Du hattest gleich recht mit der verzögerten Reaktion: FK ->sofort > WT > verzögert > RT-DN. Und ich hatte recht mit HK <- sofort -> RT-DN bei manuellen Temperaturänderungen.
Ich wollte Dir das eigentlich nur bestätigen... außerdem findet's vielleicht mal ein anderer und freut sich.
AES ... ja witzig: Der FK hat R-sign on, beide peers (WT und RT-DN) hingegen off. Trotzdem hat FHEM beim FK expectAES zum WT gesetzt, statt des peerNeedsBurst. ... ??? Komisch, dass das bei Dir sofort geklappt hat.
preferedIO stellt man über IOGrp ein: "vccu:HMLAN1" legt's dann fest, hatte ich bei dem Ding tatsächlich offen gelassen, kann daran gelegen haben. Trotzdem sollte die vccu zwar Wahlfreiheit im Sendedevice haben, das aber nicht ständig umswitchen - oder die doppelt eintreffenden Meldungen überfordern, das kann Martin besser einschätzen. Damit kann ich leben, ein IO bei kritischen Aktionen zu pausieren. Beim Firmwareupdate etwa muss das HMLAN in Pause, bricht sonst immer ab.
Ich wiederum bevorzuge übrigens eine sofortige Reaktion auf offenes Fenster und ein möglichst zügiges Wiederaufheizen... kann ja jeder für sich entscheiden.
Ich glaube mit meinem Halbwissen verwirre ich nur mich und euch, deshalb einfach mal all meine Lists:
Stellantrieb
Internals:
DEF 269BFF
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 268
NAME wz0_sta00
NOTIFYDEV global
NR 120
STATE CMDs_done
TYPE CUL_HM
channel_01 wz0_sta00_Weather
channel_02 wz0_sta00_Climate
channel_03 wz0_sta00_WindowRec
channel_04 wz0_sta00_Clima
lastMsg No:A1 - t:10 s:269BFF d:000000 0AA0EB8B0000
protLastRcv 2017-01-06 23:14:18
protResnd 1 last_at:2017-01-06 16:15:56
protSnd 11 last_at:2017-01-06 22:45:08
protState CMDs_done
rssi_ActionDetector min:-56 cnt:6 lst:-56 avg:-54.66 max:-54
rssi_at_wz0_cul00 lst:-58.5 cnt:268 min:-68.5 avg:-54.71 max:-51.5
wz0_cul00_MSGCNT 268
wz0_cul00_RAWMSG A0FA18610269BFF0000000AA0EB8B0000::-58.5:wz0_cul00
wz0_cul00_RSSI -58.5
wz0_cul00_TIME 2017-01-06 23:14:18
Readings:
2017-01-06 23:09:45 CommandAccepted yes
2017-01-05 01:10:11 D-firmware 1.4
2017-01-05 01:10:11 D-serialNr LEQ0105862
2017-01-05 02:01:51 PairedTo 0x000001
2016-12-26 01:50:04 R-backOnTime 10 s
2016-12-26 01:50:04 R-burstRx on
2016-12-26 01:50:04 R-cyclicInfoMsg on
2016-12-26 01:50:04 R-cyclicInfoMsgDis 0
2017-01-05 00:08:01 R-pairCentral 0x000001
2017-01-05 02:01:51 RegL_00. 01:01 02:01 09:01 0A:00 0B:00 0C:01 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 00:00
2017-01-05 18:02:26 RegL_07.
2017-01-06 23:14:18 actuator 0
2017-01-06 22:45:08 battery ok
2017-01-06 23:14:18 batteryLevel 2.6
2017-01-01 17:15:43 controlMode auto
2017-01-06 23:14:18 desired-temp 20.0
2017-01-06 23:14:18 measured-temp 23.5
2017-01-06 23:14:18 motorErr communicationERR
2017-01-01 12:46:31 powerOn 2017-01-01 12:46:31
2017-01-01 12:46:31 recentStateType info
2017-01-04 23:55:30 sabotageAttackId_ErrIoId_26043E cnt:17
2017-01-04 23:55:30 sabotageAttack_ErrIoAttack cnt 17
2017-01-06 22:45:08 state CMDs_done
2017-01-06 20:28:10 time-request -
Helper:
HM_CMDNR 161
cSnd 11000001269BFF860428,11000001269BFF860428
mId 0095
rxType 140
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
dwoCAA 116
lRcTm 173972188
lstRecType 10
lstSndTgd 120
newChn +269BFF,00,00,00
nextSend 1483740858.49501
nxtSndMcnt A1
prefIO
rxt 2
tgtDly 120
vccu
p:
269BFF
00
00
00
Mrssi:
mNo A1
Io:
wz0_cul00 -56.5
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
prs 1
Rssi:
Actiondetector:
avg -54.6666666666667
cnt 6
lst -56
max -54
min -56
At_wz0_cul00:
avg -54.7126865671642
cnt 268
lst -58.5
max -51.5
min -68.5
Shregw:
07 04
Tmpl:
Attributes:
IODev wz0_cul00
actCycle 000:10
actStatus
alias Stellantrieb Wohnzimmer
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group [Homematic] Stellantriebe
model HM-CC-RT-DN
room X_Geräte
serialNr LEQ0105862
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
Wandthermostat:
Internals:
DEF 26043E
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 395
NAME wz0_the00
NOTIFYDEV global
NR 81
STATE CMDs_done
TYPE CUL_HM
channel_01 wz0_the00_Weather
channel_02 wz0_the00_Climate
channel_03 wz0_the00_WindowRec
lastMsg No:49 - t:70 s:26043E d:000000 00EB24
protLastRcv 2017-01-06 23:14:37
protSnd 7 last_at:2017-01-06 22:45:01
protState CMDs_done
rssi_ActionDetector max:-57 avg:-57.33 min:-58 cnt:3 lst:-57
rssi_at_wz0_cul00 max:-62 avg:-67.11 lst:-67 cnt:395 min:-85
wz0_cul00_MSGCNT 395
wz0_cul00_RAWMSG A0C49847026043E00000000EB24::-67:wz0_cul00
wz0_cul00_RSSI -67
wz0_cul00_TIME 2017-01-06 23:14:37
Readings:
2017-01-06 23:09:44 CommandAccepted yes
2017-01-05 19:06:41 D-firmware 1.3
2017-01-05 19:06:41 D-serialNr LEQ0000562
2017-01-05 02:00:19 PairedTo 0x000001
2016-12-26 00:57:22 R-burstRx on
2016-12-26 00:57:22 R-cyclicInfoMsg on
2016-12-26 00:57:22 R-cyclicInfoMsgDis 0
2017-01-05 01:06:36 R-pairCentral 0x000001
2017-01-05 02:00:19 RegL_00. 01:01 02:01 09:01 0A:00 0B:00 0C:01 0F:00 11:00 12:16 16:00 18:00 19:00 1A:00 00:00
2017-01-05 18:09:10 RegL_07.
2017-01-06 23:08:58 battery ok
2017-01-06 23:08:58 batteryLevel 2.6
2017-01-06 23:08:58 desired-temp 20.0
2017-01-06 23:08:58 measured-temp 23.5
2017-01-05 01:02:41 powerOn 2017-01-05 01:02:41
2017-01-05 01:02:41 recentStateType info
2017-01-06 22:45:01 state CMDs_done
2017-01-06 22:37:45 time-request -
Helper:
HM_CMDNR 73
PONtest 1
cSnd 1100000126043E860430,1100000126043E860428
mId 00AD
rxType 6
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 1
tpl 0
Io:
dwoCAA 116
lRcTm 173991160
lstRecType 70
lstSndTgd 120
newChn +26043E,00,00,00
nextSend 1483740877.46662
nxtSndMcnt 49
prefIO
rxt 0
tgtDly 120
vccu
p:
26043E
00
00
00
Mrssi:
mNo 49
Io:
wz0_cul00 -65
Prt:
awake 0
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
Actiondetector:
avg -57.3333333333333
cnt 3
lst -57
max -57
min -58
At_wz0_cul00:
avg -67.1101265822785
cnt 395
lst -67
max -62
min -85
Shregw:
07 02
Tmpl:
Attributes:
IODev wz0_cul00
actCycle 000:10
actStatus
alias Thermostat Wohnzimmer
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.3
group [Homematic] Thermostate
model HM-TC-IT-WM-W-EU
msgRepeat 1
room X_Geräte
serialNr LEQ0000562
subType thermostat
webCmd getConfig:clear msgEvents
Kontakt 0:
Internals:
DEF 359B02
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 63
NAME wz0_kon00
NOTIFYDEV global
NR 160
STATE closed
TYPE CUL_HM
lastMsg No:12 - t:10 s:359B02 d:000001 06010000
protLastRcv 2017-01-06 23:10:02
protSnd 13 last_at:2017-01-06 23:10:02
protState CMDs_done
rssi_at_wz0_cul00 max:-54.5 avg:-59.44 cnt:63 lst:-59 min:-66
wz0_cul00_MSGCNT 63
wz0_cul00_RAWMSG A0D12A610359B0200000106010000::-59:wz0_cul00
wz0_cul00_RSSI -59
wz0_cul00_TIME 2017-01-06 23:10:02
Readings:
2017-01-05 01:06:53 CommandAccepted yes
2017-01-05 01:06:51 D-firmware 1.0
2017-01-05 01:06:51 D-serialNr LEQ1510020
2017-01-05 00:51:02 PairedTo 0x000001
2016-12-30 02:32:04 R-cyclicInfoMsg on
2016-12-30 02:32:05 R-eventDlyTime 0 s
2017-01-05 01:06:51 R-pairCentral set_0x000001
2016-12-30 02:32:04 R-sabotageMsg on
2016-12-30 02:32:05 R-sign on
2016-12-30 03:07:35 R-wz0_kon01-expectAES on
2016-12-30 03:07:35 R-wz0_kon01-peerNeedsBurst off
2017-01-01 12:35:29 R-wz0_kon01_chn-01-expectAES on
2017-01-01 12:35:29 R-wz0_kon01_chn-01-peerNeedsBurst off
2017-01-05 00:50:38 R-wz0_the00_WindowRec-expectAES set_off
2017-01-05 00:50:38 R-wz0_the00_WindowRec-peerNeedsBurst set_on
2017-01-05 01:06:53 aesKeyNbr 00
2017-01-06 23:10:02 alive yes
2017-01-06 23:10:02 battery ok
2017-01-06 23:10:02 contact closed (to ActionDetector)
2017-01-06 23:09:43 powerOn 2017-01-06 23:09:43
2017-01-06 23:10:02 recentStateType info
2017-01-06 23:10:02 sabotageError off
2017-01-06 23:10:02 state closed
2017-01-06 23:09:45 trigDst_ActionDetector noConfig
2017-01-06 23:09:58 trigDst_wz0_kon01 noConfig
2017-01-06 23:09:45 trigDst_wz0_sta00 noConfig
2017-01-06 23:09:44 trigDst_wz0_the00 noConfig
2017-01-06 23:09:58 trigger_cnt 1
Helper:
HM_CMDNR 18
PONtest 0
mId 00C7
rxType 28
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 1
tpl 0
Io:
dwoCAA 116
lRcTm 173716180
lstRecType 10
lstSnd 1483740602.4918
lstSndTgd 120
newChn +359B02,00,00,00
nextSend 1483740602.4918
nxtSndMcnt 12
prefIO
rxt 2
tgtDly 120
vccu
p:
359B02
00
00
00
Mrssi:
mNo 12
Io:
wz0_cul00 -57
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rpt:
IO wz0_cul00
flg A
ts 1483740602.44609
ack:
HASH(0x29058f4)
128002000001359B0200
Rssi:
At_wz0_cul00:
avg -59.4444444444444
cnt 63
lst -59
max -54.5
min -66
Tmpl:
Attributes:
IODev wz0_cul00
actCycle 002:50
actStatus
alias Fensterkontakt Wohnzimmer links
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group [Homematic] Kontakte
model HM-SEC-SCo
peerIDs
room X_Geräte,Kontakte
serialNr LEQ1510020
subType threeStateSensor
Kontakt 1:
Internals:
DEF 359B3E
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 42
NAME wz0_kon01
NOTIFYDEV global
NR 164
STATE closed
TYPE CUL_HM
lastMsg No:E0 - t:41 s:359B3E d:359B02 010B00
protLastRcv 2017-01-06 23:09:04
protSnd 10 last_at:2017-01-06 23:08:50
protState CMDs_done
rssi_at_wz0_cul00 lst:-80.5 cnt:42 min:-82 max:-66 avg:-74.2
wz0_cul00_MSGCNT 42
wz0_cul00_RAWMSG A0CE0A241359B3E359B02010B00::-80.5:wz0_cul00
wz0_cul00_RSSI -80.5
wz0_cul00_TIME 2017-01-06 23:09:04
Readings:
2017-01-05 01:07:42 CommandAccepted yes
2017-01-05 01:07:41 D-firmware 1.0
2017-01-05 01:07:41 D-serialNr LEQ1510062
2017-01-05 00:52:04 PairedTo 0x000001
2016-12-30 02:40:39 R-cyclicInfoMsg on
2017-01-01 12:47:48 R-eventDlyTime 0 s
2017-01-05 01:07:41 R-pairCentral set_0x000001
2016-12-30 02:40:39 R-sabotageMsg on
2017-01-01 12:47:48 R-sign on
2017-01-01 12:47:49 R-wz0_kon00-expectAES on
2017-01-01 12:47:49 R-wz0_kon00-peerNeedsBurst off
2017-01-01 12:47:49 R-wz0_kon00_chn-01-expectAES on
2017-01-01 12:47:49 R-wz0_kon00_chn-01-peerNeedsBurst off
2017-01-05 00:51:50 R-wz0_sta00_WindowRec-expectAES set_off
2017-01-05 00:51:50 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2017-01-01 13:16:45 R-wz0_the00_WindowRec-expectAES set_off
2017-01-01 13:16:45 R-wz0_the00_WindowRec-peerNeedsBurst set_on
2017-01-05 01:07:42 aesKeyNbr 00
2017-01-06 22:54:20 alive yes
2017-01-06 23:09:04 battery ok
2017-01-06 23:09:04 contact closed (to wz0_kon00)
2017-01-05 18:56:23 powerOn 2017-01-05 18:56:23
2017-01-06 22:54:20 recentStateType info
2017-01-06 22:54:20 sabotageError off
2017-01-06 23:09:04 state closed
2017-01-06 23:08:50 trigDst_ActionDetector noConfig
2017-01-06 23:09:04 trigDst_wz0_kon00 noConfig
2017-01-06 23:08:50 trigDst_wz0_sta00 noConfig
2017-01-06 23:08:50 trigDst_wz0_the00 noConfig
2017-01-01 14:39:06 trigLast wz0_kon00:open
2017-01-01 14:39:06 trig_wz0_kon00 Open_168
2017-01-06 23:09:04 trigger_cnt 11
Helper:
HM_CMDNR 224
mId 00C7
rxType 28
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 1
tpl 0
Io:
dwoCAA 116
lRcTm 173657996
lstRecType 41
lstSndTgd 120
newChn +359B3E,00,00,00
nextSend 1483740544.30893
nxtSndMcnt E0
prefIO
rxt 2
tgtDly 120
vccu
p:
359B3E
00
00
00
Mrssi:
mNo E0
Io:
wz0_cul00 -78.5
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rssi:
At_wz0_cul00:
avg -74.2023809523809
cnt 42
lst -80.5
max -66
min -82
Tmpl:
Attributes:
IODev wz0_cul00
actCycle 002:50
actStatus
alias Fensterkontakt Wohnzimmer rechts
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
group [Homematic] Kontakte
model HM-SEC-SCo
room X_Geräte,Kontakte
serialNr LEQ1510062
subType threeStateSensor
Wie ihr seht sind jetzt alle CMD's done und die meisten peerIDs leer.
Öffne und schließe ich eines der beiden Fenster reagiert der Stellantrieb unmittelbar in weniger als 10s, auf und ab, IMMER.
Öffne ich ein Fenster leuchtet der Kontakt ewig (ca 30s) orange und dann kurz rot. Fenstersymbole erscheinen korrekt an Wandthermostat und Stellantrieb.
Wenn ich die Wiki und was ich sonst noch so zusammengelesen habe richtig interpretiert habe, dürfte das nicht so sein. Anfangs als die Fensterkontakte nur gepaired und nicht gepeert waren, leuchteten sie orange wenn ich das Fenster öffnete und kurz grün und beim Schließen wieder die gleiche Sequenz.
Es funktioniert bei mir ja alles, ich würde es nur so gerne verstehen, nachdem ich schon soviel Zeit in die Dinger investiert habe. Alle anderen Device (sogar der doofe 55er Bewegungsmelder) arbeiten so, wie man es sich von ihnen erwartet.
Zitat von: Pfriemler am 06 Januar 2017, 14:45:08
Ja. Aneinander vorbei. Also Du hattest gleich recht mit der verzögerten Reaktion: FK ->sofort > WT > verzögert > RT-DN. Und ich hatte recht mit HK <- sofort -> RT-DN bei manuellen Temperaturänderungen.
Ich wollte Dir das eigentlich nur bestätigen... außerdem findet's vielleicht mal ein anderer und freut sich.
AES ... ja witzig: Der FK hat R-sign on, beide peers (WT und RT-DN) hingegen off. Trotzdem hat FHEM beim FK expectAES zum WT gesetzt, statt des peerNeedsBurst. ... ??? Komisch, dass das bei Dir sofort geklappt hat.
Ah, dann is ja gut... ;)
Jep, bislang hat es bei den Wandthermostaten immer sofort geklappt das Peering.
Zuvor halt alles schön sauber Gepaired und AES aus und cyclig Messages an...
Gruß, Joachim
Zitat von: theophilou85 am 06 Januar 2017, 23:19:55
Wie ihr seht sind jetzt alle CMD's done und die meisten peerIDs leer.
Öffne und schließe ich eines der beiden Fenster reagiert der Stellantrieb unmittelbar in weniger als 10s, auf und ab, IMMER.
Öffne ich ein Fenster leuchtet der Kontakt ewig (ca 30s) orange und dann kurz rot. Fenstersymbole erscheinen korrekt an Wandthermostat und Stellantrieb.
Wenn ich die Wiki und was ich sonst noch so zusammengelesen habe richtig interpretiert habe, dürfte das nicht so sein. Anfangs als die Fensterkontakte nur gepaired und nicht gepeert waren, leuchteten sie orange wenn ich das Fenster öffnete und kurz grün und beim Schließen wieder die gleiche Sequenz.
Es funktioniert bei mir ja alles, ich würde es nur so gerne verstehen, nachdem ich schon soviel Zeit in die Dinger investiert habe. Alle anderen Device (sogar der doofe 55er Bewegungsmelder) arbeiten so, wie man es sich von ihnen erwartet.
Also solange AES NUR bei den Fensterkontakten aktiviert ist also erwartet wird, wird es immer Rot enden, da der Fensterkontakt ein ACK mit AES erwartet aber nur ein "normales" bekommt -> Fehler -> Rot.
Dass es trotzdem funktioniert (oder für dich so aussieht) liegt daran, dass "auf/zu" als normales Telegramm verschickt und empfangen wird und entsprechend angezeigt und reagiert wird.
Peer-IDs konnte ich keine sehen.
Ist noch nichts gepeered??
Einige Register sehen "eigenartig" aus.
Z.B. beim Kontakt00:
2016-12-30 03:07:35 R-wz0_kon01-peerNeedsBurst off
2017-01-01 12:35:29 R-wz0_kon01_chn-01-expectAES on
2017-01-01 12:35:29 R-wz0_kon01_chn-01-peerNeedsBurst off
2017-01-05 00:50:38 R-wz0_the00_WindowRec-expectAES set_off
2017-01-05 00:50:38 R-wz0_the00_WindowRec-peerNeedsBurst set_on
und Koontakt01:
2017-01-01 12:47:49 R-wz0_kon00-expectAES on
2017-01-01 12:47:49 R-wz0_kon00-peerNeedsBurst off
2017-01-01 12:47:49 R-wz0_kon00_chn-01-expectAES on
2017-01-01 12:47:49 R-wz0_kon00_chn-01-peerNeedsBurst off
2017-01-05 00:51:50 R-wz0_sta00_WindowRec-expectAES set_off
2017-01-05 00:51:50 R-wz0_sta00_WindowRec-peerNeedsBurst set_on
2017-01-01 13:16:45 R-wz0_the00_WindowRec-expectAES set_off
2017-01-01 13:16:45 R-wz0_the00_WindowRec-peerNeedsBurst set_on
Sieht irgendwie so aus als wären die Fensterkontakte untereinander gepeered was aber (wie bereits Pfriemler ausgeführt hat) nicht geht...
Auch sieht es so aus als wäre gepeered worden, allerdings sehe ich (oder habe es übersehen) Peer-IDs...
Das mit dem Rot geht weg, wenn entweder AES aktiviert wird überall bzw. bei allen beteiligten Komponenten oder bei den Fensterkontakten deaktiviert wird.
(es ist, wie bereits ausgeführt denke ich, von Beginn an aktiviert weil diese potetiell "sicherheitsrelevant" sind [Alarmanlegen] allerdings [für mich total sinnfrei ;) ])
Ansonsten sieht es schon mal gut aus...
...die set_ müssen halt noch abgearbeitet werden bzw. halt direkt bei den Geräten entsprechend eingestellt werden, je nachdem was der Peer "fordert"...
...also AES und burst...
Gruß, Joachim
Zitat von: theophilou85 am 06 Januar 2017, 23:19:55
Wie ihr seht sind jetzt alle CMD's done und die meisten peerIDs leer.
Das ist nicht normal. Komisch. Normalerweise steht da wenigstens 000000 drin. Späte Rache der falschen hmID-Entscheidung. Da Heizkörper und Wandthermostat reagieren, gehören dort beide _WindowRec-Kanäle hinein, klarschriftlich oben, in den attr peerIDs 269BFF
03 und 26043E
03. Bitte nicht dort eintragen, das mach FHEM selbst. Normalerweise.
ZitatÖffne und schließe ich eines der beiden Fenster reagiert der Stellantrieb unmittelbar in weniger als 10s, auf und ab, IMMER.
Öffne ich ein Fenster leuchtet der Kontakt ewig (ca 30s) orange und dann kurz rot. Fenstersymbole erscheinen korrekt an Wandthermostat und Stellantrieb.
Nein, das dürfte nicht so sein. Rot kommt, wenn nur eine der erforderlichen Kommunikationen nicht bis zu Ende durchgeführt ist. Da die Fenstersymbole an Wandthermostat und Heizkörper sofort kommen, wissen die Geräte dass sie auf die FKs hören sollen. Anscheinend ist dann bei beiden im Kanal _WindowRec auch Was die Fensterkontakte für ACKs erwarten, kann man ohne gültige Registerliste nicht einsehen.
Du hast clear Readings und getConfig offenbar nicht durchgeführt, sonst wären die Peerings der FKs each other und die veralteten "set_off"/"set_on" weg.
Also wir brauchen eine gültige peer-Liste der Fensterkontakte, sonst befragen wir die Glaskugel umsonst, was die Fensterkontakte als Antwort erwarten: Sie schicken eine Botschaft in die Welt und erwarten von allen Peers eine korrekte Antwort. Also müssen wir wissen wer gefragt ist. Befindet sich darunter noch eines, was noch nichts von seinem Glück weiß, dann wird es auch nicht antworten.
Last but not least kommt natürlich auch ein Defekt des Empfangsteils des Fensterkontakts (also dass zwar Antworten gesendet werden, aber nicht ankommen). Aber bei beiden?
Ach, ich sehe gerade, eine Antwort ist schon da ...
Also dazu: Nein, bei mir ist der Fensterkontakt von heute AES-aktiviert, erwartet vom Wandthermostaten AES, nicht vom Heizkörper - beide Geräte sind im gepeerten Kanal aber R-sign off. Und es gibt kein rot. Das ist in der Theorie zwar seltsam, aber praktisch funktioniert es...
Zitat von: Pfriemler am 07 Januar 2017, 00:01:20
Ach, ich sehe gerade, eine Antwort ist schon da ...
Also dazu: Nein, bei mir ist der Fensterkontakt von heute AES-aktiviert, erwartet vom Wandthermostaten AES, nicht vom Heizkörper - beide Geräte sind im gepeerten Kanal aber R-sign off. Und es gibt kein rot. Das ist in der Theorie zwar seltsam, aber praktisch funktioniert es...
Wie gesagt ich schalte AES sofort nach dem Pairing der Fensterkontakte bei selbigen aus...
...daher nur Theorie (habe einige Threads bzgl. AES etc. verfolgt, weil ich überlege es irgendwann mal zu aktivieren) in der Praxis fahre ich noch komplett ohne AES...
Gruß, Joachim
Sodala, Neuigkeiten auf meiner Front: Nagelneuen optischen Fensterkontakt bekommen. Interessanterweise leuchtet der schon vor dem Pairing korrekt, schnell von orange auf grün.
Kontakt gepaired, leuchtet noch immer korrekt, get config:
Internals:
DEF 414C50
IODev wz0_cul00
LASTInputDev wz0_cul00
MSGCNT 26
NAME HM_414C50
NOTIFYDEV global
NR 313
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:57 - t:41 s:414C50 d:000001 012400
protCmdDel 1
protLastRcv 2017-01-10 01:20:14
protResnd 3 last_at:2017-01-10 01:20:20
protResndFail 1 last_at:2017-01-10 01:20:25
protSnd 7 last_at:2017-01-10 01:20:14
protState CMDs_done_Errors:1
rssi_at_wz0_cul00 avg:-70.28 max:-63.5 min:-78 cnt:26 lst:-68
wz0_cul00_MSGCNT 26
wz0_cul00_RAWMSG A0C57A641414C50000001012400::-68:wz0_cul00
wz0_cul00_RSSI -68
wz0_cul00_TIME 2017-01-10 01:20:14
Readings:
2017-01-10 01:05:12 CommandAccepted yes
2017-01-10 01:05:10 D-firmware 1.0
2017-01-10 01:05:10 D-serialNr MEQ0947186
2017-01-10 01:05:10 R-pairCentral set_0x000001
2017-01-10 01:05:12 aesKeyNbr 00
2017-01-10 01:05:22 battery ok
2017-01-10 01:05:22 contact closed (to ActionDetector)
2017-01-10 01:20:25 state RESPONSE TIMEOUT:RegisterRead
2017-01-10 01:20:14 trigDst_ActionDetector noConfig
2017-01-10 01:20:14 trigger_cnt 36
Regl_00.:
VAL
Helper:
HM_CMDNR 87
cSnd 01000001414C5000040000000000,01000001414C5000040000000000
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
dwoCAA 116
lRcTm 440733356
lstRecType 41
lstSnd 1484007614.39814
lstSndTgd 360
newChn +414C50,00,00,00
nextSend 1484007614.39814
nxtSndMcnt 57
prefIO
rxt 0
tgtDly 120
vccu
p:
414C50
00
00
00
Mrssi:
mNo 57
Io:
wz0_cul00 -66
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO wz0_cul00
flg A
ts 1484007614.41894
ack:
HASH(0x400327c)
578002000001414C5000
Rssi:
At_wz0_cul00:
avg -70.2884615384615
cnt 26
lst -68
max -63.5
min -78
Tmpl:
Attributes:
IODev wz0_cul00
autoReadReg 4_reqStatus
expert 2_raw
room CUL_HM
Bei diesem nagelneuen Kontakt bekomme ich jetzt wieder ein "RESPONSE TIMEOUT:RegisterRead".
Io ist cul. Fw ist tscul? Sonst geht hm nicht.
Wenn es so ist dann ein getconfig sniffen.
Korrekt, io=cul, fw=tscul
2017.01.11 23:04:26.822 4: TSCUL_Parse: wz0_cul00 494899 A FF01 12164744 00 0C 63 8470 26043E 000000 00F227 -65
2017.01.11 23:04:28.681 4: TSCUL_send: wz0_cul00 As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:28.731 4: TSCUL_Parse: wz0_cul00 496810 A FF13 12166704 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:28.978 4: TSCUL_Parse: wz0_cul00 497056 A FF13 12166956 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:29.275 4: TSCUL_Parse: wz0_cul00 497353 A FF13 12167208 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:29.494 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E6A48001002A001000001414C5000
2017.01.11 23:04:29.494 4: TSCUL_Parse: wz0_cul00 497572 A FF10 12167456 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:34.368 4: TSCUL_send: wz0_cul00 As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:34.478 4: TSCUL_Parse: wz0_cul00 502557 A FF13 12172392 02 10 02 A001 000001 414C50 00 _CCAdly:8 -138
2017.01.11 23:04:34.712 4: TSCUL_Parse: wz0_cul00 502791 A FF13 12172640 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:34.978 4: TSCUL_Parse: wz0_cul00 503057 A FF13 12172892 01 10 02 A001 000001 414C50 00 _CCAdly:4 -138
2017.01.11 23:04:35.197 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E6FD5001002A001000001414C5000
2017.01.11 23:04:35.197 4: TSCUL_Parse: wz0_cul00 503275 A FF10 12173140 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:38.306 4: TSCUL_Parse: wz0_cul00 506383 A FF11 12176316 00 0C A0 A641 414C50 000001 012BC8 -71
2017.01.11 23:04:38.321 4: TSCUL_send: wz0_cul00 As 0A A0 8002 000001 414C50 00
2017.01.11 23:04:38.321 3: TSCUL_XmitDlyHM: wz0_cul00 id:414C50 dDly:35 toms:67
2017.01.11 23:04:38.494 4: TSCUL_Parse: wz0_cul00 506572 A FF13 12176436 01 0A A0 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:04:38.555 4: TSCUL_send: wz0_cul00 As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:38.666 4: TSCUL_Parse: wz0_cul00 506744 A FF13 12176576 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:260 -138
2017.01.11 23:04:38.869 4: TSCUL_Parse: wz0_cul00 506947 A FF13 12176828 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:512 -138
2017.01.11 23:04:39.088 4: TSCUL_Parse: wz0_cul00 507166 A FF13 12177080 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:764 -138
2017.01.11 23:04:39.306 4: TSCUL_Parse: wz0_cul00 507383 A FF11 12177312 00 0C A1 A641 414C50 000001 012C00 -70.5
2017.01.11 23:04:39.416 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E73F7001002A001000001414C5000
2017.01.11 23:04:39.416 4: TSCUL_Parse: wz0_cul00 507494 A FF10 12177372 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:39.853 4: TSCUL_Parse: wz0_cul00 507930 A FF11 12177872 00 0C A2 A641 414C50 000001 012C00 -71
2017.01.11 23:04:40.635 4: TSCUL_Parse: wz0_cul00 508711 A FF11 12178648 00 0C A3 A641 414C50 000001 012C00 -73
2017.01.11 23:04:41.571 4: TSCUL_send: wz0_cul00 As 0A A1 8002 000001 414C50 00
2017.01.11 23:04:41.635 4: TSCUL_Parse: wz0_cul00 509713 A FF13 12179592 01 0A A1 8002 000001 414C50 00 _CCAdly:4 _dhmSt:944 -138
2017.01.11 23:04:41.649 4: TSCUL_send: wz0_cul00 As 0A A2 8002 000001 414C50 00
2017.01.11 23:04:41.713 4: TSCUL_Parse: wz0_cul00 509791 A FF13 12179684 01 0A A2 8002 000001 414C50 00 _CCAdly:4 _dhmSt:1036 -138
2017.01.11 23:04:41.728 4: TSCUL_send: wz0_cul00 As 0A A3 8002 000001 414C50 00
2017.01.11 23:04:41.791 4: TSCUL_Parse: wz0_cul00 509869 A FF13 12179772 01 0A A3 8002 000001 414C50 00 _CCAdly:4 _dhmSt:1124 -138
2017.01.11 23:04:43.213 4: TSCUL_Parse: wz0_cul00 511289 A FF11 12181228 00 0C A5 A641 414C50 000001 012DC8 -72
2017.01.11 23:04:43.227 4: TSCUL_send: wz0_cul00 As 0A A5 8002 000001 414C50 00
2017.01.11 23:04:43.228 3: TSCUL_XmitDlyHM: wz0_cul00 id:414C50 dDly:40 toms:67
2017.01.11 23:04:43.369 4: TSCUL_Parse: wz0_cul00 511447 A FF13 12181348 01 0A A5 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:04:43.384 4: TSCUL_send: wz0_cul00 As 10 02 A001 000001 414C50 00040000000000
2017.01.11 23:04:43.384 3: TSCUL_XmitDlyHM: wz0_cul00 id:414C50 dDly:0 toms:67
2017.01.11 23:04:43.494 4: TSCUL_Parse: wz0_cul00 511572 A FF13 12181436 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:208 -138
2017.01.11 23:04:43.712 4: TSCUL_Parse: wz0_cul00 511791 A FF13 12181688 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:460 -138
2017.01.11 23:04:43.978 4: TSCUL_Parse: wz0_cul00 512056 A FF13 12181940 01 10 02 A001 000001 414C50 00 _CCAdly:4 _dhmSt:712 -138
2017.01.11 23:04:44.212 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 414C50/HM_414C50: AFF10002E78AB001002A001000001414C5000
2017.01.11 23:04:44.212 4: TSCUL_Parse: wz0_cul00 512291 A FF10 12182188 00 10 02 A001 000001 414C50 00 _sfail -138
2017.01.11 23:04:44.759 4: TSCUL_Parse: wz0_cul00 512836 A FF11 12182788 00 0C A6 A641 414C50 000001 012E00 -66.5
2017.01.11 23:04:45.306 4: TSCUL_Parse: wz0_cul00 513383 A FF11 12183332 00 0C A7 A641 414C50 000001 012E00 -65.5
2017.01.11 23:04:46.197 4: TSCUL_Parse: wz0_cul00 514274 A FF11 12184172 00 0C A8 A641 414C50 000001 012E00 -65
2017.01.11 23:04:46.399 4: TSCUL_send: wz0_cul00 As 0A A6 8002 000001 414C50 00
2017.01.11 23:04:46.478 4: TSCUL_send: wz0_cul00 As 0A A7 8002 000001 414C50 00
2017.01.11 23:04:46.556 4: TSCUL_send: wz0_cul00 As 0A A8 8002 000001 414C50 00
2017.01.11 23:04:46.619 4: TSCUL_Parse: wz0_cul00 514697 A FF13 12184576 01 0A A8 8002 000001 414C50 00 _CCAdly:4 _dhmSt:404 -138
2017.01.11 23:04:46.728 4: TSCUL_Parse: wz0_cul00 514807 A FF13 12184668 01 0A A6 8002 000001 414C50 00 _CCAdly:4 _dhmSt:496 -138
2017.01.11 23:04:46.838 4: TSCUL_Parse: wz0_cul00 514916 A FF13 12184756 01 0A A7 8002 000001 414C50 00 _CCAdly:4 _dhmSt:584 -138
2017.01.11 23:04:47.041 4: TSCUL_Parse: wz0_cul00 515110 A FF12 12184948 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.01.11 23:04:47.369 4: TSCUL_Parse: wz0_cul00 515446 A FF11 12185292 00 0C A9 A641 414C50 000001 012E00 -66
2017.01.11 23:04:47.384 4: TSCUL_send: wz0_cul00 As 0A A9 8002 000001 414C50 00
2017.01.11 23:04:47.447 4: TSCUL_Parse: wz0_cul00 515525 A FF13 12185412 01 0A A9 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:04:49.338 4: TSCUL_Parse: wz0_cul00 517412 A FF11 12187260 00 0F D3 8610 269BFF 000000 0AA0F28B0000 -60
2017.01.11 23:05:20.875 4: TSCUL_Parse: wz0_cul00 024656 A FF12 12218888 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.01.11 23:05:25.203 4: TSCUL_Parse: wz0_cul00 029002 A FF01 12223164 00 0C AA A641 414C50 000001 012FC8 -71.5
2017.01.11 23:05:25.218 4: TSCUL_send: wz0_cul00 As 0A AA 8002 000001 414C50 00
2017.01.11 23:05:25.281 4: TSCUL_Parse: wz0_cul00 029081 A FF13 12223284 01 0A AA 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
2017.01.11 23:05:27.640 4: TSCUL_Parse: wz0_cul00 031440 A FF01 12225656 00 0C AB A641 414C50 000001 013000 -69.5
2017.01.11 23:05:27.655 4: TSCUL_send: wz0_cul00 As 0A AB 8002 000001 414C50 00
2017.01.11 23:05:27.655 3: TSCUL_XmitDlyHM: wz0_cul00 id:414C50 dDly:45 toms:73
2017.01.11 23:05:27.828 4: TSCUL_Parse: wz0_cul00 031628 A FF13 12225776 01 0A AB 8002 000001 414C50 00 _CCAdly:4 _dhmSt:120 -138
So, ich bin jetzt ziemlich am Ende meiner Reise mit den Fensterkontakten. Dank der neuen Firmware sehe ich endlich alle peerID's. Habe jetzt alle alten peerID's gelöscht und mir werden nun alle Peers korrekt angezeigt.
Stellantrieb und die beiden Fensterkontakte arbeiten tadellos. Das einzige was im Moment nicht übertragen wird, ist das Fenstersymbol an das Wandthermostat. Es erscheint aber korrekt am Stellantrieb.
Was ist jetzt eigentlich die korrekte Form des Peerings? Fensterkontakte(WindowRec) mit Stellantrieb(WindowRec)+Fensterkontakt(WindowRec) mit Wandthermostat(WindowRec). Oder Fensterkontakt(WindowRec) mit Stellantrieb(WindowRec)+Stellantrieb(WindowRec) mit Wandthermostate(WindowRec)?