Feature Request: Limit calculations to a time slot

[volkerrichert]

i'd like to have the best price calculations to be limited to a timespan.

e.g. i'l like my e.g. dish washer / car / battery pack to be finished / charged at 8am. But when i schedule a "best block", it may get triggered noon.

Volker

[hombach]

same feature requested in #169 by @wunderlag

[hombach]

my current idea of implementation would be:

• there'll be a new state-object "EndHour"
• I wouldn't implement more granular than full hours - so "EndHour" is the last full hour that is included in search for good prices
• As "EndHour" is only a hour - there's no need to have this saved as datetime object (string) -> just an integer number
• Start would the be triggered externally by setting "EndHour" and/or "Active"
• When TibberLink calculator is handling a channel AND "EndHour" isn't "0" it would stop with the defined last hour and calculate only for this timespan
• reaching the hour after "EndHour", calculator would just set "Active" to "0" and stop the channel tasks herewith.

Are there better ideas? Doing it this way would be quite good to implement and will work with all 3 existing channel types.

This is not the same than "run each day from 12:00 to 19:00" .... !!!

[Wunderlag]

First of all, the adapter „tibber“ already does this, maybe you can find inspiration there. (Sadly it’s a little buggy, you can’t get it to run from 23:00-01:00 for example)

Thoughts on your implementation:

1. just „EndHour“ could mean 16:00 today or 16:00 tomorrow. (As I understand it, the prices overlap a couple of hours?)
2. Full hours are sufficient
3. Having separate „EndHour“ and „active“ gives possibilities for checking the state and deactivating more clearly
4. I’m not that fond of your current implementation with the settings inside the instance. It would be nice to set all available parameters with a script

I’m on mobile now, if needed I can elaborate further when I’m home

thanks for that awesome adapter btw ;)

Edit:

• Here is the Link to the referenced Tibber adapter: https://github.com/Magnus8513/ioBroker.tibber/blob/main/README.md
• changed example time
• specifically my problem with the current implementation is, that I can't define what the output of the calculation is. Maybe i want to control a second parameter dependent on the actual price (i.e. start charging and change SOC limit of a battery, but dependent on the actual price for that timeslot, ...). Also, I can't really trigger it externally or at least don't have a "status" while it's not engaged (i.e. My car is always plugged in and is waiting for excess PV production, but sometimes i want to make sure that I am at 90% by 06:00 but at the cheapest price. I manually trigger this via Button change, calculate how much time (x) it takes to charge before 06:00, find best block of (x) hours, start charging at "startTime". But I want to see that this mode is active and maybe want to deactivate it again if neccesary.) Of course some of that is not exactly dependent on your adapter, but just to give you an idea of what i mean.

Of course, your current implementation would be very easy to set up for the user, but it's not very flexible. Maybe you can just add an "advanced" mode that can be controlled by script, that would involve the following:

• Parameter endTime (2023-11-05 09:00)
• Parameter channelType (1=best hours block; 2=best single hours; 3=best cost)
• Parameter hoursAmount (3)
• Parameter trigger (triggers the calculation of the following output, resets itself when done)
• Output startTime (2023-11-05 03:00)
• Output offset ( [0,2,6] for 3 best single hours (=03:00; 05:00; 08:00) or [0,1,2,3] for 4 best hours block (=03:00; 04:00; 05:00; 06:00)

and that would be all I think?

[hombach]

@Wunderlag

Maybe i want to control a second parameter dependent on the actual price (i.e. start charging and change SOC limit of a battery, but dependent on the actual price for that timeslot, ...).

You could have some simple Blockly scripting or just use two channels in TibberLink with the same config - one writes true for charging the other has a SoC Value as output.

[Wunderlag]

I see your point, but my usecase would be

• Battery size 30kWh
• Estimated PV output for tomorrow 15kWh
• battery needs to be full tomorrow afternoon
• Set SoC to 50%

The next day it could be 5kWh PV Output, so SoC should be at 83%

maybe I’m overthinking this stuff?

[volkerrichert]

@Wunderlag I have the same use case. But how do you estimate PV output? All services provides wrong values (+50% - -50%)

[Wunderlag]

@volkerrichert i checked for a couple of weeks and came to the conclusion that mix of 2 sevices (forecast.solar + solcast / 2) comes pretty close, only problem now would be snow covered panels, but that's not really soveable I think :)

[volkerrichert]

@Wunderlag i have 3 different parts 2x south (32 & 12 Grad) and 1x north. That's not easy, sure. How do you do it? Just use the average?

[Wunderlag]

@volkerrichert oh yeah that might have a big impact. i only have one array facing directly south with 40° angle, this way there are almost no errors that can cause bigger ripples.

If you can, maybe save every single arrays daily output for a couple of weeks (with iobroker history or sql) and also map the forecasts from at least 2 sources (maybe even each with 3 settings for your 3 arrays). then use the data and try to match it. Maybe it's as easy as taking like (forecast x 0,6) for your estimates if its aligning better?

[volkerrichert]

@Wunderlag yes, maybe something like that.

[hombach]

@volkerrichert I would also try to get a better estiamtion by tracking first as @Wunderlag explained.

@Wunderlag : got your point.... for me this sounds like an extra feature request: e.g. "Have a JSON input interface for calculator settings" -> JSON Input-Object to be read and deleted afterwards by adapter - there could be all data included that should be changed in the "internal" config (and perhaps also in the state objects)

[Wunderlag]

@hombach That would work too, my explanation stems from the way I have implemented it from the other adapter and of course that would be easier to change if you did it my way ;) but I guess with some work on my scripts I'll be able to adapt to a JSON style option

[shelly20222]

@hombach thank you for your work. It is really great to have this adapter. and thank @volkerrichert @Wunderlag to your suggetions. I really have the same thoughts, so I am looking forward to a new version with the mentioned features :-)

[hombach]

"Have a JSON input interface for calculator settings" -> JSON Input-Object to be read and deleted afterwards by adapter - there could be all data included that should be changed in the "internal" config (and perhaps also in the state objects)

@Wunderlag I filed a new feature request to cover this needs: #194

[hombach]

To cover the base idea of this request "Feature Request: Limit calculations to a time slot" I want to implement:

• new Calculator state object "StartTime" (DateTime)
• new Calculator state object "StopTime" (DateTime)
• object "Active" of the same channel has to be set to False before and back to true after setting one of the above or both states.
• if "StartTime" or "StopTime" isn't set it will be set to the correponding first or last hour of the same day that the other state is defining.
• accuracy is 1 hour. So given times will be rounded to full hours
• if "StartTime" and "StopTime" aren't defining hours of the same day, the channel will work from StartTime to the end of the day and start next run from beginning of the next day, etc. etc.
• new channel types: BestCostLTF, BestSingleHoursLTF, BestHoursBlockLTF - LTS = Limited Time Frame

[hombach]

in implementation, version 1.6.0

[hombach]

HINT: The calculation is performed for "multiday" data. As we only have information for "today" and "tomorrow" (available after approximately 13:00), the time scope is effectively limited to a maximum of 35 hours. However, it's crucial to be mindful of this behavior because the calculated result may/will change around 13:00 when new data for tomorrow's prices becomes available.

To observe this dynamic change in the time scope for a standard channel, you may opt for a Long-Term Forecast (LTF) spanning several years. This is particularly useful for the "Best Single Hours LTF" scenario.

[hombach]

1.6.0 released to "latest" repository

[shelly20222]

I have tried the new feature over night. But somehow it didn't work.

These are my settings:

Tibberprices were best at around 3 a.m. Is there something wrong in my settings?

StartTime: 2023-11-28T19:00:00.000+01:00 StopTime: 2023-11-29T05:00:00.000+01:00

Or ist there something wrong with "beste Einzelstunden LTF" / "beste Stundenblock LTF" ? What is the difference exactly?

[hombach]

did you set active to true? Einzelstunden (best single hours) are the amounthours number of absolute best hours. Doesn't matter when. Best hours block is seaching for the best block of amounthours number of hours with the lowest total cost.... so for a washing mashine you should use best hours block

[shelly20222]

The active was Not Set to true. I have Tested IT and now it works fine. Thank you very much

[hombach]

OK - so I'll close this issue