Feature request: Future prices in one list
stigvi opened this issue · comments
Future prices as in the 0.5.0. version is great. Could you please, please, please, have these prices in one list instead of separating them in two, one for today and one for tomorrow? Having them in two lists makes template sensors for the cheapest hours thru the night much more difficult to make. Template sensors dealing with one list is easy to sort by price and you dont need to handle the strange situation around midnight when tomorrow suddenly is moved to today. Having two lists is also implemented in another integration (Nordpool) and handling them is so tedious in template sensors that the only solution is to use some python script to combine them to one list. One list needs to update once each 24 hours between 13:00 and 13:30. Two lists has to be updated twice each 24 hours, between 1300 and 1330 and at midnight. Finding the cheapest hours betwenn 22:00 and 06:00 is trivial with one list, and complex with two lists that change at midnight.
@Knodd Any comment on that?
The structure is based on the Nordpool to make it an "easy swap".
I'm guessing youre talking about "Today" and "Tomorrow" attributes?
I prefer not to include tomorrows prices in my automations until after 20.00 to avoid a cold house today if tomorrow's prices are very cheap :-)
If you prefer a combined list you can easily combine the two lists into one in a template sensor like this:
value_template: "{{ state_attr('sensor.total_price_XXX', 'today')+state_attr('sensor.total_price_XXX', 'tomorrow') }}"
(Remember to swap XXX for your address)
This will make [a,b,c] + [d,e,f] = [a,b,c,d,e,f] and you can use it in your automation.
Charging a car or heating the water through the night is common. Suppose I want to charge the car between 22:00 and 06:00 and want to find the 4 cheapest hours. I start with selecting the hours with state_attr('sensor.energy_price_', 'list')[22:30] and I sort it with state_attr('sensor.energy_price_', 'list')[22:30]|sort(attribute='total'). I now have the cheapest hours in element 1 to 4 and it is easy to check time and make a template sensor true or false based on this.
You suggest I could just add or combine the today and tomorrow lists. But it is [a,b,c] + [d,e,f] = [a,b,c,d,e,f] only before midnight. After midnight it is [d,e,f] + empty list = [d,e,f]. And a, b, and c are lost so I have to store them or information about them somewhere else in case those was the cheapest hours. All this extra logic makes it almost impossible to create with a single template sensor in HA. Template sensors does not maintain state of variables so anything that needs to be stored, must be done in another sensor created for this.
I work as a full time developer and are able to do this. I have already done it for the Nordpool integration. But I know inexperienced home users, with no or little practice in software development, really struggle with the concept of two different lists, that they change at midnight and finding the lowest price through the night.
Having one list wont make it difficult for you, either. With state_attr('sensor.energy_price_', 'list')[0:20] you will have a list with prices from midnight to 20:00
I don’t think I fully understand your needs here. You want todays prices to be retained in the list even after midnight? That would result in a system calculating todays behavior based on yesterdays prices between midnight and 13 if past prices are not sorted out actively.
I use todays prices for 00-20, todays and tomorrow’s prices combined 20-24 and then only tomorrow’s prices (as new today) 00-20 as a loop. I have template sensors calculating average for the current period and a block and boost level. My automations just check if current price is above or below these level templates to determine if to turn stuff off or boost the hot water
when you calculate the 4 cheapest hours between 22 and 6, why not write the threshold (4th cheapest price) to an input number and automate on current_price<=threshold_price between 22 and 6?
The API returns data as one list of dictionaries and it’s then split up into attributes for today and tomorrow for the different entities so it an easy implementation. I’just concerned about overloading the users with data making it seem overly complicated if we add today+tomorrow changing to today+yesterday at midnight on top of today and tomorrow as separate lists
In my opinion it would probably be more useful to add a “raw_data” entity containing the entire API result (7 days price history including tomorrow) for custom automation use
I want a single list with all the available prices wich are updated only between 13:00 and 13:30. It is the change wich happens currently on today and tomorrow lists at midnight, that makes it difficult.
Will keep it as it is for now