Split Energy Channels (import/export) require total_decreasing sensor_type

It would be great if there would be an option to allow for a sensor to allow a state class: total_decreasing.

For my power management and energy dashboard I use an Iotawatt input for the data. This -among many other options- provides me with a value for the power consumption for all three phases at my house.
When exporting power, it returns a negative value, when importing power it returns a positive value, mathematically correct.

This shows up in the History correct, as negative when exporting and positive when importing, that’s great.

If I however want to use these values in my energy dashboard, the system starts providing ‘weird’ data as the ‘export’ of power is seen as a negative supply of power, not as an export of power.

It subsequently ‘assumes’ that because there was no ‘export’ of power, it must have used all the solar power for consumption. It completely ignores the negative value of the “consumption” channel.
image

As I cannot add the same sensor to the export input in the energy dashboard I tried to separate the main channel into two channels, export & import.

So, what I tried to do is to separate the positive from the negative into two sensors, so that I can add them separately to the energy dashboard.
Based on below templates:

- sensor:
    - name: "Main B Export.wh"
      unique_id: sensor.sensor.main_b_export_wh
      state_class: total
      device_class: energy
      last_reset: "1970-01-01T00:00:00+00:00"
      unit_of_measurement: "Wh"
      state: >-
        {% set wh = states('sensor.main_b_wh') | float %}
        {% if wh < 0 %}
          {{ states('sensor.main_b_wh') }}
        {% else %}
          {{ 0 | float }}
        {% endif %}

- sensor:
    - name: "Main B Import.wh"
      unique_id: sensor.sensor.main_b_import_wh
      state_class: total
      device_class: energy
      last_reset: "1970-01-01T00:00:00+00:00"
      unit_of_measurement: "Wh"
      state: >-
        {% set wh = states('sensor.main_b_wh') | float %}
        {% if wh >= 0 %}
          {{ states('sensor.main_b_wh') }}
        {% else %}
          {{ 0 | float }}
        {% endif %}

I added both channels and separated the main data into two datasets using SQL
directly in the database.

This on itself seems to work correctly as I can see in the history of the data, where now one sensor channel has the positive portion of the values and the other carries the negative values.

After adding the two channels to the the energy dashboard this also works fine.

The problem however, is with the energy dashboard, if based on the templated sensors for values that are set by the system itself (i.e. when the system itself stores the values and they are not set by a database query)

The energy dashboard is based on the delta between each subsequent sum value in the database for a sensor. Which, if set for a positive value channel is not a problem, but for a negative channel it is a problem. As the sensor_type setting should be total_decreasing to avoid stepping up when the value transitions from say -200 Wh to 200Wh, the < 0 state template filter will return a value of 0. this however also implies that the sum value (which is negative for a negative sensor value) is now seen to be going up (by +200) all of a sudden, which is obviously incorrect.
As it should merely ignore the change and stay at whatever negative value it had before and only increase (i.e. get more negative) if the return value is again below 0.

So, a sensor_type of total_decreasing would be great.
Alternatively, and possibly more flexible would be an option to be able to template the sum value that gets set in the sum (total) field of the sensor when storing the data.

For those of you using IotaWatt (or similar) there is an option for IotaWatt to generate the already split values for import & export. However, these values are correct for the energy dashboard, they are, technically incorrect from a mathematical perspective.

i.e. if using them in the energy dashboard they are both assumed to be the delta of the each subsequent sum value and as these are stored as total_increasing -positive values- they therefore display correctly.

However, when viewed in the history graph, they show their incorrect value clearly, with both of them showing as positive values: