Change all uses of protobuf messages other than status and history data so that they will not crash the calling script in the case where the grpc protocol removes the message or field being accessed. Instead, they will return None for the affected field (which most calling scripts interpret as "no data") or raise the same error as when the dish is not reachable.
This is for issue #66.
Change all uses of history data protobuf messages so that they will not crash the calling script in the case where the grpc protocol removes the message or field being accessed. Instead, they will return None for the affected field (which most calling scripts interpret as "no data") or raise the same error as when the dish is not reachable.
Same caveats about code readability and adherence to the advertised type data as the change for protecting status usage.
This is for issue #66.
Change all uses of status data protobuf messages so that they will not crash the calling script in the case where the grpc protocol removes the message, field, or enum value being accessed. Instead, they will return None for the affected field (which most calling scripts interpret as "no data") or raise the same error as when the dish is not reachable.
This makes the code a little less readable, but it's better than breaking every time the protocol obsoletes fields.
mypy now complains about the return types for some fields that are now technically optional but are not marked as such in the type data, because the type data reflects what will currently be returned, not what may turn to None in the future if the protocol changes.
This is for issue #66.
Now, only the main Python scripts are copied into the Docker image, so none of the testing/example stuff or the auxiliary files that aren't relevant to running the Docker image.
This should address issue #74 by removing the script that would have required extra bits to run.
This should allow for a working image if built manually, but does not add it to the multi-arch package built for this project's package repository.
As discussed in issue #72, needed to work around some shared library issue between the binary wheel for one of the prerequisites published to PyPI and the base Docker image.
Move the global state onto the http server object so it doesn't have to be accessed as module globals.
Limit the mode groups that can be selected via command line args to the ones that are actually parsed. There are a few other options added in dish_common that don't really apply to this script, but they are mostly harmless, whereas some of the other mode groups will cause this script to throw an exception.
Reject access to "/favicon.ico" path, so testing from a web browser does not result in running the dish queries twice, and thus confusing the global state a little.
Add a lock to serialize calls to dish_common.get_data. That function is not thread-safe, even with CPython's Global Interpreter Lock, because the starlink_grpc functions it calls block. This script is really not meant for concurrent HTTP access, given that the usage stats are reported as usage since last access (by default), but since it's technically supported, might as well have it work properly.
Add the same handling of keyboard interrupt (Ctrl-C) and SIGTERM signal as the other grpc scripts, along with proper shutdown.
As noted in issue #72, pypng was missing from the list of pip packages installed for the Docker image, which is required for dish_obstruction_map.
Without extraneous changes this time....
They're still pinned to specific versions, just the newest ones as of right now. This should avoid the need for the ARM64 build to compile any wheels that need native code.
Also, reorder how the pip packages are listed for easier maintenance.
Add building of ARM64 Docker image (via QEMU and buildx) and publish it to GitHub Packages Repository along with the AMD64 image as a multi-arch package.
Per discussion on issue #68, setting INFLUXDB_SSL to "false" is not useful here. This was probably copied over from the MQTT example service conf file, where it is supported (although essentially ignored).
The dish firmware stopped reporting the wedge fraction obstructed detail a few weeks ago, and now has apparently dropped it from the grpc protocol.
The core module now reports a sequence of None values for those fields, which is represented as "no data" in most of the database outputs. Without meaningful data in these fields, the obstruction_detail mode group is mostly useless, but the obstruction map was a much better representation of that data, anyway.
This should address issue #65.
I don't necessarily think all of these make the code better or easier to read, but it's easier to just go along with what the tools want, since they do generally make things better.
There should be no functional changes here.
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
Jeffrey C. Ollie
