(#10) Raising the Alarm 

If you're a glutton for punishment, or you're doing graduate work in the space, or if you're both a glutton and a grad student, you'll eventually stumble across the concept of event types.  Just Google "event stream vs event cloud" and start reading about event types.

But that's not the point of this post. I've got two types of events coming off the various publishers scattered around the house.  And it comes from the sense that I'll have "status" events and "alarm" events.  And they'll be easily winnowed (or 'sifted') from the event cloud/stream.  

Because I'll want to react to Alarm Events differently from Status Events.

"A subtle thought that is in error..."
The distinction between the two, an alarm and a status event, can be conspicuous or subtle.

1. "The Door just opened."
2. "The Door is still open."
3. "The Door is still open and has been open for two minutes."

By my sophistic thinking, the first one is an Alarm.  The second one a Status Event.

The third - "The door is still open and has been open for two minutes" - could be either.  It depends on whether you consider a Two-Minute-Left-Open Door in your house worrisome or not.

(One of) my point(s) being that whether something is an Alarm or a Status will depend. Depend on a few things.  A few things that will make sense to you and your house and your situation. And your few things that will probably not match my few things.

So?

So don't code this.  This needs to be flexible, changeable, adaptable.

A door open for two minutes in winter's cold December - is an alarm.  A door open for two minutes in Summer might just mean your hands are full taking burgers to the grill.

Wait, no - a door open for two minutes in December in Australia is...


Well, you get the gist.  As programmers we make decisions, lots of them, based on our context. And that leads to inflexibility, complexity and a lack of adoption.


Details, Boy, Details
Ok - so here's an example of two ALARM Events in my system:

WS2308/ALARM | 2014-05-08 20:29:00 -0600 | OUTDOOR HUMIDITY HIGH | 89.0 |

WS2308/ALARM/OUTDOOR/PRESSURE | 2014-05-08 20:29:04 MDT | RAPID OUTDOOR PRESSURE DROP | 0.07 |

Take note of my current, but may change, convention when I publish events

• The MQTT topic is part of the message payload
• The MQTT topic starts with the system that created the event -- WS2308 is the name of my weather station
• The MQTT subtopic is ALARM in this case
• Vertical bars separate the fields
• Information is human readable for debugging, instead of in XML or JSON
• I'm still inconsistent in my MQTT Topic usage. The first alarm could also have been published on the "WS2308/ALARM/OUTDOOR/HUMIDITY" topic.

My weather station publishes weather STATUS events about twice a minute. But it only publishes ALARM events when a threshold has been reached or exceeded.

There's one more thing that I do by convention for my ALARM events, and that is they are published ONCE.

Fire and Forget, Spray and Pray
That's right - my ALARM events are published once.  When a door opens in my house, you'll get one and only one of these:


HHB/ALARM | 2014-05-09 16:19:57 -0600 | 03 | OPEN-CLOSE SENSOR | Front Door | OPEN | 1 | 0000010228 |

I think that's what you want.  I don't think you want your event generator solving for network reliability issues.

And speaking of reliability issues...