Hallo Gemeinde....
mal wieder ein kleines Problem, ich habe einen HM-SEC-SC-2 angeschafft, und möchte diesen über einen Dummy in meine Present Struktur einbinden. Das Paring war auch unproblematisch. nur erhalte ich keinen Status vom Kontakt. Also Open / Close.
Warum?
CUL_HM_ID_00B1_24D14C
CUL_HM_ID_00B1_24D14C
Internals
CFGFN
DEF
24D14C
HMLAN1_MSGCNT
14
HMLAN1_RAWMSG
E24D14C,0000,000B35DC,FF,FFCA,0FA64124D14C23A684010EC8
HMLAN1_RSSI
-54
HMLAN1_TIME
2014-01-25 17:54:02
IODev
HMLAN1
LASTInputDev
HMLAN1
MSGCNT
14
NAME
CUL_HM_ID_00B1_24D14C
NR
342
STATE
MISSING ACK
TYPE
CUL_HM
lastMsg
No:0F - t:41 s:24D14C d:23A684 010EC8
protLastRcv
2014-01-25 17:54:02
protResnd
3 last_at:2014-01-25 17:55:37
protResndFail
1 last_at:2014-01-25 17:55:41
protSnd
1 last_at:2014-01-25 17:55:24
protState
CMDs_done_events:4
rssi_at_HMLAN1
avg:-56.35 min:-59 max:-54 lst:-54 cnt:14
Readings
CommandAccepted
yes
2014-01-25 17:42:53
R-intKeyVisib
set_invisib
2014-01-25 17:42:53
R-pairCentral
set_0x0
2014-01-25 17:54:40
noReceiver
src:24D14C A641 010EC8
2014-01-25 17:54:02
state
MISSING ACK
2014-01-25 17:55:41
CUL_HM_ID_00B1_24D14C
Attributes
expert
2_full
deleteattr
firmware
2.2
deleteattr
model
unknown
deleteattr
peerIDs
deleteattr
room
CUL_HM
deleteattr
serialNr
KEQ0951262
deleteattr
subType
Jemand eine Idee?????
hi noanda
das sieht aber schlecht aus. hast du schon einmal die Attribute angesehen?
model unknown
subType
und die Readings stehen alle auf "set_"
da klappt erst einmal garnichts
ZitatDas Paring war auch unproblematisch.
was verleitet dich zu dieser Aussage?
drucke noch einmal anlernen, dann sollten wenigstens model, subtype und ein paar andere Attribute gesetzt werden. Dann prüfen noch einmal das pairen, wiederhole es ggf
Gruss Martin
Der Sensor wurde gleich erkannt, ich sehe ihn in fhem ja auch
ich kann ja auch die config holen:
CUL_HM_ID_00B1_24D14C
CUL_HM_ID_00B1_24D14C
Internals
DEF
24D14C
IODev
HMLAN1
NAME
CUL_HM_ID_00B1_24D14C
NR
283
STATE
MISSING ACK
TYPE
CUL_HM
protCmdPend
1 CMDs_pending
protSnd
1 last_at:2014-01-25 20:02:52
protState
CMDs_pending
Readings
CommandAccepted
yes
2014-01-25 17:42:53
R-intKeyVisib
set_invisib
2014-01-25 17:42:53
R-pairCentral
set_0x0
2014-01-25 17:54:40
RegL_00:
noReceiver
src:24D14C A641 0110C8
2014-01-25 18:58:26
state
MISSING ACK
2014-01-25 17:55:41
CUL_HM_ID_00B1_24D14C
Attributes
expert
2_full
deleteattr
firmware
2.2
deleteattr
model
unknown
deleteattr
peerIDs
deleteattr
room
CUL_HM
deleteattr
serialNr
KEQ0951262
deleteattr
subType
1
Was bedeutet es wen die Readings auf "set_" stehen? sollte ich noch mal löschen ?
'set_' bedeuted, dass ein Kommando abgesetzt wurde (oder zumindest in der queue ist) aber keine Bestätigung den Device vorliegt. Es ist also nicht gesichert wie der Zustand ist.
Wie sollte man vorgehen.. mal überlegen
a) nachsehen, ob kommandos pending sind. Wenn ia, warten auf wakeup oder anlernen drücken, je nach device typ.
a1) prüfen, dass keine Fehler aufgetreten sind (protoState ohne error)
b) wenn immer noch set_ vorliegen ein getConfig machen - wieder zu a)
c) mit HMInfo configCeck wird das gesamte System geprüft, ob noch register set_ sind..
sollte ein sonstiger zustand set_ sein sollte man ein statusRequest absetzen.
ZitatDer Sensor wurde gleich erkannt, ich sehe ihn in fhem ja auch
noch einmal zurück: dein Sensor ist nicht wirklich erkannt. Wenn kein model eingetragen ist, ist dies eine Katastrophe (so etwas checke ich noch nicht einmal in configCheck)
Bitte einmal die rohmessage einschalten
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
und anlernen drücken
So wirst du nicht weiter kommen
Gruss Martin
ich habe da auch eine frage.
es herscht doch die meinung man muss die fensterkontakte peeren mit einem aktor (virtuell oder real) damit man eine Rückmeldung am SC bekommt.
Ich habe die Kontakte lediglich gepairt aber bekomme trotzem eine Rückmeldung.
Wie kann das sein? Oder ist das bei den SC-2 nicht mehr notwendig?
da müsst eich einmal die Logs sehen. Evtl sendet der SC an die Zentrale - oder an Broadcast.
Die Zentrale würde sicher antworten, bei Broadcast würde der SC keine Antwort erwarten
Er sendet an den HMLAN.
root@raspberrypi:/opt/fhem/log# cat Tuer_EG-2014.log
2014-01-31_07:31:53 Tuer_EG Activity: alive
2014-01-31_07:55:35 Tuer_EG open
2014-01-31_07:55:35 Tuer_EG contact: open (to HMLAN1)
2014-01-31_07:55:59 Tuer_EG closed
2014-01-31_07:55:59 Tuer_EG contact: closed (to HMLAN1)
2014-01-31_08:11:02 Tuer_EG Activity: alive
2014-01-31_08:15:41 Tuer_EG open
2014-01-31_08:15:41 Tuer_EG contact: open (to HMLAN1)
2014-01-31_08:18:35 Tuer_EG closed
2014-01-31_08:18:35 Tuer_EG contact: closed (to HMLAN1)
root@raspberrypi:/opt/fhem/log#
Heißt das jetzt ich muss die SC gar nicht mit einem virtuellen Aktor peeren?
sieht so aus. Das ist wohl eher eine statusmessage, kein trigger... aber das würde man in den rohmessage besser sehen
Zitat von: netbus am 31 Januar 2014, 07:29:30
Ich habe die Kontakte lediglich gepairt aber bekomme trotzem eine Rückmeldung.
Wie kann das sein? Oder ist das bei den SC-2 nicht mehr notwendig?
Bei mir gibt es die Rückmeldung mit der grünen LED auch bei meinen SC´s, SC-2´s und den RHS ohne peeren mit einem virtuellen Aktor. Habe auch nur mit meinem HMLAN gepairt.
Gruß
Christian
Zitat von: martinp876 am 31 Januar 2014, 10:25:06
das würde man in den rohmessage besser sehen
ist das die rohmessage?
Internals:
DEF 24FC6D
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG E24FC6D,0000,1B12042D,FF,FFAD,4DA64124FC6D23A5720134C8
HMLAN1_RSSI -83
HMLAN1_TIME 2014-01-31 16:19:59
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 1
NAME Fenster_KL_Strom
NR 96
STATE open
TYPE CUL_HM
lastMsg No:4D - t:41 s:24FC6D d:23A572 0134C8
protLastRcv 2014-01-31 16:19:59
protSnd 1 last_at:2014-01-31 16:19:59
protState CMDs_done
rssi_at_HMLAN1 avg:-83 min:-83 max:-83 lst:-83 cnt:1
Readings:
2014-01-31 12:35:35 Activity alive
2014-01-30 20:59:17 CommandAccepted yes
2014-01-30 21:00:27 PairedTo 0x23A572
2014-01-30 20:59:14 R-cyclicInfoMsg on
2014-01-30 20:59:14 R-pairCentral 0x23A572
2014-01-30 20:59:14 R-transmDevTryMax 6
2014-01-30 20:59:15 R-transmitTryMax 6
2014-01-30 21:00:27 RegL_00: 02:01 09:01 0A:23 0B:A5 0C:72 10:01 14:06 00:00
2014-01-30 21:00:27 RegL_01: 08:01 20:60 21:00 22:64 30:06 00:00
2014-01-30 20:59:17 aesKeyNbr FF
2014-01-30 21:01:34 alive yes
2014-01-30 21:01:34 battery ok
2014-01-31 16:19:59 contact open (to HMLAN1)
2014-01-30 21:01:34 cover closed
2014-01-30 21:01:34 recentStateType info
2014-01-31 16:19:59 state open
Helper:
mId 00B1
rxType 12
Io:
nextSend 1391181599.20375
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1391181599.12225
ack:
HASH(0x126c9c0)
4D800223A57224FC6D0101C800
Rssi:
At_hmlan1:
avg -83
cnt 1
lst -83
max -83
min -83
Attributes:
IODev HMLAN1
actCycle 028:00
actStatus alive
autoReadReg 0_off
devStateIcon open:fts_window_1wbb_open closed:fts_window_1w
expert 2_full
firmware 2.4
model HM-SEC-SC-2
peerIDs 00000000,
room Alarmanlage
serialNr KEQ1CCCCCC
subType threeStateSensor
nein - rohmessages bekommt man so:
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
Hallo noanda,
ich bin selbst Anfänger und das ist mein erstes Posting, also verzeiht mir, falls ich Mist erzähle.
Seit gestern habe ich auch verzweifelt versucht meinen ersten HM-Sec-SC-2 zu verbinden und er wurde auch nicht ordentlich erkannt.
In Eventlog konnte sich sehen dass er immer ein ...noreceiver... lieferte und auch keinen Status.
Jetzt bin ich drauf gestoßen, dass man vermutlich für manche Geräte neuerer Bauart ein Update von FHEM machen muss, obwohl ich erst die aktuellste Version 5.5 vor wenigen Tagen herunter geladen hatte.
Einfach mal folgendes eingeben: update check
Hier kan bei mir eine lange Liste. das Update kann mit update start gestartet werden.
Hier musst du dann evtl. noch ein zusätzlichen Attribut setzen, dass du Daten an FHEM senden möchtest oder nicht.
Am Ende half bei mir nur ein update force um die geänderten Dateien auch geladen zu bekommen.
Mehr dazu hier: http://fhem.de/commandref_DE.html#update
Danach habe ich meine halb oder falsch erkannten Geräte aus der FHEM.cfg gelöscht, gespeichert und neu gestartet.
Nun wurde der HM-Sec-SC-2 als schön erkannt und tauchte unter threeStateSensor auf. Er liefert jetzt auch den Status korrekt wieder.
Auch hat es für die Erkennung der HM-ES-PMSw 1-PI Funksteckdose mit Leistungsmessung geholfen.
Viel Spaß beim Basteln
geros
kleine Anmerkung
- Version 5.5 ist eine Basis - ein Update ist eigentlich immer notwendig.
- Bei Fehlermeldungen erwarte ich IMMER eine - zumindest ziemlich- aktuelle Version. Ich debugge keine historischen Versionen. Sollten Probleme auftreten erst einmal update.
- in Zweifelsfall einen update force, der repariert einen einmal schief gelaufenen Update. Ein normaler update kann dies nicht mehr
Gruss Martin
Zitat von: martinp876 am 31 Januar 2014, 20:11:35
nein - rohmessages bekommt man so:
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
ich habe diese werte in der config.
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs all,sysweder im globalen noch im kontakt log sehe ich detailierte logs (rawmessages)
das ist selten (hatt ich noch nie).
Du verwendest HMLaN oder HMUSB, der Name ist HMLAN1. Es ist keine CUL?
deine SW ist natürlich aktuell - update erst kürzlich gemacht?
ok, ich musste fhem neustarten
hier die logs
2014.02.01 18:04:20.513 0: Server started with 112 defined entities (version $Id: fhem.pl 4769 2014-01-29 08:14:58Z rudolfkoenig $, os linux, user fhem, pid 24465)
2014.02.01 18:04:27.193 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852244 d:23A572 O:23A572 t:0078DB3F IDcnt:0003
2014.02.01 18:04:27.209 0: HMLAN_Parse: HMLAN1 R:REE685F61 stat:0002 t:00000000 d:FF r:7FFF m:99 8112 999999 000001
2014.02.01 18:04:27.212 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.01 18:04:38.858 0: HMLAN_Send: HMLAN1 I:K
2014.02.01 18:04:38.866 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0852244 d:23A572 O:23A572 t:00793D17 IDcnt:0000
2014.02.01 18:04:46.638 0: HMLAN_Parse: HMLAN1 R:E24FC6D stat:0000 t:00795B6C d:FF r:FFA9 m:61 A641 24FC6D 23A572 0146C8
2014.02.01 18:04:46.721 0: HMLAN_Send: HMLAN1 I:+24FC6D,00,00,
2014.02.01 18:04:46.727 0: HMLAN_Send: HMLAN1 S:SEE68DFC8 stat: 00 t:00000000 d:01 r:EE68DFC8 m:61 8002 23A572 24FC6D 0101C800
2014.02.01 18:04:46.766 0: HMLAN_Parse: HMLAN1 R:REE68DFC8 stat:0002 t:00000000 d:FF r:7FFF m:61 8002 23A572 24FC6D 0101C800
2014.02.01 18:04:50.135 0: HMLAN_Parse: HMLAN1 R:E24FC6D stat:0000 t:00796918 d:FF r:FF9F m:62 A641 24FC6D 23A572 014700
2014.02.01 18:04:50.149 0: HMLAN_Send: HMLAN1 S:SEE68ED27 stat: 00 t:00000000 d:01 r:EE68ED27 m:62 8002 23A572 24FC6D 0101C800
2014.02.01 18:04:50.516 0: HMLAN_Parse: HMLAN1 R:REE68ED27 stat:0002 t:00000000 d:FF r:7FFF m:62 8002 23A572 24FC6D 0101C800
hm - also der sc sendet einentrigger an die Zentrale, keinen Status. Gut zu wissen.
Sieht so aus als ob die Bestätigungslampe imemr Grün war - ist das korrekt?
Gruss Martin
Ja ist korrekt
Gesendet von meinem GT-I9505 mit Tapatalk
So sieht das Log aus wenn man mit einem vb peert
2014-02-02_20:48:10 Fenster_KL_Strom closed
2014-02-02_20:48:10 Fenster_KL_Strom contact: closed (to HMLAN1)
2014-02-02_20:48:13 Fenster_KL_Strom open
2014-02-02_20:48:13 Fenster_KL_Strom contact: open (to vb)
2014-02-02_20:48:13 Fenster_KL_Strom open
2014-02-02_20:48:13 Fenster_KL_Strom contact: open (to HMLAN1)
2014-02-02_20:48:16 Fenster_KL_Strom closed
2014-02-02_20:48:16 Fenster_KL_Strom contact: closed (to vb)
2014-02-02_20:48:17 Fenster_KL_Strom closed
2014-02-02_20:48:17 Fenster_KL_Strom contact: closed (to HMLAN1)
Zitat von: Geros am 01 Februar 2014, 14:08:14
Am Ende half bei mir nur ein update force um die geänderten Dateien auch geladen zu bekommen.
Grandios! Danke für den Tip.
Ich hatte das Problem, dass mein HM-Sec-SC-2 nicht richtig erkannt wurde. Zwar bekam ich eine vernünftige R-pairCentral Eigenschaft und habe auch die Ereignisse empfangen, aber leider konnte der status und die Eigenschaftenmodel und subType nicht korrekt ausgelesen werden. Mit dem Update Befehl hat es dann letztlich doch funktioniert.
Viele Grüße,
UniXXer