Add CSV header and sqlite schema support for the newly added location group, along with the necessary functions in the starlink_grpc module to expose the field names and types for that group. This really should have gone in with the prior change.
Also, correct the order of the ping_latency and ping_loaded_latency groups in the CSV header, which was backwards. This would have resulted in an incorrect CSV header if both those groups were selected.
Add a new mode group, location, for physical location data. This requires access to the location data being enabled on the dish in order to return data; see README file for more details. At least for now, this functionality should be considered experimental.
This is being lumped into the "status" category for the purposes of database schema, but it's a separate grpc request from the other status data, and can fail at times when the other status request does not, so it has a separate function in the starlink_grpc module.
mypy complained about the signature of conditional def of get_args not matching the one from typing module, so I made it match, but apparently hadn't actually tested it with Python 3.7. It was just the return type hint, but it sill needs to parse at run time.
Also, fix up a few other (non-error) gripes from pylint.
Implement type hints for the data returned from status_data, history_stats, and history_bulk_data, and modify the *_field_names and *_field_types functions to make use of the same data.
This is complicated a little by the fact that the field names returned for sequences in the returned data are slightly different from those in *_field_names, for reasons that I'm sure made perfect sense to me at the time.
Should work with static type checkers on Python 3.8 and later. Python 3.7 is still supported for the run time, but possibly in a way that static type checking will not be able to understand.
This is for issue #57
Reword the is_snr_above_noise_floor description to be more consistent with the rest of the field docs.
Correct the order the status field groups in the docs for the functions that return them to reflect the actual order in which they are returned.
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.
