It’s now around four and half years since I bought my Powervault G200 storage battery and two years since I started managing it from my Home Energy Management System (HEMS).
Originally the Powervault set up simply to store surplus electricity from my solar panels for later use but, following my change to Octopus’ Agile tariff, I started to use the Powervault to optimize electricity costs when there wasn’t going to be enough solar, charging when electricity was relatively cheap and discharging when electricity was relatively expensive. Initially I configured the Powervault manually to achieve this but later moved to the HEMS doing it automatically.
The fundamental principle has remained the same through both manual and automated periods, with the battery being set into one of three modes depending on price:
Force charge – where the battery charges at full power (usually from the grid) for the required number of hours – when grid electricity price is cheapest.
Only charge – when the battery charges proportionally to the solar surplus (but will not discharge) – when grid electricity is mid-price (i.e. too close to the price at which the battery was being force charged to be economically advantageous to discharge)
Normal – when the battery charges or discharges proportionately to the solar surplus/shortfall – when grid electricity is comparatively expensive compared to the force charge price.
The current logic now reflects electricity price, time of day and state of charge. The fundamental relationship is with grid electricity price as previously described, but with two further refinements:
During the day, even when the electricity price is relatively high, the battery is held in charge only until 80% state of charge is obtained. This helps ensure that a high state of charge is obtained before the early evening peak in Agile prices from 4 to 7 PM by not allowing the battery to discharge while the expectation is that it is being charged from solar. In the depths of winter, when the battery is more likely to be charged overnight and thus start the day with a high state of charge, the same logic allows the battery to discharge to 80% if electricity is costly during the day but still preserves charge for the early evening peak.
Similarly if the battery is full, but the grid price is medium, then the battery is also allowed to discharge to 95% during the day. This allows the battery to discharge slightly to cover small peaks of demand on the assumption that a small amount of solar recharge may well be possible even if the solar forecast wasn’t high enough for recharging at full power.
To consider the two bookends of behaviour:
On a really sunny day like tomorrow, the HEMS doesn’t anticipate any need to buy electricity from the grid for battery charging so all electricity is relatively expensive. The HEMS will allow the battery to discharge overnight (completely if necessary) . From 8:00 AM the battery will only be allowed to charge until 80% state of charge or 4:00 PM is reached after which the battery will be put back in Normal operation when it has the freedom to either charge or discharge.
On a winters day, the HEMS potentially fully charges the battery overnight. Between 8:00 AM and 4:00 PM the battery is allowed to discharge to 95% if grid electricity is mid-price (with some hope that the 5% may be recovered from solar), or to 80% if grid electricity is high price. After 4:00 PM the battery reverts to Normal operation for the evening peak period.
I’m very pleased with how robustly my battery integration operates. It is however reliant on the continuing availability of the Powervault G200 cloud which may not be around forever as the G200 model has now been superseded. My own example is currently four and a half years old.
We have a lot of batteries. The kids’ toys seem to use endless quantities of AA and AAA batteries plus many of my HomeKit smart devices including sensors and radiator valves are battery powered (typically AA or 1/2 AA). Over the last few years I’ve been replacing disposable batteries with rechargeable batteries to reduce waste. So far every device has worked successfully on rechargeable batteries (even when the manufacturer didn’t recommend them) although in some cases low battery warnings are triggered almost continuously since the Nickel Metal Hybrid (Ni-MH) rechargeable batteries are slightly lower voltage than regular disposable alkaline batteries (1.2 versus 1.5 Volts).
Last year I came across a Lithium AA battery that had potential to avoid such issues. Normally Lithium cells have voltages in the 3-4 Volts range, but these batteries have internal voltage regulation to reduce this down to 1.5 Volts. They need a special charger, but have the potential to eliminate the almost continuous low voltage messages.
I’ve now been using the first of these for six months. They have indeed eliminated the low battery messages. I still recharge the batteries at the end of every quarter regardless of whether I have a low battery warning or not. For the Ni-MH batteries they get replaced because the low battery warning is on most of the time anyway, while for the Lithiums I’m anticipating that the voltage may dramatically collapse not leaving time to change them after the low voltage warning is triggered. I now have three sets of eight which is enough for all my Eve Thermo smart radiator valves (eTRVs).
They are currently available via both Amazon and eBay, although Amazon seems to have the better prices whenever I’ve looked.
My sole criticism of these batteries is that they only seem to be available in sets with a charger, and not as just cells, so I now have three chargers.
I now have rechargeable Lithium cells for all my Eve Thermos (2 x 1.5V AA each) and Eve Door and Window sensors (1 x 3.7V 1/2 AA each). The Eve Room and Eve Motion sensors don’t seem to mind the lower voltage Ni-MH cells.
My home unusually uses HomeKit smart automation for central heating control among other things. One feature that I’ve not seen documented elsewhere is use of a watchdog to improve robustness of the automations. Many people of course will use HomeKit as a fancy remote control, but in my case HomeKit automations have an important role in heating control linking heat demand from rooms to enabling the boiler to provide heat. It’s thus important to me that this link works reliably. However in my experience sometimes changes in state can be missed leaving the boiler not running when it should be, or running when it shouldn’t be, an error which could last for hours.
Some two-and-a-half years ago I created a means to improve the robustness of such automations. My watchdog is a HomeKit smart plug which cycles on and off periodically. Two timers alternately turn the plug or or off every few minutes. The change of state of the watchdog is used as a second trigger for the rules in the automations causing the rules to be reevaluated every few minutes.
To illustrate what this achieves let’s imagine that the HomeKit ecosystem misses one trigger in ten or 10% of triggers. That would mean that one night in ten the boiler would fail to turn off when the last radiator valve closed, and would instead run all night. With the watchdog concept the rules are re-evaluated every few minutes, not just at the moment a valve closes. Thus, within a few minutes the rules are evaluated again and then ninety percent of the missed ten percent of events corrected – the error rate is now down to one percent from ten percent. A few minutes later the rules are evaluated a third time and ninety percent of the remaining one percent of errors corrected – the error rate is now a tenth of one percent or once in every thousand days. The risk of a continuing error state thus becomes vanishing small in minutes.
Previously the period of the cycle was five minutes i.e. the timer repeating an on/off cycle every five minutes. Five minutes was chosen as that’s the minimum cycle time available in the Eve app that I use to write rules. Today I realised that I could improve this significantly.
The illustration above shows the new solution. Here I created 3 on and 3 off rules which each repeat every six minutes, which causes the state of the watchdog to change every minute..
watchdog off (off rule #1)
watchdog on (on rule #1)
watchdog off (off rule #2)
watchdog on (on rule #2)
watchdog off (off rule #3)
watchdog on (on rule #3)
watchdog off (off rule #1).. and repeat indefinitely.
The illustration below shows a typical rule which turns off the watchdog and repeats every 6 minutes.
The net result is that my watchdog smart plug now turns on every even minute and off every odd minute which I think provides the minimum possible delay before the system responds after any missed change of state.