Bug report: meshtastic.exe app wipes some node settings
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
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 zzzThis resets the node to factory defaults:
meshtastic --setlat xx.xxxx --setlon yy.yyyySo 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.
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
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?
Unfortunately not as I don't have any other systems, just Macs.