After trying several different flavours of speedtest, I found the fast-bandwidth node and decided to try it.
Installing is not a problem, but when I trigger the node I get an error message: "failed to load the browser process", plus a whole string of text behind that.
Am I overlooking something?
I am running Node-Red on a Raspberry Pi 4, along with Domoticz. No docker.
It works ok for me. However I see it installs puppeteer which I think is a bit excessive, also it does not link to a github repository, which means there is nowhere to ask questions of report issues, so personally I would avoid it.
OK, sounds like good advice.
I am struggling with a way to do a reliable speedtest. The speedtest-cli version did not work, so I tried the speedtest node again. It seems to work OK, as long as I am online... as soon as I have it triggered by a Domoticz switch, or even by a local timer node, it sometimes fails ("server not found"). I know this sounds rediculous, but it "feels" like it works OK as long as I am watching... 
Assuming you mean node-red-contrib-speedtest (it is a good idea always to give the full name to avoid confusion) then looking at the github repo it appears that it is no longer supported, the latest version in git has never been published.
I don't know what you mean by that.
I should have phrased that better: In what way did it not work?
1 Like
OK, I guess I should have been more precise. The speedtest-cli is what I had running on the Pi, triggered by a crontab. A bash file peeled the results from the output of speedtest-cli and stored it in Domoticz variables. It ran OK, but intermittently gave non-results.. No idea why, it did not give me an error message, just null output.
So I moved to the local Node-Red solution, which runs OK most of the time.
I will attach the flow here:
[{"id":"e7fce67e1a23c0e9","type":"tab","label":"Speedtest","disabled":false,"info":"","env":[]},{"id":"ec6ec17be5140bfb","type":"inject","z":"e7fce67e1a23c0e9","name":"manual start","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payloadType":"date","x":150,"y":60,"wires":[["a3ea5a6ff5175857"]]},{"id":"2c5dfcc47c465918","type":"function","z":"e7fce67e1a23c0e9","name":"update domoticz","func":"var down = {\"command\":\"udevice\",\"idx\":4411,\"svalue\":((msg.payload.speeds.download).toString())};\nvar up = {\"command\":\"udevice\",\"idx\":4412,\"svalue\":((msg.payload.speeds.upload).toString())};\nvar trig = {\"command\":\"udevice\",\"idx\":4414,\"nvalue\":0};\n\nreturn[{payload:down},\n {payload:up},\n {payload:trig}];","outputs":3,"noerr":0,"initialize":"","finalize":"","libs":[],"x":600,"y":140,"wires":[["1ff3d119276ac3f8"],["1ff3d119276ac3f8"],["1ff3d119276ac3f8"]]},{"id":"1ff3d119276ac3f8","type":"link out","z":"e7fce67e1a23c0e9","name":"MQTT to Domoticz","mode":"link","links":["ae7ceee10a8f3a48"],"x":795,"y":140,"wires":[]},{"id":"2a05f97f936a4452","type":"link in","z":"e7fce67e1a23c0e9","name":"","links":["4b40cd9ee87e61a6"],"x":35,"y":200,"wires":[["70e7a2c54259a115"]]},{"id":"70e7a2c54259a115","type":"function","z":"e7fce67e1a23c0e9","name":"Select trigger","func":"var trig = \" \"\nif (msg.payload.idx == 4414) \n if (msg.payload.nvalue == 1)\n return[{payload:trig}];","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":150,"y":200,"wires":[["a3ea5a6ff5175857","00f05cf6fe85b340"]]},{"id":"a3ea5a6ff5175857","type":"speedtest","z":"e7fce67e1a23c0e9","name":"","serverId":null,"maxTime":5000,"x":420,"y":140,"wires":[["2c5dfcc47c465918"]]},{"id":"80faea650b9cb93a","type":"inject","z":"e7fce67e1a23c0e9","name":"start 01:00","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"00 01 * * *","once":false,"onceDelay":0.1,"topic":"","payloadType":"date","x":150,"y":120,"wires":[["a3ea5a6ff5175857"]]},{"id":"00f05cf6fe85b340","type":"debug","z":"e7fce67e1a23c0e9","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":400,"y":200,"wires":[]}]
When I trigger the flow manually, it gives me good results. It stores the up and down values in Domoticz.
When it is triggered by the timer, it fails: server not found.
WHen it is triggered by the Domoticz trigger switch, it depends: very often it will run OK, as long as I am there... 
When I set the trigger switch based on a lua script, or on it's own timer, it will usually fail.
This is driving me nuts...
The example using the "speedtest-cli --json": can you share the flow? And is it depending on a pre-installed package on the Pi OS?
When I look at the apps section of speedtest.net, I don't see a Raspberry version. Closest to that is the Linux download... does that work on Raspberry OS? If yes, which hlavour should I pick? I see five...
FYI, I use a Raspberry Pi 4.
You can install it in a Pi using
sudo apt install speedtest-cli
There is nothing to share really, it is just an exec node running that command, followed by a JSON node to convert the JSON string to a javascript object. Here is is though.
[{"id":"9e58be87e19370f0","type":"debug","z":"bdd7be38.d3b55","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":590,"y":1180,"wires":[]},{"id":"edb1b9e937ea0f6a","type":"inject","z":"bdd7be38.d3b55","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":100,"y":1180,"wires":[["9ef3a9bff8062678"]]},{"id":"9ef3a9bff8062678","type":"exec","z":"bdd7be38.d3b55","command":"speedtest-cli --json","addpay":"","append":"","useSpawn":"false","timer":"","winHide":false,"oldrc":false,"name":"speedtest-cli --json","x":270,"y":1180,"wires":[["6ab4ce753b388437"],[],[]]},{"id":"6ab4ce753b388437","type":"json","z":"bdd7be38.d3b55","name":"","property":"payload","action":"","pretty":false,"x":450,"y":1180,"wires":[["9e58be87e19370f0"]]}]
However, do you not think it is suspicious that every speedtest you have tried occasionally fails? That makes me think that perhaps there is actually a problem with you system or network access that causes the problem.
If you find that the cli version still fails for you then attach debug nodes configured to Output Complete Message directly to all three exec node outputs and see what they show for the failing case. Give the debug nodes names so you can identify them more easily.
How often are you running the speedtest?
Indeed, it is suspicious. I feel that there is some problem that is not directly related to speedtest, but the big problem is how to find it.
I will try to install one of the ookla install sets, and see where that brings me.
My original idea was to run it automatically four times a day to start with, perhaps reduce to twice after a while.
Run the cli version and capture the output. If it makes it easier, send the debug output to the Console, then you will be able to look back in syslog to see what happened.
The reason for using the cli version is that you will almost certainly get more information out of that, when it fails, than out of a packaged version.
In my experience, all of the speedtests occasionally fail. I seem to remember that a problem was reported with Telegraf and its speedtest function. If I remember correctly, there is a problem when running speedtests that hit a regular boundary such as the top of the hour.
That is intesting. @manjha you said it fails more often when run automatically by your system. Are you requesting it at the hour, or something like that? Perhaps try offsetting it a few minutes. Alternatively just ignore the occasional failure, or retry a few minutes later if you don't want to do that.
1 Like
Here is what I ended up with in my Telegraf conf, it also has the link to the issue:
[[inputs.internet_speed]]
interval = "3591s" # About every 1h but not exactly on the hour https://githubmemory.com/repo/influxdata/telegraf/issues/9852 https://www.speedtest.net/speedtest-servers-static.php https://github.com/showwin/speedtest-go
By the way, you can use Telegraf to output to MQTT for instantaneous results as well InfluxDB for historic values. So with MQTT outputs, you could simply subscribe to the appropriate topic in Node-RED.
# # Configuration for MQTT server to send metrics to
[[outputs.mqtt]]
servers = ["127.0.0.2:1883"]
keep_alive = 30
topic_prefix = "telegraf"
qos = 2
client_id = "telegraf_home"
data_format = "json"
This is an easy way to get access to lots of system and service related stats and a good way to spot when you have a network or a device problem for example.
Yes, I typically asked for it to run right on the hour.... no specific reason, I will pick another time.
As per your advice, I removed the node-red-contrib-speedtest-updated from my flows.
Then installed speedtest-cli following this instruction:
Install speedtest-cli on Raspberry Pi | Lindevs
It now runs OK, both manually as well as triggered by a Domoticz trigger switch.
I will see what happens over the next days.
Why did you not just install the version from the repository as I suggested?
Oops, overlooked your suggestion.. apologies.
Is it better to install that way? Should I remove the current and install from the repository?
