Thanks @timo12357 ! This is what open source communities are at their best! I was doing sports with my younger kid and by the time I got home the community had already solved the issue <3
I updated the URL to the entsoe.js.txt which is attached to comment #13.
Thanks!
Markus
Yeah I forgot to mention that I’m running an early generation oc scripts. I didn’t update when newer arrived. But it sure did the trick.
The difference being that you leave decision on action to compressor to the pump’s control.
It’s a really widespread misbelief that people think they can do control better than the pump vendor can. I don’t believe it, and even those who do usually that’s turning 180 degress once you had to discuss with your vendor who is to pay for a repair.
It’s ok to do it in your solution but if your intention is to share and apply your code to other houses and pumps, too, you should not nudge users into that situation, and should use a standard interface logic instead that apply to all pumps likewise. That’s what only SGr can be.
I suggest to have a look if you can use modbus or other control to block your compressor for DHW
(domestic hot water).
so “1” does not refer to the number of slices but the maximum slice size ?
Ok then, but as that would always get you the cheapest power, why would there ever be a reason to use anything slice = larger than 1 ?
I’m not forcing anyone to do anything with their pumps which they don’t fully understand.
Quoting myself from the top of #13:
and
Coming back to the actual discussion here. I tend to agree with you that it would be good to update the “solution” so that it would use the SG Ready modes as the first method and then it could be mentioned that there’s also these other more intrusive external control options if somebody wants to go that path and understand what they are doing.
In general it would probably be a good idea to split this whole thing to separate threads so that there would be one page for the introduction, another for setting up the things, etc because this thread is now starting to be overwhelmingly long… I remember reading through some series by Rich Koshak which was written in that format where each “part” was then linking to a thread of its own… (not tagging him here as there’s no need to spam him with this thinking-out-loud thing…)
On this example day 9 hours of heating was allowed.
My ground source heat pump is 10 years old.There is no warranty left, I pay all reparations on this device in any fore- and unforeseeable case. Reducing starts per day is a key target for me to extend its lifetime beyond its planned or unplanned obsolecense. @masipila’s solution enables me to reduce starts per day, while also selecting the cheapest hours while doing it. This is good enough for me.
@mstormi Additional thinking-out-loud in the generalization of this solution for wider usage in addition to recommend the SG Ready modes first.
One of first hurdles over here is the fact that persisting the day-ahead spot prices currently requires me to bypass openHab persistence layer. I would like to contribute in making a proper Entso-E day-ahead binding but I’ve learnt that bindings cannot persist data and the definitely cannot persist a future time series.
If you have time and thoughts on these, I would appreciate your thoughts but these places are better threads for those discussions than this one…
See
Cheers,
Markus
Entso-E is again having troubles on publishing the prices for tomorrow.
Here is a small javascript that writes the Finnish prices (10% VAT) for tomorrow:
influx = require('kolapuuntie/influx.js');
measurement = 'spot_price';
points = [
{ "datetime":"2023-02-16T23:00:00Z", "value": 3.85 },
{ "datetime":"2023-02-17T00:00:00Z", "value": 3.47 },
{ "datetime":"2023-02-17T01:00:00Z", "value": 3.54 },
{ "datetime":"2023-02-17T02:00:00Z", "value": 3.53 },
{ "datetime":"2023-02-17T03:00:00Z", "value": 3.81 },
{ "datetime":"2023-02-17T04:00:00Z", "value": 5.8 },
{ "datetime":"2023-02-17T05:00:00Z", "value": 8.62 },
{ "datetime":"2023-02-17T06:00:00Z", "value": 10.34 },
{ "datetime":"2023-02-17T07:00:00Z", "value": 10.34 },
{ "datetime":"2023-02-17T08:00:00Z", "value": 9.79 },
{ "datetime":"2023-02-17T09:00:00Z", "value": 9.62 },
{ "datetime":"2023-02-17T10:00:00Z", "value": 10.17 },
{ "datetime":"2023-02-17T11:00:00Z", "value": 10.81 },
{ "datetime":"2023-02-17T12:00:00Z", "value": 9.89 },
{ "datetime":"2023-02-17T13:00:00Z", "value": 7.71 },
{ "datetime":"2023-02-17T14:00:00Z", "value": 6.59 },
{ "datetime":"2023-02-17T15:00:00Z", "value": 6.42 },
{ "datetime":"2023-02-17T16:00:00Z", "value": 5.83 },
{ "datetime":"2023-02-17T17:00:00Z", "value": 4.4 },
{ "datetime":"2023-02-17T18:00:00Z", "value": 4.05 },
{ "datetime":"2023-02-17T19:00:00Z", "value": 3.81 },
{ "datetime":"2023-02-17T20:00:00Z", "value": 3.62 },
{ "datetime":"2023-02-17T21:00:00Z", "value": 3.28 }
]
influx.writePoints(measurement, points);
You must have some typo in the YAML syntax. It’s much easier to configure the graph with the Design UI
Select the “configure series” and select the Item which you want to add.
To make this Bar Chart Item to be “stacked” with the other Bar Chart Items, you need to add the “stack” attribute to the YAML code because the openHab Design UI does not have this feature of Apache ECharts:
Hmm ok, but from a 30000ft view, you’re now optimizing in two dimensions, cost and comfort these are.
There’s no ‘objective’ single optimum in those, it depends how you weigh them in comparison and everyone’s mileage will vary. If for example you asked me, it would be 100% on cost savings, but if you asked my wife it sure would have a bias towards ‘have it warm at all times’.
Then again, my claim on this is that any house has sufficient thermal buffer capacity to compensate those dips. Plus almost any heat pump user has a water buffer so you need not produce heat the instant you need it to heat, you have a thermal battery that allows to postpone heating to the cheapest hours.
You effectively will not notice the dip. Well unless you have a non-isolated hut north of the polar circle, but then you likely won’t be operating a heat pump in any such ‘home’.
I’m a big fan of the KISS principle. So rather than to complicate calculations and code for it and nonetheless end up with an optimization that will be well below 100% (and very depending on who you ask), going for an all-financial optimization will get you those 100% without that you have to pay a relevant price for the comfort you lose. I’d claim it’s negligible.
(just don’t tell anyone - as soon as he or she knows, he or she WILL notice a “significant” drop in temperature due to well known psychological effects, just like you start shivering the moment you make yourself aware that winter is coming).
As you requested I responded over there in the other thread. I don’t see the need to bypass persistence but I understand that once your existing code has a focus on that idea it can be hard to back off from it. Requires substantial out-of-the-box thinking at times.
Glad to hear it does the job for you.
Modern, properly configured heat pumps however don’t start often any more, particularly as they can modulate rather than to repeatedly toggle on/off.
So I’d dare to postulate that for most people, this isn’t a good key target as it will not substantially increase longevity but it’ll cost you some (financial) efficiency.
That is very true. Modern ground source heatpumps use a variable frequency drive to control the compressor motor. These ground source heat pumps are designed to never stop or start, just to change the motor speed down and back up when needed. As far as I understand this extends the expected lifetime of the compressor significantly. Stopping the motor of such a system does not make any sense, as it would add starts and stops thereby adding risk of compressor failure. For ground source heat pumps that have a variable frequency drive SGready is the way to go.
Nibe 1226 and Nibe 1245 are from a time before variable frequency drives had made their way into ground source heat pumps. For an old ground source heat pump like these, it makes sense to try to force the pump to run in one go for as long as needed and to start it as few times as possible per day.
Why does the algorithm select the hour at 19:00 rather than the cheaper hour at 20:00?
2 slices, 8 allowed hours, midnight to midnight, 40% minimum share.
Timo
These are the two main objectives for me but the third one is to reduce the number of compressor starts to extend the compressor lifetime. My Nibe F1226 is not an inverter-pump that runs all the time but it’s a traditional on/off pump. For me this spot price optimization reduced the number of compressor starts by roughly 90% but not all of this can be attributed to the spot price optimization, a big factor is also that the water pump for domestic hot water is no longer running all the time as I mentioned earlier. But yeah, if we leave this frequency of compressor starts aside for a while, the main objectives to balance are the cost and comfort.
You’re making unsafe assumptions here, which is understandable because you live in a country which is way warmer than Finland. Here’s some context for you.
Let’s look at some data so that we don’t need to rely on opinions as data does not lie.
On January 4th the heating stopped at 06:00 and the inside temperature peaked at 09:00 at 20.5 C. At 23:00 the temperature had decreased to 19.3 C. This decrease is noticeable, but we’re used to it and it doesn’t bother us too much
Our family is optimizing cost in favor of comfort so we can tolerate this 1.2 degree dip. But not all families want to take it to this extreme and has higher weight for comfort, which means that you can’t leave the house unheated from 06:00 until 23:00. Which means that you need to allow some amount of heating in between. Which means that you either do the scheduling manually, or you let the algorithm do it for you automatically. If you want to automate it, you need an algorithm that can select the least expensive hours before the absolute cheapest period starts at 23.00.
The slicing concept (selecting some hours also during the day time) is important in houses which are either not that well insulated OR which heats with some other means than heat pumps. One of the most common ways to heat houses in Finland is that you have electric heating where the heat cables are inside the concrete floor. This means that there is no water that would buffer the energy, but the concrete floor can “store” heat energy. But the buffering effect is less than with underfloor water heating.
Point taken. Still wondering though.
First, I’m amazed you see that much of a drop in a that well insulated house.
Yes data does not lie but it’s a one-day snapshot that may or may not be representative.
I wonder if it was a particularly cold day ? Did you vent more than other people or on other days ?
Is the measuring point representative for the house ? etc.
Don’t bother to answer, questions are rhetorical.
Second aspect, if I understood your setup right, you don’t have a heating buffer but only do ‘direct heating’. That buffer would normally be emptied mid-day to heat/keep the temp up without consuming electricity. It would get refilled during cheapest night times.
Note the heating consumer side has a big impact on this, too. If you have say radiators with smart thermostats you can automatically turn consumption down during the day when you’re off for work.
Night times are often cheap times, but as many people lower temp per default at night times, it’ll effectively result in no or just very little use of the cheap power, resulting in a lower temperature starting point for the day.
Third - move some levels up in abstraction - how representative is this type of pricing curve, i.e. how often will it apply that you have a Gauss distribution-like curve with a lengthy expensive middle period?
I’m actually becoming customer of a variable tariff provider starting March, 1st, and in preparation have been watching prices daily and my first impression is that cheapest hours are jumping around wildly and interval length varies.
Your selection of say 3 slices may be optimal for days like this, but what if that’s a unicorn (well, rare) ?
You’d be running well 300+ days of the year with a suboptimal choice.
No worries… The day is a good and representative example of a cold and windy day. I updated the screenshot of my previous comment because it had cropped so that the right Y-axis was not visible so the outdoor temperature scale was not properly visible.
Now you can see from the screenshot that the outdoor temperature was -5 and dropped to -15. However, it was also a windy day. When it’s both cold AND windy, the heat loss is faster. That’s why I have that third temperature line which represents the “wind chill compensated temperature”. It was colder than -10 from the beginning and went below -15 on that day.
The days are very different… The spot prices in Finland are heavily dependent on three factors in practice:
First of all, our house does not need heating at all for summer months so that cuts down half of that 300 days 
But yes, your thinking-out-loud is valid. Our house (and our optimization objectives) need slicing only on the coldest days of the winter. I have that UI where I can easily adjust the number of slices to be something else than 1 which it usually is, see the screenshot in #165. Only on the most coldest days will I need to use slicing to force some heating during daytime.
Or do it with a rule based on e.g. weather forecast.
Mind you that that in turn is very specific to your setup.
Commonly a heat pump will be producing DHW, too. All year long.
In new well-insulated houses hot water can account for up to 50% year-avg of the electric energy that goes into your pump, and 100% in summer.
So 1 slice should really really be the default setting for everybody.
I currently don’t do it automatically based on the forecast, but it would be conceptually possible to do it like so. Maybe next winter
Yes, of course. During the summer months I simply allow 2 cheap hours for domestic hot water heating and 22 hours of the day the compressor is resting.
Markus
Thanks, found the bug in the algorithm, I had a classic offset by one… I will publish an updated script this evening.
Has anyone yet been in contact with Entsoe about when the service is getting back to normal?
I changed the url mentioned above and now I see:
2023-02-17 14:20:19.821 [ERROR] [nhab.automation.script.ui.7847d62ba6] - entsoe.js: Exception parsing spot prices: Cannot read property "period.timeInterval" from undefined
Or is this a new normal and the entsoe.js should be changed somehow?