Consecutive runs of dishHistoryInflux.py generate error. about starlink-grpc-tools HOT 5 CLOSED

Hmm... I guess I need to make sure the stats that could be fractional always report as float, but count_full_obstructed_ping_drop shouldn't be fractional unless the pop_ping_drop_rate value in the raw data is greater than 1, which... I guess I shouldn't have assumed would never happen, but I'm not even sure what that means. More than 100% of the pings in that second were dropped?

from starlink-grpc-tools.

Could you run dishHistoryStats.py -v against that after verifying the problem is still reproducible? I think I can address the type conflict by manually forcing the data values, but I don't understand why that particular stat did what it did.

from starlink-grpc-tools.

Oh. Never mind. It's not greater than 1, it's being treated as a float because the variable it adds is sometimes a float. I guess I never ran into this because the history data from my dish is full of fractional ping drops so that variable would frequently be a float.

from starlink-grpc-tools.

Whoops, didn't mean to close this.

@neurocis : please retest with that change, but note that you may need to delete the existing data point from the database if any of the fields already got in with the wrong type. A good test will be to alternate between just an hour's worth of samples (the default) and all samples (dishHistoryInflux.py -a). If it looks good now, send this back to me, as I still need to update starlink_json.py for consistency.

from starlink-grpc-tools.

I'm pretty sure it's fixed now, as of that later change. I also checked the status Influx script and verified that it will not have the problem, since it just passes the grpc object attributes directly, and those are guaranteed to always be the same type (floats, bools, or strings).

Please re-open if it continues to be a problem with both the above changes.

from starlink-grpc-tools.