(#9) Complex : adjective kämˈpleks,kəmˈpleks,ˈkämˌpleks/

Our content's about to slow because we're catching up to where I'm still learning myself.

If you're dropping into this blog at this post, let me catch you up: I've asserted that the last 40 years of Home Automation has produced crap and I've take a stab at why I think so. I've told you that I have a couple of systems scattered around my house that broadcast events.

I've told you that it dawned on me that drawing conclusions from (a) the occurrence of an event or (b) the occurrence of a pattern of events is my next task.

CEP - Complex Event Processing
I first heard the term back around 2004, give or take, when I went out to Mountain View, CA to visit some of the engineers at TIBCO. Vivek stopped by for a few minutes and sort of asked if we had heard of this "really cool, new thing." And then he walked us through the basics of using events, specifically patterns of events, to draw conclusions.

If I recall correctly, he told us of a particular North American railroad company that was using it to drive costs out of their infrastructure.

My head jumped to the thought: all that track, all those sensors, all those cars and all that legacy infrastructure. 

If they're into this technology, it has to be approachable.

I won't go too much father into the science, for the most part because I don't know much of the science about this stuff. But I will say if you are interested, start off with two authors who are (or, in my opinion appear to be) the Fathers of CEP: David Luckham and Opher Etzion.

Life Without You

Think, just for a moment, how'd you'd code up something like this.  You'd code an MQTT subscriber, and listen for the first event.  When it came in you'd jump to a state where you'd listen for the second event.  When that one arrived, you'd jump to a state where you'd listen for the 3rd and final event.

Not too bad.

Until you realize that you need to switch things around.  Maybe swap the arrival of events 1 and 3.  Or you want to time-box the whole thing.  Event 3 must come no later than two minutes after event 1. Or maybe you want to add a 4th event.

Yuk! Pretty quickly it should dawn on you that hard-coding this will quickly become frustrating and inflexible.

Wrap it up Already!

Ask and ye shall receive. Here's the solution.

String  anEPLQuery = "SELECT * FROM PATTERN " +

  " [  every eventOne = HHBStatusEvent(macAddress='0000012467',deviceStatus='OPEN') " +

  " -> eventTwo   = HHBStatusEvent(macAddress='000000B357',deviceStatus='OPEN' ) " +

  " -> eventThree = HHBStatusEvent(macAddress='000000B357',deviceStatus='CLOSED' ) ].win:time( 5 minutes )";

Now all you need to know is abit more about the problem!

But this one Java String...

This one simple Java String...

Captures the essence of this requirement.

1) Subscribe to the event stream

2) When you see the following event pattern

2.1) An Open Event from Sensor 0000012467

2.2) Then an Open Event from Sensor 000000B357

2.3) And then a Closed Event from the same Sensor (000000B357)

2.4) And all three events have taken place within a 5 minute sliding window

3) Then do something

It's so smart, it's got to be using something like ESP (Extra Sensory Perception)!
But hold that ESP thought for a moment, I want to take a quick (one post) detour into ALARMS!