Hej @Dave_Baldwin - I ended up with the same question, when I shifted from speedtest-cli to the binding based network speedtest. The latter shows lower up/download capacity, than speedtest, which seems to automatically choose the closest server (in my case Stockholm)
Could you solve your problem and would you share your solution here?
SOLVED - for any, who runs into this issue
I had succes in using the speedtest.net servers - an overview of servers is on a github here .
My entry to this was though the webpage of an internet provider http://speedtest4.tele2.net/ , which expolians nicely the underlying concept of the speedtest servers.
The network.things file has to point at an anycast server address, which automatically connects to the closest servers, and one can choose from a range of files in different sizes in order to test the connection.
This is my working definition:
Thing network:speedtest:local "SpeedTest 100Mb" [refreshInterval=180, initialDelay=5, url="http://speedtest.tele2.net", fileName="100MB.zip"]
I benchmarked the quite simple solution here against the ookla speedtest webpage (speedtest.net) and the results are the same. There might be caveats with this simple approach, but one avoids extra rules and binding definitions, which a solution with speedtest-cli requires Openhab: speedtest-cli-by-ookla-internet-up-downlink-measurement-integration