From: Bernhard Tittelbach <xro@realraum.at>
Date: Tue, 27 Jan 2015 02:08:53 +0000 (+0000)
Subject: doku
X-Git-Url: https://git.realraum.at/?a=commitdiff_plain;h=50d078fd54245bb73233f7029b642535f3ff097b;p=svn42.git

doku
---

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() {