Monthly Archives: July 2020

Tapping the Admiral

I was recently amused to see a smart home feature in a television advertisement for Admiral Insurance. In that advertisement George the householder meets The Admiral outside the local bistro and, as the day is set to be warm, decides to turn down his smart heating from his smart phone.

George and The Admiral

Unfortunately George manages to hit the wrong button on his smartphone and instead of turning off the heating manages to open the garage door.

An unfortunate chain of events

The opening garage door hits George’s red car, which hits the yellow car, and pushes down the boundary wall onto the road. George witnesses all this as it turns out that the bistro is on the opposite side of the road to his home, so has a go with another button.

Sprinklers on

George’s second attempt at adjusting the heating is no more successful as he manages to turn the fire sprinklers on which floods the house. Hopefully George has more than just multi-car Insurance.

So, besides amusement, what else might we gain from George’s issues?

  1. Firstly, I’ll observe that in my home you can put the whole heating system into summer which disables heating completely (such as in the summer), or vacation which disables the schedules but which continues to heat as necessary to maintain a minimum temperature (such as winter frost protection), or turn off the radiators in individual rooms, or turn down the temperature until such time as the schedule turns them back up.
  2. You don’t always get many characters to label a device or scene, but it does need to be clear what function will be achieved by pushing the button. (I find rules particularly frustrating in the Apple Home app as you can’t name rules and it becomes hard to distinguish between them, although Eve’s app which edits the same rules does allow naming and is much clearer for programming rules generally. The WIFIPLUG app also allows the button to be customised with a photograph of the appliance which is quite neat.)
  3. Devices like garage door openers can be linked to safety interlocks. I don’t have one myself but you can have a light beam, for example, across the doorway so you can’t close the door when obstructed by a car. I haven’t come across an interlock which ensures that the car is far enough from the door to allow opening, although in reality I think that a domestic car door opener would likely stop when it touched the car, detect an over torque / current condition, and then automatically reverse.
  4. Finally I think that smart home systems would benefit from a configurable ‘Are you sure?’ question to double-check that the user really wanted to perform some potentially damaging action such as open or unlock a door.
Click to play the advertisement

(Tapping the Admiral is a nautical expression referring to being prepared to drink anything alcoholic rather than be without a drink, notably including drinking the contents of the barrel in which the body of a recently deceased and pickled admiral was being carried.)

Leading the charge

Regular readers will know that my Energy Smart home includes a storage battery. That battery is either charged from my solar panels (effectively free electricity), or low cost electricity bought from the grid, or some combination of the two depending on the solar forecast for the day ahead.

The logic of how much battery charging is required has until now been driven by a set value for the number of charging hours required. The number of hours of solar charging predicted is deducted from the the number of charging hours required to calculate the number of bought charging hours required outside the solar production window.

Bought charging hours required :=

Total hours required – Solar hours predicted

However with experience this appears to be a sub-optimal arrangement. At one extreme on a very sunny day the battery will fully charge and then be allowed to discharge continuously through all other hours, there is no middle ground in which the battery is not permitted to discharge through the night. However at the other extreme if the battery is replenished entirely from the grid then there will be hours when discharge is not permitted since, after accounting for cycle efficiency, the value of the electricity in the battery is higher than the cost of that from the grid and thus it’s better value to use grid electricity than stored electricity. As there are fewer discharging hours then fewer hours of charging will be required to refill. Thus the depth of discharge is greater when charged from solar than from the grid requiring more charging hours to refill. Leaving the longer charge time for a full charge in use then creates a risk of charging the battery when the grid price is higher than necessary leaving the battery possibly full by the time the lowest cost grid energy is available. Having a more accurate target for the charge time would enable the lowest cost charging periods to be selected more precisely.

Schedule with some solar

The new refinement is to automatically adjust the bought charging hours between two existing user-defined values: the existing target hours and the maximum charging hours currently used just to cap charging hours during plunge pricing events (i.e those with negative cost events). The new algorithm can adjust to any value between the two limits in half hour intervals. As currently configured that’s anything between five and seven hours. The new algorithm is:

Total hours required := minimum (Maximum hours from plunge,
maximum (Target hours, Solar hours predicted + 1))

max hours (A)Target hours (B)Solar hours (C)C + 1Max (B, c+1)Min (A, Max(B, C+1))
7.05.0>= 6.5>= 7.5>= 7.57.0
7.05.06.07.07.07.0
7.05.05.56.56.56.5
7.05.05.06.06.06.0
7.05.04.55.55.55.5
7.05.04.05.05.05.0
7.05.0<= 3.5<= 4.55.05.0
Output of new algorithm,

Too smart by half

One of the challenges in the smart home world is to distinguish between a group of functions associated with remote control of devices in the home for aesthetic or convenience reasons versus automation associated with the management of electricity costs, carbon management, or smart grid integration. I thus choose to differentiate using the terms Smart Home and Energy Smart.

Smart Home and Energy Smart

Smart Home

Functions within my Smart Home space include:

Space heating. In many homes space heating is controlled by a central thermostat and timer, possibly in combination with Thermostatic Radiator Valves (TRVs). In my home thermostats and timers are commonly pushed down to room level with individual rooms set points and schedules. General advice to reduce heating costs is to reduce heat loss through insulation and lower temperature set points, which I have but also add only heating rooms in which heat is required.

Window management. On occasions household members were known to go out leaving windows open. We now monitor the most commonly left open windows (plus the garage door) and use their status to illuminate and colour a smart bulb in the hall near the burglar alarm panel. The same window sensors can also be used to disable heating in rooms while the window is open.

Lighting control. We automate dusk-to-dawn external and internal lighting by the front door and in the downstairs hall. There’s overlap in bulbs between Window Management and Lighting Control.

Watchdog. To improve the robustness of all the rules operating the above functions, I have a smart plug that cycles on and off automatically at regular intervals and is used to trigger re-evaluation of the rules.

Energy Smart

Energy Smart functions include:

Battery Storage. Storing surplus output from my solar panels for later use, or buying energy from the grid when the price is low to avoid buying later when the price is higher.

Car charging. Managing my car charger to absorb surplus solar energy or buy energy from the grid when most cost-effective.

Water heating. Managing my car charger similarly.

Both Smart Home and Energy Smart

Wet goods. Controlling dishwasher and washing machine for lowest energy cost at the boundary of Smart Home and Energy Smart in both the Apple HomeKit ecosystem and with API integration for HEMS.

The Smart Home group of devices is managed via various user-friendly interfaces within apps like Apple’s Home or the Eve app where rules can be created of the form if {any trigger(s)} and {all conditions} then set {scene(s)}. These are processed by a hub which in my case is an Apple TV (or two).

On the other hand the Energy Smart devices are managed via the HEMS and are controlled by more fundamental programs (strictly in my case scripts) which are executed on my HEMS (which is based on a Raspberry Pi with HEMS-specific programming of my own creation.

In summary then, the Apple HomeKit ecosystem provides a smart home environment with a comparatively wide variety of supported devices managed from Apple’s own Home app or companion apps from the device manufacturers; while the Energy Smart side is in its relative infancy and (at least as far as my integration goes) quite a lot of bespoke software.

For me the need for much bespoke software is because I had the majority of the devices first with no thought when acquired of doing a HEMS-like project. They were originally bought or developed to maximise self-consumption of the output of my solar panels, so I had to develop the software to interface to what equipment I had. However for the Apple HomeKit, having settled on Apple HomeKit largely because we were iPad users, it becomes relatively easy to add additional devices that are sold as compatible with the HomeKit ecosystem.

Works with Apple HomeKit

Getting heated

Regular readers may recall that our hot water can be generated in 3 different ways: (i) conventional gas boiler, (ii) from grid electricity and (iii) from the surplus on my own solar panels. Attractions of these options are that gas is always available and stable in price, but my grid electricity is lower carbon and may at times be cheaper than gas, and my solar electricity is lowest in both carbon and cost but is subject to significant daily and seasonal variation.

The logic to sort out which source to use is managed by my HEMS. Gas is the baseline and the gas boiler is set to heat water for an hour a day in the early evening to ensure that baths etc are possible. The heating is thermostatically controlled so it doesn’t heat if the water is already hot, and that thermostat is set slightly lower than the immersion thermostat too.

The ImmerSUN normally operates automatically to divert surplus solar electricity proportionately to the immersion heater after the needs of general house load, battery charging and car charging have been taken. However if the electricity price is negative (yes, really) then the HEMS may override the ImmerSUN so that water heating is not done by free solar but instead may be delayed to allow use of paid-to-use electricity.

The final part of this triumvirate is buying electricity from the grid to heat water. Here the price of bought electricity is compared either to the price of gas and a decision made to use electricity when it is cheaper (it’s always lower CO2), or compared to the price of surplus solar (effectively zero) to buy from the grid. Both of these are obviously comparisons with a price threshold but until now the choice of threshold has been made manually – typically against gas in winter when solar output is limited and against solar in summer when more readily available. However the reality of UK weather is that this is a compromise as it may be very sunny one day but very dull the next.

Solar forecasting

The new refinement therefore is to use the existing solar forecasting integration. Solar forecasting already informs HEMS decisions about when to charge the storage battery from the grid and when to operate the wet goods (dishwasher and washing machine). The latest change is that the solar forecasting is now also use to choose whether to base a decision to buy electricity for water heating against a threshold related to the gas price or against the price of surplus solar PV.

HEMS schedule for July 4th.

The above schedule shows that, as a result of no significant solar production anticipated on the 4th, the HEMS has compared electricity price to gas price and thus elected to buy electricity from the grid to make hot water overnight since at 1.7640 to 2.4675 p/kWh electricity is cheaper than gas.

You learn something new every day.. WIFIPLUG

Increasingly I’m starting to use Siri when loading the dishwasher, as in (i) load dishwasher, (ii) start dishwasher, (iii) “Hey Siri, turn the dishwasher off”, and (iv) allow the HEMS to resume the cycle when then cycle cost is most attractive. The dishwasher (and washing machine) are operated by WIFIPLUG smart plugs to achieve this.

WIFIPLUGs v1 and v2.

However on occasions I used WIFIPLUG’s own app to control the plugs rather than Apple’s Home app, the Eve app, or Siri.

The WIFIPLUG app used for dishwasher and washing machine control

However I have a frustration with the WIFIPLUG app that it often takes three presses to turn the dishwasher off after starting the cycle:

  1. Initially the app shows that the plug is off, although the plug is physically on – the first press reports a communications issue.
  2. The second press reports that it’s turned the plug on, although the plug was physically already on.
  3. Only the third press turns the plug off as was the original intent.

However today I discovered that the WIFIPLUG app is not supposed to reflect the live status of the plugs, instead one swipes to refresh and then presses to toggle status – so two actions in my case rather than three listed above.

I find the need to swipe to refresh completely non-intuitive as both Apple’s Home app and the Eve app show the live status of devices and there is no refresh concept, but I suppose it’s reassuring to know that the app is designed to work this way rather than being broken.

In the meantime, to the best of my knowledge, WIFIPLUG is the only smart plug not only supporting Apple’s HomeKit ecosystem, but also having an exposed API for smart home integration, making it uniquely suited to my application.