Java classes are used to model things like heating and lighting, for each zone (room) in our house. These are currently being developed and tested in our existing home.
A configuration file contains programmed target values for two profiles.
- An active profile is used if the zone is considered occupied or occupancy is detected.
- An inactive profile is used if the zone is not considered to be in use or we are away from home.
Each profile results in a target value for the heating for a given time of day. The example set out below shows how a zones temperature is controlled, based upon the day of the week and time of day.
The house status (in/out/away) is the first thing used to determine which profile is in use for all zones. If we are away from home the inactive profile is always used, otherwise the active profile may be selected.
The zone usage flag is the second thing that detemines which profile is used. If this marks the zone as not currently in use, then the inactive profile is always selected.
The active and inactive profiles are defined by a set of rules of the form:
A Mo 07:00 08:30 23 // Target temperature is 23°C on Monday morning
A Mo 16:00 21:30 22 // Target temperature is 22°C on Monday evenings
The first matching rule found is used to determine the returned target value, i.e. the temperature that the heating/cooling system should be aiming to reach in this zone. This is fed into a complex software controller which drives the hardware to avoid significant undershoot/overshoot and supports hysteresis. There are also two 'hard-coded' rules that are automatically added to the end of the ruleset and ensure a meaningful value is returned, if no other rules match. The target values for these two rules are defined per zone, on creation of the rule set:
A ** 00:00 23:59 22 // Target temperature is 22°C for active profile
I ** 00:00 21:30 15 // Target temperature is 15°C for inactive profile
In the above example the ** is a wildcard to match all days. Other possible values are Su, Mo, Tu, We, Tu, Fr, Sa, We (Sa and Su) and Wd (Mo to Fr).
In addition to the above, there is a dynamic rule, called 'rule zero' (because it is element  in the array of rules and thus processed first), which can be changed dynamically and enables HCS and manual override of the other rules. This rule has the form:
A ** <start-time> <end-time> <value>
If occupancy is detected in a zone that is in use, then this rule is set to extend the active period for a duration which is also defined per zone. As an example, if the lounge temperature rule is defined in the evening to be 22°C from 18:00 to 21:30, if activity is detected in this zone at 21:32, this override rule is set to extend the target temperature, the start time being 21:32 and the end time being 21:52 (e.g. 20 minutes). This will happen each time activity is detected, essentially extending the time the heating is on. The active extension can only go up as far as midnight though and this rule is automatically removed at midnight. This approach is particularly useful when controlling lighting in various zones.
If this was the end of the process used to detemine zone target temperatures, then walking into a zone at 2am in the early morning would cause the zone heating to come on for the period that someone was in the room + the predefined time delay. This is not good. The way this is resolved is to also support usage rules in the profile, of the form:
U ** 05:00 23:59 1 // Enable usage override from 5am to midnight only
If no such rule is found then the default state is that no override is allowed.
Although this concept and software has now been tested to work perfectly well with lighting, there are a few things that currently mean that we will probably not use it for lighting automation. In some rooms it is desirable to have a light come on when you walk in at night. Typically, these would be fairly low brightness lamps and you would want to ramp them up and down gently. Now if you are already in a room with lights on, it could be quite annoying if another light keeps coming on as you move and then goes off if you stand still for a few minutes.
The way we plan to get round this, is to use just one or two out of a set of of bulbs as the 'night light' and to provide power via two routes. If the mains lights are already on, then this power is supplied too. If not, the light will come on as you enter the room. Simplistically, the light has two power sources via diodes, either of which can power it.
The simple fact is that this feature is best implemented in hardware and not software with additional computer controlled hardware. The manual and automated control would still be there but, the night activation circuit sits in between this function and the lamp. Well that's the plan for now! Since we've written and tested the software, I'm sure it will get used somewhere in our home.