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

[Enancement]: merge device.debug_log_enabled and bluetooth.device_logging_enabled #4375

Closed
geeksville opened this issue Aug 2, 2024 · 9 comments · Fixed by #4516
Closed
Labels
enhancement New feature or request

Comments

@geeksville
Copy link
Member

geeksville commented Aug 2, 2024

Category

Other

Hardware

Not Applicable

Firmware Version

master

Description

Hi @thebentern and @garthvh,

What do you think about merging device.debug_log_enabled and bt.device_logging_enabled? Since they both do the same thing but for different interfaces (and probably only turned on by devs). Does the iOS client/android client have any UI for these flags currently? If not I'd propose we keep only device.debug_log_enabled.

Relevant log output

No response

@geeksville geeksville added the enhancement New feature or request label Aug 2, 2024
@geeksville geeksville self-assigned this Aug 2, 2024
@garthvh
Copy link
Member

garthvh commented Aug 3, 2024

Both apps have it but it they don't get used much yet and we can totally coordinate on consolidation, it would be nice if we could make it easy for people to turn on one toggle and get logs on their phone, and otherwise have this stuff disabled. The always on serial console has an appreciable power hit (and is a potential security issue) for repeater / router nodes.

@thebentern
Copy link
Contributor

I'm in favor of this. Like you said, they're both protobuf logging mechanisms. Perhaps we deprecate the bluetooth one and rename debug_log_enabled to logrecord_api_enabled to be more clear from a developer standpoint. debug_log_enabled seems too vague at this point

@garthvh
Copy link
Member

garthvh commented Aug 3, 2024

If we can do the same underlying thing on android I did on iOS (push our BLE logging into apple's OSLog and then allow download of the combined app / radio log) it should really help get data from users having issues. Right now we can only really help the few users who can figure out the CLI.

@geeksville
Copy link
Member Author

geeksville commented Aug 3, 2024

ok @garthvh and @andrekir. Since it sounds like usage is currently low:

I'll send in protobuf changes to remove bluetooth.device_logging_enabled from the protobufs and rename device.debug_log_enabled as device.logrecord_api_enabled. The device code will only use that new name and any old clients happen to use the old boolean it will be no effect on the device.

@garthvh can I also remove the deprecated pre logrecord BLE debugging endpoints at the same time?

cool?

@andrekir
Copy link
Member

andrekir commented Aug 3, 2024

sounds good to me.

do we still need a separate BLE characteristic for logs now that it's using the LogRecord fromRadio?

@garthvh
Copy link
Member

garthvh commented Aug 4, 2024

sounds good to me.

do we still need a separate BLE characteristic for logs now that it's using the LogRecord fromRadio?

That is a good question, @thebentern?

@garthvh
Copy link
Member

garthvh commented Aug 4, 2024

ok @garthvh and @andrekir. Since it sounds like usage is currently low:

I'll send in protobuf changes to remove bluetooth.device_logging_enabled from the protobufs and rename device.debug_log_enabled as device.logrecord_api_enabled. The device code will only use that new name and any old clients happen to use the old boolean it will be no effect on the device.

@garthvh can I also remove the deprecated pre logrecord BLE debugging endpoints at the same time?

cool?

Yeah I think ben left it in place but I will consolidate everything, feel free to remove old stuff.

@thebentern
Copy link
Contributor

Since it was only shipped in one version in the past behind our beta builds, I think we can safely remove it.

@geeksville
Copy link
Member Author

ok starting on this now.

geeksville added a commit to geeksville/Meshtastic-protobufs that referenced this issue Aug 20, 2024
security option.  Per discussion in meshtastic/firmware#4375
no need to preserve the old options when changing to this new simpler
single boolean because they were newish, rarely used and only for 'advanced'
developers.
geeksville added a commit to geeksville/Meshtastic-esp32 that referenced this issue Aug 20, 2024
security option.  Per discussion in meshtastic#4375
no need to preserve the old options when changing to this new simpler
single boolean because they were newish, rarely used and only for 'advanced'
developers.
@geeksville geeksville removed their assignment Aug 20, 2024
thebentern pushed a commit that referenced this issue Aug 24, 2024
security option.  Per discussion in #4375
no need to preserve the old options when changing to this new simpler
single boolean because they were newish, rarely used and only for 'advanced'
developers.
geeksville added a commit to geeksville/Meshtastic-esp32 that referenced this issue Aug 28, 2024
…htastic#4516)

security option.  Per discussion in meshtastic#4375
no need to preserve the old options when changing to this new simpler
single boolean because they were newish, rarely used and only for 'advanced'
developers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants