Hallo,
ich habe heute den optischen Fensterkontakt an meinen CUL angelernt.
Derzeit habe ich (noch) kein AES in FHEM aktiviert.
Der SCo liess sich zuerst nicht anlernen, wobei ich Empfangsprobleme vermutet hatte (war auch richtig wie sich später herausstellen sollte).
Also habe ich einen Werksreset beim SCo durchgeführt, danach konnte er sofort gepaired werden.
Nachdem was ich gelesen habe ist im Auslieferungszustand AES beim SCo aktiv und nach einem Werkreset eben nicht mehr.
Jedenfalls funktionierte die Statusübermittlung dann nur sporadisch (Raspberry steht im EG, Sensor ist im DG).
Ich vermute mal, dass der SCo keine so hohe Sende-/Empfangsleistung hat wie ein Aktor. Die Kommunikation mit den Strom-gebundenen Aktoren im DG klappt nämlich einwandfrei.
Lange Rede...wenn ich den Raspberry hoch ins DG verfrachte, klappt die Statusübermittlung des SCo ebenfalls einwandfrei. Hier muss ich mir was überlegen.
Aber jetzt zu meinen Fragen - im Logfile des SCo steht immer:
015-10-09_20:26:23 HM_3CD481 battery: ok
2015-10-09_20:26:23 HM_3CD481 contact: closed (to broadcast)
2015-10-09_20:26:23 HM_3CD481 closed
2015-10-09_20:26:23 HM_3CD481 trigDst_broadcast: noConfig
2015-10-09_20:26:23 HM_3CD481 trigger_cnt: 119
Ich meine die "to broadcast"-Meldung. Müsste hier nicht CUL_0 stehen? Oder ist das ok so?
Zweite Frage - mit welchem Befehl bekomme ich den "sign" Status des SCo ausgelesen, also ob AES auf dem SCo an oder aus ist?
Hab es bisher nicht hinbekommen.
Danke euch.
Hallo,
das sollte eher so aussehen:
2015-10-09_20:46:59 EG_WC battery: ok
2015-10-09_20:46:59 EG_WC contact: closed (to CUL_0)
Ein List vom Device liefert (bei mir) unter den Readings:
2014-12-28 13:14:47 R-sign off
AES war bei meinen Ende 2014 gekauften SEC-SCo eingeschaltet.
Gruß Hermann
Zitat von: Hermann20 am 09 Oktober 2015, 22:04:05
Hallo,
das sollte eher so aussehen:
2015-10-09_20:46:59 EG_WC battery: ok
2015-10-09_20:46:59 EG_WC contact: closed (to CUL_0)
Ein List vom Device liefert (bei mir) unter den Readings:
2014-12-28 13:14:47 R-sign off
AES war bei meinen Ende 2014 gekauften SEC-SCo eingeschaltet.
Gruß Hermann
Danke für die Antwort.
Ahh list...hätte ich ja mal drauf kommen können. Nur leider steht bei mir in den Readings vom SCo kein r_sign.
Bei einem anderen Device (UP-Funkschaltaktor) steht es in den Readings.
Was genau bedeutet das nun...gepaired ist es ja offenbar, laut Readings stimmt die hmId und es funktioniert ja soweit. Aber das "to broadcast" und der nicht sichtbare sign-Status deutet doch andererseits wieder auf ein Pairing-Problem hin, oder?
Gesendet von meinem GT-I9305 mit Tapatalk
Hallo , mal getConfig gemacht?
Danach muss R-pairCentral und PairedTo mit 0x... eingetragen sein.
Ansonsten ist der SCO eben nicht gepairt.
Gruß Helmut
Zitat von: pv_is am 09 Oktober 2015, 22:38:53
Hallo , mal getConfig gemacht?
Danach muss R-pairCentral und PairedTo mit 0x... eingetragen sein.
Ansonsten ist der SCO eben nicht gepairt.
Gruß Helmut
Habe ich gemacht.
R-pairCentral zeigt meine hmId, aber PairedTo taucht gar nicht auf und auch das sign fehlt.
Wie gesagt, der Sensor funktioniert, aber irgendwas scheint ja nicht zu stimmen. Bekommt man AES überhaupt zuverlässig per Werksreset abgeschaltet oder MUSS ich zwingend AES aktivieren?
Gesendet von meinem GT-I9305 mit Tapatalk
Ich habe bei meinen SCO's AES nicht mit einem Werksreset entfernen können.
Hatte mich aber auch nicht mit AES über SCC beschäftigt und kurzerhand bei Ebay einen HM-USB gebraucht (19€) gekauft und per PC Aes entfernt.
Werde mich wenn mal Zeit ist mit AES beschäftigen.
Gruß Helmut
Hallo,
wenn im Auslieferzustand AES on ist, wird man es mit einem Werksreset auch nicht abschalten können.
Ich habe bei meinen Devices (die mit AES on geliefert wurden) AES mit einem HM-USB-CFG abgeschaltet. Ansonsten wird das mit einem CUL wahrscheinlich nicht richtig funktionieren.
Such mal im Forum AES, CUL, Verschlüsselung, könnte sein, dass sich da etwas tut.
Gruß Hermann
So ich habe einen Fortschritt erzielt, aber ich glaube noch läuft es nicht ganz rund.
AES scheint jetzt zu laufen, dazu habe ich folgendes getan:
- das fehlende Crypt-Paket nachinstalliert
- eine VCCU eingerichtet
- einen hmKey in der VCCU gesetzt
- allen Devices das ioGrp Attribut zugewiesen
- den Fenstersensor werksresetted und neu angelernt
- dem Fenstersensor den hmKey zugewiesen
Der Sensor ist gepaired, Kommunikation klappt auch (er sendet jetzt auch an die CCU und nicht mehr "to broadcast"). Aber:
- ich sehe immer noch nicht das R-Sign Attribut
- Es sind anscheinend ständig "CMDs_pending" (Funkreichweite ist ok, der Raspberry steht momentan nur 2 Meter entfernt)
Versuche ich ein set sign on kommt:
cannot calculate value. Please issue set HM_3CD481 getConfig first - invalid
ein getConfig bringt keine Änderung.
- hminfo gibt aus:
peerCheck done:
peer list incomplete. Use getConfig to read it.
incomplete: HM_3CD481:
regCheck done:
missing register list
HM_3CD481: RegL_00:
Register changes pending
HM_3CD481
Hier mal ein List:
Internals:
CFGFN
CUL_0_MSGCNT 9
CUL_0_RAWMSG A0C07A6413CD4818286FF010300::-58:CUL_0
CUL_0_RSSI -58
CUL_0_TIME 2015-10-10 12:22:32
DEF 3CD481
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 9
NAME HM_3CD481
NR 148
STATE closed
TYPE CUL_HM
lastMsg No:07 - t:41 s:3CD481 d:8286FF 010300
protCmdPend 9 CMDs_pending
protLastRcv 2015-10-10 12:22:32
protSnd 8 last_at:2015-10-10 12:22:32
protState CMDs_pending
rssi_at_CUL_0 cnt:9 lst:-58 min:-74.5 avg:-61.11 max:-53
Readings:
2015-10-10 12:19:51 Activity alive
2015-10-10 12:19:47 CommandAccepted yes
2015-10-10 12:19:46 D-firmware 1.0
2015-10-10 12:19:46 D-serialNr MEQ0724814
2015-10-10 12:19:46 R-pairCentral set_0x123456
2015-10-10 12:19:47 aesCommToDev ok
2015-10-10 12:19:47 aesKeyNbr 00
2015-10-10 12:22:32 battery ok
2015-10-10 12:22:32 contact closed (to CCU)
2015-10-10 12:22:32 state closed
2015-10-10 12:22:32 trigDst_CCU noConfig
2015-10-10 12:22:32 trigger_cnt 3
Vor 5 Minuten waren es noch 6 CMDs_pending, jetzt sind es schon 12.
Was meint ihr dazu?
Ich hoffe ich nerve nicht zu sehr und es liest noch jemand mit :) Sorry wenn es doofe Anfängerfragen sind, aber ich bin halt gerade dabei, mich durchzuwurschteln.
Folgender neuer Stand:
Es waren mittlerweile 32 CMDs_pending. Ich habe dann mal den Config-Knopf am Sensor gedrückt...und zack wurden alle CMDs übertragen.
In den Readings sehe ich jetzt auch endlich alle Werte inklusive r-sign (on).
Aber wenn ich irgendwas mit dem Sensor machen will (z.b. getconfig) laufen sofort wieder CMDs_pending auf und das bleibt auch so.
Die Commands werden offenbar nicht selbsständig übertragen, auch nicht nach 1 Stunde...wenn ich den Knopf drücke aber sofort.
Hat da jemand eine Idee, woran das liegen könnte?
das is normal. wahrscheinlich auch beim oeffnen/schliessn.
Nein, beim öffnen/schliessen wird leider nichts übertragen.
Was heisst normal - soll das heissen, die Commands werden niemals übertragen solange ich nicht den Knopf drücke?
Glaube, die SCO gehen in Tiefschlaf.
Aufwachen erst bei Auf/Zu oder wenn man kurz den Config Taster betätigt.
Alles klar, mittlerweile meldet sich der SCo in unregelmässigen Abständen (40-80 Minuten) bei der Zentrale und arbeitet die CMDs ab.
Somit funktioniert nun alles.
Vielen Dank an alle für die Hilfe.
Hallo nochmal,
ich habe mittlerweile sieben dieser optischen Fenstersensoren verbaut.
Ein Sensor zeigt jedoch ein merkwürdiges Verhalten, wofür ich keine Erklärung habe.
Alle Sensoren, bis auf einen, melden sich ca. alle 60-70 Minuten mit einem "alive" bei der CCU.
Der siebte Sensor tut das normalerweise auch, jedoch kommt es regelmässig vor, dass er sich auch mal 5-8 Stunden lang gar nicht meldet und deshalb auf "dead" gesetzt wird.
Irgendwann meldet er sich wieder (auch wenn er nicht ausgelöst wurde) von ganz alleine.
Funkabdeckung ist hier nicht das Problem, der Sensor ist in gleicher Reichweite wie 3 andere, die das Problem nicht haben.
Hier mal ein Log-Auszug:
2015-10-17_19:21:03 HM_3CC191 battery: ok
2015-10-17_19:21:03 HM_3CC191 contact: open (to CCU)
2015-10-17_19:21:03 HM_3CC191 open
2015-10-17_19:21:03 HM_3CC191 trigDst_CCU: noConfig
2015-10-17_19:21:03 HM_3CC191 trigger_cnt: 111
2015-10-17_19:21:12 HM_3CC191 battery: ok
2015-10-17_19:21:12 HM_3CC191 contact: closed (to CCU)
2015-10-17_19:21:12 HM_3CC191 closed
2015-10-17_19:21:12 HM_3CC191 trigDst_CCU: noConfig
2015-10-17_19:21:12 HM_3CC191 trigger_cnt: 112
2015-10-17_20:29:12 HM_3CC191 Activity: dead
2015-10-17_22:43:57 HM_3CC191 battery: ok
2015-10-17_22:43:57 HM_3CC191 contact: open (to CCU)
2015-10-17_22:43:57 HM_3CC191 open
2015-10-17_22:43:57 HM_3CC191 trigDst_CCU: noConfig
2015-10-17_22:43:57 HM_3CC191 trigger_cnt: 113
2015-10-17_22:44:05 HM_3CC191 battery: ok
2015-10-17_22:44:05 HM_3CC191 contact: closed (to CCU)
2015-10-17_22:44:05 HM_3CC191 closed
2015-10-17_22:44:05 HM_3CC191 trigDst_CCU: noConfig
2015-10-17_22:44:05 HM_3CC191 trigger_cnt: 114
2015-10-17_22:49:12 HM_3CC191 Activity: alive
2015-10-17_23:27:27 HM_3CC191 alive: yes
2015-10-17_23:27:27 HM_3CC191 battery: ok
2015-10-17_23:27:27 HM_3CC191 contact: closed (to CCU)
2015-10-17_23:27:27 HM_3CC191 sabotageError: off
2015-10-17_23:27:27 HM_3CC191 closed
2015-10-17_23:27:27 HM_3CC191 alive: yes
2015-10-17_23:27:27 HM_3CC191 battery: ok
2015-10-17_23:27:27 HM_3CC191 contact: closed (to CCU)
2015-10-17_23:27:27 HM_3CC191 sabotageError: off
2015-10-17_23:27:27 HM_3CC191 closed
2015-10-18_00:29:07 HM_3CC191 alive: yes
2015-10-18_00:29:07 HM_3CC191 battery: ok
2015-10-18_00:29:07 HM_3CC191 contact: closed (to CCU)
2015-10-18_00:29:07 HM_3CC191 sabotageError: off
2015-10-18_00:29:07 HM_3CC191 closed
2015-10-18_01:22:50 HM_3CC191 alive: yes
2015-10-18_01:22:50 HM_3CC191 battery: ok
2015-10-18_01:22:50 HM_3CC191 contact: closed (to CCU)
2015-10-18_01:22:50 HM_3CC191 sabotageError: off
2015-10-18_01:22:50 HM_3CC191 closed
2015-10-18_01:22:51 HM_3CC191 alive: yes
2015-10-18_01:22:51 HM_3CC191 battery: ok
2015-10-18_01:22:51 HM_3CC191 contact: closed (to CCU)
2015-10-18_01:22:51 HM_3CC191 sabotageError: off
2015-10-18_01:22:51 HM_3CC191 closed
2015-10-18_02:29:12 HM_3CC191 Activity: dead
2015-10-18_10:01:43 HM_3CC191 alive: yes
2015-10-18_10:01:43 HM_3CC191 battery: ok
2015-10-18_10:01:43 HM_3CC191 contact: closed (to CCU)
2015-10-18_10:01:43 HM_3CC191 sabotageError: off
2015-10-18_10:01:43 HM_3CC191 closed
2015-10-18_10:09:12 HM_3CC191 Activity: alive
2015-10-18_10:53:38 HM_3CC191 alive: yes
2015-10-18_10:53:38 HM_3CC191 battery: ok
2015-10-18_10:53:38 HM_3CC191 contact: closed (to CCU)
2015-10-18_10:53:38 HM_3CC191 sabotageError: off
2015-10-18_10:53:38 HM_3CC191 closed
2015-10-18_11:46:10 HM_3CC191 alive: yes
2015-10-18_11:46:10 HM_3CC191 battery: ok
2015-10-18_11:46:10 HM_3CC191 contact: closed (to CCU)
2015-10-18_11:46:10 HM_3CC191 sabotageError: off
2015-10-18_11:46:10 HM_3CC191 closed
2015-10-18_12:00:32 HM_3CC191 Activity: alive
2015-10-18_12:06:43 HM_3CC191 Activity: alive
2015-10-18_12:12:54 HM_3CC191 Activity: alive
Wie zu sehen, der Sensor meldet sich ca. alle Stunde, nachts hört er jedoch damit auf - zwischen 2.30 Uhr und 10:01 kein Kontakt mehr.
Um 10:01 hat er sich von alleine wieder gerührt, er wurde wie gesagt nicht ausgelöst oder sonst etwas.
Das passiert jede Nacht - manchmal meldet er sich ab 22 Uhr nicht mehr, manchmal ab 01:00 Uhr ... bis er morgens irgendwann wieder aufwacht.
Alle anderen Sensoren zeigen dieses Verhalten nicht...
Hier noch ein List des Sensors: (Serial und hmid auskommentiert)
Internals:
DEF 3CC191
IODev CUL_0
NAME HM_3CC191
NR 143
STATE closed
TYPE CUL_HM
Readings:
2015-10-18 12:12:54 Activity alive
2015-10-13 19:47:26 CommandAccepted yes
2015-10-13 19:47:25 D-firmware 1.0
2015-10-13 19:47:25 D-serialNr 123456
2015-10-13 19:47:26 PairedTo 0123456
2015-10-13 19:47:26 R-cyclicInfoMsg on
2015-10-13 19:47:27 R-eventDlyTime 0 s
2015-10-13 19:47:27 R-msgScPosA open
2015-10-13 19:47:27 R-msgScPosB closed
2015-10-13 19:47:26 R-pairCentral 0123456
2015-10-13 19:47:26 R-sabotageMsg on
2015-10-13 19:47:27 R-sign on
2015-10-13 19:47:26 R-transmDevTryMax 6
2015-10-13 19:47:27 R-transmitTryMax 6
2015-10-13 19:47:26 RegL_00: 02:01 09:01 0A:82 0B:86 0C:FF 10:01 14:06 00:00
2015-10-13 19:47:26 RegL_01: 08:01 20:9C 21:00 30:06 00:00
2015-10-13 19:46:42 aesCommToDev ok
2015-10-13 19:46:42 aesKeyNbr 00
2015-10-18 11:46:10 alive yes
2015-10-18 11:46:10 battery ok
2015-10-18 11:46:10 contact closed (to CCU)
2015-10-18 11:46:10 recentStateType info
2015-10-18 11:46:10 sabotageError off
2015-10-18 11:46:10 state closed
2015-10-17 22:44:05 trigDst_CCU noConfig
2015-10-17 22:44:05 trigger_cnt 114
Helper:
HM_CMDNR 1
mId 00C7
rxType 28
Io:
newChn +3CC191,00,01,00
rxt 2
vccu CCU
p:
3CC191
00
01
00
prefIO:
CUL_0
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev CUL_0
IOgrp CCU:CUL_0
actCycle 001:05
actStatus alive
alias EG_Haustuer
autoReadReg 4_reqStatus
devStateIcon open:fts_door_right_open@red closed:fts_door_right@green
expert 2_full
firmware 1.0
group Fenster
icon fts_door_right
model HM-SEC-SCo
peerIDs 00000000,
room CUL_HM,Fenster,Hausstatus
serialNr xxxxx
subType threeStateSensor
Hat jemand eine Idee, woran das liegen könnte?