This adds alert_install_pending and alert_is_heating to the documentation at the top of the module. These alerts were added approximately forever ago, and get picked up automatically via reflection any time the scripts restart, so this is just to get the docs caught up.
This has now tripped up more than one user (see issues #47 and #53). There is a note in the README about this, but it's easy to miss if you don't read it thoroughly.
Not sure why I thought the InfluxDB 2.x client library accepted a bare host/port for the server, in addition to a full URL. It does not, as reported in issue #49. The 1.x client did, but it didn't take a URL for server, anyway.
This corrects the help text to indicate the URL argument specifies a... URL, and corrects the default to be something that could actually work.
While the scripts can mostly work with Python 3.5, the installation or pre-reqs gets really messy, per issue #45. Python 3.5 has been end-of-lifed for a while now, anyway.
As reported in issue #43, the unstow operation is not quite as straightforward to perform using grpcurl as reboot or stow.
This also serves as a simplified example of using reflection (via yagrc) to perform grpc operations on the dish.
For some reason, I had decided that non-stdout output needed to be line buffered, but not stdout? Python will only line buffer stdout by default if it is a TTY, and there are lots of use cases where it is not. And since I started re-opening the output FD, the python executable command line option (-u) no longer works to force it to be unbuffered.
Fix#44
Reintroduce validity check for prolonged obstruction duration and interval, but based on checking for 0.0 and NaN values instead of relying on the valid flag in the gRPC message. Empirical evidence suggests that the dish reports (0, NaN) for those 2 values when it has no obstruction data with which to work, such as when there actually are no obstructions or when the dish has recently rebooted.
This should fix#42.
I noticed this while testing the change that added the --json option, though it is not related to that change.
Sequence types get mushed into a string when not in JSON mode, and that was turning None object values into the string "None", which is not desirable. So, similar to how the text output script handles it, those now get emitted as an empty string instead. JSON mode is probably better to use for this type of data, anyway, but it was bugging me to have it report as "None".
Per discussion in PR #40 comments. This will prevent a stack dump from littering the output when interrupting script run via Control-C. That was useful to have for a while, but probably is not anymore.
Also, fix up a few corner cases where rc could be used without it having been set.
Adjust how the --poll-loops option handles the first set of polled loops for history stats, to make that set of data run against a number of samples (and therefore total time interval) that more closely matches subsequent sets of polled loops. This especially applies to the case where the stats are resuming from a prior counter, where without this logic, the first set had an unintuitively large number of samples.
Fix timestamp reporting for history stats to better reflect the actual accumulated data, for cases where later polls of the history data had failed. This introduced the potential for the status data and the history stats data to have inconsistent timestamps, and required the timestamp collection to be moved from the individual output scripts into dish_common. Rather than deal with the complication this would create for CSV output, where there is only 1 timestamp field, just disallow the combination of options that could result in different timestamps (For CSV output only).
Fix an error case where poll loop counting was not being reset correctly.
Fix explicit --samples option to be honored when resuming from counter for history stats.
Stop pretending 3600 is a meaningful default for the --samples command line option. That hasn't been the case since the history buffer was reduced to 900 samples.
The default behavior if loop interval not set is now to process all samples, which was what effectively what it was doing, anyway.
Remove the validity check that was gating the reporting of the obstruction_duration and obstruction_interval data items.
When that got added to the grpc protocol, I assumed that the valid flag meant whether the other 2 fields were useful data. That may actually have been the intent, for all I know, but I've never seen that flag report true. However, I also never saw the banner in the app telling me I would get obstructions every X minutes, either. That is, until a few weeks ago, probably due to a dish firmware change. Now I see the app reporting this data, so it must be ignoring that valid flag, or at least not using it for that purpose.
Probably nobody cares about this data (including me), given that nobody ever complained about it always reporting empty values, but I don't want to remove it and mess up db schemas, so it might as well be populated.
Add an option to output to a specified file instead of standard output (which is still the default), and if set, attempt to read prior end counter for use in resuming history stats computation at that point. This behavior can be disabled using the --skip-query (-k) option.
Resuming will only work for CSV files that start with a header line that matches the last line in the file, and is currently only enabled for history stats, not bulk history, because the file read operation is not at all optimized for large files. (And because I don't think anyone is really using CSV for recording bulk history data, I only implemented that because it was easy to do so and helps with testing.)
While testing this, I realized that the implementation of the --poll-loops option has an awkward interaction with resuming from prior counter value, but that impacts all the scripts that support resuming from counter, so I will address that in a subsequent change.
This should address all the comments I dropped onto pull request #37.
The only significant fix here is that the SSL command line options should all work now, although slightly differently than how they work in the InfluxDB 1.x script. Whether or not SSL is enabled is controlled by the URL, specifically whether it is an https: URL or an http: one, and the options just control the CA cert parameters.
If there was history data collected via the --poll-loops option, but not yet used to compute history stats, do so on script shutdown. This should reduce the amount of data lost when the script restarts, for example to reboot the system on which it runs, since --poll-loops allows for collection of history data beyond the 15-minute buffer size the dish (currently) holds.
This will only work if the script is shut down via SIGTERM or SIGINT (for example, by interrupting with Control-C).
Not really Starlink specific, and pretty much redundant with similar functionality in grpcurl, but more appropriate for running periodically, as it will use a filename that should be specific to the protocol data content, so old data will not be overwritten when there is new data available.
Add the Python packages required for the InfluxDB 2.x client to Dockerfile, at the specific versions that I tested with. Most of the package dependencies overlap with the InfluxDB 1.x client package, so there was not much added.
Note the new script name in the relevant parts of the README.
Noticed while reviewing the new InfluxDB 2.x script, which was derived from this one.
Also, denote this script as being for InfluxDB 1.x, since there is now a separate script for 2.x.
