Conditions, Rules and Actions

We need to produce discrete digital events from the analogue data generated by our sensors, in order to switch our actuators. The Condition does this job in the hub. An example will help to illustrate.

One of the motivations for building the home hub was to control a bathroom extractor fan; part of a condensation reduction initiative. OK I could have bought a fan with an integrated sensor, but where’s the fun in that! I was measuring the relative humidity, so it was a simple task to check when this exceeded a threshold in order to switch the fan on, and check for going below another threshold to switch off. This Set/Reset pattern provides hysteresis, ensuring we don’t perform unnecessary switching, and is the essence of Conditions.

I had a number of other requirements I was hoping to satisfy in the design.

A simple UI – allowing non-admins to edit conditions and thresholds

Time clock facilities – treating the time of day like a sensor reading, allows the hub to replace a traditional central-heating programmer

Complex Expressions – a system that could cope with multiple variables in set/reset expressions

The implementation has fulfilled all of these requirements.

Returning to the bathroom fan problem, I started with the following simple expressions:

SET: S3 > 99 RESET: S3 < 75 ( where S3 is bathroom R.H. )

until the complaints from occupants arrived, ‘Can you switch that fan off – it’s freezing in here’. So I added temperature to the expressions:

SET: S3 > 99 and S4 > 17

RESET: S3 < 75 or S4 < 16 ( S4 is bathroom Temperature )

This improved the situation, but then I noticed that the fan would sometimes run for long periods. The assumption was that the replacement air was also high in moisture, so Actuator Timers were introduced. Here are the final expressions:

SET: S3 > 99 and S4 > 17 and t1 > 5 ( t1 is Fan Off-Timer )

RESET: S3 < 75 or S4 < 16 or T1 > 15 ( T1 is Fan On-timer )

The use of timers ensures the fan only runs for 15 minutes, and then pauses for 5.