Not trying to add unnecessary complexity here, but another use case for consecutive runtimes is to ensure water boilers reaches high enough temperature to kill any legionella bacteria.
I usually need close to 3 hours of heating (12-15kwh) before the built-in thermostat is happy (also confirmed via multiple temp sensors). Splitting over up to 3 random periods usually won’t bring it to safe temperature if water consumption happens within the same 24 hour scheduling period.
I think most users would strongly prefer not getting infected over saving a few cents a day.
(I have a similar system as @masipila only implemented in Java/JRule with blessing unit tests)
Well, apart from the fact that most to get a heat pump will also have or get a separate fresh water reservoir (which doesn’t require the oldish type of legionella desinfection), please do not put too much emphasis on edge cases.
Remember that even if you drop out of the cheapest hours it doesn’t mean your reservoir heating or EV charging will stop. It will continue, just the price will be a little higher (some single-digit cents, nothing to worry about when that’s just once a week or so like desinfection typically is).
The type of boiler I have is in fact the very standard at least here in Norway. I would argue that the type of boiler you are describing is in fact the edge case . For general heating we mostly use electrical panel heaters and air to air heat pumps, but also water to water heat pumps for floor heating as well as centralized hot water supply in some central areas.
I am using both start and stop time and allows for splitting of the period in case it falls to the evening. So the cheapest hour before getting up in the morning and the rest when it is cheapest.
full ACK as those kind of heating is standard at least in southern Germany also. You’ve got some water storage layer, which was usually heated by oil or gas and provides the heat for your underfloor heating. Some use this layer also for hot water via plate heat exchanger. So you can de-couple generating heat from using it and you need less boiler starts. Recommended since years for gas boilers to avoid burning too much fuelage and thus clugging - and especially for heat pumps as they don’t like intensive cycling re their compressor life time. I’d argue paying a few cents more per energy for having it run consecutively is cheaper than having it replaced in a few years.
Apologies for being frank but you expose a questionable understanding of what ‘edge case’ means.
First, it’s about the relative number of cases to apply. We’re talking about a genuine algorithm for every OH user so Norwegian (pre)conditions aren’t representative. Not saying German ones are, but they at least make up for a substantially larger percentage of the user base the EM algorithm is to be applied to.
But second, and this is even more important, it’s also about the impact to apply.
When it’s just some cents once a week, who cares? That’s also an edge case even if that applies to millions.
Let’s not make the very common mistake to design software that is meant to work well for everybody and that we know is gonna be complex and often sub-optimal anyway by approaching it from a personal anecdotal-individual perspective. Please let’s take a systematic, quantitative approach.
PS just for fun’s sake but somewhat related, I just (in parallel) read this on the state of discussion on summer time (use translator)
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 !
. For general heating we mostly use electrical panel heaters and air to air heat pumps, but also water to water heat pumps for floor heating as well as centralized hot water supply in some central areas.
so cannot share much knowledge there other than that it’s usually cheapest to fuel it at 20:00-21:00 
