The easy stats interface is just so excellent. Am using it as an API all the time. Apart from the sheer usefulness of it, as an api I can now generate automatically customised sections of config for my Firebrick router which contain upstream speed limiter values which the router requires. These speed values are derived by querying the modems using the Johnson easy-stats api. The router needs these to control the fractions of the split of traffic going to each modem according to its own speed capability. Before I had to set these numbers by hand and query the required numbers by hand. Now everything is automated including configuring the router according to the possibly changed speeds as the program can upload changed config into the router. Unfortunately I don’t have a service process / daemon running continuously to oversee this and keep things up to date as I don’t have a suitable box to run it in. The program is running in an iPad and I can’t use such a machine to do that anyway. But aside from that, it’s now just one click to update the router’s configuration to match changed modem upstream sync rates.
Having the easy-stats interface avoids the need to log in, which is irrelevant anyway and would be annoying. It would also be a minor potential security threat. For an application program’s use, if it logs in to the web admin UI, you would have to store some account username + pw somewhere, required for it to get into the modem’s admin interface, and the more places where you store passwords the more possibilities for trouble.
I haven’t yet tried writing an iPad Shortcuts program to log in using the web UI, and I don’t know how much pain that would be.
What I would like to do is test whether or not I have a johnson-easy-stats-api-speaking modem present or not. I want to handle failure conditions properly which include: (i) no modem, (ii) wrong kind of modem (one which doesn’t speak easy-stats), (iii) no speed value available because the link is not up. And I hope that that’s the complete list.
I have a problem with the program hanging in some of the error cases. It maybe that I can’t fix some of the hangs if they are due to a lack of error handling in iOS Shortcuts library routines used to talk to the modem.
I am however wondering if my application program could be made more reliable and more intelligent if it explicitly detected lack of an easy-stats speaker rather than relying on error mechanisms reporting errors or getting a bad value back from http-based queries and checks on its value turn the situation into a ‘fail’ where the fact that the return value is garbage is because we do have some modem, but it is a non easy-stats speaker, could easily be the wrong modem altogether - one of my DLink backup/swapout modems, for example. This doesn’t remove the need to do error handling properly. But if I can’t get error handling the way I want it, then I can perhaps do a workaround for some common cases, and such a workaround might improve things for the most part.
If there is a non easy-stats-speaking modem present, it will be that the wrong model of modem is connected, in my particular situation. So what I’m thinking of doing is poking it with some harmless query first. I could do a getdata, and check that it returns "DONE".
So in future releases, could we keep the getdata / "DONE" protocol? Even if it doesn’t do anything any more, it is a nop that works as a very useful presence-test.
For me though, using the pre-poke-with-getdata strategy might just replace one error-handling problem with another in some cases and it might easily be a stupid idea. There are two questions, one is: can I just fix the error handling anyway? And the second is whether or not this will improve things in practice in a real test with the wrong model of modem present. I suspect I am likely to replace one kind of hang with another. I can hope that with a DLink modem present the http queries will fail straight away, with an error code, and if so I can pick up on that without the pre-poke strategy, and if not then I’m probably stuffed anyway. But I’d like to keep this nop in the api, just in case, if that’s ok?