doku
authorBernhard Tittelbach <xro@realraum.at>
Tue, 27 Jan 2015 02:08:53 +0000 (02:08 +0000)
committerBernhard Tittelbach <xro@realraum.at>
Tue, 27 Jan 2015 02:08:53 +0000 (02:08 +0000)
go/door_daemon_zmq/handle_commands.go

index 3b27fff..1eb72e7 100644 (file)
@@ -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() {