HM-SCI-3-FM an Keymatic

[Damian]

Hallo zusammen,

das heiße Thema scheint hier z. Zt. das Peeren zu sein - ist ja auch kein Wunder bei der Komplexität der HM-Komponenten.

Nun zu meinem Anliegen, was auch mit dem Peeren zu tun hat.

Ich habe ein Keymatic-Schloss installiert und einen Fingerprintsensor an HM-SCI-3-FM  (Schließerschnittstelle) angeschlossen.
Bisher sind die beiden Komponenten mit FHEM einfach gepairt.

Über ein notify:

define Tuer_auf notify Tuer_Sw1:.*contact:.closed.* set Tuerschloss open

lässt sich die Tür auch öffnen.

Einen zweiten Channel des HM_SCI-3-FM will ich an den Sabotageschalter des Fingerprintsensors anklemmen und beim Auslösen über einen weiteren Notify den Tuer_auf-Notify (siehe oben) zum Öffnen der Tür deaktivieren, so dass die Tür beim Kurzschließen des ersten Kontaktes nicht mehr aufgeht.

So weit so gut. Das Ganze wird funktioniert solange FHEM läuft. Eleganter wäre HM-SCHI-3_FM mit dem Keymatic-Schloss zum Öffnen zu peeren, wenn es überhaupt geht. Dann müsste ich allerdings beim Auslösen des Sabotagekontaktes auf Channel 2 das Peeren wieder löschen, bevor der Einbrecher den Channel 1 kurzschließen kann.

Was sagen die Experten?

Gruß

Damian

[martinp876]

Hallo Damian,

Peeren sollte funktionieren.
Du solltest aber beim SCI3 channel AES einstellen. Kannst es ohne probieren, sollte aber nicht funktionieren.

Kannst du dass mit dem 2. Channel nicht mit inhibit loesen?
Wenn inhibit gesetze ist sollten die schalter nicht mehr funktionieren - oder was macht inhibit?

Gruss
Martin

[martinp876]

Noch eins,

wenn du selektiv peers sperren willst kannst du dies mit
- ent-peeren, wie du es vor hattest
- die onTime dieses Peers auf 0 setzen. dann sollte nicht geoeffnet werden.

Beachte, dass es eine ontime je peer fuer long und short gibt. Evtl kannst du de fuer long immer ausschalten und nur die fuer short nutzen, ein und ausschalten.

Besser waere es mit inibit zu loesen - wenn dies funktoniert

Gruss
Martin

[Damian]

Noch eins,

wenn du selektiv peers sperren willst kannst du dies mit
- ent-peeren, wie du es vor hattest
- die onTime dieses Peers auf 0 setzen. dann sollte nicht geoeffnet werden.

Beachte, dass es eine ontime je peer fuer long und short gibt. Evtl kannst du de fuer long immer ausschalten und nur die fuer short nutzen, ein und ausschalten.

Besser waere es mit inibit zu loesen - wenn dies funktoniert

Gruss
Martin

Hallo Martin,

danke für die Tipps. Es ist offenbar nicht so einfach wie einen virtuellen Button zu peeren - das habe ich zumindest schon mal hinbekommen;)

Ich habe zunächst versucht über den HomeMatic-Konfigurator zu peeren. Dort konnte ich erkennen welche Aktionen kombinierbar (oder besser vorgesehen) sind.

Der HM-SCI-3-FM ist dort offenbar nur als Türkontakt vorgesehen und kann nur verriegeln bzw. entriegeln aber nicht das Öffnen auslösen.

Das Öffnen von Keymatic kann man wiederum der dazugehörigen Fernbedienung HM-RC-Key3-B zuordnen.

Ich habe mir gedacht, ich peere die Dinger, also: HM-RC-Key3-B mit Keymatic-öffnen und HM-SCI-3-FM mit Keymatic-entriegeln mit dem HomeMatic-Konfigurator und lese dann die Listen in FHEM aus, um die entsprechenden Register-Belegungen zu erkennen. Wenn ich denn hoffentlich die Registerbelegung verstanden habe, wollte ich das Öffnen der Tür, durch Setzen der entsprechenden Register, dem HM-SCI-3-FM zuordnen.

Es sei denn du wüsstest, wie man direkt HM-SCI-3-FM:closed mit Keymatic:open in FHEM peert.

Der Zustand inibit ist sicherlich die elegante Lösung für den Sabotagekontakt, aber zuerst muss ich überhaupt die Tür aufbekommen;)

Gruß

Damian

[martinp876]

Hi Damian,

mit der win-SW peeren und dann auslese ist sicher elegant.

Die Register, die einen peer betreffen ist hier ueberschaubar, alles was in regList mit 'peer required' markiert ist. Wie immer gibt es alles fuer 'short press' und 'long-press'. long sollte fuer den SCI irrelevant sein, kann der wohl nicht.
Ich erwarte folgendes
Der SCI3 liefert einen Trigger und einen 'wert' offen oder zu. Diesen Wert benoetigst du um die CT (condition table) zu steuern. Die Werte sind normal 0 und 200. Somit kannst du in CT-low 10 und in high 190 eintragen.

Der RC3 liefert keinen wert, nur verschiedene trigger, also von verschiedenen Channels (Buttons). CT ist hier nicht relevant und kann quasi disabled werden. Jeder Button sollte auch short und long signallisieren koennen womit du dann je eine Aktion unterstuetzen kannst.

#CT: kann auch umgekehrt sein, je nachdem wann der SCI 0 und wann 100 meldet (auch das ist einstellbar)
CT_OFF        #accept trigger if value < low
CT_ON         #accept trigger if value > high
regSet shCtOn ltLo <peer>
regSet shCtOff geHi <peer>

# und die Werte
COND_VALUE_LO #vergleichswert low = 10
COND_VALUE_HI #vergleichswert high = 190

ON_TIME       # klar: wie lange soll offen sein
JT_OFF        
JT_ON        

Die Zustandsmaschine hat wohl folgende Zustaende:

lock->dlyUnlock->rampUnlock->unlock->open->dlyLock->rampLock->wieder zum Anfang
Ist also
zu,warten, oeffnen Beginn, oeffnen, offen, warten, schliessen beginn, zu

Der Ablauf ist nicht veraenderbar und laeuft eigentlich immer im Kreis. Im Zustand 'zu' wird sicher unendlich lange gewartet, also quasi stop. Die Zeit, wie lange in 'offen' gewartet wird kannst du mit onTime festlegen.

Wenn ein trigger kommt kannst du also festlegen, wohin geprungen wird. Wenn also gerade 'zu' ist und der entsprechende trigger des peers kommt (kurz oder lang) zwingst du die Zustandsmaschine in - sagen wir dlyUnlock
regSet shKeyJtOn dlyUnlock <peer>

Die Maschine laeft jetzt durch die Zustaende. Mit ontime = 111600 kannst du dauer-offen einstellen.

Also RC3 kurz: offen fuer 40 sec, lang offen fuer immer. Wenn offen, egal welcher, mache zu

regSet shKeyJtOn dlyUnlock <peer>
regSet shKeyJtOff dlyLock <peer>
regSet shOnTime 40 <peer>
regSet lgKeyJtOn dlyUnlock <peer>
regSet lgKeyJtOff dlyLock <peer>
regSet lgOnTime 111600 <peer>

ohne gewaehr, mit tippfehlern

Gruss
Martin

[Damian]

Hallo Martin,

Dank deiner Unterstützung geht die Tür jetzt durch direktes Peeren beim Schließen von Fenster_sw1 (wird später noch sinnvoll umbenannt) auf;)

Die Readings von Tuerschloss (Keymatic) sehen wie folgt aus:

R-Fenster_Sw1-lgCtOff geLo
R-Fenster_Sw1-lgCtOn geLo
R-Fenster_Sw1-lgCtValHi 100
R-Fenster_Sw1-lgCtValLo 50
R-Fenster_Sw1-lgKeyJtOff open
R-Fenster_Sw1-lgKeyJtOn open
R-Fenster_Sw1-lgOnTime 111600 s
R-Fenster_Sw1-shCtOff geLo
R-Fenster_Sw1-shCtOn ltLo
R-Fenster_Sw1-shCtValHi 180
R-Fenster_Sw1-shCtValLo 50
R-Fenster_Sw1-shKeyJtOff no
R-Fenster_Sw1-shKeyJtOn open
R-Fenster_Sw1-shOnTime 111600 s
R-intKeyVisib invisib
R-keypressSignal on


Diese Readings wurden weitgehend vom HM-Konfigurator gesetzt, ich habe lediglich dlylock gegen open bei shKeyJtOn geändert.

So, jetzt steht die Sache mit dem Sabotagekontakt noch aus.

Weiß noch nicht genau, wo ich den Zustand inhibit finde.

Unter supported register gibts folgende Möglichkeiten:

angelLocked angelMax angelOpen holdPWM holdTime intKeyVisib keypressSignal ledFlashLocked ledFlashUnlocked lgCtOff lgCtOn lgCtValHi lgCtValLo lgKeyJtOff lgKeyJtOn lgOnTime pairCentral setupDir setupPosition shCtOff shCtOn shCtValHi shCtValLo shKeyJtOff shKeyJtOn shOnTime signal signalTone

Gruß

Damian

[martinp876]

R-Fenster_Sw1-shKeyJtOn open

bin etwas ueberascht. Ich waere von On auf rampUnlock gesprungen. Open hielt ich fuer einen statischen Zustand, das entriegeln hatte ich in rampUnlock vermutet.
hatte es mit dlyUnlock nicht funktioniert oder hast du es nicht probiert?
dly sollte nur eine Verzoegerung addieren, die bei deinem keymatic ein fixer Wert ist.

inhibit ist kein Zustand der Maschine.
Es gibt ein Kommando 'inhibit':

set <dev> inhibit on|off

Da ich kein Device habe, kann ich es nicht probieren.

Bei genauem Hinsehen gibt es inhibit fuer viele entities, also immer channels, alle switches, dimmer...
werde ich einmal einbauen

Gruss
Martin

[Damian]

dlyUnlock ist zum Entriegeln, wie du schon vermutet hast. Ich will aber nicht nur entriegeln, sondern die Tür öffnen und das entspricht wohl dem open.

Die möglichen Kommandos sind:

use: open,rampLock,lock,rampUnlock,dlyUnlock,no,dlyLock



set <dev> inhibit on|off

bei mir also:

set Tuerschloss inhibit on

funktioniert bereits über FHEM wunderbar.

Wenn es aber keinen solchen Zustand gibt, werde ich es dann wohl nur über ein notify setzen können oder?

Oder was verstehst du unter "werde ich einmal einbauen"?

Gruß

Damian

[martinp876]

Die möglichen Kommandos sind:
use: open,rampLock,lock,rampUnlock,dlyUnlock,no,dlyLock

klar (habe ich getippt:-) ) - mit Tipfehler. Fehlt noch unLock - was dann eigentlich das entriegeln sein sollte.
Fuer den naechsten Update werde ich noch ein bisschen brauchen..., kommt aber

set Tuerschloss inhibit on
funktioniert bereits über FHEM wunderbar.
Wenn es aber keinen solchen Zustand gibt, werde ich es dann wohl nur über ein notify setzen können oder?

ich gehe davon aus, dass nach inhibit alle Zustaende eingefrohren werden, bis inhibit off kommt. Ich haette erwartet, dass alle trigger zur statemachin gesperrt werden.
Wenn das nicht zutrifft, was macht inhibit sonst?

Ich erwarte, dass nach inhibit eine offene Tuer offen bleibt.

Wenn du auf sabotage reagieren willst brauchst du ein notify. Ich wuerde nur mit allen Mitteln versuchen nicht an der Konfiguration zu drehen aufgrund eines notify (peeren, register setzen). Inhibit ist eben keine Configuration sondern ein operational state.

dabei faellt mir ein, wie kann man inhibit eigentlich lesen? Kannst du einmal die messages aufnehmen von einem statusRequest mit inhibit on und off? Das sollte doch unbedingt in die Readings.

Gruss
Martin

[Damian]

ich gehe davon aus, dass nach inhibit alle Zustaende eingefrohren werden, bis inhibit off kommt. Ich haette erwartet, dass alle trigger zur statemachin gesperrt werden.
Wenn das nicht zutrifft, was macht inhibit sonst?

Nach dem ich set Tuerschloss inhibit on gesetzt habe, konnte ich beim Auslösen des Kontaktes anhand des Funksymbols an der Keymatic sehen, dass Message ankommt, aber, wie du schon vermutet hast, die Zustände ändern sich nicht - das Schloss öffnet sich nicht.

Erst durch:

set Tuerschloss inhibit off

funktionieren wieder die Zustansübergänge wie definiert - das Schloss geht wieder auf.

Wenn du auf sabotage reagieren willst brauchst du ein notify. Ich wuerde nur mit allen Mitteln versuchen nicht an der Konfiguration zu drehen aufgrund eines notify (peeren, register setzen). Inhibit ist eben keine Configuration sondern ein operational state

.

schade, d. h. Sabotage unterbinden geht nur wenn FHEM läuft;(


Allerdings, unter der Annahme, dass FHEM zu über 99% der Zeit funktioniert und der Sabotageakt mit einer eher geringen Wahrscheinlichkeit anzusehen ist, kann ich mit der notify-Lösung zur Not leben.

dabei faellt mir ein, wie kann man inhibit eigentlich lesen? Kannst du einmal die messages aufnehmen von einem statusRequest mit inhibit on und off? Das sollte doch unbedingt in die Readings.

Hier die Messages für inhibit on/off:

2013.04.24 14:36:48 2: CUL_HM set Tuerschloss inhibit on rxt:2
2013.04.24 14:36:48 5: HMLAN_Send:  HMLAN S:S3C0BD590 stat:  00 t:00000000 d:01 r:3C0BD590 m:9A B011 260265 12A81A 0101
2013.04.24 14:36:48 5: HMLAN_Send:  HMLAN S:+12A81A,00,01,
2013.04.24 14:36:48 5: HMLAN/RAW: /E12A81A,0100,22E6D5F6,FF,FFBE,9AA00212A81A26026504871BC095144100
2013.04.24 14:36:48 5: HMLAN_Parse: HMLAN R:E12A81A   stat:0100 t:22E6D5F6 d:FF r:FFBE     m:9A A002 12A81A 260265 04871BC095144100
2013.04.24 14:36:48 5: HMLAN dispatch A119AA00212A81A26026504871BC095144100::-66:HMLAN
2013.04.24 14:36:48 5: HMLAN: Skip ACK
2013.04.24 14:36:49 5: HMLAN/RAW: /R3C0BD590,0021,22E6D5FB,00,FFBD,9A800212A81A260265007C1365A6
2013.04.24 14:36:49 5: HMLAN_Parse: HMLAN R:R3C0BD590 stat:0021 t:22E6D5FB d:00 r:FFBD     m:9A 8002 12A81A 260265 007C1365A6
2013.04.24 14:36:49 5: HMLAN dispatch A0E9A800212A81A260265007C1365A6::-67:HMLAN


2013.04.24 14:36:55 2: CUL_HM set Tuerschloss inhibit off rxt:2
2013.04.24 14:36:55 5: HMLAN_Send:  HMLAN S:S3C0BF325 stat:  00 t:00000000 d:01 r:3C0BF325 m:9B B011 260265 12A81A 0001
2013.04.24 14:36:55 5: HMLAN_Send:  HMLAN S:+12A81A,00,01,
2013.04.24 14:36:56 5: HMLAN/RAW: /E12A81A,0100,22E6F38C,FF,FFBE,9BA00212A81A26026504EF3D6B46C7D200
2013.04.24 14:36:56 5: HMLAN_Parse: HMLAN R:E12A81A   stat:0100 t:22E6F38C d:FF r:FFBE     m:9B A002 12A81A 260265 04EF3D6B46C7D200
2013.04.24 14:36:56 5: HMLAN dispatch A119BA00212A81A26026504EF3D6B46C7D200::-66:HMLAN
2013.04.24 14:36:56 5: HMLAN: Skip ACK
2013.04.24 14:36:56 5: HMLAN/RAW: /R3C0BF325,0021,22E6F391,00,FFBE,9B800212A81A26026500B048A4A6
2013.04.24 14:36:56 5: HMLAN_Parse: HMLAN R:R3C0BF325 stat:0021 t:22E6F391 d:00 r:FFBE     m:9B 8002 12A81A 260265 00B048A4A6
2013.04.24 14:36:56 5: HMLAN dispatch A0E9B800212A81A26026500B048A4A6::-66:HMLAN
2013.04.24 14:36:57 5: HMLAN_Send:  HMLAN I:K
2013.04.24 14:36:57 5: HMLAN/RAW: /HHM-LAN-IF,03C1,JEQ0186249,1AC944,260265,22E6F8C1,0007
2013.04.24 14:36:57 5: HMLAN_Parse: HMLAN V:03C1 sNo:JEQ0186249 d:1AC944 O:260265 m:22E6F8C1 IDcnt:0007


Gruß

Damian

[StefanV]

Hi Damian,

hast Du zu Deiner Lösung weitere Details?
Welchen Fingerprint sensor verwendest Du?

Bin stark an dem Thema interessiert.

Cheers, Stefan.

[Damian]

Hallo Stefen,

um das Thema hier nicht zu hijacken,

siehe hier (extra für dich und Interessierte habe ich gerade den letzten Beitrag dort verfasst):

Link

Gruß

Damian

[StefanV]

Hi Damian,

Danke für den Link, dann schau ich mir das mal im Detail an und versucht mal meine Frau zu überzeugen. :-)

Cheers, Stefan.

[Damian]

Die Readings von Tuerschloss (Keymatic) sehen wie folgt aus:

R-Fenster_Sw1-lgCtOff geLo
R-Fenster_Sw1-lgCtOn geLo
R-Fenster_Sw1-lgCtValHi 100
R-Fenster_Sw1-lgCtValLo 50
R-Fenster_Sw1-lgKeyJtOff open
R-Fenster_Sw1-lgKeyJtOn open
R-Fenster_Sw1-lgOnTime 111600 s
R-Fenster_Sw1-shCtOff geLo
R-Fenster_Sw1-shCtOn ltLo
R-Fenster_Sw1-shCtValHi 180
R-Fenster_Sw1-shCtValLo 50
R-Fenster_Sw1-shKeyJtOff no
R-Fenster_Sw1-shKeyJtOn open
R-Fenster_Sw1-shOnTime 111600 s
R-intKeyVisib invisib
R-keypressSignal on

Die obige Änderungen waren noch nicht vollständig.
Denn das Öffnen der Tür funktionierte nur, wenn die Tür zu war, aber nicht wenn sie vollständig abgeschlossen war.
Dafür ist offenbar shKeyJtOff zuständig, der muss auch auf open gesetzt sein und damit bei der Schließer-Schnittstelle nicht auf open, sondern auf close (entspricht offenbar dem Wert 0) reagiert, muss shCtOff auch auf ltLo gesetzt werden.

Die ganze Sache sieht dann so aus:


R-Fenster_Sw1-lgCtOff geLo
R-Fenster_Sw1-lgCtOn geLo
R-Fenster_Sw1-lgCtValHi 100
R-Fenster_Sw1-lgCtValLo 50
R-Fenster_Sw1-lgKeyJtOff open
R-Fenster_Sw1-lgKeyJtOn open
R-Fenster_Sw1-lgOnTime 111600 s
R-Fenster_Sw1-shCtOff ltLo
R-Fenster_Sw1-shCtOn ltLo
R-Fenster_Sw1-shCtValHi 180
R-Fenster_Sw1-shCtValLo 50
R-Fenster_Sw1-shKeyJtOff open
R-Fenster_Sw1-shKeyJtOn open
R-Fenster_Sw1-shOnTime 111600 s
R-intKeyVisib invisib
R-keypressSignal on

Damit wird nun die Tür auch dann geöffnet, wenn sie vollständig abgeschlossen war.

Gruß

Damian

[martinp876]

so ist es zu lesen. Also
state 'on' entspricht tuer zu, nicht verriegelt
state 'off' entspricht tuer verriegelt
Andere Zustaende sind nicht separat aufgefuehrt, nur intern verwendet.  

R-Fenster_Sw1-shKeyJtOff open
besagt:
wenn wir im state "off" = verriegelt sind und ein Trigger short vom peer Fenster_Sw1 kommt gehe in den Zustand "open"

'open' ist entriegelt UND der 'tuerdruecken' gedrueckt.

Die condition Table ct besagt, dass der sekundaerwert, den der peer liefert ausgewertet werden soll, und als filter dient.

R-Fenster_Sw1-shCtOn ltLo
R-Fenster_Sw1-shCtValLo 50

wenn wir also im state On sind und ein short trigger vom peer Fenster_Sw1 kommt muss der sekundaerwert kleiner 50 sein. Ansonsten wird der Trigger verworfen.

Sollte Fenster_Sw1 ein Fensterkontakt mit 3-state sein koennen Werte von 0, 100 oder 200 geliefert werden - das entspricht 0%, 50% und 100%.

Zu erwarten ist, dass des statt mit "open" auch mit "dlyUnlock" oder "rampUnlock" funktioniert und dabei die Wartezeiten intern einhaelt, sofern vorhanden.

Gruss
Martin