Hallo zusammen,
Ich habe in einem geheizten Kellerraum einen HM-SEC-SCo (opt. Türsensor) mit Thermostat (HM-TC-IT-WM-W-EU) und Ventil Stellantrieb (HM-CC-RT-DN) gepeert, via FHEM. Das klappt alles ganz prima. Einziger Nachteil: sobald ich die Türe öffne, schliesst das Ventil innert einem Sekundenbruchteil. Das ist nicht sinnvoll, wenn ich die Türe innert weniger Sekunden wieder schliesse, weil ich nur in den Raum komme. Klar geht das Ventil danach auch wieder auf, aber für die Batterien im Stellantrieb ist das sicher suboptimal. Was ich eigentlich möchte, ist, dass das Signal erst kommt, wenn die Türe z.B. 10 Sekunden offen steht.
Ich hoffte, das mit einem "set <Tuersensor> regSet eventDlyTime 10" hinzubekommen. Aber egal, wie oft ich den Befehl eingebe, wie oft ich danach den Anlernknopf drücke, ein getConfig absetze, etc... eventDlyTime bleibt auf "set_10s", d.h., das Register wird lediglich zum Setzen vorbemerkt, aber nicht tatsächlich übertragen. Dabei klappt die Verbindung, ich bekomme am Sensor auch beim Öffnen und Schliessen (fast) immer ein grünes Signal (ich habe es FHEM seitig mit vccu gekoppelt), ich habe sogar das Raspi in denselben Raum genommen, damit die Signalstärke genug gross ist. Aber ich kann dieses Register nicht setzen... alles Andere scheint zu klappen, ich sehe die Events auch in FHEM, nur das Register bleibt einfach bei 0. "get regTable" liefert
No regs found for:
AZ_Tuer type:threeStateSensor -
list:peer register :value
0: cyclicInfoMsg :on
0: pairCentral :0x31B3A1
0: sabotageMsg :on
0: transmDevTryMax :6
1: eventDlyTime :set_10 s
1: msgScPosA :set_open
1: msgScPosB :set_closed
1: sign :set_on
1: transmitTryMax :set_6
Weiss jemand Rat...? Oder mache ich was prinzipiell falsch?
Danke und Grüsse,
Andreas
PS: AES ist nicht aktiviert.
PPS: Zu Testzwecken habe ich auch das Register ledOnTime zu änder versucht - auch dieses schafft es nicht über den set_ Zustand hinaus.
Hallo Andreas,
ich kann Dich in einem "beruhigen" das ist bei mir auch so.
Vom Verständnis her bin ich mir aber nicht sicher, ob es der richtige Weg ist.
Ich kenne aber auch keinen anderen, außer es mit einem DOIF oder watchdog zumachen.
Gruß Otto
Versuch mal ein "clear readings" und danach ein "get config".
Das wirkt manchmal Wunder :P.
Also ich hab bei meinen das Register schon ohne Probleme gesetzt. Hast mal ein Reset durch kurzes Batterie-rausnehmen versucht? Hatte hier auch schon störrische Devices bei denen das Wunder gewirkt hat.
Bei mir läuft das Ganze ebenfalls (mit 60 Sek. Verzögerung).
Hatte anfangs nur nicht gewusst, daß man zur Übernahme der Werte den Config-Knopf am Sensor drücken muß. Aber dann funktionierte alles problemlos.
Tatsächlich, man kann zwar die Datenübertragung auch durch "Aktion" auslösen (also auf oder zu) aber da werden die regSet Befehle offenbar verworfen.
Wenn man den configtaster drückt funktioniert es.
Gruß Otto
Irgendwo hatte ich mal gelesen, daß das so eine Art "Sicherheitsfeature" sein soll - Konfig-Änderungen können nur übernommen werden, wenn man "vor Ort", also am Knopf ist...
Martin
Zitat von: klaymen am 11 Februar 2017, 18:12:02
Aber egal, wie oft ich den Befehl eingebe, wie oft ich danach den Anlernknopf drücke, ein getConfig absetze, etc... eventDlyTime bleibt auf "set_10s", d.h., das Register wird lediglich zum Setzen vorbemerkt, aber nicht tatsächlich übertragen
So wie ich ihn verstanden habe, hatte er das schon probiert.
Naja wenn er vorher aus versehen die Tür aufmacht oder mit der Hand am Sensor vorbeifährt war es das. Dann wird die Übertragung ausgelöst und alles verworfen.
Gruß Otto
Also der HM-Sec-SC-2 überträgt auch schon beim Öffnen des Kontakts. Sollte sich der HM-SEC-SCo da wirklich anders verhalten?
Ich habe es gestern mehrfach getestet, es ist offenbar so:
Man kann immer die Datenübertragung per Aktion (open/closed) oder configtaster auslösen.
Für solche Dinge wie getConfig oder getRegRaw funktioniert das auch in beiden Fällen, die Daten kommen an.
Für regSet funktioniert das bei Aktion nicht. Bei Auslösen durch Aktion wird zwar optisch sichtbar und auch durch CMDs_done quittiert die Übertragung angestoßen, das Ergebnis ist aber nicht wie erhofft. Kein Register gesetzt und es steht set_
Nachträglich Configtaste drücken bewirkt nichts.
Nur bei Auslösen durch configTaster nach dem regSet werden die Register gesetzt und alles ist wie erwartet.
Sicherheitsfeature wie Martin oben schrieb, wird wohl so sein. Und macht ja durchaus Sinn
Gruß Otto
Zitat von: Otto123 am 12 Februar 2017, 10:53:54
Nur bei Auslösen durch configTaster nach dem regSet werden die Register gesetzt und alles ist wie erwartet.
Danke, leider funktioniert das trotzdem nicht. Ich kann noch so oft das Register setzen und danach die Anlerntaste drücken - dann nochmals getConfig plus Anlerntaste - es wird konstant ignoriert. Anfangs stehts auf set_xx, irgendwann dann mal wieder auf 0. Die Tür habe ich dabei on Anfang an geschlossen gehabt und nicht geöffnet. Das Ganze mehrfach durchgespielt, mit gleichem Ergebnis. Zur Sicherheit dann nochmals alles mehrfach bei geöffneter Türe (nur für den Fall, dass es nur bei offenem Kontakt funktioniert). Das Ergebnis ist immer dasselbe. Das Register - und wie gesagt auch das ledOnTime Register - lässt sich nicht beschreiben. Das kann ich mir fast nur mit einem fehlerhaften Teil bei mir erklären... naja, es ist nicht so tragisch, ich kann damit leben, aber nerven tut es schon etwas.
Ich nehme schon an, zum Drücken der Config Taste habt ihr das Gehäuse (also die äussere Ummantelung) entfernt? Dachte da an einen Intrusion Schutz oder so, aber kann ja nicht sein, dass man die äussere Ummantelung soweit eindrücken muss, dass der Anlernknopf runtergeht.
Die Batterie rausnehmen und wieder reintun habe ich übrigens auch getestet, ohne Erfolg.
configtaster geht ohne Probleme mit der Fingernagelspitze oder einem Stift, das ist dort wo die LED leuchtet! ;D Ich hatte mein Gehäuse geschlossen.
ich glaube ledOnTime ist ein fake, das ginge denke ich sowieso nicht. Hatte ich mal woanders gelesen, bin aber nicht 100 % sicher.
Gruß Otto
Zitat von: Otto123 am 12 Februar 2017, 17:07:27
configtaster geht ohne Probleme mit der Fingernagelspitze oder einem Stift, das ist dort wo die LED leuchtet! ;D Ich hatte mein Gehäuse geschlossen.
Ok, das wusste ich nicht, aber du hast recht, es geht auch mit geschlossenem Gehäuse. Aber leider auch so ohne Erfolg. Ich habe jetzt auch nochmals das Teil abmontiert (eher abgerissen, da ich es angeklebt hatte) und direkt zum Raspi genommen, also unmittelbar nebeneinander, damit es ja keine Übertragungsprobleme gibt. Und habe nochmals icher um die 30 Mal (!) versucht, das Register zu beschreiben. Jeweils 60,61,62,... bis 70, gefolgt von getConfigs - egal was ich mache, es endet immer gleich, im Register landet am Ende immer 0.
Was mir bei getConfig auffiel: Es gibt dabei 3 Verhaltensvarianten:
- Nach ganz kurzem Blinken kommt gleich ein grünes Licht. Werte werden dabei offenbar nicht zu FHEM übertragen ("regTable" zeigt weiterhin set_... an)
- Langsames oranges Blinken, bis offenbar ein Timeout eintritt (ca. 1 Minute). Kein grünes LED. Werte werden ebenfalls nicht übertragen.
- Schnelles oranges Blinken, gefolgt von grünem LED. Nur hier werden offenbar Werte gelesen, aber eben immer 0 s, egal was vorher reingeschrieben wurde ("set_60s" wird durch "0s" ersetzt)
Das dritte Verhalten ist dabei offenbar die Ausnahme - so einmal pro 5 Versuche, alle anderen enden in Varianten 1 und 2, mit "set_..." Werten (also offenbar ohne Datenempfang).
Natürlich habe ich versucht, im Vorfeld jeweils den regSet Befehl mehrfach zu wiederholen (mit wechselnen Werten, damit FHEM immer einen Wechsel sieht und somit immer etwas zu übertragen hat), immer mit der Anlerntaste kombiniert. Ich ahbe jeweils auch versucht, die Anlerntaste vor- oder nach dme Absetzen des Befehls zu drücken (macht das einen Unterschied?) - Ich habe keine Ahnung, was ich sonst noch versuchen könnte.
Kommt es eventuell auf die Firmware Version an? Meine ist 1.0 (Typ HM-SEC-SCo). Etwas speziell finde ich, dass sich das Teil als "threeStateSensor" meldet, obschon es ja nur 2 Zustände - open und close - übermittelt. Ich nehme aber an, das ist so normal?
Wenn das so weiter geht und du noch nicht die Lust verloren hast, dann wirst du mal die Raw-Messages loggen müssen. Vielleicht kann martinp876 dann mal drauf gucken und was dazu sagen.
Die Firmware habe ich auch. Ja alle Fenstersensoren sind treestate, scheinbar haben die ein "Innenleben".
Erst regSet absetzen, dann configtaste drücken. Ich glaube anders geht es nicht. Du hast das mit dem Verhalten der LED richtig beobachtet.
Hast Du RegL_01 oder ist das leer?
Generell: Hast Du hminfo definiert? Wenn nicht mach das mal und mache configcheck.
Vielleicht wirklich mal einen Versuch mit clear msgEvents und clear Readings und dann nochmal getConfig und dann ein Versuch ein Register zu setzen.
Gruß Otto
ZitatVielleicht wirklich mal einen Versuch mit clear msgEvents und clear Readings und dann nochmal getConfig und dann ein Versuch ein Register zu setzen.
Sag ich doch! 8) 8) 8)
Vorher bitte noch sicherstellen, dass das Attribut "autoReadReg" auf "5_readmissing" steht.
Viel Erfolg!
Der optische Sensor war bei mir auf AES Signatur eingestellt. Ich musste die erst rausnehmen bevor ich andere Register setzen konnte. Was steht bei dir in den readings Bei R-sign?
Internals:
CFGFN
DEF 38303F
HMLAN1_MSGCNT 66
HMLAN1_RAWMSG E38303F,0000,C84EC63F,FF,FFB5,5CA64138303F123ABC015200
HMLAN1_RSSI -75
HMLAN1_TIME 2017-04-27 20:48:58
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 132
NAME OG.KZ.TFK.li
NOTIFYDEV global
NR 408
NTFY_ORDER 50-OG.KZ.TFK.li
STATE zu
TYPE CUL_HM
hmusb_MSGCNT 66
hmusb_RAWMSG E38303F,0000,D85DDE04,FF,FFB7,5CA64138303F123ABC015200
hmusb_RSSI -73
hmusb_TIME 2017-04-27 20:48:58
lastMsg No:5C - t:41 s:38303F d:123ABC 015200
protLastRcv 2017-04-27 20:48:58
protSnd 66 last_at:2017-04-27 20:48:58
protState CMDs_done
rssi_at_HMLAN1 avg:-77.53 lst:-75 max:-71 min:-99 cnt:66
rssi_at_hmusb max:-67 avg:-74.19 lst:-73 cnt:66 min:-83
Helper:
Dblog:
Battery:
Mydblog:
TIME 1493318938.10804
VALUE ok
Contact:
Mydblog:
TIME 1493318938.10804
VALUE zu (to vccu)
State:
Mydblog:
TIME 1493318938.10804
VALUE zu
Trigger_cnt:
Mydblog:
TIME 1493318938.10804
VALUE 82
Readings:
2017-04-25 22:09:57 Activity alive
2017-01-28 16:43:18 D-firmware 1.0
2017-01-28 16:43:18 D-serialNr MEQ0029646
2017-01-28 16:43:18 PairedTo 0x123ABC
2017-01-28 16:43:18 R-cyclicInfoMsg on
2017-01-28 16:43:19 R-eventDlyTime 0 s
2017-01-28 16:43:18 R-pairCentral 0x123ABC
2017-01-28 16:43:18 R-sabotageMsg on
2017-01-28 16:43:19 R-sign on
2017-04-27 20:28:16 alive yes
2017-04-27 20:48:58 battery ok
2017-04-27 20:48:58 contact closed (to vccu)
2017-03-26 22:22:47 powerOn 2017-03-26 22:22:47
2017-04-27 20:28:16 recentStateType info
2017-04-27 20:28:16 sabotageError off
2017-04-27 20:48:58 state closed
2017-04-27 20:48:58 trigger_cnt 82
Helper:
HM_CMDNR 92
mId 00C7
rxType 28
supp_Pair_Rep 0
Ack:
Expert:
def 1
det 0
raw 0
tpl 0
Io:
newChn +38303F,00,01,00
nextSend 1493318938.08697
rxt 2
vccu vccu
p:
38303F
00
01
00
prefIO:
HMLAN1
Mrssi:
mNo 5C
Io:
HMLAN1 -73
hmusb -73
Prt:
bErr 0
sProc 0
sleeping 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO hmusb
flg A
ts 1493318937.98832
ack:
HASH(0xb7e1588)
5C8002123ABC38303F0101C800
Rssi:
At_hmlan1:
avg -77.530303030303
cnt 66
lst -75
max -71
min -99
At_hmusb:
avg -74.1969696969697
cnt 66
lst -73
max -67
min -83
Shadowreg:
Tmpl:
Attributes:
Fenster TFK_FG
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 002:50
actStatus alive
alias Marvin's Fenster links
autoReadReg 0_off
devStateIcon auf:fts_window_2w_open_l@red zu:fts_window_2w@green
event-on-change-reading .*
event-on-update-reading state,battery
eventMap closed:zu open:auf
expert 0_defReg
firmware 1.0
group Fenster
model HM-SEC-SCo
peerIDs 00000000,
room Marvin
serialNr MEQ0029646
subType threeStateSensor
userattr Fenster Fenster_map structexclude