Hallo zusammen,
ich bitte um Hilfe bei meinem HM optischen Türkontakt. Er ist sauber in FHEM eingebunden und tut eigentlich was er soll. Leider bekomme ich aufgrund der zyklischen Statusmeldungen ca. alle Stunde die Telegram Meldung, die Kellertür sei geschlossen. Kann ich das im DOIF oder in den Attributen des Kontakts ändern? Anbei das device listing:
Internals:
CUL_0_MSGCNT 127
CUL_0_RAWMSG A0D0E861069767B00000006010000::-83.5:CUL_0
CUL_0_RSSI -83.5
CUL_0_TIME 2019-06-14 17:35:15
DEF 69767B
FUUID 5ce16aea-f33f-de77-ccab-21fd3bda6d8a3f42
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 127
NAME Keller_Tuerkontakt
NOTIFYDEV global
NR 119
NTFY_ORDER 50-Keller_Tuerkontakt
STATE
TYPE CUL_HM
chanNo 01
lastMsg No:0E - t:10 s:69767B d:000000 06010000
protCmdDel 18
protLastRcv 2019-06-14 17:35:15
protRcv 127 last_at:2019-06-14 17:35:15
protResnd 9 last_at:2019-06-12 20:10:33
protResndFail 3 last_at:2019-06-12 21:03:35
protSnd 12 last_at:2019-06-12 21:03:30
protState CMDs_done_Errors:1
rssi_at_CUL_0 cnt:127 min:-87.5 max:-70 avg:-76.91 lst:-83.5
READINGS:
2019-06-11 19:14:08 Activity alive
2019-05-19 16:41:08 D-firmware 1.0
2019-05-19 16:41:08 D-serialNr PEQ0579907
2019-06-11 18:36:39 R-cyclicInfoMsg set_off
2019-05-19 16:40:43 R-pairCentral set_0x001975
2019-05-19 16:41:08 aesKeyNbr 00
2019-06-14 17:35:15 alive yes
2019-06-14 17:35:15 battery ok
2019-06-14 17:35:15 contact closed (to broadcast)
2019-05-19 16:43:00 powerOn 2019-05-19 16:43:00
2019-06-14 17:35:15 recentStateType info
2019-06-14 17:35:15 sabotageError off
2019-06-14 17:35:15 state closed
2019-06-14 15:01:10 trigDst_broadcast noConfig
2019-06-14 15:01:10 trigger_cnt 110
helper:
HM_CMDNR 14
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +69767B,00,00,00
nextSend 1560526515.1603
rxt 2
vccu VCCU
p:
69767B
00
00
00
prefIO:
CUL_0
mRssi:
mNo 0E
io:
CUL_0:
-81.5
-81.5
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_0:
avg -76.9133858267716
cnt 127
lst -83.5
max -70
min -87.5
shadowReg:
RegL_00. 09:00
tmpl:
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
actCycle 001:15
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_door_open@red closed:fts_door@green
expert 2_raw
firmware 1.0
model HM-SEC-SCO
room 60_Keller
serialNr PEQ0579907
stateFormat {if (ReadingsVal("Sensor","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Sensor","contact","")} else {InternalVal("Sensor","STATE","")}}
subType threeStateSensor
Ich habe in einem Beitrag gelesen man könne die zyklischen Meldungen mit
set Keller_Tuerkontakt regSet cyclicInfoMsg off
abschalten. Hab ich ausgeführt, allerdings bekomme ich die Meldungen immer noch.
Hier mein DOIF zur State-Änderung:
([Keller_Tuerkontakt:state] eq "open") (set teleBot msg @XXX @XXX Kellertür wurde geöffnet!) DOELSEIF ([Keller_Tuerkontakt:state] eq "closed") (set teleBot msg @XXX @XXX Kellertür wurde geschlossen!!)
Der erste Teil wird nur versendet wenn state == open, aber der DOELSEIF wird jede Stunde bei der zyklischen Meldung ausgeführt. Hilft mir bitte jemand mein Brett vorm Kopf loszuwerden? Ich habe noch nicht soooo viel mit FHEM umgesetzt. Bin über jeden Hinweis von Euch dankbar!
Greetz
d00my
Er ist (noch) NICHT sauber eingebunden:
Zitat
2019-05-19 16:40:43 R-pairCentral set_0x001975
Du musst die Config-Taste drücken (OHNE auszulösen!) bis das set_ weg ist!
Bzw. da es beim Übertragen wohl Fehler gegeben hat noch mal ein getConfig auslösen und dann Config-Taster drücken...
...bis cmds_pending weg ist und das set_
Für die häufigen Meldungen gibt es 2 Möglichkeiten:
cyclicMessage abschalten: dann sendet der Kontakt nicht mehr zyklisch (schlecht, weil damit auch eine leere Batterie evtl. nicht [rechtzeitig] erkannt wird)
EDIT: ja hast du versucht. ABER: solange das set_ nicht weg ist, der Sensor also noch NICHT (vollständig) GEPAIRED ist, nimmt er keine Befehle an. Und dann eben nur von "seiner" Zentrale und die wird gekennzeichnet durch die HMID (die sollte dann eben statt dem set_ alleine dort stehen, damit ist die Verbindung vollständig: Befehle werden akzeptiert)
oder event-on-change-reading setzen, dann gibt es nur noch Events bei Änderung...
Gruß, Joachim
ausserdem ein besseres reading nutzen => contact.
Und wenn das wirklich heißt du hast einen CUL
Zitat
IODev CUL_0
Dann überlegen auf einen vernünftigen HomeMatic-IO zu wechseln!
(evtl. mal im Forum nach CUL und HomeMatic und Problemen suchen: Timeout Register Read z.B.)
Falls das mit dem Pairing nicht sauber funktioniert: dann kann das der Grund sein...
(Notlösung: Timing-FW für den CUL)
Gruß, Joachim
Wow!
Erst einmal recht herzlichen Dank Euch beiden für die schnellen Antworten! Ich werde Eure Hinweise umsetzen und mich im Anschluss noch einmal melden.
Danke nochmal und schönen Abend!
Greetz
d00my
Zitat von: d00my am 14 Juni 2019, 19:44:52
Wow!
Erst einmal recht herzlichen Dank Euch beiden für die schnellen Antworten! Ich werde Eure Hinweise umsetzen und mich im Anschluss noch einmal melden.
Danke nochmal und schönen Abend!
Greetz
d00my
Gerne.
Wer "anständig" frägt und brauchbare Infos liefert, der wird auch umgehend geholfen (versucht)... ;)
Viel Erfolg, Joachim
;D Ich freu mich grad wie ein Schnitzel ;D
Vielen Dank! Beim ersten Betätigen der Config-Taste endete es in einer roten LED, das zweite Mal hat funktioniert!
Output aktuelles Listing:
Internals:
CHANGED
CUL_0_MSGCNT 139
CUL_0_RAWMSG A0D68861069767B00000006010000::-85:CUL_0
CUL_0_RSSI -85
CUL_0_TIME 2019-06-14 20:25:34
DEF 69767B
FUUID 5ce16aea-f33f-de77-ccab-21fd3bda6d8a3f42
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 139
NAME Keller_Tuerkontakt
NOTIFYDEV global
NR 119
NTFY_ORDER 50-Keller_Tuerkontakt
STATE
TYPE CUL_HM
chanNo 01
lastMsg No:68 - t:10 s:69767B d:000000 06010000
protCmdDel 18
protCmdPend 8 CMDs pending
protLastRcv 2019-06-14 20:25:34
protRcv 139 last_at:2019-06-14 20:25:34
protResnd 13 last_at:2019-06-14 20:25:38
protResndFail 3 last_at:2019-06-12 21:03:35
protSnd 24 last_at:2019-06-14 20:25:34
protState CMDs_pending
rssi_at_CUL_0 cnt:139 min:-91 max:-70 avg:-77.54 lst:-85
READINGS:
2019-06-14 20:01:05 Activity alive
2019-06-14 20:01:05 D-firmware 1.0
2019-06-14 20:01:05 D-serialNr PEQ0579907
2019-06-14 20:01:06 PairedTo 0x000000
2019-06-14 20:00:58 R-cyclicInfoMsg on
2019-06-14 20:00:58 R-eventDlyTime 0 s
2019-06-14 20:00:58 R-pairCentral 0x000000
2019-06-14 20:00:58 R-sabotageMsg on
2019-06-14 20:00:58 R-sign on
2019-05-19 16:41:08 aesKeyNbr 00
2019-06-14 20:25:34 alive yes
2019-06-14 20:25:34 battery ok
2019-06-14 20:25:34 contact closed (to broadcast)
2019-05-19 16:43:00 powerOn 2019-05-19 16:43:00
2019-06-14 20:25:34 recentStateType info
2019-06-14 20:25:34 sabotageError off
2019-06-14 20:25:34 state closed
2019-06-14 15:01:10 trigDst_broadcast noConfig
2019-06-14 20:21:35 trigger_cnt 112
cmdStack:
++A00100197569767B01040000000001
++A00100197569767B0103
++A00100197569767B00040000000000
++A00100197569767B01040000000001
++A00100197569767B0103
++A00100197569767B00040000000000
++A00100197569767B01040000000001
++A00100197569767B0103
helper:
HM_CMDNR 105
cSnd 0100197569767B00040000000000,0100197569767B01040000000001
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +69767B,02,00,00
nextSend 1560536734.13297
rxt 2
vccu VCCU
p:
69767B
00
00
00
prefIO:
CUL_0
mRssi:
mNo 68
io:
CUL_0:
-83
-83
prt:
bErr 0
sProc 2
wuReSent 3
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_CUL_0:
avg -77.5431654676259
cnt 139
lst -85
max -70
min -91
shadowReg:
tmpl:
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
actCycle 001:15
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_door_open@red closed:fts_door@green
event-on-change-reading state
expert 2_raw
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000,
room 60_Keller
serialNr PEQ0579907
stateFormat {if (ReadingsVal("Sensor","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Sensor","contact","")} else {InternalVal("Sensor","STATE","")}}
subType threeStateSensorErgo --> jetzt ist der Sensor sauber eingebunden. Und die Telegram Meldung bekomme ich wirklich nur noch bei der Änderung von closed auf open und umgekehrt. Weil ich immer die Kellertür offen stehen lasse schicke ich mir täglich um 20:30 den aktuellen state per Telegram zusätzlich.
Zitat von: frank am 14 Juni 2019, 19:02:01
ausserdem ein besseres reading nutzen => contact.
Wie erkenne ich als Noob am besten, welches Reading das bessere oder schlechtere ist? Gibt es da einen "roten Faden"?
Vielen Dank nochmal!
Greetz
d00my
Ich weiß nicht wie aktuell das list ist aber es ist immer noch nicht richtig GEPAIRED!
Zitat
2019-06-14 20:01:06 PairedTo 0x000000
2019-06-14 20:00:58 R-pairCentral 0x000000
Da sollte/muss statt der 000000 die HMID stehen (Attribut hmid beim CUL)!
(aber nicht einfach dort versuchen einzutragen sondern noch mal PAIREN. Das was hier steht, auch bei Peerlist etc. ist nur die "Anzeige" wichtig ist was in den Registern der Geräte steht wo eben auch die Kennung der Zentrale [HMID] hinterlegt ist, also IM Gerät)
Somit scheint er zwar zu funktionieren, da die Funktelegramme empfangen und zugeordnet werden aber wenn du die PEEREN (direkte Verbindung zu einem Aktor, beispielsweise WT oder HT wegen Fenster auf) willst (oder Register setzen) wird das NICHT funktionieren!
Also noch mal anlernen!
Aber nicht wild löschen, resetten etc.
Einfach nur set CUL_0 pairForSec 600 und dann eben den Anlernknopf drücken...
(evtl. ist dir beim letzten Drücken ein Reset "gelungen" ;) )
Anfragen per PM eher mal lassen, da geht viel Information verloren (und ich kuck da auch nicht so oft rein)... ;)
Besseres HM-IO: HMOD-PCB z.B.: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
(geht auch per USB, LAN, WLAN, ... steht aber auch im Wiki)
Im Homematic Wiki stehen aber weitere...
...aber für einen PI ist das sehr gut! Und echt günstig: ca. 20EUR...
Du kannst aber auch mit dem CUL weitermachen, ich würde allerings bei (weiteren) Problemen v.a. sowas wie Timeout Register Read etc. umsteigen...
...falls du jetzt noch nicht willst...
(ich würde da nicht lang rum tun sondern umsteigen: geht schneller macht weniger Ärger als lang rumtun)
Wenn wir schon dabei sind: ich würde auch das Anlegen einer vccu empfehlen! https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Bzgl. "besseres Reading" ist schwer zu beantworten. Am besten mal den EventMonitor öffnen und schauen was bei den Aktionen so kommt und dann bei mehreren Versuchen schauen was am besten passt... Bei state ist es halt bzgl. Events oft nicht so eindeutig und v.a. es hat manchmal auch andere Zustände: z.B. Fehler etc.
Viel Erfolg noch, Joachim
Hallo Jürgen!
Du hattest Recht: der Kontakt war *NICHT* korrekt eingebunden.
Ich bin nun folgendermaßen vorgegangen:
1. set CUL_0 hmPairForceSec 600
2. Config Taste am Türkontakt gedrückt
--> Türkontakt steht weiterhin auf R-pairCentral 0x000000
Habe ich mehrfach versucht - leider hat es nichts gebracht.
Ich habe das Device gelöscht und im Anschluss
1. durchgeführt
2. durchgeführt
Aktuelles Listing nun:
Internals:
CFGFN
CUL_0_MSGCNT 18
CUL_0_RAWMSG A0C7FA64169767B001975017600::-74:CUL_0
CUL_0_RSSI -74
CUL_0_TIME 2019-06-15 11:27:57
DEF 69767B
FUUID 5d04b6b5-f33f-de77-145a-9e5fdf1bbd3257d6
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 18
NAME Keller_Tuerkontakt
NOTIFYDEV global
NR 152
STATE closed
TYPE CUL_HM
chanNo 01
lastMsg No:7F - t:41 s:69767B d:001975 017600
protLastRcv 2019-06-15 11:27:57
protRcv 19 last_at:2019-06-15 11:27:57
protSnd 24 last_at:2019-06-15 11:27:57
protState CMDs_done
rssi_at_CUL_0 cnt:19 min:-94.5 max:-73.5 avg:-81.28 lst:-74
READINGS:
2019-06-15 11:17:31 Activity alive
2019-06-15 11:17:00 CommandAccepted yes
2019-06-15 11:17:31 D-firmware 1.0
2019-06-15 11:17:31 D-serialNr PEQ0579907
2019-06-15 11:17:32 PairedTo 0x001975
2019-06-15 11:17:32 R-cyclicInfoMsg on
2019-06-15 11:17:32 R-eventDlyTime 0 s
2019-06-15 11:17:32 R-pairCentral 0x001975
2019-06-15 11:17:32 R-sabotageMsg on
2019-06-15 11:17:32 R-sign on
2019-06-15 11:17:32 RegL_00. 00:00 02:01 09:01 0A:00 0B:19 0C:75 10:01 14:06
2019-06-15 11:17:32 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2019-06-15 11:17:00 aesCommToDev ok
2019-06-15 11:17:00 aesKeyNbr 00
2019-06-15 11:27:57 battery ok
2019-06-15 11:27:57 contact closed (to VCCU)
2019-06-15 11:27:57 state closed
2019-06-15 11:27:57 trigger_cnt 118
helper:
HM_CMDNR 127
cSnd 0100197569767B01040000000001,0100197569767B0103
mId 00C7
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +69767B,00,00,00
nextSend 1560590877.31447
prefIO
rxt 2
vccu
p:
69767B
00
00
00
mRssi:
mNo 7F
io:
CUL_0:
-72
-72
prt:
bErr 0
sProc 0
sleeping 1
helper:
prt:
rspWait:
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO CUL_0
flg A
ts 1560590877.21537
ack:
HASH(0x42d2a20)
7F800200197569767B00
HASH(0x42d2a20)
7F800200197569767B0101C800
rssi:
at_CUL_0:
avg -81.2894736842105
cnt 19
lst -74
max -73.5
min -94.5
shadowReg:
tmpl:
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
event-on-change-reading contact
expert 2_raw
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000,
room 60_Keller
serialNr PEQ0579907
subType threeStateSensor
Nun steht bei R-pairCentral auch meine korrekte HM ID drin. Mein DOIF habe ich auf das Reading "contact" umgebaut. Somit ist *JETZT* alles gut.
Die PM schrieb ich aufgrund Off-Topic. Ich weiß ehrlich gesagt noch nicht, ob ich dafür besser einen neuen Thread erstellen sollte. Aber auch da hast Du natürlich Recht: vielleicht sind Forenuser unterwegs, mit den gleichen Fragen wie ich!
Eine VCCU ist bei mir angelegt:
Internals:
CUL_0_MSGCNT 46
CUL_0_RAWMSG A0FC586106A1D3C0000000A88DF0E0040::-71.5:CUL_0
CUL_0_RSSI -71.5
CUL_0_TIME 2019-06-15 11:36:43
DEF 001975
FUUID 5c6d758e-f33f-de77-57a5-ca2fb52d2856c0c4
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 46
NAME VCCU
NOTIFYDEV global
NR 21
NTFY_ORDER 50-VCCU
STATE CUL_0:ok
TYPE CUL_HM
assignedIOs CUL_0
channel_01 VCCU_Btn1
READINGS:
2019-06-15 11:09:05 IOopen 1
2019-06-15 11:09:05 state CUL_0:ok
2019-06-15 11:36:34 unknown_5B0C70 received
2018-12-26 15:42:20 unknown_5C6711 received
2018-12-26 14:06:45 unknown_67EDF8 received
2019-05-19 16:40:39 unknown_69767B received
2019-06-15 11:36:43 unknown_6A1D3C received
2019-06-15 11:36:13 unknown_6A1D40 received
2019-06-15 07:30:00 unknown_BA4BC3 received
helper:
HM_CMDNR 232
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU1
ioList:
CUL_0
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev CUL_0
IOList CUL_0
IOgrp VCCU1
expert 2_raw
model CCU-FHEM
room 99.3_HM
subType virtual
webCmd virtual:update
Ich werde mich in HM mit FHEM nochmal genauer anlesen.
Danke für die Unterstützung und ein schönes Wochenende!
Greetz
d00my
Zitat von: d00my am 15 Juni 2019, 11:38:18
Hallo Jürgen!
Du hattest Recht: der Kontakt war *NICHT* korrekt eingebunden.
Joachim aber macht nix ;)
Jep, klar :)
Zitat von: d00my am 15 Juni 2019, 11:38:18
Ich bin nun folgendermaßen vorgegangen:
1. set CUL_0 hmPairForceSec 600
2. Config Taste am Türkontakt gedrückt
--> Türkontakt steht weiterhin auf R-pairCentral 0x000000
Habe ich mehrfach versucht - leider hat es nichts gebracht.
Ich habe das Device gelöscht und im Anschluss
1. durchgeführt
2. durchgeführt
Aktuelles Listing nun:
Internals:
CFGFN
CUL_0_MSGCNT 18
CUL_0_RAWMSG A0C7FA64169767B001975017600::-74:CUL_0
CUL_0_RSSI -74
CUL_0_TIME 2019-06-15 11:27:57
DEF 69767B
FUUID 5d04b6b5-f33f-de77-145a-9e5fdf1bbd3257d6
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 18
NAME Keller_Tuerkontakt
NOTIFYDEV global
NR 152
STATE closed
TYPE CUL_HM
chanNo 01
lastMsg No:7F - t:41 s:69767B d:001975 017600
protLastRcv 2019-06-15 11:27:57
protRcv 19 last_at:2019-06-15 11:27:57
protSnd 24 last_at:2019-06-15 11:27:57
protState CMDs_done
rssi_at_CUL_0 cnt:19 min:-94.5 max:-73.5 avg:-81.28 lst:-74
READINGS:
2019-06-15 11:17:31 Activity alive
2019-06-15 11:17:00 CommandAccepted yes
2019-06-15 11:17:31 D-firmware 1.0
2019-06-15 11:17:31 D-serialNr PEQ0579907
2019-06-15 11:17:32 PairedTo 0x001975
2019-06-15 11:17:32 R-cyclicInfoMsg on
2019-06-15 11:17:32 R-eventDlyTime 0 s
2019-06-15 11:17:32 R-pairCentral 0x001975
2019-06-15 11:17:32 R-sabotageMsg on
2019-06-15 11:17:32 R-sign on
2019-06-15 11:17:32 RegL_00. 00:00 02:01 09:01 0A:00 0B:19 0C:75 10:01 14:06
2019-06-15 11:17:32 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2019-06-15 11:17:00 aesCommToDev ok
2019-06-15 11:17:00 aesKeyNbr 00
2019-06-15 11:27:57 battery ok
2019-06-15 11:27:57 contact closed (to VCCU)
2019-06-15 11:27:57 state closed
2019-06-15 11:27:57 trigger_cnt 118
helper:
HM_CMDNR 127
cSnd 0100197569767B01040000000001,0100197569767B0103
mId 00C7
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +69767B,00,00,00
nextSend 1560590877.31447
prefIO
rxt 2
vccu
p:
69767B
00
00
00
mRssi:
mNo 7F
io:
CUL_0:
-72
-72
prt:
bErr 0
sProc 0
sleeping 1
helper:
prt:
rspWait:
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rpt:
IO CUL_0
flg A
ts 1560590877.21537
ack:
HASH(0x42d2a20)
7F800200197569767B00
HASH(0x42d2a20)
7F800200197569767B0101C800
rssi:
at_CUL_0:
avg -81.2894736842105
cnt 19
lst -74
max -73.5
min -94.5
shadowReg:
tmpl:
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
actCycle 002:50
actStatus alive
autoReadReg 4_reqStatus
event-on-change-reading contact
expert 2_raw
firmware 1.0
model HM-SEC-SCO
peerIDs 00000000,
room 60_Keller
serialNr PEQ0579907
subType threeStateSensor
Nun steht bei R-pairCentral auch meine korrekte HM ID drin. Mein DOIF habe ich auf das Reading "contact" umgebaut. Somit ist *JETZT* alles gut.
Eine VCCU ist bei mir angelegt:
Internals:
CUL_0_MSGCNT 46
CUL_0_RAWMSG A0FC586106A1D3C0000000A88DF0E0040::-71.5:CUL_0
CUL_0_RSSI -71.5
CUL_0_TIME 2019-06-15 11:36:43
DEF 001975
FUUID 5c6d758e-f33f-de77-57a5-ca2fb52d2856c0c4
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 46
NAME VCCU
NOTIFYDEV global
NR 21
NTFY_ORDER 50-VCCU
STATE CUL_0:ok
TYPE CUL_HM
assignedIOs CUL_0
channel_01 VCCU_Btn1
READINGS:
2019-06-15 11:09:05 IOopen 1
2019-06-15 11:09:05 state CUL_0:ok
2019-06-15 11:36:34 unknown_5B0C70 received
2018-12-26 15:42:20 unknown_5C6711 received
2018-12-26 14:06:45 unknown_67EDF8 received
2019-05-19 16:40:39 unknown_69767B received
2019-06-15 11:36:43 unknown_6A1D3C received
2019-06-15 11:36:13 unknown_6A1D40 received
2019-06-15 07:30:00 unknown_BA4BC3 received
helper:
HM_CMDNR 232
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU1
ioList:
CUL_0
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev CUL_0
IOList CUL_0
IOgrp VCCU1
expert 2_raw
model CCU-FHEM
room 99.3_HM
subType virtual
webCmd virtual:update
Bei HomeMatic ist wichtig: Ruhe bewahren, evtl. (bei Batteriegeräten) ab und an mal (ohne Hektik) das "Config-Knöpfchen" drücken...
Viel Löschen und Resetten ist meist eher schlecht...
Aber das hast du ja jetzt raus: prima hingekriegt, list sieht gut aus.
In der vccu stehen einige unknown Geräte: noch neu und noch nicht gepaired? Nachbar? Nur so weil es mir aufgefallen ist...
Aber nachdem du das vor hast:
Zitat von: d00my am 15 Juni 2019, 11:38:18
Ich werde mich in HM mit FHEM nochmal genauer anlesen.
Kannst du ja bei Gelegenheit selber schauen ;)
Zitat von: d00my am 15 Juni 2019, 11:38:18
Die PM schrieb ich aufgrund Off-Topic. Ich weiß ehrlich gesagt noch nicht, ob ich dafür besser einen neuen Thread erstellen sollte. Aber auch da hast Du natürlich Recht: vielleicht sind Forenuser unterwegs, mit den gleichen Fragen wie ich!
Nicht schlimm ;)
Da es dein Thread ist, kannst du nat. auch "off-topic" zum (neuen) Topic machen ;)
Schlimmstenfalls lesen halt nur die bereits beteiligten (also in dem Fall nur ich) noch mit...
...wenn dir die Gruppe auch bei dem "off-Topic" (neuen Topic) helfen kann: dann passt es.
Wenn nicht: besser neuer Thread. Weil: neuer Titel der nat. besser passt und "neues Publikum" was evtl. besser helfen kann.
Off-Topic ist nur unschön, wenn man Threads von anderen "kapert" und dann wild seine (off-toipc) Probleme "bespricht"...
...auch da ist es besser einen eigenen neuen Thread aufzumachen...
Und genau das ist der Grund: evtl. hat jemand ein ähnliches Problem und findet hier die Lösung! (und ich schaue wirklich nicht so oft in meine Nachrichten bzw. fällt mir eine Antwort in einem Thread an dem ich mitmache eher auf)...
Zitat von: d00my am 15 Juni 2019, 11:38:18
Danke für die Unterstützung und ein schönes Wochenende!
Greetz
d00my
Klar gerne!
Danke ebenso!
Viel Spaß noch, Joachim ;)