I’ve been happily running the speedtestdotnet integration in my Home Assistant OS VM running on an i5 NUC and it regularly measures the correct maximum connection speed to my ISP. Since upgrading to from 0.115 to 0.116 it now averages at just over 50% of that. Running the speedtest from a browser on the NUC host still shows the full download speed (as does fast.com for that matter).
The VM has plenty of RAM, CPU barely rises over 4%, etc. I’ve tried restarted the VM and also manually selecting the speedtest server, but no change. Anybody else experienced this?
I nearly said yes I’m seeing that, but I’m not. I forgot I dropped to a lower speed plan last month. Was 100/40Mb/s now 50/20Mb/s. I can see roughly that speed with speedtest but I’m not using a VM. I’m using the home assistant NUC image directly on the hardware.
Thanks, both. It is curious. It’s night and day different for me. I was on a RPI3B+ and migrated to the VM on a NUC on the 24th September and then upgraded to 0.116 4 days ago. I’ve tried rebooting the NUC in case it was an issue with VirtualBox but still no difference. I haven’t made any config changes myself, just whatever would have been done automatically during the upgrade.
I don’t use Speedtest, but I’ve seen my speed fluctuate all over the place for the past week now. Some days, it’s been as low as 200mb/s and other days I’ll be around 800mb/s. This is from my unifi controller running on the same network as my HA instance.
I’ve tried running speedtest-cli from within a container on HASSOS and also on a different physical host on the same network with a different version of python. Same results. On all machines, running the test from speedtest.net in a browser will yield more accurate results. Maybe I should be amazed that I was getting accurate results from the hassio integration rather than the other way round!
I’ve also been seeing this issue, but it seems to have slowed down since the 0.118 release and was fine before. This was both on my RPi4 and now on my branch new very over-powered NUC.
This is what my chart looks like now. I upgraded to 0.117 on 30th October and since then it has been a steady ~80Mbps (should be 220Mbps) apart for a blip I can’t explain for a few days 6-9th November. I upgraded to 0.118 on the 23rd November. No Change. I’m running HASS on a VM on an overpowered NUC, did you install HASS onto bare metal on yours?
In my experience, the Python based speedtest used by HA is way off when the connectivity to your home is several hundred Mbps. For my HA, I use instead the speetest-cli binary , which matches well with the Speedtest App I use on Windows10 (and matches very close to by home connectivity speed).
Thanks. I’ve used your solution which gives me the results I expect. They have upgraded python versions in recent releases and I wonder if that coincided with the loss of performance of the python speedtest program being used. The accurate results from the speedtest binary prove that it is nothing to do with my VM, networking, etc. so that seems to be the most plausible explanation.
It works great though whenever the host restarts, e.g. OS update, I have to log in and run speedtest.bin again to provide the YES prompts - they don’t seem to persist on my HASSOS instance. Do you have the same problem/are you using a different HA install?
I think I see the problem. When you accept the license, speedtest.bin writes a file to ~/.configure/ookla/speedtest-cli.json (where ~ means user’s home directory). Assuming you ssh into HA when you execute speedtest.bin, the json file is located in the homeassistant container’s home directory which is /root. Most likely everytime HA core is upgraded, the /root directory is blown away and so is the json file. I don’t see a way around this at the moment…to answer one of your questions, my production HA environment is python-venv which is why I don’t see this problem.
I think I have the solution. There appear to be two “hidden” args --accept-license and --accept-gdpr which do what you’d expect and remove the prompting (they also seem to inhibit the creation of the ookla .config file). So I just changed process creation to this: