I have this sensor, that integrates the power over time:
- platform: integration
name: home_solar_production_energy
source: sensor.home_solar_production_power
round: 3
unit_prefix: k
method: left
It usually works, but it does not recover, when the underlying sensor changes from unavailable to zero:
template:
- sensor:
- name: home_solar_production_power
unique_id: home_solar_production_power
unit_of_measurement: "W"
device_class: power
state_class: measurement
icon: mdi:flash
state: |
{{
states('sensor.power_production_now')|float(0)
}}
availability: >
{{ not false in
[states('sensor.power_production_now')]|map('is_number')
}}
This sensor usually goes to unavailable during the night. When it becomes available again, it mostly has a state of “0”.
The Riemann Sum sensor stays in state “unavailable” until the underlying sensor is greater then zero.
These are the relevant rows from the states in the database:
add a | float(default=0)
at the end of your power sensor state
then you could even skip the avaiability section
if 0 would fit your needs in case of being unavailable
Template Editor snippet
{% set xx = -2 %}
{{ xx | float(default=0) }} # ==> gives you -2.0
{% set xx = 2 %}
{{ xx | float(default=0) }} # ==> gives you 2.0
{% set xx = "unavailable" %}
{{ xx | float(default=0) }} # ==> gives you 0
I am having the same issue and have made a similar post. A 60 second dropout makes a Reimann Sum sensor go offline until solar production resumes. Tom has made suggestions around ‘available’, but sadly none has worked. If I can work out how to insert @justone 's suggestion, I’ll give it a go, but fixing Reimann Sum would be a better outcome, instead of bandaid fixes.
Well the (default=0) does nothing but to ensure you get a numerical state in case something goes wrong preventing a numerical state. I never tried but if “0” prevents the Riemann to re-pickup it’s duty, perhaps a (default=0.001) does the trick? All the default= does is to replace an expected non-numerical value by the one given by the default specification. And 0.001 surely won’t add a larger deviation to the summed up energy.
I have in effect, tried that using ‘available’. I’ve used 0 and 1, but it hasn’t worked.
I tested it in the Template under Developer Tools and an unavailable entity returned a number, but didn’t help in real life.
I’ve also tried it in the Template test in the way you suggest but will give it another shot in the config.
My formula uses ‘int’ so I’ll (default=2) after that and see.
state: >
{{ [0, states('sensor.envoy_current_power_production') | int -
states('sensor.envoy_current_power_consumption') | int] | max }}
It just seems there is a glitch in the Reimann Sum that I am sure was not there a few months ago.
I want to use these Riemann integrations in my configuration.yaml because in the helper section I can’t choose month or year.
Sadly the configuration.yaml is giving a error (platform integration unknown).
Can someone tell me what I am doing wrong?
sensor:
- platform: integration
source: sensor.power_usage
name: monthly_power_usage
unit_prefix: k
round: 2
method: left
unit_time: mon
reset: 1st day of the month
- platform: integration
source: sensor.power_usage
name: yearly_power_usage
unit_prefix: k
round: 2
method: left
unit_time: yr
reset: 1st day of the year