having sporadic issues with Energy metrics

[libussa]

hey, about ~once a week I get a pretty annoying issue; the routed energy counter goes to 0 for a moment

pretty hard to debug as it happens quite infrequently 😕
What I can tell is that it's not tied to a reboot of yasolr, but that's about it.

The issue is that it completely messes up HA's energy dashboards, as they rely on the counter being always increasing. Every time I need to remove the bad value by hand.

[mathieucarbou]

@libussa : Hi,

What are you using to monitor routed energy already ? Is it the JSY that is connected to the ESP32 ?

as they rely on the counter being always increasing

This is not true. A counter that is always increasing is allowed to restart from 0: this is also what can happen even with shellys or water counter or basically any counter since at one point the value will reach the maximum possible amount of what can be stored and will overflow and restarts from 0, or the battery will be depleted and upon restart the counter will be 0.

So always increasing does not mean that it cannot reset.

I also have the same issue with my OpenDTU: each time I restart, I need to clean the energy counters that go wrong. This is annoying.

They fixed the issue in 2023 in HA: home-assistant/core#72943

YaSolR does not keep track of counters: this is the hardware.

But I suspect that what you see is that YaSolR receives 2 measures.

Remember:

• always update to the latest version
• if you have a JSY remote using a JSY-MK-194: disable UDP sending for channel 1

[mathieucarbou]

Note: I myself added periodically_resetting: true to several energy meters

[libussa]

What are you using to monitor routed energy already ? Is it the JSY that is connected to the ESP32 ?

Yes, local JSY for that, and remote JSY for the grid

So always increasing does not mean that it cannot reset.

indeed I phrased that wrong; but in this case it's not resetting, it's dropping to 0 and then going back to the previous value

if you have a JSY remote using a JSY-MK-194: disable UDP sending for channel 1

done for a few weeks now

always update to the latest version

I'm currently on 63, I'll update to latest and see

[mathieucarbou]

ok! That's weird...

And do you know how much time it stays at 0 ?

For the energy to drop to 0 like that for a local jsy, it would require:

• either that the jsy remote sends the channel 1 data
• or that the local jsy does not send data anymore for 10 seconds (metrics expiration time), and for that to happen it would require that the jsy times out (power issue), or the jsy is not connected to the grid anymore (AC power issue), or that the ESP32 core 0 (main core) is stalled for more than 10 sec (which is not supposed to happen and not likely since core 0 is used for all arduino core tasks like wifi).

Note: NQTT publish is one each 5 sec, so there is also this delay to consider when looking in HA for the times.

[kumy]

Hi, coming from #150, my issue looks really similar to this one so continuing here.

also, always increasing does not mean never reset. That is totally fine and acceptable for an energy counter to reset and HA supports that.

I agree periodically_resetting is allowed, counters are not infinite. But after resetting to 0 we expect the next value to continue counting from the 0, so maybe next value is 1. Here on my graphs, there is one counting to 0 value then back to "normal" value. This is that spike that seem detected by HA : the 0 to 4332 (not the 4332 to 0).

And do you know how much time it stays at 0 ?

I'm sending reading to mqtt every 1s, And it seem to be just on one second.

And all the numbers matches:

I also see the drop on metric Grid Energy and probably on Grid Power Without Routing (for other sensors I don't have the history recorded)

This lead me thinking to a read failure from the jsy. Do you think it could be possible to not publish the 0 values in such [specific] case to mqtt or publish something like nan value? And wondering at the same time what to publish if a real reading give also all zeros 🤔

Questioning myself: since when I remarked this issue. I can't really remember but I don't remember noticing that behavior at my beginning with Yasolr

[mathieucarbou]

Yes, that could be an idea indeed to treat 0W energy as nan!

This way any 0 value won't be published and be unavailable.

I will implement it and do a quick test this weekend !

[mathieucarbou]

@libussa @kumy : I have launched a release (v1.0.0-rc69) that should be available in 30 minutes and it includes the fix suggested by @kumy . The idea is not avoid publishing energy counters when their value is 0, because 0 could mean that the reads have expired, or that there is no measurement device setup (no jsy, no pzem) or that there is a read timeout / error. So YaSolR now only publishes energy values to MQTT if they are positive and non 0.

I am waiting for your tests and feeback on this, thanks a lot!

[libussa]

I had a look at the grid energy sensor, and it also happens there, but not aligned with Returned Energy 🤔

[kumy]

Thanks for your quick fix. Installed rc69 a few seconds ago, as @libussa said this does not happen frequently, let's monitor for the next weeks... Thanks again

[kumy]

I created this simple automation, I hope it will catch my attention if needed, even if I check the dashbaord at least once a day...

alias: Alert on yasolr status watcher
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.yasolr_pro_d3e458_grid_energy_returned
    to:
      - unavailable
      - unknown
conditions: []
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >-
        grid_energy_returned:{{
        states('sensor.yasolr_pro_d3e458_grid_energy_returned') }}
      title: Yasolr status
mode: single

[kumy]

I got one of the alert configured above two days ago and all my graphs we fine, I think you fixed it 👍 thanks

[mathieucarbou]

Yes I had to report energy as unavailable except when I sure there is a value 😄