Since several months, I run speedtest (the node) at 08:00 in the morning just to get a daity check on network performance. I do this on a Raspberry Pi 4B 8GB at home, but also on a R-Pi 3B in my vacation house.
Both installations started strange behaviour about a week ago.
The automatically triggered speedtest gives me no speed results. When I log on manually and click the trigger node, it runs OK.
I added a debug node logging into syslog, and there I found that the 08:00 run results in an error:
[speedtest:7eef8f1a.84532] Error: No server found, verify your proxy/network
I know the network is OK, because I can see other messages coming in via MQTT, just before and after the error..
I tried changing th speedtest node config, by filling a specific speedtest server id for a server nearby. No change.
Before I decide to abandon the speedtest node approach, is there anyone that can shed some light on this?
I picked the latest one.
But I'm thinking it may be better to move away from the node approach, and revert to the version I have been using before.....
OK, I've moved away from the speedtest node, now using a bash file that is triggered from a virtual Domoticz device.
When I click that deice, the speedtest bash is started and produces results as I would expect.
But I also trigger that device once a day via a timer, and there I find the same problem as before... any clues?
Try running you script direct from cron, so node-red is not involved at all. You can send the results to a file. I suspect you will find it still won't run. If so then either it is a problem at the speedtest server, which doesn't sound likely, or it is something about your system or internet connection when it tries to run.
To narrow it down, you could try a different script from node-red. Maybe one just running wget to fetch a web page from somewhere, or curl to download a file. That will tell you if it is an network problem. My gut feeling is that something is happening to your network connection.
Yes, at first glance it looks that way.
But consider this:
when I run it during the day, it runs just fine. I trigger it from Domoticz.
when I run it locally (bash) it runs fine
this has been running OK for months, on two different Raspberry Pi's, in two locations, on separate network connections
The way it is set up now, Node-Red is not involved. The Domoticz virtual device simply triggers the bash script, and that script stores the results directly into Domoticz virtual sensors using json.
This morning I set the time for the auto trigger to 09:00. Output of speedtest.cli is redirected to a file, when it runs OK it contains the measured values.
I was hoping it would contain an error message when it fails.
Unfortunately it is empty...
Are you hitting an API limit - you might be running it too often and therefore getting a temporary ban?
Perhaps if you helped us understand what you are trying to achieve, we could give more specific help.
For example, on my own system, I run Telegraf which is easily configured to capture a number of different system and network metrics. It feeds the data into InfluxDB which I then use with Grafana to show the stats. You will find a number of screenshots I've previously shared in the forum.
All that I am trying to achieve is run a speedtest once a day on each of my networks, and collect that data centrally. This has worked fine sofar. I am usually not running more than one test per day, so I don't expect a ban.
The only thing I can bring to mind: I played around with the Node-Red speedtest node for a little while, not touching the already installed speedtest-cli. Once I decided to get rid of the Node-Red speedtest, things started to fall over.
This afternoon I decided to remove all traces of speedtest, and re-installed. We'll know in the morning if that worked... (I run the daily test at 07:00).
it seems that the problem is not really Node-Red related. When I google the error message I can see a lot of people suffering from this over the past weeks... unfortunately no solution (yet).
The error:
ERROR: Unable to connect to servers to test latency.
I gave in. There are simply too many problem reports about this, and it doesn't look like a solution...
So I moved to the Ookla version of Speedtest.
Installed it on two instances, sofar it runs good.
This morning both instances ran without any problems, so this chapter is closed.
Although it feels like this: I have an engine problem with my car, and all that I can come up with is to buy a new car...
Seems to me more like you had to replace the engine Welcome to the world of IT
To be fair though, I don't think you are paying for those services so complaints about their performance probably won't get very far. At least you have lots of alternatives to choose from.
The IT world that I helped build over the past 45 years... yeah, I know.
And I agree, I am not paying for a lot of these services, so can't really complain. It works as long as it works. Doesn't help against frustration, though.
Compare with the Nora plugin. It worked great, but now that a large crowd is using it, the system crashes. The author knows this, and when explained the users accept it. At least there we know what is going on.
There is no frustration bigger than the "unknown error".
You may be beating me by a couple of years but only just
This is why I got into Node-RED in the first place. Avoiding 3rd-party "free" tools that end up being anything but. Whether because of lost privacy or developers/vendors walking away or one of many other issues. And in any case, I like the challenge and creativity of building my own things which Node-RED has massively helped because I don't have to start from scratch each time. And yet, NR gives me the freedom that something like HA doesn't.
Still, we are drifting off-topic. Yes I absolutely get and share your frustrations.
As a closing note, it is probably worth mentioning that I've found the standard speedtest's increasingly less useful for analysing WAN issues. As such I no longer use them but rather use the tests at DSLreports.
Importantly, they measure buffer bloat which is really important for high-speed connections. Along with jitter and measuring from multiple international locations. This gives you a much better picture of what is going on.
For the rest, I rely on regular ping and DNS checks as this gives me early indication of most issues. DNS in particular I've found to go through issues from time to time, Google DNS being especially bad. At which point, you think you have a general network issue but actually switching to a different DNS fixes things.
