HM-SEC-SCo und eventDlyTime

[klaymen]

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

Code Auswählen Erweitern

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.

[Otto123]

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

[Papaloewe]

Versuch mal ein "clear readings" und danach ein "get config".
Das wirkt manchmal Wunder  .

[MarcelK]

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.

[Linef]

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.

[Otto123]

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

[Linef]

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

[vbs]

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.

[Otto123]

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

[vbs]

Also der HM-Sec-SC-2 überträgt auch schon beim Öffnen des Kontakts. Sollte sich der HM-SEC-SCo da wirklich anders verhalten?

[Otto123]

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

[klaymen]

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.

[Otto123]

configtaster geht ohne Probleme mit der Fingernagelspitze oder einem Stift, das ist dort wo die LED leuchtet!  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

[klaymen]

configtaster geht ohne Probleme mit der Fingernagelspitze oder einem Stift, das ist dort wo die LED leuchtet!  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?

[vbs]

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.