Support .env files & major refactoring of argument parsing about tmo-monitor HOT 5 CLOSED

By the way, my usage is to only reboot if the ping fails (so your multiple tries on the ping logic is nice.)

The log format I'm thinking of is to always check the connection stats and log when they change. Also, log when ping fails and the modem reboots.

For example:

2021-12-02 11:35:00   4G: B2 5G: n41 Ping: 75ms
2021-12-02 11:36:00   4G: B66 5G: n41 Ping: 80 ms       # logged due to 4G band change
2021-12-02 11:40:00   4G: B2 5G: n41 Ping: 100ms        # logged due to 4G band change
2021-12-02 11:40:00   4G: B2 5G: n41 Ping: failed ***REBOOTING***

This led me to separate the configuration and reboot logic in the .env file. Instead of "suppress reboot on X" switches, I have entries to explicitly specify "reboot when X fails."

from tmo-monitor.

@AndrewPardoe thanks for sharing - I am glad you are finding value in the script. I prefer supporting your changes so everyone can benefit and your work can maintained long-term. To adhere to semantic versioning and to anticipate differences in output based on the introduction of logging, I think this calls for a version bump to 2.0.0 once merged and released.

I already wanted to add support for .env files and for logging, so this is great. Let's aim to ensure that there's feature parity and hopefully the notation in the .env file can be as close as possible to the command line arguments to be easily understood in isolation without relying too heavily on the placeholder values.

I had a chance to start reviewing your changes before you rewrote the history after my upstream commit, and saw you namespaced the config values to avoid inherited values like USERNAME causing conflicts.

I think logging the reason for reboots is helpful as demonstrated in your example so it can serve as a proper audit trail. I do want to make sure that people don't need to resort to scraping their logs to analyze changes over time, so in the spirit of #11 hopefully this can eventually evolve to appending stats to a CSV or similar location (in theory the serialization format should be pluggable).

Naturally, we'd still want the sort of logging you've shown.

In terms of "reboot on X", I do think it may be nice to have a more declarative set of configuration (through the .env and/or flags), so giving this release a major version bump should give some freedom to changing defaults vs what was necessary for backwards compatibility up to this point when I was bolting on additional functionality.

Namely, I think the script should not have opinionated defaults to the point where the user has to specify tons of configuration to undo defaults that don't suit common use cases. I also believe that the user shouldn't be surprised by what it is doing.

Probably the most neutral thing the script can do is check for bands (preferring none) and signal metrics, maybe perform a ping, possibly log the results, and then exit.

Let me know if you plan to add any extra polish, but I think for sure your work is welcome and can be merged in rather than staying separate.

from tmo-monitor.

Sounds good! Let me finish up the testing this week and I'll prepare a PR. I've got a few busy days at work ahead but I should be able to finish this week.

from tmo-monitor.

PR is #23

from tmo-monitor.

Fixed by #23

from tmo-monitor.