Occupant detection has been working pretty well (for the surveillance system) but on occasion it’s had some hiccups.  These have been difficult to pin down to a particular cause/effect relationship, but I recently decided to take a step back and make some design decisions.

As things were written, the occupant detection code kind of hard one in the door and the other foot out of the door.  I say this, because the code still seemed to want to abide by a fixed schedule (to set the Home/Away macro states) but also rely on occupant detection to explicitely set these states.  And it dawned on me (much too late, perhaps) that this can cause unnecessary problems.

Conceptually, there’s really no need for a schedule if you’ve got an active, automated occupant detection system active.  There’s no need to set an explicit Home/Away state based on time-of-day or day-of-week, if the system is able to make a more representative determination of that state completely of its own accord.  And further, in the absence of a working detection solution (where that solution is present but broken for some reason) it makes more sense to default to an Away state – a sort of failsafe, if you will.

So my schedule pretty much said to set the system to Away at all times, and the occupant detection would override this.  But the thing is, we were bridging two worlds – there’s the detection world, which consists of occupant detection and also surveillance events.  Then there’s the notification world, which decides which events should lead to an administrative notification.  And the mechanism to pass state changes between these two worlds… well, rife with odd bugs.

So instead of chasing down these bugs – which is about as much fun as getting standardized web code to work in Internet Explorer – I decided that it made much more sense for the notification world to always believe itself to be in an Away state, while the detection/surveillance world would change based on occupant state.   Then, the notification world only has to query the detection world to see if anybody is home when an event occurs.

You might be wondering – if occupant detection and surveillance exist in the same world, why do we ever get to the point where the notification world needs to check in again with detection?  Why can’t detection tell surveillance to stop when it determines that occupants are Home?

The simplest answer is, again, conceptual.  The surveillance system is always active.  Even when we’re home, we want the system to start recording when it notices activity at the front door, for example.  We want that record to exist in case something odd happened.  And because surveillance is always active, notifications are always being generated.  The question is whether those notifications should be quenched.

So there it is then – the notification system has to query the detection system to see if occupants are home before a notification is sent.  If occupants are home, no notification is sent.   The surveillance event will still be recorded and archived, but no notification will be sent.  Then, if the detection system is in failure mode, the failsafe is that both worlds – detection/surveillance and notification – believe the entire system to be in Away mode, and a notification will be sent for every qualifying surveillance event.

This equates to a polling, or “pull” model.  The notification world has proven to be very stable, so in the current design we need an explicit “Home” result from the detection world before a notification is quenched.  And that’s the extent of the communications.  The surveillance world no longer attempts to push its state information to the notifications world.

So this approach has worked quite well over the last few days.  I’ll keep an eye on it, and of course I’ll be sure to report back here if something comes up 🙂