Indeed.
From the top.
as_datetime() is a Home Assistant specially added function in templates and the documentation can be found here
https://www.home-assistant.io/docs/configuration/templating/#time
The underlying code for Jinja templating is Python, and therefore uses the date time library.
An alternative function would be strptime(), with the difference that this permits a default value.
date times as strings are ISO formatted if the date is separated from the time by ‘T’.
In many languages, datetime strings with timezone identifiers are processed precisely to the given zone, whereas without a timezone they are treated as local time.
The ‘Z’ is for Zulu time, being GMT and UTC. As such there is no ambiguity and the datetime string as provided will be converted correctly to the datetime object. Octopus Energy always generate rates using UTC.
Octoblock generates sensor entities in HA based on the Agile prices just read in, and your definition yaml of what you are looking for. The 2 hour sensor will hold the start datetime of a period where the incoming prices are lowest for two hours.
This, I read, works either on an all-day basis, or just from ‘now’, and clearly if the API call has failed, and you have opted for the from now setting, and there are less than 2 hours of data between now and 22:30, the octoblock code will return the Python ‘none’ for the lowest 2 hour price block.
The error message is very clear. HA is seeing a sensor with state value ‘none’.
When you test a template in the developer sandbox, it will update on edit, regularly, and on state changes. Hence {{states(‘sens. }} will be unavailable (HA speak) for state’ none’ and will reflect the latest state value.
The developer > states page is not updated, and together with the Web page cache, means that the state shown was the last one seen when the page was generated. If you want the “now” state, you need to refresh the page, or click on the entity link to load the state into the state editing box at the top.
So, in conclusion, you were looking at your octoblock 2hour sensor just before 21:00,with the last 2 hour block of the day being 21:00 to 23:00. Octopus rates have not been updated (due to whatever), and just after 21:00 the octoblock half-hourly update can no longer find 2hours left in the day, so updates the sensor with the Python None, and the rest is history.
Root cause: Octopus rate API call not completed successfully before 2 hours prior to end of rate table.
Solution: debug that failure and/or modify original template to cope with unavailable states, on the rare occasion it happens
Education: if you want the latest sensor value in Developer > States page, refresh the page
I rest my case m’lud.
