core: Utility Meter: Invalid state

This is not an error message… this is a warning.

That’s what I reported in the issue.

This warning wasn’t there before the upgrade to 2023.4 and I think it’s quite usual, that many sensors are not available at startup or am I wrong? I can live with this log message but there may be many users that are worried about this.

updated the PR to only activate warnings after HA is marked as started…

Yes, but

• a warning without specifying which utility_meter has problem isn’t really helpful, rather annoying
• during startup this isn’t a problem at all, just later starting of a component I think most of us likes to have clean logs without even warnings if possible.

@gfrancesco good point, I’ve reverted the unavailability of utility_meter in https://github.com/home-assistant/core/pull/93274

The best scenario would be that:

• utilty meter is showing a warning message when a sensor is really unavailable, to make the end-user aware
• utility meter is handling the startup of home asisstant in a good way, so it won’t send a warning when everything is working just fine (like in my case).

I’ve installed 2023.5.3. The same error appears when restarting Home Assistant.

also: “The warning is there, so that you know that the source sensor needs to be fixed…” The warning appears in the log, when the source sensor came back… so, at the point when the warning will be logged, there’s nothing to fix anymore.

I would agree if the warning would be the opposit - and will be logged, as soon as the source sensor became unknown / unavailable. But not when it recovers from that state to a “good” / valid state

It has been made clear that, according to the dev team, this is not a bug. It is a behavior that has been introduced deliberately. See my posts above, anyway I won’t hold my breath for this to be changed since the PR was closed.

At the moment I’m using a partial workaround using trigger template sensors. Essentially the source sensor used by the utility meter becomes the trigger sensor. The trigger sensor references the energy meter of your inverter, and it only updates when there is a new valid read coming from your inverter.

For example if your inverter goes down and its energy meter reads unavailable, the trigger sensor is not updated, does not go unavailable, and keeps reporting the latest number, thus the utility meter also keep showing a good read.

Here’s an example of one of my trigger sensors:

- trigger:
    - platform: state
      entity_id: sensor.inv_1_e
      not_to:
        - "unavailable"
        - "unknown"
        - "none"
  sensor:
    - name:         "Inv-1 E NU"
      state:        "{{ states('sensor.inv_1_e') }}"
      state_class:  "total_increasing"

Do you have a link to the issue you are referring? I agree with your point of view, I just don’t understand how it’s supposed to be fine to willingly break user facing behaviors that are in place since years for the sake of having some common rule on how to handle helpers. Helpers components are very different, e.g. text boxes, buttons, utility meters, etc. Maybe trying to force some common behaviors to all of them is not a good idea? From a user perspective, it’s hard to imagine why an utility meter should be unavailable. It’s a counter, the normal behavior would be to either increase it’s value or stay fixed, but it should always show the count. Imagine if you can read a car mileage only if it’s wheels are moving, not very handy. Anyway, sorry for the rant, I know it’s not your fault and you tried your best, it’s just that it will take quite some work to fix this problem on the user side, I’m not even sure how to do it at the moment.

I appreciated the effort @dgomes, might be that the goal of the PR was misunderstood? Just to recap, let’s see if I got it correctly:

• There was an issue with unwanted warnings in log;
• The PR to fix that broke how the utility meter worked since years (being readable even when the source sensor is unavailable);
• The PR to restore the original behaviour was rejected.

In my opinion, it doesn’t make much sense, especially considering that this is not an edge case at all. Source sensors go unavailable all the time, that’s the norm not an exception, and it was correctly handled for years! This is further aggravated if your source sensor is battery driven and just measures intermittently, imagine water consumption for a sprinkler for example. To save battery the source sensor would be unavailable most of the time and the water consumption would be readable only when the sprinklers are on, which would not be very useful.

Even if you think how physical utility meters works, it doesn’t make any sense. Imagine if you cannot read how much water you used this year just because the little plastic spinner of the sensor broke.

The sensor itself is fully working and rock-solid. The issue the booting of Home Assistant itself. By definition, when home assistant is starting, sensors will often be unavailable until home assistant is fully started. This leads me to a different conclusion: the utility meter is not correctly handling the startup of Home Assistant.

I’ve added yet another PR that might address the template issue

https://github.com/home-assistant/core/pull/91035

Thanks for pushing the improvement in the logging @dgomes .

I do however also agree with @realthk on the second comment: in my case the source (not being Z2M) is only “misbehaving” at the (re)start / (re)load of Home Assistant and unfortunately at every (re)start / (re)load. After all has been initialized there is no issue anymore (and if there would be an issue, then I would like to see it in the log). With the current setup, warnings could potentially be seen as “spam to skip” in the logs.