Open aaronpowell opened 1 day ago
Hi @aaronpowell - thanks for sharing. This is new data edge-case which I haven't seen before. I gather with the start of a new day things are back to normal for you. The reason the code checks for both [0] and [1] is there were instances where the first energy read after midnight was None (never sure why); in your example there's many more before there's numeric data. More generally this was a check that the returned list contained valid "looking" data. In your example, the data is valid "looking", but is full of nulls (aka None) until much later in the list. I otherwise presume >99% of the time you have no issues. Let me have a think about it. Any solution will be hard to test given the situation is rare, but I think worth looking into. Chrs, Peter
@aaronpowell Here's some test code with a mocked-up value_json based on your sample data above - copy/paste it into the Developer Tools / Template tester. It's an alternative to sa_data_by_5min_energy_consumed and essentially deletes the checks for the [0] and [1] items in the list. It also implements some default values in case the value_json.data list only has a single item with null for energy_consumed (e.g. at midnight). This seems to be a worthwhile improvement and would need to be adapted for all other sa_data_by5min... related sensors.
{% set value_json =
{
"data": [
{
"t_stamp": "2024-09-27 00:00:00",
"energy_generated": null,
"energy_consumed": null
},
{
"t_stamp": "2024-09-27 00:05:00",
"energy_generated": null,
"energy_consumed": null
},
{
"t_stamp": "2024-09-27 00:10:00",
"energy_generated": null,
"energy_consumed": null
},
{
"t_stamp": "2024-09-27 00:15:00",
"energy_generated": null,
"energy_consumed": null
},
{
"t_stamp": "2024-09-27 00:20:00",
"energy_generated": null,
"energy_consumed": null
},
{
"energy_generated": 20,
"energy_consumed": 10,
"t_stamp": "2024-09-27 16:20:00"
},
{
"energy_generated": 21,
"energy_consumed": 11,
"t_stamp": "2024-09-27 16:25:00"
},
{
"energy_generated": 22,
"energy_consumed": 12,
"t_stamp": "2024-09-27 16:30:00"
}
],
"t_step": 5
}
%}
{{ value_json }}
{%- if (value_json is defined) -%}
{%- set most_recent_sensor_data = value_json['data'] | rejectattr('energy_consumed', 'equalto', None) | list | last -%}
{{- most_recent_sensor_data.energy_consumed|default(0.0)
if most_recent_sensor_data.energy_consumed|default(0.0) > 0.0
else 0.0
-}}
{%- else -%}
{{- states.sensor.sa_data_by_5min_energy_consumed.state|default(0.0) -}}
{%- endif -%}
I had my Solar Analytics offline for about half a days' worth of time, and that spanned through the night and what I've noticed is that all the sensors are reporting
unavailable
for their values, despite data now being present in Solar Analytics, and via their API.I think the problem is because of this starting code in each template:
If the first two items are
null
then it won't ever parse beyond that.For reference, here's the payload that I get back for today, note that the API started returning data at 9:05am:
It would be preferable that it didn't write off the whole day if the first two time blocks are
null
.