There are a number of great Energy projects in Home Assistant. I wish to share my project for controlling my heat pumps to limit grid demand and cost. My target is to save > 50% from my historical energy bills.
Utility-scale management with distributed (solar) power sources is a complex issue. Utility cost, particularly for delivery of peak-power, is a major concern. My utility, Salt River Project (Phoenix, AZ USA) has responded with residential tariff for solar customers with low “volumetric” energy (kWh) rates but high (escalating) charges for on-peak power demand (kW). A detailed explanation with analysis may be found here:
Unfortunately, this pricing plan makes residential solar an unattractive investment for most customers. However, I decided to try to find a way to realize a ~10-year payback period for solar by writing my own “load controller” in HA. (I decided not to install a commercial load controller due to cost and to concerns about cycling appliance power off and on.)
Here I will outline the approach I am taking for demand/load control and home energy management.
This applies to home cooling during summer months.
II. Approach and equipment
My largest electrical loads during the summer are from two air-to-air split heat pumps. We defer other large loads to off-peak (hot water, laundry, oven etc.). Summer peak-tariff periods are from 14:00-20:00 weekdays. The automations control the use of the heat pumps. Rather than turn the HP’s on and off, the automation sets low or high temperature setpoints. This allows each HP to ramp power as designed.
I use a Sense Home Energy Monitor (Solar model), and I have two inverter heat pumps controlled by two Ecobee thermostats. The larger heat pump is for the downstairs (rated at 5 tons or 17.5 kW), and the smaller for the upstairs (rated at 3 tons or 10.5 kW). Typical power draw is much less than the rated power. The Ecobees are controlled by a Hubitat hub (I started in home automation with Hubitat), and I created two virtual switches that are shared with Home Assistant.
In Home Assistant I am using the Node-Red add-on for automation. I think Node Red greatly facilitated writing the main automation.
a. “Supercool” This is a simple automation that pre-cools the home from 08:00 – 14:00 (off-peak) to a setpoint adjusted based on the high-temperature forecast for the day. For hot days the setpoint is around 70 F (21 C). My wife complains about the “cold,” but pre-cooling is necessary to limit maximum temperature in the home later in the day.
b. Thermostat control. This is an automation that controls Ecobee temperature setpoints based on the state of the two virtual switches. If the “Upstairs Heatpump” switch is “on,” the setpoint on the corresponding Ecobee is set to 70 F (21 C). If it’s off the setpoint is set to 85 F (29.4 C). The same applies to the “Downstairs Thermostat.” This automation runs every 6 minutes to avoid excessive heat pump cycling but allow responsiveness to loss of solar power or to high grid demand. This automation is constrained to run only during peak-rate periods on weekdays.
c. Primary “Switch Automation” in Node Red. In NR, I decided not to create complex objects or arrays containing all the information required to set the switches, opting instead to use message payloads. I created a few global variables that are used several times in the flow. I also created a couple of sub-flows to tidy up the look a bit.
Note that this is my very first Node Red automation, and it’s likely there are more efficient ways of accomplishing the same goals.
Trigger (30 s) and set Global Variables. The automation uses Net Power production (Solar – total power use, minimum 0), the setpoints for the upstairs and downstairs thermostats, and reads in a Demand Limit from a helper. The two change nodes for thermostat setpoints pull the setpoints from the message object and set corresponding global variables. FYI, global variables are used since they are passed to sub-flows.
Main Automation. The green nodes are debug nodes. The blue call-service nodes simply set the states of the two virtual switches. For example:
Call service node that turns on both virtual switches.
The logic is set by several switch nodes.
First Power Switch:
This switch takes the rolling-average Net Power Production and evaluates whether there is enough excess power to start both heat pumps (output 1), enough excess power to start one of the two heat pumps (output 2), enough excess power to “do nothing” (if one or both heat pumps are running this is ok), or zero Net Power Production (which requires evaluating how much power is being pulled from the grid).
From here there are several possible combinations of Heat Pump states and grid export/import power levels that are used to set the virtual switches. Explaining the rest would require a very long (and very dull) post. But the idea is to set the switches in such a way as to keep the demand below a threshold (demand_limit).
So, how well does it work? Here is an example from yesterday.
Power and temperature plots for yesterday. On the power plot, you can see that grid demand fell at 14:00 (the start of the peak-tariff period). Around 16:00 it appeared that the automation was not working – you can see that power was being exported to the grid. I found that the Ecobee thermostats were in “eco+ mode,” and at that time my thermostats were ignoring the automation setpoints. Around 16:54 I turned eco+ off, but it was too late to prevent the home from becoming uncomfortably warm. Lesson learned!
(Apologies for using the Fahrenheit temperature scale – my wife would be unhappy if I set up the thermostats in Celsius.)
Yesterday, my power company reported that my peak demand was 1.2 kW, which occurred after sunset between 19:30 and 20:00. Maximum demand between 14:00 and 18:30 was 1.0 kW, a little below the automation’s demand_limit.
My June electric bill ran around 30% of historical values, and if I stay on-track with demand, July will be about the same. It’s early days, but so far, I am on-track with my goal to pay-back the solar panel investment in < 10 years.