From 50d078fd54245bb73233f7029b642535f3ff097b Mon Sep 17 00:00:00 2001 From: Bernhard Tittelbach Date: Tue, 27 Jan 2015 02:08:53 +0000 Subject: [PATCH] doku --- go/door_daemon_zmq/handle_commands.go | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/go/door_daemon_zmq/handle_commands.go b/go/door_daemon_zmq/handle_commands.go index 3b27fff..1eb72e7 100644 --- a/go/door_daemon_zmq/handle_commands.go +++ b/go/door_daemon_zmq/handle_commands.go @@ -21,6 +21,20 @@ var cmdToDoorCmdHandler = map[string]DoorCmdHandler{ // ---------- Talk with Firmware directly in response to stuff it sends ------------ +// The problem is this: +// If the key/motor turns just far enough so that the door is unlocked, +// but still get's blocked on the way (because the door clamped) +// the firmware will enter state "timeout_after_open" instead of "open" +// In this state, manual moving the key/cogwheel will not trigger the state "manual_movement" +// Users however will not notice that the door is in an error state and needs to manually be moved to the real open position, +// they have after all, already successfully entered the room. +// Without that information however, the r3-event-broker daemon, cannot tell if the door is being locked manuall from the inside +// or if someone else is locking the door for other reasons. +// Thus, if the door has been opened imperfectly and is then closed manually, it will trigger a presence=false event and switch off the lights. +// +// As Workaround, the door daemon watches for "timeout_after_open" events. +// If one is detected and followed by an "door is now ajar" info, we tell the firmware +// to open the door, causing it to move out of the error state and into the final open key/cogwheel position. func WorkaroundFirmware(serial_wr chan string) (in chan [][]byte) { in = make(chan [][]byte, 5) go func() { -- 1.7.10.4