New Event Plug-in proposal

[esev]

I'd like to look into redesigning the Event Plug-in to make it better suited to handling complex events.  In the current Event Plug-in, a complex event might need to be broken into several separate events.

Lets say, as an example, you would like to automate whether your lawn sprinklers should be On or Off. In this example, you have two sensor devices to help determine when to water your lawn.  The first sensor, a rain sensor detects if it is currently raining.  If is is raining the state of the sensor will be "Raining" and if it is not raining, the state will be "No Rain".  The second sensor, a ground moisture sensor, detects the percentage of moisture in the ground.

In this example, you'd like the lawn to be watered only if the following conditions are satisfied:
  - The time is between 0500-0659
  - The rain sensor state is "No Rain"
  - The moisture sensor state is 25% or less
  - House mode is not Entertaining (you don't want to soak your guests)

Using the current Event Plug-in you would need to define six different events to manage your sprinklers.  You need two events (one On and one Off) for each type of event that effects the sprinklers.  Here are the six events, the event criteria are shown in parentheses:

  - Event 1 - Time Based at 0500, turn on
    (AND
      (sprinkler state = "Off")
      (moisture sensor state <= 25%)
      (rain sensor state "No Rain")
      (NOT
        (house mode "Entertaining")
      )
    )
    * ACTION: Turn the sprinklers on

  - Event 2 - Time Based at 0700, turn off
    (sprinkler state = "On" )
    * ACTION: Turn the sprinklers off

  - Event 3 - State Based, turn on
    (AND
      (sprinkler state = "Off")
      (current time >= 0500)
      (current time < 0700)
      (moisture sensor state <= 25%)
      (rain sensor state = "No Rain")
      (NOT
        (house mode "Entertaining")
      )
    )
    * ACTION: Turn the sprinklers on

  - Event 4 - State Based, turn off
    (AND
      (sprinkler state = "On")
      (OR
        (moisture sensor state > 25%)
        (rain sensor state = "Raining")
      )
    )
    * ACTION: Turn the sprinklers off

  - Event 5 - House Mode Based, turn on
    (AND
      (sprinkler state = "Off")
      (current time >= 0500)
      (current time < 0700)
      (moisture sensor state <= 25%)
      (rain sensor state = "No Rain")
      (NOT
        (house mode "Entertaining")
      )
    )
    * ACTION: Turn the sprinklers on

  - Event 6 - House Mode Based, turn off
    (AND
      (sprinkler state = "On")
      (house mode "Entertaining")
    )
    * ACTION: Turn the sprinklers off

As you can see, it takes a bit of thought to get this setup properly.  This is due to the current implementation of the Event Plug-in only being able to act on single events.  In this example, the individual events are Time, State, and House Mode.

An alternate implementation of the Event Plug-in could be less focused on the events that occur in the system and more focused on the overall state of the devices managed by LinuxMCE.  In this implementation, instead of being tied to a specific event, you just define the conditions necessary for your sprinklers to be On or Off.  To implement the example above only two rules are needed.  This is much easier for a person to implement and understand.

  - Rule 1 - Sprinklers auto-on
    (AND
      (sprinkers state off)
      (current-time >= 0500)
      (current-time <  0700)
      (rain-sensor state "No Rain")
      (moisture-sensor state <= 25%)
      (NOT
        (house-mode "Entertaining")
      )
    )
    * ACTION: (sprinklers send-command "on")

  - Rule 2 - Sprinklers auto-off
    (AND
      (sprinklers state on)
      (OR
        (current-time <  0500)
        (current-time >= 0700)
        (rain-sensor state "Raining")
        (moisture-sensor state > 25%)
        (house-mode "Entertaining")
      )
    )
    * ACTION: (sprinklers send-command "Off")

Implementing an event plugin that is based on the overall state of the system can quickly become inefficient if the right algorithm is not used.  You can immagine a nieve algorithm, checking each condition of each rule every time an event is fired, would bog down the system in a hurry.  I'm proposing this plug-in be based on the Rete algorithm.  You can read more about the Rete algoritm on Wikipedia, but in a nutshell it is designed to efficiently handle this type of rule based logic.  A C language public domain implementation of the Rete algorithm exists and is called CLIPS (C Language Integrated Production System).  I'd like to use CLIPS to implement a Rules-Base event plugin for LinuxMCE.  I'd also like to re-do the web interface for events to make it work with this new implementation.

Is it alright if I implement a new Event Plug-in?  Are there any other suggestions on how this should be done or features it should support?

[tschak909]

esev, we've talked a bit before on this, and this approach is definitely the right way to go.

I am all for this. (And this will knock down yet another plugin needing to be GPL'd!)

-Thom

[sambuca]

This seems like a good approach. I've come across the limitation you describe myself more than once, so I think this will be an improvement.

I've done some small improvements to the current Event plugin over the last year, so if you need any assistance, I'll try to help out.

I can't think of any new features is should support, as long as the basic functionality we have today is still available. Timed event, for instance, not sure if they should be handled separately, or if they can be efficiently implemented in the CLIPS.

I think focusing on replacing what we have today is a good first step, then we can use it for a while and new ideas might appear.

best regards,
sambuca

[esev]

I've done some small improvements to the current Event plugin over the last year, so if you need any assistance, I'll try to help out.

Much appreciated.  I'll probably ping on you with some questions when I get stuck

I can't think of any new features is should support, as long as the basic functionality we have today is still available. Timed event, for instance, not sure if they should be handled separately, or if they can be efficiently implemented in the CLIPS.

I think I'll be able to keep the timed events all within CLIPS and do away with the special cases that we have today.  At its core, CLIPS is based on reacting to changes in data.  I just need to feed CLIPS data for 'Day of Month', 'Day of week', and 'Current time' and keep those data points updated as time passes.

I think focusing on replacing what we have today is a good first step, then we can use it for a while and new ideas might appear.

That's my first goal of this project.  To read the events in the current database tables and represent them in a format that CLIPS understands.  Eventually I'm going to need to update the table structures to support some of the more advanced features of CLIPS, but starting small like this is a good idea.

One nice thing supported in CLIPS is the use of variables.  As a simple example of how powerful this can be, take a look at the existing events for Watching and Stopped Watching Media.  Currently those two events need to be duplicated for each Room.  If I'm able to model all the data from our devices into CLIPS, those rules could be re-written like this.

Rule 1 - Lights Off when Watching media
    (room (PK_Room ?room) (watching-media True))
    ?the_light <- (light (PK_Room ?room) (state On))
  * ACTION (?the_light send-command Off)

Rule 2 - Lights On when Stopped Watching media
    (room (PK_Room ?room) (watching-media False))
    ?the_light <- (light (PK_Room ?room) (state Off))
  * ACTION (?the_light send-command On)

?room and ?the_light are variables.  The first condition with the variable is the one that sets it.  So if you're watching media in Room 1, ?room will be 1.  The next condition will use the value of ?room to select only the light in that room that is On.  The action will use ?the_light as the target for the command to be sent.  The Rete algorithm specifies this rule will continue to run for each light On in each room that playing Media.  The rule will stop running when all the lights in all the rooms where media is played are Off.

Using the sprinkler example, it wouldn't be hard to extend the example to support Sprinkler Zones - only allowing a Zone to turn On if all the conditions were met and another Zone was not currently On.  The current database tables won't support this type of rule.  That's why I'll be looking to change them after the first version comes out.

The Rete algorithm is pretty powerful and can do some really tricky things.  Check out the CLIPS User Guide if you're interested in what can be implemented with CLIPS.  JBoss also has some videos demoing their Rete based products.  The Drools Expert is pretty much the same thing as CLIPS - but with a very pretty interface.

[esev]

Just to follow up on the last post.  I wish we could use Drools for the Event Plug-in.  I'd drop CLIPS in a heartbeat.  Drools would give us much more capabilities than are currently available in CLIPS - Temporal Reasoning being the biggest capability I see missing from CLIPS (see description about half way down the Drools Fusion page).  Temporal Reasoning would allow me to add a "Motion Detector not tripped in the last 10 minutes" type of condition to my Sprinkler rules.  But Drools requires Java and I'm not sure how well the rest of the developers would like adding Java into a core plugin.

[sambuca]

Adding a Java plugin could be an issue. I'm a full-time Java/JEE developer myself, so I wouldn't mind as such, but there is always the question if mixing languages are worthwhile. As this probably would need to be a plugin to DCERouter itself, I think more people would be against it. If it were a separate device only communication via DCE, I think almost none would care 

br,
sambuca

[tschak909]

since it is a plugin, i would be very nervous, even if you bridged the code. but... this community has a very simple rule.. He who writes the code, makes the rules.

-Thom

[esev]

I think I've talked myself out of interfacing with Drools.  ...for now...    For the simple cases like "Motion Detector not tripped in the last 10 minutes" just keeping track of the last time a device changed state will be sufficient enough to get CLIPS to understand that type of event.

[sambuca]

Just thought of one thing; I've tried to make the event plugin reload its rules without requiring a router reload. I think we should think along these lines for new plugin too. So make sure the rule set can be updated whenever the rules are edited in the web admin.

br,
sambuca

[esev]

Just thought of one thing; I've tried to make the event plugin reload its rules without requiring a router reload. I think we should think along these lines for new plugin too. So make sure the rule set can be updated whenever the rules are edited in the web admin.

Will do.  I plan to support all the commands the current Event Plug-in supports.

[Marie.O]

I wonder if the event plugin is the problem, or the presentation of the plugin to the user

[esev]

I wonder if the event plugin is the problem, or the presentation of the plugin to the user

It is both.   When the Event Plug-in intercepts an event, it uses the PK_Event to only find event handlers for that specific type of event.  The web interface works the same way, allowing the user to only enter an event handler for a specific type of event.

I'm not sure which came first, but they both have the same issue.

[sambuca]

I wonder if the event plugin is the problem, or the presentation of the plugin to the user

It would probably be possible to create a web interface which hides the before-mentioned ugliness, but this would produce a huge mess of rules for the plugin. We're also missing handling of device statuses etc. from the current plugin.
And we'd still be stuck with a non-GPL event plugin 

best regards,
sambuca

[Marie.O]

And we'd still be stuck with a non-GPL event plugin 

THAT's probably the biggest issue

[zogie]

Hi

One thought if you are looking into this, I have used timed events to handle my heating system and have thought that the ability to handle event modes would be really handy (this may already be doable but I haven't yet found it).

This way you could have multiple modes for your houses heating, for example,

Timed:Use a pre defined set of times to turn the heating on and off
Auto: Use a temperature sensor do decide the heating requirements
On: Just put the heating on regardless of the time and/or temperature
Off:
Boost: Turn the heating on for 1 hour then reset to previous settings.

These modes would then show up in the climate panel of the UI for quick and easy setting.  Like I say this may already be possible, but if you are re-thinking the events module then it could be worth adding in. 

Lastly I'm not that up to speed on LMCE yet, but if you need any help with simple coding or UI work I would be more than willing to help.