P1 meter: calculated value sometimes trough the roof in the Energy card

Hi everyone,

I have a P1 meter that registers the engergy consumption (electricity and gas)
The hardware device (although not relevant here): HomeWizard Wi-Fi P1 Meter

I connected this to my HA-instance with the “P1 meter - HomeWizard Energy” integration.
Data are nicely displayed in the Energy card.

Because I want to see the total energy in kWh, I created a template sensor as follows:

template:
  - sensor:
      - name: "P1 meter Total Gas kWh"
        unique_id: "sensor.p1_meter_total_gas_kwh"
        icon: mdi:gas-cylinder
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: >
          {% set gasm3 = states('sensor.p1_meter_total_gas') | float %}
          {{ (gasm3  * 10.2346) | round(2, default=0) }}

This sensor converts the m3 to kWh.

To sum things up in the Energy card: I configured my gas consumption (in m3) also as “solar energy” (in kWh). By doing this you get following result:
2022-03-31_14-31-42

  • (1): Electricity consumption of today
  • (2): Gas consumption (in kWh) of today (as you can see, this is 7.3m3 * 10.2346, as defined in my template sensor)
  • (3): Total consumption (in kWh)

so far so good!

However,
“sometimes”, the calculation of daily energy (kWh) fails totally:


You can see here

  • (1) Gas consumption (kWh). But on 03/03 and 05/03 the value is about 33.000 kWh!!!
  • (2) Gas consumption (m3)

If everything went well, (1) should equal (2) * 10.2346

For some reason, the energy card does not display the daily energy consumption on that specific day, but the absolute value of my “sensor.p1_meter_total_gas_kwh”.

Indeed:
The template sensor “sensor.p1_meter_total_gas_kwh” registers the total amount of energy
2022-03-31_14-45-46

For some reason, HA interprets the calculated value wrong sometimes. Note that the error does not occur on Gas (m3)!

This problem probably has nothing to do with the hardware and/or integration: I have 2 other instances of HA running on my same network, and also connected to the P1 meter with the same integration. On those instances, the same problem occurs from time to time, but on other times.

What am I doing wrong?
Is there some secret that I have to configure in my template sensor?

any help is appreciated!

Kind regards,
Bart Plessers

Maybe this is a better illustration:

2 different instances of Home Assistant, on different servers, both with the P1 integration and connected to the same P1-meter.

Left side: server 1: correct calculated value.

The (gas consumption in KWh) = 10.2346 * (gas consumption in m3)

Right side: server 2: wrong value

The (gas consumption in KWh) = 2* absolute value of my (TOTAL gas consumption in kWh)
This is caused by the fact that my calculated value (P1 meter Total Gas kWh) shows 2 artefacts:

So the energy monitor thinks that at those 2 points in time, there was a consumption of +/- 35.000 kWh, resulting in a total “consumption” of +/- 70.000 kWh between 07:00 am and 08:00 am.

1 Like

i have the same on a complete different setup.
I have a SMA system, with a smartgateways P1 reader.
And i have also a drop in the reading, 2-3 value’s = ‘0’ and then back to normal.

Same thing, slightly different setup.

I have a similar issue. Measuring P1 through Toon Thermostat.

Glitch in measurement (so no usage available temporarily):
image

Results in high peak consumption:

This is normal behavior for a sensor with state class total_increasing - the docs warn for this behaviour. state-class total would probably be less affected. That would result in a power delivery followed by a reverse use, which should cancel out.

But in the end it all comes down to integrations not using 0 when the sensor is unavailable. So the other option is to use a template that filters out the 0.

I have the same issue. Does anybody have a suggestion how to set-up a template sensor to solve this? I am currently adding the consumption from both tariffs and use the utility meter function.

Highly appreciated

this does the trick: if the sensor is unavailable for some reason, you have to make the template sensor also unavailable, otherwise it interpreted as “0”, wich causes all those spikes…

Tip: as you can see: I DON’T use the “physical” sensor in my dashboard, but I define my own "virtual’ sensor. This because, maybe some time in the future I will have another sensor. So by defining this virtual sensor, I can garanty continuity of the sensor.

      # ----------------------------------------------------------------------
      # gasmeter: meterstand in m3
      # ----------------------------------------------------------------------
      # Virtuele sensor:
      # Om continuiteit te garanderen van de sensor: definieer een eigen virtuele sensor op basis van een fysieke sensor.
      # Als de fysieke sensor ooit vervangen moet worden, kan je de nieuwe sensor koppelen aan dezelfde virtuele sensor,
      # zo blijven de tellingen doorlopen en blijf je long-term statistieken behouden.
      # Verder kan je zo ook garanderen dat er altijd een waarde is ("0"), zelfs als de fysieke sensor niet beschikbaar is.
      - name: "gasmeter Total Gas"
        unique_id: "sensor.gasmeter_total_gas"
        icon: mdi:gas-cylinder
        unit_of_measurement: "m3"
        device_class: energy
        state_class: total_increasing
        state: >
          {% if ( states('sensor.p1_meter_total_gas') not in ['unknown', 'unavailable', 'None'] ) %}
            {{ states('sensor.p1_meter_total_gas') | float  | round(3, default=0) }}
          {% else %}
            {{ "0" | float }}
          {% endif %}
        availability: >
            {{ states('sensor.p1_meter_total_gas')  }}



      # ----------------------------------------------------------------------
      # gasmeter: meterstand, omgerekend naar kWh
      # ----------------------------------------------------------------------
      - name: "gasmeter Total Gas kWh"
        unique_id: "sensor.gasmeter_total_gas_kwh"
        icon: mdi:gas-cylinder
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: >
          {{ (states('sensor.gasmeter_total_gas') | float  * 10.2346) | round(3, default=0) }}
        availability: >
          {{ states('sensor.gasmeter_total_gas')  }}


      # ----------------------------------------------------------------------
      # gasmeter: meterstand, omgerekend naar Wh
      # ----------------------------------------------------------------------
      - name: "gasmeter Total Gas Wh"
        unique_id: "sensor.gasmeter_total_gas_wh"
        icon: mdi:gas-cylinder
        unit_of_measurement: "Wh"
        device_class: energy
        state_class: total_increasing
        state: >
          {{ (states('sensor.gasmeter_total_gas') | float  * 10.2346 * 1000.0) | round(0, default=0) }}
        availability: >
          {{ states('sensor.gasmeter_total_gas')  }}



sensor:
      # ----------------------------------------------------------------------
      # gasmeter: momentaan gasverbruik in m3/h
      # ----------------------------------------------------------------------
      - name: "gasmeter Total Gas Flow"
        platform: derivative
        source: sensor.gasmeter_total_gas
        unit_time: h
        time_window: "00:05:00"  # we look at the change over the last half hour

      # ----------------------------------------------------------------------
      # gasmeter: momentaan gasverbruik in kW
      # ----------------------------------------------------------------------
      - name: "gasmeter Total Gas Flow kW"
        platform: derivative
        source: sensor.gasmeter_total_gas_kwh
        unit_time: h
        time_window: "00:05:00"

      # ----------------------------------------------------------------------
      # gasmeter: momentaan gasverbruik in W
      # ----------------------------------------------------------------------
      - name: "gasmeter Total Gas Flow W"
        platform: derivative
        source: sensor.gasmeter_total_gas_wh
        unit_time: h
        time_window: "00:05:00"


kind regards,
Bart

Excellent Bart, that does the trick and I have also implemented your virtual sensor suggestion.