Use the New Rules Features

Recently Dan announced the release of new features in rules.  In this How-To I'll expand on that and demonstrate some use cases.

But first, what are those new features I hear you ask?

  1. Short Codes
  2. 'For At least' Deferred Action feature
  3. Enhanced Time Precondition features
  4. Enable / Disable Rule from a Rule
  5. State Device

 

Short Codes

 

Short Codes are designed to be used in places where you would provide textual content- .e.g. the body of an email or SMS, or the content of a POST to a webhook.  Use them to insert dynamic data- for instance the time/date or a sensor's data value.

There are currently 6 supported forms:

  1. {{DATE_UTC}}
  2. {{TIME_UTC}}
  3. {{DATE_TIME_UTC}}
  4. {{GUID.deviceData}} ie {{1012BBxxxxx_0_0_31.deviceData}} (You can get guid from the info box in the device's widget)
  5. {{GUID.deviceName}}
  6. {{GUID.subDeviceName}}, ie if you have a motion sensor on the RF widget called 'motion' it will put 'motion' in.

Let's use this feature in a Rule.  We'd like to know when the temperature is below 20 degrees C, but we'd like exactly what temperature it is in that circumstance.  We'll need to know our temperature sensor's GUID, and we can find that on the Dashboard, by clicking the cog icon for the sensor, and selecting 'Info':

 

 

We then make a new Rule, choose our temperature sensor as the precondition; selecting 'When below' and entering 20:

 

We press 'Next' and then choose the email action.  (Please enable the email service in Settings:Services if you haven't already.)

 

For the body of the email, we would write something of the form:

 

{{1012BB013151_0301_0_31.deviceName}} is below critical: {{1012BB013151_0301_0_31.deviceData}}

 

Now when the Rule is triggered, we'll receive an email with the exact sensor data value.  The Short Codes feature is brilliant for data-specific usage of Rules.

 

 

'For At Least' Deferred Action feature

 

This makes the delay smarter, and will only continue after the delay if that amount of time has passed. This is useful for 'If motion, turn on my lights, delay at least 30 seconds, and turn them off'.  Thus constant motion will not result in constantly turning the lights off and on.

 

As an example, consider a simple Rule that is triggered by a PIR sensor.  The idea is that a light is turned on for 15 seconds and then turned off.

In this version, if the PIR sensor is triggered again before the 15 seconds (15000 milliseconds) has elapsed, then the Rule will fire again.  This will result on the lights (in this case Nina's eyes) turning on and off for as many times as the Rule is triggered.  This is not what we want!

 

Now, with the 'at least' checkbox enabled:

In this version, the setting of the 'For at least' flag will mean that the Rule will not be triggered until at least 15 seconds have elapsed.  The result of this will be a light that behaves the way we intended.  Hooray for computers doing what *we* want!  (No offence, Skynet.)

 

Enhanced Time Precondition features

 

The Time Precondition widget now has a great deal more expressive power.  It has two main modes- Daily and Custom.  Both modes support time zone selection.

 

Daily

 

This mode lets you choose which days the Rule will fire on, allowing you to represent such concepts as 'weekday', 'every Tuesday', etc.  Let's imagine we have a commitment to meet our fellow workers online for a good old healthy chat every weekday at 9.30am.  We can easily make a rule that will send us an SMS 5 minutes before the meeting starts.  Ensure you've enabled the 'Twilio' service in Settings:Services.

 

Create a new Rule, and choose the 'Time Between' precondition.  De-select 'Su' and 'Sa'.  Our meeting in question begins at 9.30am so we'd like to be reminded 10 minutes beforehand.  Select between 9.20am and 9.25am.  

 

 

Choose 'Next' and then add the SMS action, writing an appropriate message.

 

 

Name the Rule, and make sure you change the Frequency to 'Once every 10 minutes'.  That way the Rule will fire exactly once.

 

 

Custom

 

The Custom time mode allows us to specify any number of distinct, arbitrary time periods.  Click the 'Add Time Period' button and specify a time period.  You can span the time period over a number of days if required, and/or set multiple periods within a day.

 

Let's imagine we have a school pickup schedule that is rather arbitrary- 5pm on Monday, 3pm on Tuesday, not on Wednesday, 3pm on Thursday, etc.  This is now easy to achieve with the new time features.

 

Enable / Disable Rule from a Rule

 

I'm rather excited about this one, and not just because I requested it!  It can become tiresome to have to enable/disable whole suites of Rules.  Why would you need to do this?

 

* Testing - you might wish to disable all of your rules apart from the one you're working on.

* Suiting - you may wish to enable a whole suite of Rules that work with each other and provide you with some cool feature or other.

* Algorithms - you may wish to run a Rule or Rules for a certain period of time or until some conditions are met at which point they disable.  Think about the definition of an algorithm- a series of steps that completes.

 

We can enable/disable as many Rules as we need, so with the press of a button we can bring complex Rule relationships to life.

 

State Device 

A State Device is essentially a variable- think of it as type enum.  You define valid values for that variable, and the variable can be in one and only one of those values- i.e. state.  Perhaps an example may be instructive:

Let's set up a simple cycle using states.

  1. Enable the States Service in Settings: Services if you haven't already.  (Currently you are limited to one but if you use blocktool.ninjablocks.com you can add more)
  2. You'll see a new Widget on your Dashboard, called 'Generic State Device'.
  3. Use the cog (Widget Menu) and add a new Custom State.  Name it 'Red State'.
  4. Do this twice more, naming the states 'Green State' and 'Blue State'.
  5. Now go to Rules, and add a new Rule.
  6. Make the precondition State Red.  Click Next.
  7. Make the actions: Nina's Eyes Red, Delay (at least should be checked) for 3 seconds, then State Green.
  8. Save the Rule as 'Red to Green'.  Ensure it only fires once every 5 seconds.
  9. Make two more Rules, making one that goes from Green to Blue, and one that goes from Blue to Red.
  10. Go to the Dashboard, and click on 'State Red'.

You should see Nina's eyes turn red, then 2 seconds later, turn Green, then 3 seconds later turn Blue, and so on.  The cycle should continue indefinitely.

 

Another use for a State Device could be in controlling lights in a room.  Let's say you wanted to keep track of whether you are in a room or not, and if so, turn a light on, and if not, turn it off.  A State Device is perfect for this purpose.  You could define States:

  • Room Empty
  • Room Occupied

And set up Rules:

  • IF Door Sensor AND Room Empty THEN Turn on Light and set State to Room Occupied
  • IF Door Sensor AND Room Occupied THEN Turn off Light and set State to Room Empty

I'm going to try this out now!  Needless to say, the assumption is that there will only be one person using the room at one time.  More sophisticated Rules that involve PIR sensors would be needed to detect inactivity if we wanted to make this work with multiple people.

[EDIT] I did the experiment, but it's not working as I would expect it to.  I'll update this post when I get to the bottom of it.  Weigh in on the forums http://forums.ninjablocks.com/index.php?p=/discussion/1147/new-rules-features-state-devices#Item_1 if you think you know what's happening here.

 


Justin Clayden
Justin Clayden

Author