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

Bug report: meshtastic.exe app wipes some node settings #500

Open
clwgh opened this issue Mar 13, 2024 · 4 comments
Open

Bug report: meshtastic.exe app wipes some node settings #500

clwgh opened this issue Mar 13, 2024 · 4 comments
Labels
help wanted Extra attention is needed

Comments

@clwgh
Copy link

clwgh commented Mar 13, 2024

meshtastic --version
2.2.22
Heltec V3 running the 2.3.0 Alpha firmware

Using the meshtastic.exe app to configure various settings on a Heltec V3, I've found that various Heltec's settings often being reset unexpectedly. So far the examples I've seen are:

This works (replacing x, y and z with proper values):
meshtastic --setlat xx.xxxx --setlon yy.yyyy --setalt zzz

This resets the node to factory defaults:
meshtastic --setlat xx.xxxx --setlon yy.yyyy

So does this incorrect command (typing as shown to trigger the list of correct parameters to be shown):
meshtastic --set xxx xxx

@rcarteraz
Copy link

meshtastic --version 2.2.22 Heltec V3 running the 2.3.0 Alpha firmware

FYI there's a new version available 2.3.0.

Using the meshtastic.exe app to configure various settings on a Heltec V3, I've found that various Heltec's settings often being reset unexpectedly. So far the examples I've seen are:

This works (replacing x, y and z with proper values): meshtastic --setlat xx.xxxx --setlon yy.yyyy --setalt zzz

This resets the node to factory defaults: meshtastic --setlat xx.xxxx --setlon yy.yyyy

So does this incorrect command (typing as shown to trigger the list of correct parameters to be shown): meshtastic --set xxx xxx

I was not able to reproduce this. All these commands worked as expected multiple times. There was some weirdness though. Commands that normally wouldn't require a reboot of the device, like --info, would reboot the device. Likewise the last example you provide, you wouldn't expect the device to reboot since nothing was set -- but it did.

Worth noting that I do not have these issues with macOS. I opened up my windows laptop to test this and it's only an issue with Windows. Additionally, I tested both the standalone.exe version and the the packaged version from pip and same results across both.

@clwgh
Copy link
Author

clwgh commented Mar 13, 2024

Many thanks for the reply and for testing. I'll grab the new version and test again in the next few days, and let you know if I find anything of interest.

I'm using a Windows 10 VM on a Mac under Fusion, the flasher and the meshtastic app work okay, no issues with the interface itself.

I've seen a few examples of people posting, eg, three commands

meshtastic --setlat xx.xxxx
meshtastic --setlon yy.yyyy
meshtastic --setalt zzz

But when I try that, the two settings that were not set each time are nulled, which is why I've been using a one-liner. I assumed it was just that the CLI behaviour had changed since those posts, as a way to be able to unset the desired parameters, but maybe this is the same effect.

Regarding the example, I set a manual location with the one-liner, and then (unrelated to this issue) a bug in the iOS app's behaviour overwrote the Lat, Lon and Alt registers with the phone's location. So I reconnected it to the CLI to use the one-liner again and this time left off the --setalt parameter, in order to just set the Lat and Lon.

When I did --export-config I could see that all settings had mostly been wiped. The screen had reverted direction, IMPERIAL units were unset, Lat, Lon and Alt were not listed, the node name and short name were reset to firmware defaults, the node and position reporting intervals were reset to default values.

This was repeatable. However I did not test whether the cause was the missing --setalt after being previously set, or just the act of using this command a second time after the iOS app had also written values to those registers.

It may be related to the Alpha 2.3.0 firmware, I've also not yet tested the normal firmware. Sorry for the slightly untested report, but I thought worth mentioning in case it's useful to you.

Is there an option to display the many --set parameters that can be invoked without using incorrect parameters to trigger it? Eg the many options which include the likes of --set device.node_info_broadcast_secs xxx and --set position.position_broadcast_secs xxx?

Thanks again.
Chris

@caveman99
Copy link
Sponsor Member

serial handling is problematic in a virtualized environment. Also depending on how the serial interface is wired in a certain board, the windows serial code of python trigger s(hardware) reboots, e.g. my m5stack core does that. - Can you please try to repro this with a hardware/os level serial port?

@clwgh
Copy link
Author

clwgh commented Mar 13, 2024

Unfortunately not as I don't have any other systems, just Macs.

@garthvh garthvh added the help wanted Extra attention is needed label Mar 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants