HM-SCI-3-FM an Keymatic

Begonnen von Damian, 19 April 2013, 22:51:58

Vorheriges Thema - Nächstes Thema

Damian

Hallo Martin,

Zitat von: martinp876 schrieb am Di, 21 Mai 2013 16:21so 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.  


wo liest du so was?

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

Wie ich oben schon geschrieben habe, bei dlyUnlock entriegelt zwar das Schloss, aber der Schlüssel wird nicht so weit gedreht, dass der Türschnapper eingezogen wird und die Tür sich öffnet. Das ist aber erforderlich, wenn von außen keine Klinke zum Öffnen vorhanden ist;)

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

martinp876

Hallo Damian,

wo ich es lese - nun es sind ein Teil vermutungen. Die eQ3 Teile haben eine statemachine, die immer sehr aehnlich ist. Sicher wird sie weiter-entwickelt... also kann sie sich von Aktor zu Aktor aendern.

Keymatic hat nur 2 Zustaende, on und off. Das kann so garnicht stimmen und wird auch durch die moeglichen eintraege der Jumptable bestaetigt. Es gibt also mindestens
dlyUnlock,rampUnlock,unLock,
dlyLock,rampLock,lock,
open

wobei "on" und "off" jetzt garnicht auftauchen. Diese muessen sich also hinter einer der anderen verbergen, einem statischen. Da kommt eigentlich nur lock und unlock in Frage. Alle anderen sind transient, wie auch bei dimmern u.ae. .
dlyLock/Unlock sollte eine Verzoegerung vor dem aktiven Zustand sein. Dieser Zustand hat immer einen timeout, wird also irgendwann automatisch verlassen.
rampLock/Unlock ist wohl das Anfahren, ein interner Zustand. Vorstellen kann ich mir, dass dies eigentlich das Oeffnen des Schlosses abarbeiten soll. Auch dieser Zustand wird automatisch verlassen.

Aktionen muss keymatic m.E. folgende bearbeiten:
abschliessen, aufschliessen, offnen
Im Vergleich zu anderen Aktoren passt dies (auch nummerisch) gut zu
rampLock, rampUnlock, open
Auch open wird nach einen timeout wieder verlassen - quasi der Tuerdruecker losgelassen.

Das sind alles Indizienbeweise. Wenn du mir die rohen Register einmal senden koenntest kann ich es noch einmal gegenpruefen. Auch die xml-files zeigen nur einen Teil der Wahrheit, in den Registern steht mehr.
ZitatWie ich oben schon geschrieben habe, bei dlyUnlock entriegelt zwar das Schloss, aber der Schlüssel wird nicht so weit gedreht, dass der Türschnapper eingezogen wird und die Tür sich öffnet. Das ist aber erforderlich, wenn von außen keine Klinke zum Öffnen vorhanden ist;)

macht sinn, passt ins Bild. Der Uebergang von unlock nach open erfolgt nicht automatisch. Offensichtlich entriegelt open auch das Schloss - was natuerlich auch sinn macht, und geht dann in den Zustand unlock ueber. Anders haette eQ3 wohl nicht einen single-klick uebergang von lock nach offen bereitstellen koennen. SW-technisch nicht sauber getrennt, aber Userfreundlich.

Praktisch sollten auch die anderen Parameter programmierbar sein, wie die delay zeit fuer lock/unlock. Aber dazu brauchen wir die rohdaten, da es im XML nicht vermerkt ist

Gruss Martin