(#19) "What? Were you born in a barn?"

No, Dad. Well, come to think of it, I'm not entirely sure, but I believe I was born in a hospital. But then you'd know better than I.

The point is there are some times when it's fine to leave the door open.

Let's say, hypothetically speaking of course, that you leave last night's pizza in the toaster oven too long and the smoke cloud clashes with the off-white of the walls.  

Or you accidentally microwaved the key fob to the Honda Pilot, again hypothetically speaking, of course and the house smells of burnt plastic.


That's my gripe with simplistic home monitoring. They're more than willing to alert you to a door being left open whether you want it open or not.  So, how could you make a system a bit smarter? Under what conditions would it be OK for the door to be left open?  Or conversely, or what conditions should the door be closed?

Here's an easy one - how about not leaving the door open in the winter?  Nothing aggravates a parent more than using your home's furnace to heat the entire neighborhood.  


And, respectively, keeping the door closed in the summer. Nothing aggravates a parent -- and a climate scientist -- more than using your air conditioner to combat global warming.

Let's go to the whiteboard!

If you've been following along, first you have my sympathies. You really need to spend less time on the Internet.  But, if you've been following along, you know that we have some simple sensors in the house:

• sensors that tell us if a door is open or closed - and how long it's been that way
• sensors that tell us the weather outside
• sensors that tell us the temperature inside
• sensors that tell us if the furnace is heating or the air conditioner is cooling
• an MQTT hub that servers up sensor data as events

And we've been toying with a Complex Event Processing engine, called Esper, to see if we could correlate data from these sensors and make conclusions.

All we need to do is figure out how we want to correlate the sensor data to draw a conclusion. In this case, how can we tell if the door is open when it shouldn't be?

Two approaches pop up quickly.

IFTATATTEIF... #1

"If this and this and this then that else if..."  OK- here's one possibility: If the door has been open for longer than one minute and the furnace is running then send an alert.   That would work for the winter.  In the summer it would change slightly: If the door has been open for longer than one minute and the AC is running then send an alert.

This seems straightforward to express in Esper's EPL syntax. Here's our first attempt:

//
// If we get a HHB status event for a Door (type 3) 
// and it's open, and the Furnace is running
//

String anEPLQuery = "SELECT * FROM "
 + "  HHBStatusEvent as doe, NestStatusEvent as nse "
 + "WHERE "
 + " ( (doe.deviceType = 3 "             // Open Close sensors are of type 3
 + " AND doe.deviceStatus = 'OPEN' "     // Door is open
 + " AND doe.statusDuration > 60) "      // for more than 60 seconds
 + " AND (nse.hvacStatus = 'HEATING' )"  // And the Furnace is on


The Door Open Event ('doe') will come in as an HHBStatusEvent object, and the Furnace running event will be a NestStatusEvent ('nse').

It should be readable, you should be able to get the gist.  There are two small problems. First, it won't run-- it's invalid EPL and Esper will barf and second, it doesn't handle the air conditioner running in the summer.

Let's fix the EPL first.

For the 37th time, I'll profess my SQL skills are abysmal and that makes EPL a challenge too. But what we're doing in the EPL above is an "inner join". We're joining two event streams. Esper needs more information before it can successfully join the two event streams.

Here's part of the error message you'll get from Esper (v5.3) when the Esper engine tries to digest that EPL:

Error starting statement: Joins require that at least one view is specified for each stream, no view was specified for doe



What I think Esper is saying is "Look, I need some bounds around the join.In this case, how many events do I hang on to to find the match?  How many results do you want?" 

 
If you think about it - suppose the matching events (door left open and furnace running) happened at 9:00am. Should Esper still call it a match at 5:00pm? 


No, of course not.





There are many ways to specify a view, but the one I'll try is a time limit. If the event match happens at 9:00am, then I'd like the matching events forgotten about after a few minutes.  While this might not be the best way, it's one way and it popped into my head first.  


Let's try this:

String anEPLQuery = "SELECT * FROM "
 + "  HHBStatusEvent.win:time(3 min) as doe, "    // 3 minutes of events
 + "  NestStatusEvent.win:time(3 min) as nse "    // only. Dump anything older
 + "WHERE "
 + " ( (doe.deviceType = 3 "             // Open Close sensors are of type 3
 + " AND doe.deviceStatus = 'OPEN' "     // Door is open
 + " AND doe.statusDuration > 60 ) "     // for more than 60 seconds
 + " AND (nse.hvacStatus = 'HEATING'  )" // And the Furnace is on

What you'll find out is that this compiles, run and works!  It may not be ideal, it may over alarm, over alert - but it does work.  



Now let's fix the Summer issue:

String  anEPLQuery = "SELECT * FROM "
+ "  HHBStatusEvent.win:time(3 min) as doe, "
+ "  NestStatusEvent.win:time(3 min) as nse "
+ "WHERE "
+ " ( (doe.deviceType = 3 "                 // Open Close sensors are of type 3
+ " AND doe.deviceStatus = 'OPEN' "         // Door is open
+ " AND doe.statusDuration > 60 "           // for more than 60 seconds
+ " AND doe.deviceOnline = TRUE ) "         // Sensor is online
+ " AND (nse.hvacStatus in ('HEATING','COOLING') ) )" // Furnace/AC is on

With the changes in red. I added a check to make sure the sensor is actually online. I've noticed that if an HHB sensor is offline, I cannot trust the status to be correct.


And when I run this EPL on some test data, it works! Again - it might not be optimal and I haven't verified the views are the best, but it is working. It finds those events when the door has been left open at the HVAC is running.



I'll skip the other Esper details - the Listener code because I think this post has gone on far enough and made the point I was shooting for:

A house full of sophisticated sensors that act in isolation isn't enough. In fact, it'll annoy the crap out of you!

It's only useful when you're able to draw meaningful conclusions from the wide variety of sensors in the house.

 
Let's save approach #2 for the next post.