Graphing total_increasing variables without zeros

Configuration
1

Hi this feels like an obvious question but I can’t see the answer

I have an entity whose value is configured as total_increasing - it’s the counter for the yield from my solar panels that counts up continuously and in theory doesn’t reset so it could span several days, if it wasn’t for the fact the whole solar system powers off when weather is bad or it’s dark. It could turn of on the evening, or at any time the weather makes generation too low to keep the system powered on

That means my entity resets to zero randomly.

I want to graph total yield every day, month, etc and I thought total_increasing would mean that when graphed the 0 resets would be taken into account. However I see the counter climb then reset to zero, climb then reset

What am I doing wrong?

Didn’t post as WTH as I think this is my fault!

Chris

2

Templates

If x > 0

          {% set x = states('sensor.xyz')float(0) %}
          {% if x > 0 %}
            {{ x }}
          {% endif %}
3

Sorry I totally forgot to follow this up

I don’t see how this means that the count keeps increasing during the day rarer than revert to zero

It does however possibly help me with the time it returns an error (different thread unrelated) so thats useful but essentially for the graph I need an ever increasing counter that represents all the +ve increments but ignore zeros.

4 
template:
  - sensor:
    - name: new sensor
      unique_id: new_sensor
      state: >-
        {% set x = states('sensor.old_sensor')|float(0) %}
        {% if x > 0 %}
          {{ x }}
        {% else %}
          {{ states('sensor.new_sensor') }}
        {% endif %}
      state_class: total_increasing
      device_class: energy
      unit_of_measurement: "kWh"
5

Definitely that avoids the error problem. But I don’t think it solves the graphing problem.

The reason I think that’s true is because as I see it, with data (hugely simplified example) like

0,1,2,3,4,4,5,5,5,6,0,0,0,0,1,2,3,4,4,4,5

across a period, that means that (assuming this starts at the day start) I have generated 6kwh of power before the system powers off (maybe it rained) then I have once it powers up again I have then generated 7, then 8 etc eventually at day end having generated 11kwh (6+5)

As such ideally I would see a graph that showed the following data

0,1,2,3,4,4,5,5,5,6,6,6,6,6,7,8,9,10,10,10,11

(ie the cumulative value had it not reset to zero)

…and for the week, month etc I would be able to do the same (ie as a normal counter would, given counters usually only increase and never reset to zero.

I kind of thought that total_increasing would do that and this the graphs would do what I wanted be default

Chris

1 Like
6

total_increasing is a state class, it’s a tag, a description to the system how your data is behaving (ie. it’s supposed to be an increasing sum). It doesn’t actually enforce this or modify the behavior of your sensors. It’s your job (or the job of the integration you’re using) to supply data that behaves in compliance with the total_increasing state class.

That said, from your example above, it is compliant. A total_increasing entity is allowed to reset to zero and this will (normally) not affect the calculation of daily / montly / yearly totals. The reset is supposed to be taken into account when doing the math. Are you saying it isn’t ? Of course if you look at the total increasing value directly, the graph will look funny. But the derived totals should be fine.

7

That confirms what i was thinking, ie that being a total_increasing doesn’t manipulate the stored values, it flags to upstream consumers the behaviour of the source data.

So to create the right graphs (ie daily weekly, etc, negating the 0 resets and showing the cumulative totals of usage) is it possible to configure the graph, or to refer to derivative entities, that means the graphs and stats show the correct values?

The energy tab seems to show the right values. But I want to show dashboards that show usage, and also I want to do the same in Splunk using exported data (nice to have, thought I would mention)

–Chris

8

I don’t know, to be honest. I found the native graphs to be entirely inadequate, so I don’t use them and I created this here to visualize my total_increasing entities (and more). But yeah, I guess there’s some way to configure the native ones too.

9

That’ll do as a workaround for now. There must be a way to create a counter that increases, incremented in line with the raw entity increases. Probably the answer. I’ll go digging in HACS to see if anyone has done it already

10

Update on this. I have been trying to work out why at dawn I get an anomalous reading as my first data point, skewing my daily power generation stats.

What I have discovered is that the Solis controller does exactly the opposite of what you expect a ‘today’ value to do. If the controller resets during the day (ie the sun goes in) then it resets the today counter to 0. If it powers off a sundown and powers up and sunrise it continues the counter from the point it powered off. So yes, literally the opposite of what ‘today’ should do!

By adding the value_template in as a fall back for the times when the controller is offline, it works fine daytime but it creates a problem at dawn as the totally_increasing counter sees values like 10:00pm:0.48kwh. 10.01pm 0.5kwh 5am:0kw 5:01am 0.51kwh

The 0kwh is created as it boots but fails to return a value immediately, so I backfilll that (wrongly I now see) with a 0, and so the total increasing counter thinks that 0.51kwh has been generated in the minute between 5am and 5:01am

Just in case anyone else trips over this. Testing at the moment and will update if my hunch is wrong and the 0 is coming from somewhere else but I don’t think it is