Hallo zusammen,
ich hatte nachträglich eine vccu eingerichtet. Nun habe ich noch einige Devices die sich direkt mit den CULs bzw HMLAN unterhalten. Diese sollen aber auch über die vccu laufen. Wie ist es möglich die Peerings umzubiegen, dass sie sauber von der vccu bedient werden ?
Ein Zuordnen des IODEV reicht anscheinend nicht, da auch durch einen Neustart keine IOGrp angelegt wird.
Muss ich die betroffenen Devices alle löschen und neu anlegen lassen ?
Danke für eure Hilfe
ZitatNun habe ich noch einige Devices die sich direkt mit den CULs bzw HMLAN unterhalten. Diese sollen aber auch über die vccu laufen. Wie ist es möglich die Peerings umzubiegen, dass sie sauber von der vccu bedient werden ?
Erkläre dies an einem vorhanden Beispiel deiner configuration
Zitat von: raspklaus am 10 Juli 2016, 17:42:31
Ein Zuordnen des IODEV reicht anscheinend nicht, da auch durch einen Neustart keine IOGrp angelegt wird.
IODEV ist dafür ja auch erst mal irrelevant.
Du musst in deinen Devices die zuordnung zur vccu über IOGrp vornehmen.
Optional unter Angabe eines preferred IO.
Das hat mit peering rein gar nichts zu tun.
Ein (direktes) Peering gibt es nur zwischen Sensoren und Aktoren und nicht mit den IOs.
Was es noch gibt, sind virtuelle Aktoren, bzw. Kanäle mit denen gepeert werden kann.
Die kannst du entweder direkt über CUL_HM definieren, oder aber über die Kanäle der vccu.
Aber auch das hat primär erst mal nichts mit deiner nachträgliIchen vccu Einrichtung zu tun.
Zitat von: Benni am 10 Juli 2016, 18:32:44
Ein (direktes) Peering gibt es nur zwischen Sensoren und Aktoren und nicht mit den IOs.
Das stimmt nicht.
Hier ein Beispiel:
Internals:
CUL_800HM_MSGCNT 2
CUL_800HM_RAWMSG A0CD5844126B50D00000001D500::-63.5:CUL_800HM
CUL_800HM_RSSI -63.5
CUL_800HM_TIME 2016-07-10 18:21:45
DEF 26B50D
HMLAN1_MSGCNT 2
HMLAN1_RAWMSG E26B50D,0000,062AE793,FF,FFAC,D5844126B50D00000001D500
HMLAN1_RSSI -84
HMLAN1_TIME 2016-07-10 18:21:46
IODev CUL_800HM
LASTInputDev hmusb
MSGCNT 6
NAME Garagentor146a_offen
NR 354
NTFY_ORDER 50-Garagentor146a_offen
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 2
hmusb_RAWMSG E26B50D,0000,5D62A84D,FF,FFC6,D5844126B50D00000001D500
hmusb_RSSI -58
hmusb_TIME 2016-07-10 18:21:46
lastMsg No:D5 - t:41 s:26B50D d:000000 01D500
protLastRcv 2016-07-10 18:21:46
rssi_at_CUL_800HM avg:-68 min:-72.5 max:-63.5 lst:-63.5 cnt:2
rssi_at_HMLAN1 avg:-82.5 min:-84 max:-81 lst:-84 cnt:2
rssi_at_hmusb avg:-61 min:-64 max:-58 lst:-58 cnt:2
Readings:
2016-07-10 17:30:46 Activity alive
2015-09-02 21:39:51 D-firmware 2.4
2015-09-02 21:39:51 D-serialNr LEQ0138267
2016-05-22 20:05:12 alive yes
2016-07-10 18:21:45 battery ok
2016-07-10 18:21:45 contact closed (to broadcast)
2016-05-22 20:05:12 powerOn 2016-05-22 20:05:11
2016-05-22 20:05:12 recentStateType info
2016-05-22 20:05:12 sabotageError off
2016-07-10 18:21:45 state closed
2016-07-10 18:21:45 trigger_cnt 213
Helper:
HM_CMDNR 213
mId 00B1
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +26B50D,00,00,00
nextSend 1468167706.15367
prefIO
rxt 2
vccu
p:
26B50D
00
00
Unter IODev ist der CUL, sollte dann doch aber die vccu sein
Zitat von: Benni am 10 Juli 2016, 20:24:12
Ok! Klär mich auf!
Darüber solltest Du mit Deinen Eltern reden :P
Bei mir sind sämtliche Fernbedienungen (deren Channels) direkt mit dem Homematic USB Stick gepeert, das in meinem fhem definiert ist. Das sorgt dafür, dass ich beim Taste-Drücken eine grüne Rückmeldung bekommen und nicht nur eine orange. Was letztendlich mein fhem ausführt, wenn ich eine Fernbedienungstaste drücke, ist ein völlig anderes Thema und wird per notify bzw. Auswertungsfunktion in der 99_myUtils.pm gesteuert. Mit einem Aktor ist keine meiner Fernbedienung direkt verbunden.
Zitat von: betateilchen am 10 Juli 2016, 20:28:09
Bei mir sind sämtliche Fernbedienungen (deren Channels) direkt mit dem Homematic USB Stick gepeert, das in meinem fhem definiert ist.
Mag sein, dass ich bisher alles falsch verstanden habe - aber:
Der USB Stick ist doch Dein IO?
Und peering wie Du es beschreibst läuft doch über einen virtuellen Channel, oder VCCU Channel?
Gruß Otto
Bei mir gibt es keine vccu.
Jedes IO stellt selbst (und automatisch) virtuelle Kanäle bereit, um die man sich als Anwender überhaupt nicht kümmern muss (im Sinne von "man muss sie per CUL_HM definieren"). Insofern habe ich schon ein direktes peering mit meinem IO, denn genau so wird das peering auch hergestellt: direkt mit der HmId des IO ohne Angabe eines channels. Funktioniert seit Jahren völlig streßfrei.
Genau deswegen habe ich den Sinn einer vccu, wenn man nur ein einzelnes echtes IO hat, noch nie verstanden.
Danke für die Erklärung, da hab ich doch wieder was gelernt :D
Schönen Abend
Otto
Zitat von: Otto123 am 10 Juli 2016, 22:52:08
Danke für die Erklärung, da hab ich doch wieder was gelernt :D
Ich auch! Vielen Dank!
Zitat von: betateilchen am 10 Juli 2016, 20:28:09
Darüber solltest Du mit Deinen Eltern reden :P
Das ist übrigens längst erledigt! ;D
Es ist immer wieder nett hier im Forum, dass man eine Frage stellt und dann einige solange über Ihre Meinungsverschiedenheiten diskutieren bis sich niemend mehr an die eigentliche Frage erinnern kann ;D
Deshalb hier meine konkrete Frage:
Ich habe die vccu angelegt:
# Virtuelle HM CCU
define vccu CUL_HM 353143
attr vccu IODev CUL_800HM
attr vccu IOList CUL_800HM,hmusb,HMLAN1
attr vccu model CCU-FHEM
attr vccu room CUL_HM
attr vccu subType virtual
attr vccu webCmd virtual:update
Hoffentlich richtig so ? Die IODevices haben die gleiche HMID
Verschiedene HM Komponenten wurden vorher nur mit dem CUL_800HM gepaired.
Reicht es nun aus die einzelnen Devieces mit den Attributen
IODev vccu
IOGrp vccu:CUL_800HM
zu definieren ? oder reicht die IOgrp aus und man kann IODev löschen ?
Ein Device hat sich bei mir nun schon verabschiedet und ist nicht mehr erreichbar. Muss ich wahrscheinlich neu pairen aber dann mit der vccu, oder ?
Ein list devies der vccu ergibt:
devices using vccu
current IO / preferred
CUL_800HM / CUL_800HM Garagentor_146
CUL_800HM / CUL_800HM Garagentor_146a
CUL_800HM / CUL_800HM Heizung
CUL_800HM / CUL_800HM Wandbild
vccu / CUL_800HM Alarmgong
vccu / CUL_800HM BM_Bewegungsmelder_1
vccu / CUL_800HM Garagentor146_offen
vccu / CUL_800HM Garagentor146a_offen
vccu / CUL_800HM Tueroeffner
vccu / CUL_800HM Vordereingang
vccu / CUL_800HM openDoor
Wenn alle Devices die gleichen Attribute haben verstehe ich diese Auswertung nicht.
IODev nicht löschen aber ignorieren.
Man pairt nicht mit einem IODev sondern mit einer zentrale. Also: gleiche HMID verwenden und alles ist und bleibt gepairt.
lists sind im Übrigen sinnvoller als defines.
Hier das list:
Internals:
CUL_800HM_MSGCNT 98
CUL_800HM_RAWMSG A0F1986102B8DD60000000A24F70C0040::-61.5:CUL_800HM
CUL_800HM_RSSI -61.5
CUL_800HM_TIME 2016-07-11 12:59:10
DEF 353143
HMLAN1_MSGCNT 37
HMLAN1_RAWMSG E2B8DD6,0000,00261F1A,FF,FFDE,1986102B8DD60000000A24F70C0040
HMLAN1_RSSI -34
HMLAN1_TIME 2016-07-11 12:59:10
IODev CUL_800HM
LASTInputDev hmusb
MSGCNT 249
NAME vccu
NR 72
NTFY_ORDER 50-vccu
STATE CUL_800HM:ok,hmusb:ok,HMLAN1:ok,
TYPE CUL_HM
assignedIOs CUL_800HM,HMLAN1,hmusb
hmusb_MSGCNT 114
hmusb_RAWMSG E2B8DD6,0000,6161A97D,FF,FFC0,1986102B8DD60000000A24F70C0040
hmusb_RSSI -64
hmusb_TIME 2016-07-11 12:59:10
lastMsg No:06 - t:02 s:353143 d:1DD868 00
protLastRcv 2016-07-11 12:25:46
rssi_at_CUL_800HM avg:-74.5 min:-74.5 max:-74.5 lst:-74.5 cnt:1
rssi_at_HMLAN1 avg:-74.4 min:-75 max:-74 lst:-74 cnt:5
rssi_at_hmusb avg:-70 min:-70 max:-70 lst:-70 cnt:1
Readings:
2016-07-11 12:25:46 CommandAccepted yes
2016-07-02 05:45:46 recentStateType ack
2016-07-11 12:18:28 state CUL_800HM:ok,hmusb:ok,HMLAN1:ok,
2015-11-18 17:13:00 unknown_091BA9 received
2015-12-18 17:14:48 unknown_157B39 received
2015-12-01 15:27:01 unknown_218339 received
2015-09-27 10:57:57 unknown_23F885 received
2015-09-20 11:02:51 unknown_24F44A received
2016-06-29 04:05:04 unknown_2539FB received
2015-11-07 16:32:27 unknown_27813A received
2016-06-14 17:13:50 unknown_293B79 received
2015-10-09 15:12:29 unknown_293BF9 received
2016-04-11 10:23:13 unknown_297331 received
2015-12-03 18:07:04 unknown_297B19 received
2016-07-10 07:56:07 unknown_297B39 received
2015-11-19 17:53:56 unknown_297B79 received
2015-12-15 00:44:13 unknown_29BE0D received
2015-11-11 11:18:45 unknown_29FBB9 received
2015-12-08 09:05:35 unknown_29FBBB received
2016-07-11 12:59:10 unknown_2B8DD6 received
2016-07-11 12:58:56 unknown_2BBE0D received
2015-09-29 20:44:49 unknown_2BBF0C received
2015-10-03 12:00:51 unknown_2C9918 received
2016-02-12 00:18:18 unknown_2D7739 received
2016-07-11 11:46:01 unknown_2DD611 received
2016-05-28 14:36:33 unknown_2E190B received
2016-05-23 04:02:34 unknown_2E1974 received
2015-09-20 11:33:42 unknown_2E198B received
2015-09-29 19:42:00 unknown_2EC25A received
2016-07-09 23:19:36 unknown_2F02C2 received
2015-11-15 16:51:26 unknown_3051D6 received
2015-10-10 20:08:14 unknown_3071B2 received
2016-07-11 12:58:20 unknown_3071B6 received
2016-04-19 16:42:37 unknown_3116EE received
2016-07-11 12:59:01 unknown_3133D2 received
2016-07-11 12:58:48 unknown_31340C received
2016-07-11 12:57:05 unknown_31377A received
2016-03-31 09:32:19 unknown_3137FE received
2016-04-27 15:20:38 unknown_313BFC received
2016-07-11 12:39:56 unknown_3141C0 received
2015-11-16 09:59:32 unknown_31C140 received
2016-07-11 12:58:46 unknown_31DAA5 received
2015-12-12 20:04:46 unknown_322DE3 received
2016-05-29 15:28:59 unknown_322F44 received
2016-03-05 13:52:10 unknown_3C9934 received
2016-07-10 09:56:31 unknown_449330 received
2016-02-25 09:01:37 unknown_49FBB9 received
2016-02-11 16:49:17 unknown_6522E1 received
2015-10-06 22:13:56 unknown_69B93B received
2016-07-11 12:18:15 unknown_999999 received
2016-07-02 15:10:38 unknown_A97AB8 received
2016-07-11 12:18:45 unknown_F10000 received
Helper:
HM_CMDNR 6
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 0
tpl 0
Io:
nextSend 1468232746.676
prefIO
vccu
ioList:
CUL_800HM
hmusb
HMLAN1
Mrssi:
mNo 06
Io:
HMLAN1 -74
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Also reicht dann die Angabe der beiden Attribute ?
Sorry, aber Benni hatte doch eigentlich alles gesagt?
Einfach wie hier (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Dynamisches_IO)machen. Beachte besonders diesen Abschnitt (http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU#Setzen_der_IOgrp_auf_.28fast.29_allen_Devices_mit_einem_einzigen_Befehl)
Und Du hast in der Einleitung von peerings gesprochen, das hat glaube ich alle verwirrt - Du meintest pairing?
Gruß Otto
Zitat von: raspklaus am 11 Juli 2016, 13:00:56
Also reicht dann die Angabe der beiden Attribute ?
Nein, eines Attributes IOGrp
ZitatEin Device hat sich bei mir nun schon verabschiedet und ist nicht mehr erreichbar.
Was genau meinst Du damit?
Der Fensterkontakt zur Anzeige ob das Garagentor offen ist reagiert nicht mehr
dein list des Garagentores ist nicht vollständig
und außerdem so wie es aussieht nicht gepairt,
da er nach broadcast sendet oder hat.
es fehlen die attr , die hast du nicht reinkopiert!
genauso bei der vccu, da ist das list auch unvollständig.
Das list vom der vccu:
Internals:
CUL_800HM_MSGCNT 298
CUL_800HM_RAWMSG A0C4C865A3071B600000088FA3A::-95.5:CUL_800HM
CUL_800HM_RSSI -95.5
CUL_800HM_TIME 2016-07-11 14:24:25
DEF 353143
HMLAN1_MSGCNT 87
HMLAN1_RAWMSG E2B8DD6,0000,0072D11E,FF,FFDE,3A86102B8DD60000000A24F70C0040
HMLAN1_RSSI -34
HMLAN1_TIME 2016-07-11 14:22:56
IODev CUL_800HM
LASTInputDev hmusb
MSGCNT 735
NAME vccu
NR 72
NTFY_ORDER 50-vccu
STATE CUL_800HM:ok,hmusb:ok,HMLAN1:ok,
TYPE CUL_HM
assignedIOs CUL_800HM,HMLAN1,hmusb
hmusb_MSGCNT 350
hmusb_RAWMSG E3071B6,0000,61AFB253,FF,FFA2,4C865A3071B600000088FA3A
hmusb_RSSI -94
hmusb_TIME 2016-07-11 14:24:25
lastMsg No:87 - t:02 s:353143 d:2A82AF 00
protLastRcv 2016-07-11 14:17:16
rssi_at_CUL_800HM avg:-74.25 min:-74.5 max:-74 lst:-74 cnt:2
rssi_at_HMLAN1 avg:-74.33 min:-75 max:-74 lst:-75 cnt:9
rssi_at_hmusb avg:-70 min:-70 max:-70 lst:-70 cnt:2
Readings:
2016-07-11 14:17:16 CommandAccepted yes
2016-07-02 05:45:46 recentStateType ack
2016-07-11 14:08:13 state CUL_800HM:ok,hmusb:ok,HMLAN1:ok,
2015-11-18 17:13:00 unknown_091BA9 received
2015-12-18 17:14:48 unknown_157B39 received
2015-12-01 15:27:01 unknown_218339 received
2015-09-27 10:57:57 unknown_23F885 received
2015-09-20 11:02:51 unknown_24F44A received
2016-06-29 04:05:04 unknown_2539FB received
2015-11-07 16:32:27 unknown_27813A received
2016-06-14 17:13:50 unknown_293B79 received
2015-10-09 15:12:29 unknown_293BF9 received
2016-04-11 10:23:13 unknown_297331 received
2015-12-03 18:07:04 unknown_297B19 received
2016-07-10 07:56:07 unknown_297B39 received
2015-11-19 17:53:56 unknown_297B79 received
2015-12-15 00:44:13 unknown_29BE0D received
2015-11-11 11:18:45 unknown_29FBB9 received
2015-12-08 09:05:35 unknown_29FBBB received
2016-07-11 14:22:56 unknown_2B8DD6 received
2016-07-11 14:24:04 unknown_2BBE0D received
2015-09-29 20:44:49 unknown_2BBF0C received
2015-10-03 12:00:51 unknown_2C9918 received
2016-02-12 00:18:18 unknown_2D7739 received
2016-07-11 14:23:17 unknown_2DD611 received
2016-05-28 14:36:33 unknown_2E190B received
2016-05-23 04:02:34 unknown_2E1974 received
2015-09-20 11:33:42 unknown_2E198B received
2015-09-29 19:42:00 unknown_2EC25A received
2016-07-09 23:19:36 unknown_2F02C2 received
2015-11-15 16:51:26 unknown_3051D6 received
2015-10-10 20:08:14 unknown_3071B2 received
2016-07-11 14:24:25 unknown_3071B6 received
2016-04-19 16:42:37 unknown_3116EE received
2016-07-11 14:23:24 unknown_3133D2 received
2016-07-11 14:21:48 unknown_31340C received
2016-07-11 14:22:53 unknown_31377A received
2016-03-31 09:32:19 unknown_3137FE received
2016-04-27 15:20:38 unknown_313BFC received
2016-07-11 14:23:52 unknown_3141C0 received
2015-11-16 09:59:32 unknown_31C140 received
2016-07-11 14:21:49 unknown_31DAA5 received
2015-12-12 20:04:46 unknown_322DE3 received
2016-05-29 15:28:59 unknown_322F44 received
2016-03-05 13:52:10 unknown_3C9934 received
2016-07-10 09:56:31 unknown_449330 received
2016-02-25 09:01:37 unknown_49FBB9 received
2016-02-11 16:49:17 unknown_6522E1 received
2015-10-06 22:13:56 unknown_69B93B received
2016-07-11 12:18:15 unknown_999999 received
2016-07-02 15:10:38 unknown_A97AB8 received
2016-07-11 12:18:45 unknown_F10000 received
Helper:
HM_CMDNR 135
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 0
tpl 0
Io:
nextSend 1468239436.9563
prefIO
vccu
ioList:
CUL_800HM
hmusb
HMLAN1
Mrssi:
mNo 87
Io:
HMLAN1 -75
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Rssi:
At_cul_800hm:
avg -74.25
cnt 2
lst -74
max -74
min -74.5
At_hmlan1:
avg -74.3333333333333
cnt 9
lst -75
max -74
min -75
At_hmusb:
avg -70
cnt 2
lst -70
max -70
min -70
Tmpl:
Attributes:
IODev CUL_800HM
IOList CUL_800HM,hmusb,HMLAN1
model CCU-FHEM
room CUL_HM
subType virtual
webCmd virtual:update
sorry war anscheinend abgeschnitten. Beim Garagentor waren die Attribute zu dem Zeitpunkt natürlich noch nicht drin, da das ja erst später geklärt wurde.
Aber genau das Garagentor ist nun das Problem. Es hat sich verabschiedet.
Muss ich es nun komplett in FHEM löschen und neu pairen oder reicht es mit den vorhandenen Daten ein neues Pairing anzuwerfen ?
Löschen ist nicht nötig. Einfach pairen.
die vccu sieht in Orndung aus.
rssi_at_CUL_800HM avg:-68 min:-72.5 max:-63.5 lst:-63.5 cnt:2
rssi_at_HMLAN1 avg:-82.5 min:-84 max:-81 lst:-84 cnt:2
rssi_at_hmusb avg:-61 min:-64 max:-58 lst:-58 cnt:2
Readings:
2016-07-10 17:30:46 Activity alive
2015-09-02 21:39:51 D-firmware 2.4
2015-09-02 21:39:51 D-serialNr LEQ0138267
2016-05-22 20:05:12 alive yes
2016-07-10 18:21:45 battery ok
2016-07-10 18:21:45 contact closed (to broadcast)
2016-05-22 20:05:12 powerOn 2016-05-22 20:05:11
2016-05-22 20:05:12 recentStateType info
2016-05-22 20:05:12 sabotageError off
2016-07-10 18:21:45 state closed schau doch mal hier das an, vorallem das datum
Zitat2016-05-22 20:05:12 powerOn 2016-05-22 20:05:11
2016-05-22 20:05:12 alive yes
2016-07-10 18:21:45 contact closed (to broadcast)
drüberpairen,
set vccu hmPairForSec 600 und dann knöpfchen drücken, wie man das eben so macht, getConfig und wieder knöpfchen drücken
Das mit dem Datum dürfte nichts zu sagen haben, denn solange ist der garantiert schon am Netz. Er hat ja auch noch gestern abend richtig angezeigt.
Zitat von: raspklaus am 11 Juli 2016, 14:45:35
Das mit dem Datum dürfte nichts zu sagen haben, denn solange ist der garantiert schon am Netz. Er hat ja auch noch gestern abend richtig angezeigt.
Das er gestern noch angezeigt hat, hat auch nichts zu sagen. Empfangen kann man offenbar ohne vollständiges pairing (FHEm hat ein Device angelegt) aber steuern kann man nicht ohne komplettes pairing. Das liest man relativ oft hier im Forum.
So, hier nochmal das neue Listing des Garagentors:
Internals:
CUL_800HM_MSGCNT 23
CUL_800HM_RAWMSG A0C09A64126B50D353143010900::-60:CUL_800HM
CUL_800HM_RSSI -60
CUL_800HM_TIME 2016-07-11 19:50:03
DEF 26B50D
HMLAN1_MSGCNT 21
HMLAN1_RAWMSG E26B50D,0000,019E5A01,FF,FFA9,09A64126B50D353143010900
HMLAN1_RSSI -87
HMLAN1_TIME 2016-07-11 19:50:03
IODev CUL_800HM
LASTInputDev hmusb
MSGCNT 67
NAME Garagentor146a_offen
NR 354
NTFY_ORDER 50-Garagentor146a_offen
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 23
hmusb_RAWMSG E26B50D,0000,62D9D405,FF,FFC8,09A64126B50D353143010900
hmusb_RSSI -56
hmusb_TIME 2016-07-11 19:50:03
lastMsg No:09 - t:41 s:26B50D d:353143 010900
protLastRcv 2016-07-11 19:50:03
protResnd 1 last_at:2016-07-11 17:06:51
protSnd 21 last_at:2016-07-11 19:50:03
protState CMDs_done
rssi_at_CUL_800HM avg:-61.45 min:-68 max:-56.5 lst:-60 cnt:23
rssi_at_HMLAN1 avg:-84.33 min:-99 max:-77 lst:-87 cnt:21
rssi_at_hmusb avg:-63.69 min:-83 max:-56 lst:-56 cnt:23
Readings:
2016-07-11 17:08:55 Activity alive
2016-07-11 17:08:36 CommandAccepted yes
2016-07-11 17:08:55 D-firmware 2.4
2016-07-11 17:08:55 D-serialNr LEQ0138267
2016-07-11 17:08:55 PairedTo 0x353143
2016-07-11 17:08:55 R-cyclicInfoMsg off
2016-07-11 17:08:55 R-eventDlyTime 0 s
2016-07-11 17:08:55 R-pairCentral 0x353143
2016-07-11 17:08:55 R-sabotageMsg on
2016-07-11 17:08:55 R-sign off
2016-07-11 17:08:55 RegL_00. 02:01 09:00 0A:35 0B:31 0C:43 10:01 14:06 00:00
2016-07-11 17:08:55 RegL_01. 08:00 20:60 21:00 22:64 30:06 00:00
2016-07-11 17:11:22 alive yes
2016-07-11 19:50:03 battery ok
2016-07-11 19:50:03 contact closed (to vccu)
2016-07-11 17:11:22 powerOn 2016-07-11 17:11:22
2016-07-11 17:11:22 recentStateType info
2016-07-11 17:11:22 sabotageError off
2016-07-11 19:50:03 state closed
2016-07-11 19:50:03 trigDst_vccu noConfig
2016-07-11 19:50:03 trigger_cnt 9
Helper:
HM_CMDNR 9
PONtest 0
cSnd 0135314326B50D01040000000001,0135314326B50D0103
mId 00B1
peerIDsRaw ,00000000
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +26B50D,00,00,00
nextSend 1468259404.09337
rxt 2
vccu vccu
p:
26B50D
00
00
00
prefIO:
CUL_800HM
Mrssi:
mNo 09
Io:
CUL_800HM -58
HMLAN1 -87
hmusb -56
Prt:
bErr 0
sProc 0
sleeping 1
try 1
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL_800HM
flg A
ts 1468259403.83446
ack:
HASH(0x2dda0a0)
09800235314326B50D0101C800
Rssi:
At_cul_800hm:
avg -61.4565217391304
cnt 23
lst -60
max -56.5
min -68
At_hmlan1:
avg -84.3333333333333
cnt 21
lst -87
max -77
min -99
At_hmusb:
avg -63.695652173913
cnt 23
lst -56
max -56
min -83
Shadowreg:
Tmpl:
Attributes:
IODev CUL_800HM
IOgrp vccu:CUL_800HM
actCycle 028:00
actStatus alive
alias Garagentor 146a offen
autoReadReg 4_reqStatus
devStateIcon closed:FS20.off open:FS20roton
event-on-change-reading state,battery
expert 2_full
firmware 2.4
group Garage
model HM-SEC-SC-2
peerIDs 00000000,
room Garage,Sicherheit
serialNr LEQ0138267
subType threeStateSensor
an was erkenne ich denn nun ob es jetzt richtig gepaired ist ?
2016-07-11 17:08:55 PairedTo 0x353143
2016-07-11 17:08:55 R-pairCentral 0x353143
2016-07-11 19:50:03 contact closed (to vccu)
lastMsg No:09 - t:41 s:26B50D d:353143 010900 das sieht doch jetzt gut aus, zu deiner Frage woran erkennt man es
Ich persönlich sehe es noch an der last Message.
ABER wenn du dein Garagentor jetzt 1,5 Tage nicht aufmachst , wird Fhem festellen dass dein Sensor dead ist, im Actiondetector.
da du -->
Zitat2016-07-11 17:08:55 R-cyclicInfoMsg off
nicht aktiviert hast :)
und wie aktiviere ich das ?
So wie es im Wiki beschrieben ist.
http://www.fhemwiki.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt#Hinweise_zum_Betrieb_mit_FHEM (http://www.fhemwiki.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt#Hinweise_zum_Betrieb_mit_FHEM)
Ja, hatte ich auch schon gefunden. Was da allerdings nicht erklärt wird ob man den Anlernknopf kurz oder wie beim normalen Anlernen 4 sec drücken muss
Man braucht die Taste doch sowieso nur kurz zu drücken (auch zum anlernen), außer zum zurücksetzen des Fensterkontaktes die Taste mindestens 5 Sek. gedrückt halten.
Zitat von: raspklaus am 13 Juli 2016, 10:23:47
Ja, hatte ich auch schon gefunden. Was da allerdings nicht erklärt wird ob man den Anlernknopf kurz oder wie beim normalen Anlernen 4 sec drücken muss
unglaublich. :)
tipp: falls du deine bedienungsanleitung "entsorgt" hast, kannst du sie auch downloaden. zb bei eq3.
Hallo Frank,
kann ich auch die von elv nehmen ? ;D
Zitat von: raspklaus am 13 Juli 2016, 14:26:02
Hallo Frank,
kann ich auch die von elv nehmen ? ;D
aber lass dich nicht erwischen. 8)