I’d rather argue that in the use case context, it’s advantageous to have a second load chunk right in the morning before you leave for work. Cheapest rates are often the hours before 6 and your car will be better prepared for the drive. I’d even move on to state that we don’t want consecutiveness in this case.
Applies even more so if you use cabin preconditioning, I’d guess in Finland you do a lot.
I do also here in southern Germany! 
But your arguing depends on having a heat pump. If your car doesn’t have a heat pump, then you gain nothing from a warm battery. And there’s a lot (normally cheap, but also some more expensive) BEVs, that don’t have one.
But normally cabin pre-heating isn’t that “expensive”. It needs about 3-4kW for a max of 15mins, and that’s normally not even a kWh. Loading your car in 20°C with 16A/phase probably uses up more load loss in one hour than this pre-heating.
One more thing related to two topics that have been recently discussed here.
The day ahead market currently uses a one hour time resolution. In other words, each hour has its own price.
The time resolution of the day ahead market will most likely change to 15 minutes in 2025. It is going to change to 15 minutes on the intra day market already in this May, but it will not yet affect consumer agreements at this point.
What does this mean in our context?
-
If we store the day ahead prices in different channel like awattar binding does, it would mean 4 x 24 = 96 channels (!)
-
After that change it’s probably less likely that the cheapest individual slots are one after each other (even though I would assume that most of the timecthey still are). Whether or not the mode changes back and forth every 15 mins is a good or bad thing depends of course on the real world device. But latest at this point I would assume that it will be desireable to be able to do our optimizations so that our system will guarantee consecutive run time.
2 Likes
My $0.02 on this consecutive thing.
First, IMHO it’s just covering edge cases and therefore is not worth the effort.
Remember that in the general case, a consecutive chunk is genuinely worse than are multiple chunks or equal at best because you cannot always have all cheapest hours in a row.
Note that’s a debit that the use case needs to compensate before it can turn into an advantage and to be frank, those examples weren’t convincing to me.
More chunks will only mean this is even getting worse.
But what worries me way more is that permanent peeking at consecutiveness can make for a huge difference in implementation complexity.
Allow me to remind you that I myself have already gone through the ups and downs of full-blown implementation of an EMS combining different energy provider and consumer types.
I’ve been scratching my head on lots of occasions throughout that development process, trying to recap how the algorithm should be behaving while debugging why it didn’t. It’s so complex really, mind blowing at times. KISS is really of utmost importance here, far more than you might be willing to admit as long as you only look at it from the theoretical pov as we all currently still do.
Let’s reduce complexity by design. It’ll be hard enough to come up with a clever, correct algorithm and implementation to do the scheduling without incorporating consecutiveness.
I’d therefore suggest to start without looking at it. It can be added at any later time, think of it as an option. Peace deal?
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)
Cheers
3 Likes
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.
1 Like
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.
2 Likes
What’s your “system”: openHAB or an external application?
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…
2 Likes
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.
Consumption / phase 1: 3 kWh
Consumption/ phase 2: 1 kWh
Consumption / phase 3: 0 kWh
Net result: all production of that hour is considered to go to own consumption and 1 kWh is purchased.
Previously we did not have this kind of netting in Finland so the result would have been 2 kWh purchasing and 1 kWh selling.
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?
Cheers,
Markus
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.
Example from today.
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.
Cheers,
Markus
2 Likes
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.
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).
wdyt?