Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autoprint other types of telemetry when returned from --request-telemetry #691

Merged
merged 1 commit into from
Oct 15, 2024

Conversation

logikal
Copy link
Contributor

@logikal logikal commented Oct 15, 2024

Fixes #690.

I didn't want to break the existing output from device_metrics in case people are depending on that specific format, but this is begging for a --json switch in the future.

This approach (iterating and printing keys) should make the output more future proof if/when the protobufs change over time.

Example when requesting !device_metrics:

❯ poetry run meshtastic --request-telemetry power --dest '!dc3b65fb'
Connected to radio
Sending power_metrics telemetry request to !dc3b65fb on channelIndex:0 (this could take a while)
Telemetry received:
powerMetrics:
  ch1Voltage: 16.08
  ch1Current: 4.0
  ch2Voltage: 2.68
  ch2Current: 37.6
  ch3Voltage: 0.0
  ch3Current: 0.0

> poetry run meshtastic --request-telemetry environment --dest '!dc3b65fb'
Connected to radio
Sending environment_metrics telemetry request to !dc3b65fb on channelIndex:0 (this could take a while)
Telemetry received:
environmentMetrics:
  temperature: 17.26
  relativeHumidity: 66.96
  voltage: 16.08
  current: 4.4

Example when not specifying a type, or when specifically requesting device:

at 16:59:16 ❯ poetry run meshtastic --request-telemetry device --dest '!dc3b65fb'
Connected to radio
Sending device_metrics telemetry request to !dc3b65fb on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 15.00%
Voltage: 3.36 V
Total channel utilization: 10.72%
Transmit air utilization: 2.20%
Uptime: 792641 s

at 17:02:25 ❯ poetry run meshtastic --request-telemetry --dest '!dc3b65fb'
Connected to radio
Sending device_metrics telemetry request to !dc3b65fb on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 15.00%
Voltage: 3.37 V
Total channel utilization: 20.17%
Transmit air utilization: 2.22%
Uptime: 792641 s

Copy link

codecov bot commented Oct 15, 2024

Codecov Report

Attention: Patch coverage is 0% with 17 lines in your changes missing coverage. Please review.

Project coverage is 60.57%. Comparing base (3eabaf9) to head (ee405fe).
Report is 2 commits behind head on master.

Files with missing lines Patch % Lines
meshtastic/mesh_interface.py 0.00% 17 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #691      +/-   ##
==========================================
- Coverage   60.68%   60.57%   -0.12%     
==========================================
  Files          24       24              
  Lines        3770     3777       +7     
==========================================
  Hits         2288     2288              
- Misses       1482     1489       +7     
Flag Coverage Δ
unittests 60.57% <0.00%> (-0.12%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ianmcorvidae
Copy link
Contributor

Nice, this is a straightforward way to do it. Agreed on the JSON format, too. That, at least, can pretty straightforwardly match the protobufs, hopefully, but need to get the wiring in place and all that (excuses excuses, I know). I could swear I'd checked and thought the response function was already doing something like this, but I was clearly more tired than I thought when I did that PR, heh. Thanks for finding my mistake/putting up a solution!

@ianmcorvidae ianmcorvidae merged commit 3afb294 into meshtastic:master Oct 15, 2024
9 of 11 checks passed
if telemetry.device_metrics.uptime_seconds is not None:
print(f"Uptime: {telemetry.device_metrics.uptime_seconds} s")
else:
# this is the new code if --request-telemetry <type> is used.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably need to add a guard for some sort of 'received empty or garbled TELEMETRY_APP packet' here. Otherwise we'll choke on this. The old version at least checked for telemetry.HasField("device_metrics")

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're parsing the protobuf out of the payload up above on line 662, I think it wouldn't get here at all if it's garbled in some fashion we could usefully detect. If it got an empty value back, the MessageToDict wouldn't have keys in it anyway, so it'd just print "Telemetry received:" and then nothing. Which, while a little confusing, probably not a big deal. I guess maybe it'd be reasonable to check what happens when requesting telemetry types not supported by a given node, since that'd possibly (probably?) return a payload with the right oneof selected but nothing to put into it. But I think it'd still print something comprehensible enough, so not too worried about it.

@logikal logikal deleted the telemetry_output branch October 23, 2024 21:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug: --request-telemetry with non-default types prints the wrong telemetry
2 participants