search

hombach / ioBroker.tibberlink

links tibber API data to be used in ioBroker
https://github.com/hombach/ioBroker.tibberlink
GNU General Public License v3.0
23 stars 5 forks source link

Calculation triggers external state on day-change incorrectly #516

Open boriswerner opened 2 months ago

boriswerner commented 2 months ago

Describe the bug
I have a calculation for best hour LTF and want to have it check the best price for a time range of several days. I activated the calculation on 09.09.2024 10:00 with the following values: tibberlink.0.Homes.[id].Calculations.0.StartTime = 2024-09-09T10:00:00.000+02:00 tibberlink.0.Homes.[id].Calculations.0.StopTime = 2024-09-13T23:00:00.000+02:00

On activation the best price was identified on 09.09. at 15:00. After the update of the prices at 13:00 the new best price is identified for the next day 10.09. 13:00. The calculation updated from tibberlink.0.Homes.[id].0.BlockStartFullHour=15 to tibberlink.0.Homes.[id].0.BlockStartFullHour=13. In addition my external target state that I configured in the instance was set to true (i checked the last change date and that was at 13:01 today) so the external trigger was activated. The internal state tibberlink.0.Homes.[id].Calculations.0.Active was not changed and remained false.

To Reproduce
Hard to reproduce as the best price for the next day has to be better as todays best price and the new best price has to start at exactly 13:00 the next day.

Expected behavior
Not trigger the external state as also the internal "Active"-Flag was not triggered. Seems to be a timing issue? Maybe also add a date information for the Block Start and End Times (also valuable if the best price block ranges from e.g. 23:00 to 01:00).

Screenshots & Logfiles

Versions:

Additional context
Add any other context about the problem here.

hombach commented 1 month ago

The internal state tibberlink.0.Homes.[id].Calculations.0.Active was not changed and remained false.

This state is used to active the calculator channel.... it's not changed by the adapter itself till the end of an LTF StopTime. So I am a little bit confused that it "remains false" ....

Sorry I don't get your point exactly.... perhaps you could explain your use case...

I have a calculation for best hour LTF and want to have it check the best price for a time range of several days.

Adapter could only look max 35h ahead (13:00, getting new prices for next day till end of next day) - so, "best price for a time range of several days" doesn't work - unfortunately. Or are you looking for the best price each day, for a couple of days?

hombach commented 1 month ago

@boriswerner Is the problem still present?