Multiple issues running tools on new(er) dish

[tuctboh]

Running a new(er) dish/router, and ran into some issues -

1) It seems the new port is 192.168.1.1:9000 for the RPC calls 2) I wasn't able to use any of the "spacex.api" files until I touched a init.py 3) My system (Older Pi running stretch) couldn't find influxdb and the whole requirements.txt install failed 4) Traceback (most recent call last): File "dump_dish_status.py", line 25, in print("Connected" if response.dish_get_status.state == AttributeError: 'DishGetStatusResponse' object has no attribute 'state' 5) To be able to run some things, I needed to create spacex/api/device/dish_config.proto 6) python3 dish_obstruction_map.py -e 192.168.1.1:9000 obstruction.png Traceback (most recent call last): File "/home/pi/starlink-grpc-tools/starlink_grpc.py", line 1242, in obstruction_map map_data = get_obstruction_map(context) File "/home/pi/starlink-grpc-tools/starlink_grpc.py", line 1222, in get_obstruction_map return call_with_channel(grpc_call, context=context) File "/home/pi/starlink-grpc-tools/starlink_grpc.py", line 427, in call_with_channel return function(channel, *args, *kwargs) File "/home/pi/starlink-grpc-tools/starlink_grpc.py", line 1219, in grpc_call timeout=REQUEST_TIMEOUT) File "/home/pi/.local/lib/python3.5/site-packages/grpc/_channel.py", line 946, in call return _end_unary_response_blocking(state, call, False, None) File "/home/pi/.local/lib/python3.5/site-packages/grpc/_channel.py", line 849, in _end_unary_response_blocking raise _InactiveRpcError(state) grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with: status = StatusCode.UNIMPLEMENTED details = "Unimplemented: device.Request_DishGetObstructionMap" debug_error_string = "{"created":"@1653509590.780266717","description":"Error received from peer ipv4:192.168.1.1:9000","file":"src/core/lib/surface/call.cc","file_line":1070,"grpc_message":"Unimplemented: *device.Request_DishGetObstructionMap","grpc_status":12}"

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "dish_obstruction_map.py", line 186, in main() File "dish_obstruction_map.py", line 172, in main rc = loop_body(opts, context) File "dish_obstruction_map.py", line 28, in loop_body snr_data = starlink_grpc.obstruction_map(context) File "/home/pi/starlink-grpc-tools/starlink_grpc.py", line 1244, in obstruction_map raise GrpcError(e) starlink_grpc.GrpcError: Unimplemented: *device.Request_DishGetObstructionMap

but in spacex/api/device/dish_pb2.py I see - _DISHGETOBSTRUCTIONMAPREQUEST = _descriptor.Descriptor( name='DishGetObstructionMapRequest', full_name='SpaceX.API.Device.DishGetObstructionMapRequest',

and

_DISHGETOBSTRUCTIONMAPRESPONSE = _descriptor.Descriptor( name='DishGetObstructionMapResponse', full_name='SpaceX.API.Device.DishGetObstructionMapResponse',

But not sure why now.

Anything I can do for testing/help, lemme know!

Tnx, Tuc

[sparky8512]

192.168.1.1:9000 is the RPC port of the router, not the dish. The Starlink stock router also runs a gRPC server, and while it shares protocol definitions with the dish, it implements a different set of them. Since you're not actually connecting to the dish, this is causing some of your problems (item 6 for sure, although the error reporting could certainly be better on that).

Beyond that, I'm a little unclear on how you're installing. It sounds like you're generating the protocol files rather than using reflection? If the install with requirements.txt failed, then did you manually install all the other modules besides influxdb?

If you are generating the protocol files manually, it appears the protocol file spacex/api/device/dish_config.proto was added since last I verified those instructions. I will update the instructions to reflect that, but I generally recommend installing the yagrc module to avoid the need for generating the prorocol modules.

For dump_dish_status.py, which does still need those protocol modules as I never ported it to use reflection in order to keep it simple, I guess I never updated it to the protocol change that happened last year. I will do so.

[tuctboh]

1. Oops. Mea culpa. But, while I'm here, anything good we can do against the router for fun? ;) No worries, just took adding - ip route 192.168.100.1 255.255.255.255 GigabitEthernet0/2 dhcp into my router and now I have access to it. FYI - I also did a git pull before running all this.

2. So I was playing around with the protocol files, but yes, reflection is working fine. :)

3. Should the requirements.txt be broken into multiple parts, so that everyone does the requirements.txt, and if you need you can run install against "influx1req.txt", "influx2req.txt", "mqttreq.txt", etc? Part of my issues is I wasn't paying attention (No surprise, huh?) and then started to load all the bits by hand as I ran into them

4. Once I actually dump the protoset on the dish, and run the script, touch the init.py in spacex , this now works perfectly.

5. Looks like I didn't need that file afterall (I think)

6. Looks like things are good now with that, I got my map. Little upset at the results. :-/

Thanks, Tuc

[sparky8512]

1 - I haven't run the Starlink router for a long time, but there's really nothing in the gRPC protocols that you can't access via the mobile app. This is true for the dish, too, but the dish provides some data that can be interesting to track over time. I'm not sure what would be worthwhile tracking for the router. That being said, it's certainly possible, just not something I've been interested in.

3 - While I don't particularly like lumping all the pre-reqs together like that, the whole point of requirements.txt is to simplify the install process for people that don't want to dig into the details (or read lengthy documentation). For those that want more granular control, there is a wiki page that describes which packages are needed for what functionality. Granted, it's a little verbose given that each of the package install steps boils down to a single pip install command, and maybe that page could benefit from a TL;DR section that just lists the commands to run for each bit of functionality.

4 - I don't understand why you would need to touch init.py anywhere. What error do you get without that? Also, what version of the Python interpreter are you running, in case that is relevant?

6 - Ouch.

[tuctboh]

1. Are you just running ethernet into something? So lets take a step back. This is for a house thats in a remote area. You drive on the edge of the Atlantic Ocean for 9 miles to get to it. Oddly, I can get DSL (That works when the horses don't eat the wire) and have 50Mb/s. I use LTE (Verizon) as a backup, and now I wanted to put in Starlink as either a primary or backup. So I'm only physically there about a total of 4 weeks throughout the year. I did order the ethernet adapter, but it didn't work, so I'm actually currently using their router with a weird SSID, and then a BrosTrend Dual Band 1200Mbps WiFi Bridge that has its ethernet into Gig0/2 of a Cisco 3945e. I keep a set of Raspberry Pis there with Smokeping and MRTG and other things. I do have a VPN into the systems which then I could use the app, but if I can use other tools/etc to get the same info and then monitor/graph even better. No worries overall, just was wondering.

2. No, I get it, I've used requirements files before, but wish there was some way to say "These are required, make sure to install them, and these are optional, if they don't install just let the user know. ". I ran it, saw the failure and figured the rest were already installed, and then kept installing them by hand as I ran into it. :)

3. pi@valhalla-p2:~/starlink-grpc-tools$ python3 dump_dish_status.py Traceback (most recent call last): File "dump_dish_status.py", line 6, in from spacex.api.device import device_pb2 ImportError: No module named 'spacex.api' pi@valhalla-p2:~/starlink-grpc-tools$ touch spacex/init.py pi@valhalla-p2:~/starlink-grpc-tools$ python3 dump_dish_status.py api_version: 5 dish_get_status { device_info {

pi@valhalla-p2:~/starlink-grpc-tools$ python3 --version Python 3.5.3

Its a Raspberry Pi 3 with Stretch. I'm working on replacing them with RPi 4s with Bullseye. Once I finish rebuilding that I'll make my "emergency" trip to replace that, and move the antenna.

6. Yea, ouch. My own fault. I dropped the dish onto an area, let it sit a while. saw what the angle/direction it pointed, and said "Ok, great. If I mount this on a pole, and the flatness isn't blocked, the world is good". So I went out and rented a 2 person auger, bought cement, and a 10ft galvanized pipe. I spaced it away from the building and any overhangs, including the ability for it to have plenty of room to move on its own. Well, apparently, it gets signal even at angles that don't match the way its facing. :-/ So, now I'm planning another trip where I gotta buy another pole+cement, rent the auger again, and move it MUCH father away from the building. Last I knew the app said I'd lose signal every 52 seconds. :-/ Fortunately, its not a primary or secondary, so its not messing anything or anyone up. I just have to figure a time to re-do it all and then bury the cabling DEEP in the sand so the horses don't eat it.

[sparky8512]

I have the older circular dish, so I can just plug directly from the separate POE brick into my own router (which is a cheap Netgear router running OpenWRT firmware).

I guess I can see the need for something other than the mobile app for the router in your use case. You could just use grpcurl to issue grpc commands directly, but I find the JSON interface it uses to be pretty clunky myself. Alternatively, there are a couple other Starlink grpc tools projects floating around, some of which do support the router. I've lost track of most of them, though.

pi@valhalla-p2:~/starlink-grpc-tools$ python3 --version Python 3.5.3

Ah. That's the reason I couldn't reproduce the behavior. I normally test with Python 3.7. Pretty sure Python 3.5 was end-of-lifed some time ago, but I did set the minimum Python version for yagrc to 3.5, and the failure seems to be coming from there. I will have to look into it in the context of that project. I take this back. I got myself confused when I reproduced it with Python 3.5, but that was because I didn't have the protocol files at all. I'm still not able to reproduce, even with Python 3.5(.4). Not sure what I was thinking, dump_dish_status.py doesn't even use yagrc....

For the benefit of anyone else reading this issue: the "missing" file is spacex/__init__.py, GitHub's markdown formatting swallowed the underscores in some of the above comments.

[sparky8512]

Starting with a clean install and using Python 3.5 to do the pip install, I found the following:

• the later versions of the grpcio package fail to install, so had to use earlier versions. Specifically, I used (these are the minimum versions that will satisfy the other package's version requirements):

  pip install grpcio==1.20.0 grpcio-tools==1.20.0 grpcio-reflection==1.7.3

• no version of the InfluxDB 2.x client package was available for Python 3.5, which may be why it failed when using requirements.txt: I had thought it had to do with it being RPi and needing some binary package, but it wouldn't have worked on any system using Python 3.5
• Still not able to reproduce a failure due to not having __init__.py in the package directory

So anyway, I'm going to write this off as being due to some combination of old Python version and/or some quirk of the RPi Python build, and not worry about it much. If you still see this with the later RPi distro, it may be worth documenting the workaround, but given the trouble I had installing with Python 3.5, I think I'm just going to recommend people use 3.7 as a minimum.

[sparky8512]

OK, all the doc updates I've mentioned have now been made, mostly in Wiki pages. I'm going to close this issue out.