I’ve just implemented generic cheap hours support in my Energy Management System.
I hope it to be a generic (binding/tariff provider independent) approach to be compatible with various dyn tariff providers.
Let me know what you think of this architecture.
Essentially I allow for user configuration of 3 parameters, the number of
cheapest hours to enforce maximum heating (translates to SGready mode 4 for heat pump control)
cheapest hours to have increased heating (SGready mode 3)
most expensive hours to prevent heating from happening (SGready mode 1)
Note that while I use the heat pump as the prime consumer example this concept is generic in a sense that it can be applied to control e.g. EV charging, too.
I have implemented logic in openHAB rules (and do not use that of any binding) that extracts Tibber prices from their API and processes them using user-provided (!) values for 1) - 3) to finally set 3 boolean flags to reflect if <right now> we are within those hours 1) - 3).
I then use those flags within my control loop (i.e. turn the heat pump into the aforementioned corresponding SGr modes).
Note the user can change those numbers of how many cheapest hours to use at any time. That’s one key difference compared to doing the computation in a binding.
Users can also implement some more-or-less-clever “AI” to determine the best numbers themselves.
For example you can record your power consumption to determine how much power you used for heating on a typical day with a specific outside temperature, say it was 4 hours then the next day with about the same temperature forecast you will set the number of increased heating hours to 4.
These calculations currently apply when I select to use Tibber as the tariff provider. The flag-setting OH rules implementation for aWATTar is different. Likewise it would be for for Energi DS and other providers.
As a product designer looking for broadmost applicability, I also have to provide a solution to customers that do not have any dynamic tariff. So there’s a tariff selector to apply first.
Implementing logic for a standard (flat) power tariff case however also makes sense should your dyn tariff API queries fail.
I’m planning to apply a different logic to determine those “cheapest” hours. I moved to use the term “best” hours rather than “cheapest” as price in fact isn’t the only metric that may apply.
Most people don’t have a dynamic tariff, and with a standard flat tariff selected, short of the price as the prime differentiator, for heat pump application it makes sense to e.g. use the current temperature as the next-best metric.
Any heat pump’s efficiency depends on outside temperature (eventually including wind chill), and those you can get from the weather forecast binding. Doing the heating in the warmest hours of a day is more efficient than in its coldest hours.
Now for other use cases such as EV charging, one could think of more different metrics what a best hour actually would be. Off-use hours for example. Using say that as a metric, it would tendingly avoid that the car is being scheduled to charge right during those hours you’ll need the car most like in the morning & evening to get to/back from your workplace. If you have say a GPS tracker or other interface into your car you could automatically track and (likely) determine those off-use hours.
The above concept is open for any user to implement his own metric.
Sorry for the radio silence. I’ve had one of the busiest periods of curling season so haven’t had much time lately (yay, we won the Finnish Championships in Mixed Doubles curling for the second year in a row).
I’ll read and comment your concept in the near future.
I like this concept of having different “modes” instead of just binary on or off.
My relative has a summer place which is not used much during the winters, which means that they decrease the temperature during winters when they are not there. They have an air-to-air heat pump which is sufficient until the outside temperature drops below a certain threshold and then the electricity floor heating kicks in.
Anyway, for the heat pump I implemented a heating strategy that it’s always on but the set temperature is changed between +15 and +20. The amount of needed +20 hours is calculated based on the weather forecast and this mode is toggled on when the spot prices are cheap. During other times the +15 mode is used.
This is conceptually very close to what you have with your sg ready modes.
Can you elaborate more on this, please?
I like this. Now that we finally have an electric vehicle, I can’t have all the big energy loads on at the same time because that would burn the main fuses. So calling them as “best” hours is better.
I have flag items that are ON during hours they apply, e.g. bestMaximal is ON when we’re within the n cheapmost hours with n defined by another (user-configurable) number item called besteStundenMaximal, essentially like this
j = (besteStundenMaximal.state as Number).intValue
f = Float::parseFloat(StromPreisSortiert.get(j - 1))
if ((dynTarifStrompreis.state as Number).floatValue <= f) {
bestMaximal.sendCommand(ON)
Tarifniveau.postUpdate(TarifOptimal)
logInfo("Energiemanagement", "aktueller Preis = " + dynTarifStrompreis.state + " ist günstiger oder gleich der " + j + ".-günstigsten Stunde = " + f)
} else
bestMaximal.sendCommand(OFF)
Then in my main routine, I proceed depending on this doing stuff like
if (ModusWaermepumpe.state == WPWinterbetrieb && bestMaximal.state == ON)
Waermepumpe.sendCommand(SGrMode4)
Ok, so you run a rule on every full hour and that rule then calls bestMaximal.sendCommand(ON) or bestMaximal.sendCommand(OFF) depending if that hour is within the N cheapest hours of the day?
No, and that’s by design.
When it’s the cheap hour then it’s the cheap hour, no matter if you charge EV or run the dish washer.
And not even thinking about what the huge increase in complexity to handle this would mean, I don’t see a valid point for doing it.
The real challenge in energy management is to find a sleek, simple path through the jungle of competing requirements of different devices when these aren’t fully congruent (i.e. collapse into single requirements).
My favorite design principle KISS (keep it simple, stupid) should apply, with different types of devices and requirements/limits/… it’s hard enough to find the ring algorithm to rule them all.
Aggregated power/Amperage for example should not be part of the management domain.
The electrical setup of your building shall remain responsible for “managing” that (toggle the fuse breakers if needed, that is).
Yeah, I don’t disagree with the design principle of simplicity.
The conclusion that I would make here is that there is one fundamental conceptual difference between the solution you have already implemented vs. the one that I have implemented. I’m not making a statement that one is better than the other, just writing down this observation.
If I’ve now understood correctly, the approach that you have chosen is that
User can defined (manually or with some sort of de-coupled automation) the number N how many cheap hours will be needed
You have this item “bestMaximal” which always reflects that “are we now within the cheapest window”
And the controlling of individual real-world things then rely on the state of this “bestMaximal” item so that for example the heat pump can be toggled to SG Ready Mode 4 when we are within the cheapest period of the day.
My solution, on the other hand is based on the concept of control points for each real world thing separately.
Each real world thing knows how many hours they will need next day.
My solution calculates the control points (either 1 or 0 currently, but these could also be different modes like SG Ready Modes) for each hour and for each device separately.
And then the real world things are toggled on or off (or to different modes) based on an hourly rule that checks that should the state be changed.
This difference has at least three consequences that come to my mind at first glance.
1 - The control-point based approach trivially supports that different real world things can need different amount of hours. For example last night:
We charged the car for 4 hours
We heated the house for 6 hours.
We heated domestic hot water for 2 hours
All this happened within the same 6 hour window, but the domestic hot water was the cheapest 2 hours even within this 6 hour cheap window
During the coldest winter period the house heating had to be ON for significantly longer period than for example the domestic hot water heating.
2 - The control point based approach provides an easy way to have the optimization for other time periods than midnight-to-midnight.
I’m not saying that your approach would not support this. It can be achieved, because you have the other rule that utilizes the state of the bestMaximal item and then toggles the real world things to their desired state.
But what I’m saying is that with the real-world-thing specific control point approach, it’s straight forward to find the 4 cheapest hours for the car charging between 21 and 06.
3 - The control point based approach allows different optimizing algorithms for different real world things.
I want for example that the car charging is done at one go i.e. the 4 hour window needs to be consecutive. Same thing with the heating of domestic hot water.
But for the house heating, I don’t mind if the heating hours are not consecutive, I just want to find the best hours no matter where they are during the day (+ I can use the slicing concept we discussed earlier).
Again, I’m not saying that the control point based approach would be somehow superior, I’m just saying that having the “per device” control point approach allows much more fine-grained optimization result.
Well, as said I have more than one flag, at least one level-3 and one level-4.
They, too, are overlapping like in your approach.
Given the DHW shouldn’t take more than one hour to ‘charge’, using the L-4 flag for that should do.
And remember it’s just a ‘strong hint’ but ultimately decision to heat is on the pump itself, and this
will work with any SGready heat pump which is more or less about any of them.
I don’t object to extending the number of windows (or call it flag or counter) and levels, in theory I could have up to as many as my number of devices which then would equal your concept I guess.
You can have another one for your wintertime heating use case.
But frankly I don’t see the benefit of that in most cases but disadvantages I do see. Any addition makes the system and its interdependent calculations more complex and harder to schedule. Having one window per device is really the worst case in that sense. We need to reduce the number of windows.
I’d object to apply the concept to EV charging, though. You don’t want to charge a car for n hours because you don’t know how much energy it’ll take in that time as that vastly depends on its current SoC, as does the whole process.
I know where you’re coming from, you don’t have PV power, but the prime objective in car charging is to only charge with surplus PV power as that’s available in most households to own an EV and it’s a lot cheaper than Tibber etc. are at their lowest rates.
In addition you might want to get it charged during the night (no PV then) to have a specific minimum SoC by a certain time in the morning, but the time you have available for that will vary greatly as it depends when you return from work or whatever use and connect your EV to the charger.
And there’s cars whose SoC you can read and there’s those you cannot. You often can’t do the math as you can do with heating.
With my concept you could have a separate window/flag for that and determine window length dynamically by e.g. roughly analysing car use hours and/or reading the SoC (if you can).
I would not call that an advantage. It’s a long term experience from my time of working with openHAB, providing support here on the forum as well as from that as a vendor of an energy management system that far too many people lose themselves in optimizing stuff over and over, without generating substantial gains in doing so. Any parameter you can tweak also is one parameter you have to tweak, needs to be documented, and there’s many questions about its workings and effects.
Making something configurable in this context is tempting, but rarely worth the efforts people choose to and need to put in.
It’s increasing the likelihood to introduce mistakes, particularly as they’re subject to change over time.
(A heat pump is probably the only use case that could be an exception to that statement.)
KISS as said is my favorite for this and too many more reasons and experiences than could be listed here) so I strongly suggest to go bolder on reducing the number of windows like I did.
You’re making quite a lot of bold assumptions and expressing them very strongly as facts…
I actually do. I just came home and observed that the state of charge is at 62%. I know based on experience that to get 10% increase in the charge level, it takes a bit less than 1 hour of charging time. The car limits the charge to 80% by default, so it’s one glance to conclude that I need to allow 2 cheapest hours next night. So I updated the “number of charging hours” item to value 2, and that immediately finds the best 2 hour window between 21 and 06. I have noticed that OpenHab has a Binding that should be able to read the current state of charge via the API of my car vendor, which means that I could automatically update the “number of charging hours” item but so far I have not had a need for that.
Umm, this might be the case in your neighborhood but it’s definitely not a safe assumption in Finland.
PVs don’t produce pretty much anything from the beginning of October until mid March because first of all we’re so North that we barely see the Sun during the winter. It’s completely damn dark when we go to work and it’s completely damn dark when we get home in the evening. Even if the car would be at home when we see those few hours of sunlight in the winter, the PV panels are covered by snow until the snow melts in mid-March. Here’s one real world solar power production graph.
So the prime object in car charging cannot be to do it with surplus PV power from the beginning of October until the end of February because there’s simply no production at all. If you happen to have PVs to begin with.
What comes to the heating of the houses in Finland. According to the official government stats, ground source heat pumps are used in 15% of the houses in Finland. Air-to-air heat pumps are used as the primary heating source in 12%. Direct heating with electricity is by far the most common with a 36% share.
The heating with direct electricity can further be split into two categories. There are houses where the heating resistors are in concrete floor, meaning that concrete floor reserves the energy quite well. And then there are houses with heating radiators, where they just heat the air meaning that the house will cool down significantly faster. For the direct electricity heating if has been very common especially this past winter that people have optimized the heating hours just like I have done it with the ground source heat pump. In other words, they calculate the number of needed heating hours based on the weather forecast and only heat the house on the absolute N cheapest hours. Or with radiators, a common strategy has been to have two modes where the difference is the set-temperature. During cheaper hours, the set-temperature is bumped up a couple of degrees and during not-cheapest hours the set-temperature is lower. This is conceptually very, very close to the SG Ready modes with ground source heat pumps.
The point of this comment is not in any way to say that your solution would not be applicable. I’m just saying that some of the very strongly expressed assumptions that you’re stating are not universally applicable. Just like the assumptions that I have behind my solutions might not be universally optimal.
Well. Clearly we have different starting points that get reflected in our differing focus, but we’re talking generic algorithm aiming to be applicable for any openHAB user, aren’t we ?
And given the populations of Germany and Finland and over-average percentage of German openHAB users due to its origin, I’d think that my focus is better at reflecting the average OH user’s situation, would you agree?
For example there’s way more PV plants (3M !) than there’s Tibber users (<100K) in DE, and we rarely have snow. But cars we have a lot
Taking the dynamics of PV into account is a challenge as you cannot do the math there like you can with heating and only hourly changing power tariffs.
Yes it’s complex and usage hence applicability of concepts is individual but I’d maintain my claim that the prime objective (I should have called it priority, it’s not the only one) with EVs is to get them charged with PV power only as that’s so much cheaper and available at least half of the year (maybe a little less in FI and some more in DE)
It applies to many more users, it’s different by nature and it’s a challenge to properly combine that with the dyn tariff approach. With multiple metrics it gets complicated quickly hence my stab at reducing complexity.
PV priority also applies to heat pump heating … that’s by the way what SGready was designed for.
In less insulated homes it’s hardly helping in winter and summer but mostly in spring and autumn, but in homes with latest insulation standards, about 50% is for domestic hot water which is all year.
And after all, the concepts are not very far from each other and when generalized properly, both approaches can be very easily achieved. Let me elaborate:
Your concept is to find user configurable N hour window and call it bestMaximal.
This is conceptually 100% equivalent of my control point concept. A user that is happy with having just one-size-fits-all N hour window could create one control point item called “bestMaximal” which would be TRUE for the N hours and FALSE for all other hours.
My standpoint here is that when we are discussing a generic concept that should be applicable to as many different use cases as possible, we should not make the decision on behalf of the user that there cannot be a second control point item, which is then used for some other device.
Furthermore: The different use cases (dish washer and house heating as the most obvious examples I can think of) can significantly benefit from the fact if these different control points can be calculated with different algorithms. One algorithm would be to find N cheapest consecutive hours and another to find N cheapest hours that do not need to be consecutive. And a third one could be driven by solar power forecast and have nothing to do with spot prices.
Well you skipped that I already have two or actually three such windows and don’t mind setting up more if an application would benefit from having its own. I also have one ‘inverted’ window to reflect the most expensive hours. But yes, we’re pretty close to each other.
The main difference is that I want to have a static small number of windows - as few as possible, to reduce complexity in programming as well as in using. Complexity leads to problems.
It’s three windows for a good reason: they reflect the SGready modes.
That’s what device vendors know and use as a concept, too, when they have implemented SGready.
Meanwhile you would like to have a potentially large number of windows hence need to implement a dynamic number of these.
I’m a bit reluctant at that remember the comments on and issues in those threads on aWATTar and Tibber binding regarding one-channel-for-every-hour and think what it would mean for a generic all-device implementation: dynamic channel creation! naming concept !
We would also need to sort out how dynamic PV power availability fits in.
And remember now it’s not your free-form case specific implementation in your chosen language any more but it’s about a binding to use openHAB concepts.
Could you please elaborate how do you determine these? I guess the hours do not need to be consecutive in any of your windows?
This is an excellent argument!
I’m not a fan of the channel-per-hour approach at all. All this stuff that we talk about here is a time series by nature, it’s just that the timestamps happen to be in the future and not in the past. Which is essentially what the ongoing discussion in github is all about. Well not all, but one very important aspect of it.
Computation is the same for all of them, just they each have their own n hours parameter to be used.
Consecutive, right they’re not. I see little point in insisting on this, where’s the application ?
Chunks are large enough (hours) so it’s not really about ON/OFF toggling we would need to be afraid of, right?
My point with the consecutive vs. non-consecutive is that I can easily see use cases where the device must not be interrupted during the program but at the same time, the user wants to schedule it for the cheapest moment of the day.
Example 1: dish washer most probably does not like if the program is interrupted but if the family needs to wash once per day, it can be scheduled for the cheapest hours of the night.
Example 2: domestic hot water with a water boiler (not a heat pump): We have a 300 liter tank and there is a huge layering effect so that the cold water is at the bottom and warm water is at the top. The hot water is taken from the top, which means that 50% of hot water can be consumed but the water on the top is still close to the max temperature. If I would heat this in 1 hour slots, the water layers will be mixed and it screws up the internal thermostat of the boiler.
Example 3: charging the car at night when it’s -20 and there is no PV available. I’ve let myself understand that part of the electricity is first used to heat the battery and only after that the actual charging takes place. I’m not sure about this, though. If this is true, it absolutely makes sense to charge the car at one go.
on #1 almost all dish washers don’t care to get interrupted, I’m selling this as a feature.
And major consumption is really 2kW for just ~20-30 mins of the first hour so it fits in a single chunk, the rest is <100W and barely worth scheduling. Ok, another peak at the end when drying but it’snot that large.
Washing machine, same. Only 1 peak there at the beginning.
#2 No, physics will make the hot water “unmix” and flow to the top anyway. I have a 300l tank, too.
And 1 (cheapest) hour is enough to heat the whole tank anyway.
on #3 Yes colder battery means slower charging but charging in itself will increase temp as a side effect anyway and in the end that’s what we want, no ? We have enough time during the night so no need to waste energy for preconditioning. That only applies to quick dc charging when en route where charge times are important.
Apart from that, we don’t have arbitrarily changing rates. Most commonly we have a single min-max hourly tariff so while not guaranteed, effectively the n cheapest hours are consecutive in fact most of the time or they’re 2 chunks at most.
All summed up, consecutiveness is an edge case and IMHO not worth to deal with. Fine to have it as an option but don’t let incorporating this complicate thinking on your main scheduling algorithm. That’s enough of a . I am reminded every day. Once more, KISS applies.
This is what I currently do, PV surplus if over a threshold will result in energy (SGr) mode 3, regardless of tariff
chiming in on this one. It’s no secret, that curren BEVs use LiIon batteries, which are somewhat allergic to being not loaded within a certain temperature frame from +5°C to +45°C. This means the BMS in the car will not load the battery if the battery pack is not in that timeframe - at least all the cars I know do come with a battery heater/cooler, not all come with a heat pump. So what does that mean: even if loading AC at home at your wallbox (doesn’t matter if the full 3-phase 11/22kW or PV excess from 6A per phase upwards) - the BMS will prioritize heating the battery up and then load it. Which means, in cold nights (and regardless in Germany with ~9°C medium yearly temperature of Finland with ~3,9°C) it’s best to load in one go and not clutter it to multiple “cheap hours”.
apart from the logic behind it: if your water layer storage messes with your thermostats of the boiler, then there’s something at fault here. You should check your boiler settings.
. I am reminded every day. Once more, KISS applies.