Not at all connected to the current line of discussion in this thread but more on general experience from using a home-grown system for optimizing energy usage in our home for a couple of years:
There must be a functionality for human override. If one take the approach of thinking of this kind of systems as “autonomous advisory systems” rather than “steering systems”, I think the system will get a wider acceptance. The normal mode of operation I have found to be best is a “set and forget” approach, i.e. the normal is that the optimizer does it’s thing and I (or my family) as a user could not care less. But once in a while, you need that washer to do your laundry NOW regardless of energy prices on the spot market. Hence, a human override is essential.
With the high volatility (variance) of the energy prices it is helpful to consider the energy usage vs time for an appliance. A dishwasher (just to take an example) tends to have two very distinct peaks in it’s power usage. If your optimizer can account for a simple (and optional) profile of power usage of the appliance, the net result will be better optimization in terms of both price and running the appliance ASAP. In my system I have an optional “power vector”, if set the optimizer will use it and most of the time find a better solution, if not set, the optimizer will assume a constant load.
On the slightly philosophical side: What is “best” price? Is it the lowest total price? Is it time to start? Time to finish? Well, it depends. I don’t care if the washer starts doing the laundry at 23:15 or 02:00 as long as it tells med when it is done and I can hang the clothes to dry. But I would really care if my car is not charged at 07:20 when I am supposed to take the kids to school and go to work. So, in my world, “best” is definitely not always just “cheapest”. But - in order for me (or my system) to make the “best” decision, price is certainly a vital input in the optimization.
Consider the “when factor”. We humans have a tendency to expect things to happen ASAP. When I close the lid of my dishwasher, I for some reason expect it to do the dishes ASAP. In my system, I have a “time penalty factor” that I can enable when calling the optimizer stating that a cheap solution has to be X% cheaper than an earlier solution (closer to now()) in order to be used. Again, a minimal deviation from the cheapest solution but a function that contributes to increased Family Acceptance Factor of my automation.
Along that track: communicate the result of the optimizer’s job in the UI. Tell them when the washing machine (or whatever) will start unless they override the optimization. If I start an appliance and it goes dark without any explanation, I tend to wonder if something is wrong. If the UI in openHAB is saying “Laundry expected to start at 03:00, eta 04:30” the number of “Dad - why is the washer dead???” type of questions will be reduced to a minimum.Set and forget.
It is a mixture of mostly GOlang and openHAB. I do all data acquisition, persistence and rule management in GO, influxDB and some Telegram/MQTT and provides the final information to openHAB. I also use openHAB to detect events, like “Appliance X has started” and of course the UI.
As a number of this kind of applications it has been growing organically over the years. Since I felt it was time to do some refactoring of the code and with the inclusion of ECMAscript 2021 in openHAB I felt tempted to move the entire thing inside openHAB. That is a work in progress. Or, progress may not be the word coming from a strong typed environment to ECMAscript…
Slowly getting there but with some pain and scars along the way.
Right now, I’m trying to decide what to do with the persistence. I store all data on e.g. future energy prices, weather forecasts, appliance power profiles and historical data on the power usage of the house in separate influxDB databases/measurements (only vanilla openHAB in openhab_db) since I was afraid I would mess up future upgrades of openHAB. With the recent nice developments in openHAB (e.g. charting) it would probably be an advantage to have it all in the same database…
The graph you posted is a very clear example, thanks for sharing!
Do I interpret it correctly that on this example day you had 7 “overcapacity” periods?
How does the production vs. purchasing go in Germany? In Finland the production and purchasing is netted (if that is a word) with 1 hour resolution like this:
Production within 1 hour: 3 kWh, distributed equally 1 kWh per phase.
Well yes but “periods” is misleading hence bad wording here. It was PV surplus. That’s changing instantly on cloudy days so could happen thousands of times a day. I’m “debouncing” it by averaging values over a user configurable time span.
On “netting” in DE we still have the regulatory regime you used to have. It’s adding phases but doesn’t “net” in-out other than at the barest minimum possible level where this happens for technical measuring reasons.
Yeah, you were reading my mind what I was wondering.
I assume you have an EV yourself? How much of charging are you able to get from PV yourself and what times of day are you you typically able to charge the car? How have you implemented your charging optimization?
No, I’m still with a Diesel so cannot share much knowledge there other than that it’s usually cheapest to fuel it at 20:00-21:00
In my EMS I’m actually re-using EVCC which is another OSS project.
Their current implementation is 4 modes:
off
only pv surplus (with on/off if below the minimum charge power which is 6A/1.4kW per phase)
pv surplus but no on/off i.e. constant with a minimum of 1.4/4.2kW 1/3 phases
max
These EVCC modes I felt match SGr modes quite well and since I have the SGr-adjusted implementation for heat pumps, I just did the mapping for EV charging, too.
In EVCC you can configure a static price cap that if the Tibber tariff drops below, they start charging.
The EVCC guys are also discussing charge mode modifications towards having a ‘smart’ mode but AFAIK they have not ultimately decided on anything so far.
I have three DS18B20 temperature sensors measuring the temperature from the metal tank of the water heater. The blue line is from the up-most third, green one is from the middle of the tank and yellow is from the bottom third.
I’m going to skip the heating next night because it’s very expensive and the night after is going to be significantly cheaper. I also skipped last night because it too was very expensive as three nuclear reactors in Sweden were off grid at the same time and that caused prices to double also in Finland. To make sure that we don’t run out of hot water, I heated the water for 30 minutes. The thermostat is set to 75 degrees so this 30 min heating time was not enough to make the water heater / boiler to hit the thermostat max (which was not even my intention, because I will do the longer heating day after tomorrow).
The mixing effect can be seen in the diagram. When the heating went on, the temperature of the top of the tank decreased instead of increased. This is because the water layers got mixed and the cooler layers from the bottom went up.
My conclusion from this small experiment is that I will most definitely continue using consecutive heating periods with the 300 l water heater to be 100% sure that it hits the thermostat max on every single heating cycle. This will guarantee that there is zero risk of legionella bacteria. There have been several cases of legionella infections in the news in Finland this year, caused by too low temperature in the domestic hot water.
This is exactly the point @seime was making in comment 25. If the heating is split into for example 3 x 1h periods during the day and there is significant water consumption between these, it can be that the boiler does not reach the thermostat max temperature.
I’ve actually come up with a new optimization dimension to combine the above algorithm with I’d like
to hear your opinion on.
Thing is, efficiency of air-to-water (or air-to-X) heat pumps very much depends on outside air temperature. In short, when you heat during the coldest hour right before sunrise it’s say -10°C and noon that same day, with sun shining, temps can well rise to say +5°C, and note commonly provide temp values are measured in the shadow, in sunlight it can be even more, also in winter.
That 15°K spread can well make up for a 30% increase in efficiency. That’s potentially even more savings than what can be achieved through selecting cheapest hours.
While not intuitive it’s in fact clever to NOT heat when it’s coldest in the morning (and most expensive) and to heat around noon (when on average it’s both, warmer so more efficient AND cheaper).
There’s conflicts however in the evening (expensive once more but still somewhat warm) and even more so at night (cold so ineffective but then again cheap).
So how to handle those ?
I don’t think we can compare efficiency spread to price spread. I’ve spent a fair amount on design thinking but I have not come up with any good common metric I can think of to reliably compute savings and to simply compare to select the best strategy at any point in time.
So my idea was to use the 4(or 3)-level system laid out before (corresponding to SGready modes), plus sort hours by forecasted temp, and suppress heating during the n coldest hours.
Have that take precedence if there’s a conflict i.e. when it’s the normal heat level according to price but inefficient according to temperature (i.e. among the coldest hours), temp will rule and heating is suppressed that hour (n being user configurable again like in the old concept will ensure we don’t suppress too many hours of the day and user has the choice).
Also note the elegance of this: it’s rather simplistic in algorithmic terms and implementation, but more important it’ll work even if you have NO dynamic tariff ! (or if there’s problems obtaining the current price data).
Our house has a ground source heat pumps which takes the heat from a 170 meter deep hole drilled to the bedrock, which is not that sensitive to outdoor temperature changes. I have very little experience with air-to-air heat pump optimizations.
What your wrote makes sense though and the approach to block the coldest hours is probably one approach that can work, especially if the outdoor temperature is not so cold that heating can’t be blocked for that period.
I found a thesis where the COP of air-to-air pump was experimented on different outdoor temperatures and compared to what the manufacturer advertises. The results were like this:
So given that we know the hourly total electricity price (spot price + transfer tariffs and other price components) for day ahead, given that we know the hourly weather forecast for day ahead and given that we know (based on experience) how much heating is needed for tomorrow, it would also be possible to develop an algorithm that chooses the heating hours combining all this.
One thing that I’ve seen other folks doing with air-to-air heat pumps with spot price optimization is that they don’t switch it off during the expensive hours but they drop the set-temperature (target temperature) slightly and when it’s cheap, they increase the set-temperature. This is conceptually exactly what you are doing with your 3-4 “SG-ready” modes.
I’ve been thinking a lot about that but I don’t think that’s feasible in the general case.
As said, we cannot compare efficiency spread to cost spread in order to decide if to heat when one hour the cost algorithm says so but the temp algorithm does not or vice versa.
Thing is, if you forbid/postpone heating now you cannot compute when the hour to rectify/catch up will be. The amount of heat needed depends a lot on weather and the required amount of electrical energy depends on consumption of the day, plus the effect of solar (and non-solar) battery energy storage will ‘fuzz’ computations a lot.
So you cannot compute how expensive and how warm it’ll be that hour hence you don’t know if it’s better to make one or the other algorithm take precedence.
Well yes, but to dynamically adjust set-temperature requires another interface into the heat pump.
There’s proprietary IP interfaces on some pumps and even some openHAB bindings and there’s one pump I know of that implements the closed EEBUS standard, but it’s a single device only and general availability of an open such interface is what we’re far away from.
I’ve just implemented a sliding window in my energy management system for cheap hours to work with Tibber and aWATTar, the most popular dynamic tariff providers in Germany those are.
Now my flags (see post #1) aren’t computed per-day any more but forward-looking, i.e. they are set based on prices from <now> till as long as the info about forthcoming prices will last.
That should be overcoming the effect discussed here.
So now enforcing heat pump heating and EV charging will happen in the cheapest future hours (or barring during most expensive times).
Plus, I have incorporated a generic ‘catch up charging’ feature.
If consumption (+generation) forecast predicts that my (solar) battery is about to run dry the forthcoming night, I’m now charging it ahead of time when it’s the cheap hours.
It’s brand new so cannot share results yet but as preliminary info, here’s my tonight’s chart.
Thanks for diggin’ that up. So that would be an 84% increase in efficiency for my example, that’s more than we can gain from hedging tariffs.
Whoo-hoo !
It is not clear to me how you avoid the “Tinder dilemma”, i.e. always looking for a better future alternative leading to never actually getting any. I guess the question is: “When does your algorithm make decision to start or stop the heat pump?”
I think the Tinder comparison falls short.
Combining temp and price based optimization is somewhat tricky, see above, but as long as attractivity is a single dimension (price) it’s hardly ever-falling, in practice there’s a lower limit: with very few exceptions (limited to single days) price will remain above zero so you’re quickly hitting ground.
Plus, I don’t run the pump directly. My system just tells the pump that power is either A) cheap, B) expensive or C) neither of these and unless you choose an unreasonable number of hours there’s a remainder when neither A) nor B) is signalled and your pump will decide if to heat for you in that timeframe.
So in Tinder terms, when your buffer runs dry waiting for the perfect match it’ll take the next best offer.
The price will (almost) always stay above zero is not a safe assumption anymore at least here in Finland. Now that OL3 nuclear power plant is up and running and the capacity of wind power is growing all the time, the situation is that for example today’s average price is -0.14 c/kWh. Tomorrow’s average is -0.39 c/kWh (the most expensive hour tomorrow is 0 c/kWh).
Today and tomorrow are obviously exceptional days, it’s not like this every day. But the prices in general are so much more reasonable compared to what they were last year that I’m most probably going to follow the same suit that @mstormi is doing i.e. using the the SG-ready modes and letting the heat pump to decide the exact heating times.
The only thing is that my Nibe has only two AUX inputs so if I would configure these to be the SG-ready modes, then I lose control on when the domestic hot water heating takes place. I can easily do that on the absolute cheapest hour of the day and I would like to keep this. But it might be that I opt for more comfort-weighted optimization logic this winter instead of optimizing the price like I did last winter…
Here’s my tonight’s chart. It shows the battery being charged at 23:00 after a cheap day.
We didn’t have much sun but still as you can see a lot of consumption (heating, washing) was moved to before sunset (around 1800) because it was the cheap hours.
Consumption was mostly from grid (better than to charge battery first as that would involve losses).
Now charging at 2300 it wouldn’t have done that if I still was on the per-day calculation basis, but given the increase in price the next day (starting right the next hour) it was beneficial.
FYI, I’m not exclusively running the heat pump at cheap times but everything controllable such as my washing machine and EV charging (if only I had an e-car but at least my EMS is working fine).
My ‘available energy level’ calculation (to determine if to run any devices including the heat pump) as well as the recharge code are essentially independent of pump control.
Just sorta got hit albeit the other way round. I’ve defined to maximum-heat at most 1 hour i.e. the cheapest one in the forecast timeframe.
Now with an overall increase in tomorrow’s prices, this just resulted in 3 consecutive hours of maximum heating.
Next hour there’ll be a break. Just like I said the probability of hitting an ever-rising (or ever-falling ) timeframe is low enough to be ignorable.
so cannot share much knowledge there other than that it’s usually cheapest to fuel it at 20:00-21:00 
but at least my EMS is working fine).