duration not working

[ascii42]

Hi,
after upgrade to 2.0.4 and migrate my old config, the duration (i.e. 3 hours) is not working correctly.
i have configured a 3 hours duration for a device, the starttime is looks good, but after one hour the planner switches off,,,

does anybody has similar issues?

[dala318]

Is it always like this, that it turn off after 1 hour?
In that case can you supply a summary of your current config (accept cost/rate + duration & search-length) and a screenshot with history data (planner-state and price) and even better point out in time when you believe it should keep on.

[ascii42]

Maybe it‘s my fault, but i‘ve ported my config 1:1 from the configuration file to the new version, it could also be a bug (somewhere in the calculation i quess)

So here is my output

[dala318]

What would help in understanding what's happening is if you could add a screenshot of state history like this, with at least 23h (your search length) after the faulty behavior of binary sensor.

Should maybe clarify that setting the duration to 5h as in your example does not guarantee that you get 5h consecutive ON. It's just the number of consecutive hours to average when searching for the lowest average cost.

So let's as example say you have a 5h time-span during every night where the electricity price is much cheaper than the rest of the hours (and have a 23h search length), you would then find that spot during the whole day and wait for it to happen, but halfway or so into that period the next nights cheap span will start appearing in the horizon of your search and if this average turn out to be cheaper than your current 5h average (from current hour and 5h forward) it will turn off and wait for the next night.

So if you really want to achieve a 5h consecutive ON-period you likely need to add some automation to the binary switch to ensure that. (I'll think of if it might be something to add to the integration, but a bit tricky to keep history data in internal logic, similar as I'm struggling with the "static" planner #54 )

[ascii42]

sure, here is a picture...

i've also tried a shorter search length, but the example was nearly the same. (i.e. 11 hours ... ) and i'm shure that this worked before in version 1.6.

[dala318]

Could still be something wrong in my integration, but can't really spot any obvious error in the data. But it you have one specific time where you think it should have stayed on, please point it out.

Some examples from your data:

It turn off at 12PM, average price until the green line (5h later) is at the purple level. Then then average price would be lower at around the orange section.

A bit more complicated.
It turn off at ~3AM (purple average price) since the average at ~9AM is cheaper (orange level), then once at that time an even cheaper average is found at 1AM the next day (light blue level)

An even more complex example where cheaper and cheaper averages keeps getting inside the search-length and making your planner stay off for almost 1.5 days. (keep aware that the prices you see in the Nordpool plot are not always available as future prices as I think they are released at noon for the upcoming day)

But as I write in the beginning, it could stil be an error in the integration, but please pin-point where you believe it should have stayed on longer and i can try to investigate more in detail.

One thing that can help while troubleshooting is to also add the "start at" sensor in history plot, then you see where the integration believe it has found a cheaper average. (I have different durations and search-length than you so don't compare exact values)

[ascii42]

well, i've reduced my search lengh to 11 hours.
don't get me wrong, the update is pretty cool, but i'am really confused, that an block of 3 hours worked better for my devices before the update.

maybe it would be cool, to add an option to use an coherent duration or an split duration. (just an idea)

[dala318]

but i'am really confused, that an block of 3 hours worked better for my devices before the update.

I don't think I have changed the expected design in that concern, but are some pretty large reworks in between v1 and v2. So either I have missed something in v2 (and if so I would like to know of it and fix), or it was actually a bug in v1 that worked in your favor but now is fixed.

If you can pin-point a specific time where you believe it should have stayed on, please share that history so that I can look in to the logic. (You should be able to add two integrations with different configurations)

maybe it would be cool, to add an option to use an coherent duration or an split duration. (just an idea)

Yes agree, I have some todo on that part, most of it is mentioned in #54, but are some concerns that I don't know howe to tackle.
Most of it relates to persistent storage so that the integration behaves predictable even if home assistant is restarted.

Have you tried tweaking the "accept_rate" config? If you have a price profile as in last picture your average price should be in the area of 0.30, setting an accept-rate of 0,5 should then turn on for every price below 0,15.

[ascii42]

accept_rate is an good point i will try this.
meanwhile i‘ve purged an reinstalled the integration and my spooky problem seems to be gone, maybe just another ghost in the shell….