Command line sensor broken after update 2023.12.1

Not sure what’s up but this sensor broke updating 2023.11.3 to 2023.12.1

image

sensor:

  - platform: command_line
    name: "ISP"
    command: '
      checkip_result=$(dig -4 TXT +short o-o.myaddr.l.google.com @ns1.google.com || dig -4 TXT +short o-o.myaddr.l.google.com @ns1.google.com );
      echo "$checkip_result" | grep "[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*" >/dev/null && (
        ip_addr=$(echo "$checkip_result" | sed "s/.*<body>Current IP Address: //;s/<\/body>.*//;s/\"//g");
        dig_result=$(dig -x "$ip_addr" +short || dig -x "$ip_addr" +short );
        echo "$dig_result" | awk -F ''.'' ''{ print $(NF-2) "." $(NF-1) }'' 2>/dev/null || echo "Unknown DNS";
      ) || (
        echo "Unknown IP";
      )'
    scan_interval: 10
    command_timeout: 9

The only thing I see in the log is:

2023-12-09 23:46:14.353 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up command_line platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 361, in _async_setup_platform
    await asyncio.shield(task)
  File "/usr/src/homeassistant/homeassistant/components/command_line/sensor.py", line 66, in async_setup_platform
    name: str = sensor_config[CONF_NAME]
                ~~~~~~~~~~~~~^^^^^^^^^^^

Rolling back to 2023.11.3 it works fine:
image

See here :

There also would’ve been warnings in the log about the deprecation for the past 6 months (whenever you would’ve reloaded the integration or restarted HA).

I mean there are zero warnings about command line in the log on the previous so idk?

And even the error it gave was so absurdly cryptic I couldn’t figure out WHAT it was trying to tell me post upgrade, leaving me to guess.

FWIW I don’t see it ANYWHERE in the 2023.12.1 breaking-changes, which seems like a mistake. I did look at them and saw nothing I was using.

Not everyone spends all their time looking for updates and hitting every single version…so “it was briefly mentioned in 1 update 6 months ago for a version you may have never used” is a rather poor reason to know about it in THIS update, when this is the one that broke it!

Where does it say this update breaks command line? I sure don’t see it in this update.

Here’s my understanding of how it works:

An existing method is deprecated in favor of a new method and users are informed that they have several months before support for the deprecated method is removed.

For example, in the September release, it was announced that a weather entity’s forecast attribute is deprecated and will be removed in 2024.3. They now have several months to make the transition.

After the expiration of the deprecation period, and the old method is removed, it’s my impression that it’s not currently a common practice to report when a long-deprecated feature is ultimately removed.

If you feel it should always be announced, I suggest creating a Feature Request (unless one already exists; I haven’t checked). I’d vote for it.

But that’s a change, no? Why would you not report it in changelogs?

I’m 99% sure they have previously put in breaking changes “X previously deprecated thing is now removed”

This isn’t a feature request, this is just wrong documentation…idk what a feature I would request to have accurate documentation?

FWIW…I also was not aware of the forecast one changing. I actually JUST started trying to craft something over Thanksgiving that depends on that. I am also not getting warnings about that one either. Because who would comb EVERY previous changelog when adding a new automation? :frowning:

I think you’ve established the fact that reading the monthly Release Notes is advantageous.

I do read them?

So you’re saying I should have them memorized, even for things I am not using? And somehow notice if there’s one I have missed to go hunting for it?

I thought the entire point of changelogs was…to log changes. Not to make it a test for the user.

And when I have a problem, I go re-read them…foolishly expecting changes to be logged in the changelog.

Also (and this is maybe a bug?) it looks like I already had fixed the binary_sensor command line sensors back when…I apparently just overlooked the sensor command line sensor in the same YAML file.

Maybe that’s why it failed to find any warnings nor repair alerts since it was partly fixed?

The only other thing I can think of is if I’d tried converting all but “normal” sensor wasn’t fully feature complete yet and I couldn’t convert at the time, then was no changelog when they finished it, or if the documentation made me believe it was only binary sensor type ones not all of them that were changing format?

Idk in any event, this seems like a really shit experience with no advance warning it was going to fail.

I volunteer my time to assist users with technical problems. This discussion now appears to be about one’s decision to regularly read/not read Release Notes and ability/inability to recall them later. I can’t help with that.

2 Likes

That’s odd. I definitely got deprecation warnings at the time — and previously for other deprecations.

I agree it should be mentioned, just to close the loop.

It would be time-consuming to find an example right now, but I’m 99% certain I’ve seen the final removal being called out (previously), but I’d say that it perhaps wasn’t done consistently.

1 Like

I see you’ve received similar responses in the 2023.12 post.

1 Like

Yeah, I know I’ve seen some…I cleaned up the one about history exclusions that I noticed while trying to debug this one. I assume they’d go to the same logfile…so who knows.

I have the same issue on 2023.12.1 and it was working with no issue. Then just suddenly I’m getting the same error and it is not working anymore. Any help please

May have to dig thru all your YAML files and try to find the one(s) that are broken and see if they were missed in the migration.

Seems like in my case all the binary-sensors threw warnings and got fixed but the “regular” sensor I had was forgotten and threw no warnings until it just broke silently. The “fix” was to also migrate it to the new format…but it was impossible to tell from the logs and notifications that was the issue.

And finally what is the command line fix ?

Removing/updating the old YAML fixed it, it was just a nightmare to figure out with changelogs not clearly explaining which braking changes happened between skipped versions and also it didn’t mention “sensor” also was a breaking change not only “binary_sensor” so I didn’t realize I had to change those as well.

Best way to debug which YAML is I had to just start bulk commenting out stuff in my YAML until I found the one that stopped the errors and then figure out how to rewrite what was still commented out. If you use YAML package files, you can also rename them to like “my_thing.yaml.hold” and removing the .yaml extension makes it stop loading the contents.