node-red-contrib-power-saver best save not working well

bestsave heats my water at too many expensive hours. It's configured with 2H recovery but runs at least 4 hours/day - and tomorrow will run 7 hours of which 4 are quite expensive compared to the 3 cheapest hours that day (which SHOULD have been the only hours picked).

Sep 16 '22 21:09 vidarak

I believe you have interpreted the result incorrect. It finds the best saving at 08:00 on the 16th, and it saves for 22 hours, that is your maximum. That period is selected first. Then it selects some additional periods that also gives savings, but there is no room for other that long periods. This is how Best Save is supposed to work. You can try yourself here: https://powersaver.no/faq/best-save-viewer.html#tool

If you expect another result, maybe what you need is the Lowest Price node?

Sep 22 '22 06:09 ottopaulsen

I guess I want a lowest price node that finds the lowest price for the configured amount of non-consecutive hours but still provides power on other scattered hours where the price is low (a configurable % diff from min/avg/max) in the selected period.

Regardless, bestsave logic/idea seems a bit broken. If it is set with recovery for 2 hours after a 22 hour period, there is no need for bestsave to power on for 2 consecutive much pricier hours at scattered times within the 22 hour saving period as well. It should only power on for single hours beyond the 2 hours configured for recovery.

I don't understand why these would be ON since their price is much higher than the minimum price in that period: {"price":3.4011,"onOff":true,"start":"2022-09-17T19:00:00+02:00","saving":null}, {"price":3.5651,"onOff":true,"start":"2022-09-17T22:00:00+02:00","saving":null}, {"price":3.8011,"onOff":true,"start":"2022-09-17T23:00:00+02:00","saving":null}

Sep 22 '22 10:09 vidarak

I dont't think you understand the idea with the Best Save node. It assumes that energy is consumed more or less continuously, like you do with a water heater, for example, or a jacuzzi, etc. However, it is also assumed that you can postpone the "replacement" of the consumed energy, that is you can postpone heating the water, and the idea is that you can postpone this up to a certain number of hours. But you postpone only if that makes you save money. If there is nothing to save, there is no reason to postpone. Then you can just as well heat the water immediately.

For me it makes little sense to postpone for 22 hours. If that is ok, you can just look for the 2 cheapest hours in the whole day and use them. That is what you do with the Lowest Price node. The Best Save node looks for the optimal places to postpone consumption within the rules that are configured. And it is absolutely not broken. And as far as I can see it is working well in your case too. Maybe not what you want, but it is working as it is supposed to do.

Sep 22 '22 20:09 ottopaulsen

I'm using it for my water heater. Usually 2 hours/day is enough. Sometimes not (so I wouldn't mind it to heating the water during some slightly more expensive hours also - especially if they are scattered a bit throughout the day).

I just think in my example it shouldn't have planned to heat water in the mentioned hours where the price was 2x or 3x higher than just a few hours earlier in that day.

On the 16th it shouldn't have heated these hours: {"price":5.1421,"onOff":true,"start":"2022-09-16T06:00:00+02:00","saving":null} {"price":5.8301,"onOff":true,"start":"2022-09-16T07:00:00+02:00","saving":null} (which were directly following these much cheaper hours: {"price":2.2841,"onOff":true,"start":"2022-09-16T04:00:00+02:00","saving":null} {"price":3.1831,"onOff":true,"start":"2022-09-16T05:00:00+02:00","saving":null}

Instead if could have heated these hours on the 16th: {"price":3.4701,"onOff":false,"start":"2022-09-16T21:00:00+02:00","saving":1.86} {"price":3.3911,"onOff":false,"start":"2022-09-16T23:00:00+02:00","saving":1.781}

Are you able to explain why you think the bestsave plan in my example is better than my proposal?

Consider this; on 16th the plan started heating at 4AM. At this point and also at 5AM, 6AM and 7AM it only knows the price until midnight... so it doesn't know the price 22 hours ahead. It does however know that at 9PM and 11PM (last hour it knows the price for) the price is going to be cheaper than at 6AM and 7AM. Despite this, it choses to heat 6AM-7AM (Directly after a 2-hour recovery period where one would expect the water to be fully heated)...? It just doesn't make sense.

Sep 22 '22 23:09 vidarak

@vidarak What @ottopaulsen said.

If you want to make sure you heat water at the cheapest periods, use the "lowest price" node. I'm using two of them, each looking at a 12hour interval, to make sure I run the heater at least a couple of hours every 12 hours. See my response here for details.

Oct 04 '22 13:10 marhoy

Thanks, I'm not a developer but I was hoping to fix this by building my own forked and optimized powersaver module. As a start, I'm now using the dynamic configuration option. It checks if tomorrow's price data is available and configures Lowest Price from 14:00 to 14:00 based on that. (if not, from 00 to 00). It also looks at price deviation beyond the configured hours while considering how many hours have passed since the water last reached max temp (no power drawn while switch is still on) to possibly add a couple of extra hours. If the price in the evening (2300) is high (prices likely trending upwards) it will try adding an extra hour today. If the price in the evening is low, it will avoid adding extra hours that day (anticipating lower prices the next day). Saturdays and Sundays I add an extra hour just because prices are typically low. Code is ugly and not rigorously tested/tuned so prefer not to share publicly yet (It should have heated 2 hours today). ;-)

Oct 04 '22 14:10 vidarak

I have a very similar issue, that is clearly visible in the chart above. The algorithm above finds the hour with lowest cost, and then run for the recovery time.

The issue I have is that the lowest cost for the recovering time may not start on the our with lowest cost, it may very well be some hours before if you are recovering for several hours.

Take a look at the image from @vidarak. It starts at about 6 in the morning, and then recovers during the most costly time of day. That is because the least costly and most costly hours are next to each other.

What would be more interesting, for an end user perspective, is to have the recovery during the least costly period, not starting on the least costly hour. In this case it may have been better to start an hour earlier to avoid the very costly time.

Instead of doing:

Find least costly hour
Add recovery time to this hour as period end time, regardless of price on recover hours

Consider doing:

Foreach possible start period
- Summarize price for current period + recovery duration and remember price as a possible recovery period
Use the least costly period

Feb 16 '23 10:02 olle-j

It is true that the algorithm assumes that you recover all the saved energy during the first hour of recovery, and as you suggest, it would have been more accurate to use the average price for all the recovery hours. I will consider making such a change.

Feb 16 '23 21:02 ottopaulsen

node-red-contrib-power-saver node-red-contrib-power-saver copied to clipboard

best save not working well

node-red-contrib-power-saver
node-red-contrib-power-saver copied to clipboard