SpeedTest command_line config with 2023.06

Configuration
1

I’m having a similar problem to this post with my Speedtest sensor since updating to 2023.06, but find no errors and have converted several other sensors that are working just fine. In my case the old configuration is still working (albeit with the deprecation warning). The old version:

- platform: command_line
  name: SpeedTest Data
  command: "/usr/local/bin/speedtest --json --secure"
  command_timeout: 60
  scan_interval: 3600
  value_template: >
    {{
      {
        "ping": value_json.ping,
        "download": value_json.download,
        "upload": value_json.upload
      }
      | to_json
    }}

And when converted to the new configuration and replaced…

command_line:
  - sensor:
      command: '/usr/local/bin/speedtest --json --secure'
      name: SpeedTest Data
      command_timeout: 60
      scan_interval: 3600
      value_template: >
       {{
          {
            "ping": value_json.ping,
               "download": value_json.download,
        "upload": value_json.upload
         }
          | to_json
        }}

Currently I have both versions in my configuration with the new one named “SpeedTest JSON” so things keep working while I debug this issue. When replacing the old version or running both, I get no errors when I do a syntax check, nor do I get any errors in the log after restarting. But the “SpeedTest JSON” simply does not exist! I’m guessing I’m overlooking something simple here, but can’t seem to see it myself at this point.

2

Is there a reason why you aren’t using the speedtest integration?

3

Yes, it became very unreliable so I switched to using the CLI (like many others) which has been rock solid.

4

It appears that you are using the same name for both sensors. Try this:

command_line:
  - sensor:
      command: '/usr/local/bin/speedtest --json --secure'
      name: SpeedTest Data JSON
      command_timeout: 60
      scan_interval: 3600
      value_template: >
       {{
          {
            "ping": value_json.ping,
               "download": value_json.download,
        "upload": value_json.upload
         }
          | to_json
        }}

Note the difference on line 4. [ SpeedTest Data JSON ]
I would have assumed HA would have added a _2 at the end of the sensor name, but maybe that isn’t the case when running old style and new style coding concurrently. In any case, give this a try.

5

For what it’s worth, I also get periodic “unavailability” on the Speedtest integration, but a reset of the integration cures it.

6

As noted both were named “SpeedTest Data” when the new was replacing old. But currently when setup with both the new one is actually named “SpeedTest JSON” while the original SpeedTest Data continues to run.

7

Exactly the sort of problems I had with the integration and got tired of having to reset it. If you search the forums you’ll find others got tired of it as well and switched to using some method of the CLI because it’s rock solid reliable. I don’t have a problem with you or others using the integration, but for me it wasn’t worth the hassle of having it die regularly. :smiley:

8

Oh I had no idea! It was only something I initially configured since it was available, not really out of necessity, so maybe that’s why I never focused effort on it.

9

Ok, I’ll have to take a look :slight_smile:

10

Just to add one more data point, for me the speed test integration has been flawless for at least the last couple of years or so, since whenever I first added it. The only time it has ever failed to return a value was when the internet connection was down. And even then it would resume reporting data once it was reconnected, no restart required.

I’m not suggesting anyone should use it if they’ve had problems, but I wanted to put this out there so others who come across this thread can try it and see whether it works for them.

11

Why use it at all???
https://community.home-assistant.io/t/why-use-automatic-speedtest-iperf-runs/583089/2

12

Agree, the official is not reliable, however does not need a reset. I have made a small script, running a test, wait 30 sec and run again. Run no. 2 is always reliable.

13

Why? Because in the past I’ve had problems with my ISP’s network going to shit or problems on my internal network causing slow downs that have throttled my speeds. Having a check once an hour gives me a rough idea of what’s going on. Your point in your post about the parameters that affect the accuracy of a speed test are valid, but for my purposes/needs this setup suits my needs.

[Unnecessary snarky dig at @WallyR removed]. Have a nice day.

14

As I suspected, it was something fairly simple and completely of my own doing. As it turns out it wasn’t just this command line sensor that wasn’t working, but all of those I had converted. When I looked at this the other day the other sensors were “working” but not really…they were being cached and after a refresh also disappeared. Anyhow, the real issue is that I split my config up into different directories and had previously had all of these in my “sensors” directory. When I converted the command line sensors to the new method I left them in my sensors directory where they were being promptly ignored! It would be nice if the system threw up a warning or error in cases like that, but it’s all compliant YAML so no complaints unfortunately. To resolve the problem I had to create a new “command_line” directory and add and include for it in my config:

command_line: !include_dir_merge_list command_line

And then in that directory I created a speedtest.yaml with the following contents:

- sensor:
    command: '/usr/local/bin/speedtest --json --secure'
    name: SpeedTest Data
    command_timeout: 60
    scan_interval: 3600
    value_template: >
      {{
        {
          "ping": value_json.ping,
          "download": value_json.download,
          "upload": value_json.upload
        }
          | to_json
      }}

And just like magic when you do it correctly it works! :rofl:

1 Like