{% set fclist = state_attr('sensor.zonneplan_current_electricity_tariff','forcast') %}
{% set plist = fclist|map(attribute='price')|list %}
{% set ns = namespace(fc2=[]) %}
{%- for fc in fclist[:-1] -%}
{%- set ns.fc2 = ns.fc2 + [{'datetime':fc['datetime'],'price':(plist[loop.index0] + plist[loop.index0+1])/2}] -%}
{%- endfor -%}
{% set pmin = ns.fc2|map(attribute='price')|list|min %}
{{ (ns.fc2|selectattr('price','eq',pmin)|first)['datetime'] }}
It reads through the forecast up to the penultimate item (that’s what fclist[:-1] means) and builds a list of dictionaries with the datetime copied from the original sensor, and the price calculated as the mean of that slot and the next one.
We then do the same process of finding the minimum price in the new list and find the matching datetime.
You can expand this to any size of time period — just add subsequent items and adjust the total divisor in the mean calculation, and adjust the end point of the list so that your “looking forward” doesn’t go past the end.
OK — this is nothing to do with timezones, but is the problem of you blindly copying the code we suggest without understanding what it does. I’d missed the fact that your sensor also includes past data — my code finds the datetime of the cheapest price in the data regardless of when it is.
Try this for the single-slot forecast, which starts out by restricting the data to future entries:
{% set dtnow = now().isoformat()[0:26]~"Z" %}
{% set fclist = state_attr('sensor.zonneplan_current_electricity_tariff','forcast')
|selectattr('datetime','>=',dtnow)|list %}
{% set pmin = fclist|map(attribute='price')|list|min %}
{{ (fclist|selectattr('price','eq',pmin)|first)['datetime'] }}
The first line builds a datetime string that matches the format in your data; the second part of the second line uses that as a “filter” on the sensor data. Strongly recommend you play around in Developer Tools / Templates to see what’s going on.
You can work out how to translate that into the hourly calculator I posted above.
Thanks again. Will study this (and the one above). And you right, I only understand max 70% of your template but quite a steep learning curve as these are quite advanced compared to the ones I’m able to make.
@Troon I have been playing around with your template and starting to understand the logic (that is at least something) .
Few questions:
I understand what the [Z] does at the end of the datetime but not sure about the [0:26] when testing. Could also not find it by Googling. Could you explain?
Checking: To increase the consecutive hours at lowest price you mean adding another loop.index0-1 (for instance) the 5th line and then for each addition making sure I divide by the correct total divisor (to get the avg of those values & compare them with others). I’ve played around with it and this seems the logic but not 100% sure. Is my assumption Correct?
Half way the day, new data is added (another 24hours) to the attributes . This can create a situation where the lowest price is more than a day away (after this addition). This is still valuable info, but is it also possible to limit the list it creates and/or looks in to find the lowest price? With the objective to find -for example- the lowest price after ‘now’ but not further away then 12 hours?
Your sensor contains datetimes that look like this:
datetime: '2023-01-15T07:00:00.000000Z'
so I manipulate the output of now().isoformat() to match that format: first 26 characters and stick a Z on the end. Once that’s done, it’s possible to compare correctly-ordered date/time strings “alphabetically” as a later time string will always evaluate as “greater” than an earlier time string. See the first general principle of ISO8601.
Nearly, but not loop.index0-1 as that would be looking backwards. The idea is to look forward n slots (hours) and take the average. My example above was for two hours; for three, you’d do:
{% set fclist = state_attr('sensor.zonneplan_current_electricity_tariff','forcast') %}
{% set plist = fclist|map(attribute='price')|list %}
{% set ns = namespace(fc3=[]) %}
{%- for fc in fclist[:-2] -%}
{%- set ns.fc3 = ns.fc3 + [{'datetime':fc['datetime'],
'price':(plist[loop.index0] +
plist[loop.index0+1] +
plist[loop.index0+2]) / 3}] -%}
{%- endfor -%}
{% set pmin = ns.fc3|map(attribute='price')|list|min %}
{{ (ns.fc3|selectattr('price','eq',pmin)|first)['datetime'] }}
The set ns.fc3 line now gets the mean of the following three hours starting at each time. The previous (fourth) line fclist[:-2] restricts the starting point of the search to only go up to the third-last item of the list, because you can’t look two steps forward from later items.
Yes. Have a play in the template editor: see if you can filter fclist to exclude too-far-out elements from the start of the template. Here’s how to generate a correctly-formatted timestamp that is 12 hours away:
{% set dtend = (now()+timedelta(hours=12)).isoformat()[0:26]~"Z" %}
Just add a |selectattr('datetime','<=',dtend) onto your fclist definition and you should be good to go.
Ah! That was the part I did not get at first. I was assuming your approach, but was reaching the end of the list so that was I was going down. I just needed to adjust the starting point to compensate which makes total sense.
Your suggestions on limiting the fclist search also works!
On the datatime: I played around with that (the ones below tested in the in the template test part of HA) and I get different outputs (obviously), but I’m a bit surprised that the total template does not create another output if I modify the date part. All works independent of isoformat so I should not be concerned but was just trying to understand why that is.
{{ now().isoformat() }} gives 2023-01-18T10:09:00.101813+01:00
{{ now().isoformat()[0:26] }} gives 2023-01-18T10:09:00.102033
{{ now().isoformat()[0:26]~"Z" }} gives 2023-01-18T10:09:00.102180Z (which is the format the sensor we are looking into uses)
isoformat() (docs: I hadn’t realised this wasn’t directly in the HA docs but only referred to under “other datetime functions”) converts that datetime object to a string in a consistent format that we can pull about to match what we need.
The way I’ve approached this is not the only way it could be done: there are many different ways to work with date/time comparisons.
Below is the final code that gives you the time of the cheapest 2 hour upcoming.
You see a section that mentions ‘hours=6’ ; so this now looks 6 hours in the future eg cheapest 2 hours within 6 hours. Change that to 12, it looks to the next 12 hours cheapest slot.
This sensor has no direct link with apex-chart. Or am I misunderstanding your question?
- platform: template
sensors:
price_low_coming_short:
friendly_name: Price lowest coming short
unique_id: price_low_coming_short
device_class: monetary
value_template: >
{% set dtnow = now().isoformat()[0:26]~"Z" %}
{% set dtend = (now()+timedelta(hours=6)).isoformat()[0:26]~"Z" %}
{% set fclist = state_attr('sensor.zonneplan_current_electricity_tariff','forcast')
|selectattr('datetime','>=',dtnow)|selectattr('datetime','<=',dtend)|list %}
{% set plist = fclist|map(attribute='price')|list %}
{% set ns = namespace(fc2=[]) %}
{%- for fc in fclist[:-1] -%}
{%- set ns.fc2 = ns.fc2 + [{'datetime':fc['datetime'],'price':(plist[loop.index0] + plist[loop.index0+1])/2}] -%}
{%- endfor -%}
{% set pmin = ns.fc2|map(attribute='price')|list|min %}
{{ int((ns.fc2|selectattr('price','eq',pmin)|first)['price'])/100000 }}
How can I make this template to load every 24:00 hours?
So that the cheapest hour does not shift throughout the day or it is possible to make this in an automation?
Check out Hellis81’s solution. Would expect that to work although I have never tried this.
I’m curious to here your use case for a sensor like you mention as in your case (if I understand you correctly) you will get prices from the past.
Also not that most energy integrations will get new info from their supplier around mid day. At that moment in time, there is new data to evaluate and a new lowest price can come out. You have to think how you deal with that. That is the reason why I have 3 versions of this sensor; cheapest in next 3 hours (when I’m in a hurry), cheapest in 6 and 12 hours. I then created sensors that show the saving vs now in % so I can decide how long I want to postpone my ‘consumption’.
Beside Hellis81 suggestion you could adapt above. You will need to play with the template in template editor. The first line in the code is where it starts searching from. In this sensor is ‘now’ so it will only look for cheapest in the future (after now). You can also set this to any time you like, and it will start searching in the attributes from that time. You will have to play around with that.
Last thing; note that the ‘zonneplan’ integration has changed and ‘forcast’ was changed to ‘forecast’
hi i am fairly new to programming the solution i am after is very similar to the original solution for average of energy forecast however it doesn’t seem to want to play ball with my sensor attributes.
