[Bug]: export -import function not include some parameter

[bv3un]

Category

Other

Hardware

Heltec V3

Firmware Version

2.3.9.f06c56a

Description

Export and import function not include some parameter like GPS position ,NTP server , licensed amateur radio.thus after firmware upgrade and import config need to setup again

Relevant log output

No response

[bplein]

I came here to open this bug, but see that it's been open for some time.

Use case #1: back up configuration with --export-config, and restore 100% of the settings via --configure.
Expected result: 100% of configuration is backed up and restored.
Actual Result: gps position, precision are not exported, so they cannot be imported.

Use case #2: scraping information via --info in order to check a setting.
Expected result: 100% of the configurable settings should be exposed via --info
Actual result: Not all settings are revealed. Example, GPS precision is revealed, but the GPS position, altitude are not.

[ianmcorvidae]

NTP server is exported by --export-config, as is fixed position. I'm not sure where you're seeing it not export position, though it may not do so if you aren't using fixed position (since it wouldn't be useful to do so anyway). It does appear that the is_licensed field isn't exported along with the other ownership fields, though. Position precision only needs to be exported in a couple places. One is in the mqtt settings under mapReportSettings, where it is; the other is in channel settings, which is included within the channel URL. Within --info, position and altitude will be within the nodes data structure -- they're not configuration parameters in the same way other things are.

Other than the is_licensed field I don't think there's anything here to fix.

[bplein]

Thank you for responding so quickly!

For --export-config, fixedPosition: <boolean> is exported, but not the actual position information. This means that setting a fixed position on a node is not backed up, and replacing or re-imaging that node, the full configuration cannot be restored.

Example from my export

  position:
    broadcastSmartMinimumDistance: 100
    broadcastSmartMinimumIntervalSecs: 60
    fixedPosition: true
    gpsUpdateInterval: 120
    positionBroadcastSecs: 10800
    positionBroadcastSmartEnabled: true
    positionFlags: 3

I found this by having to restore a setting to a node, where i have a fixed position that is not exactly where the node is located. I checked from another node, and it was reporting the position of my phone, not the expected values from my previous --setlat etc.

[ianmcorvidae]

The position information is exported under the location header, outside of the config block, for reasons that have to do with the firmware implementation. The position settings section controls how position is managed, vs what actual location is used, basically.

In your export you should see first a channel_url, then config with a number of sub-sections, then location, module_config with subsections, and finally owner and owner_short

[bplein]

Interesting. My T-beam is correctly showing location header by my RAK is not. I was only looking at my RAK4631 device when I commented on this issue.

I wonder if there's another setting that might be preventing location header from being populated.

Thank you for your patience with me. It's on my end it appears.

[interfect]

--configure dropping large swathes of the config is I think caused by the CLI tool not waiting for the earlier transaction/config packets to be handled by the node before sending the later ones, which makes the node drop earlier packets. See meshtastic/firmware#5640 (comment)

I think _sendAdmin either needs to wait for each admin packet to actually be acknowledged (or time out?) before returning and allowing the caller to send the next one:

python/meshtastic/node.py

Lines 991 to 1000 in 622a435

	return self.iface.sendData(
	p,
	self.nodeNum,
	portNum=portnums_pb2.PortNum.ADMIN_APP,
	wantAck=True,
	wantResponse=wantResponse,
	onResponse=onResponse,
	channelIndex=adminIndex,
	pkiEncrypted=True,
	)

Or else we need to add a wall-clock delay between admin packets when restoring the config.

[interfect]

This should have been fixed by #783.

[interfect]

I think that this and related issues (#576) were not actually fixed by #783. I can still reproduce the issue with Meshtastic Python 2.7.1 on Ubuntu with a T3S3. I also just tested with 2.7.3 on Linux with a WisMesh Board One and the 2.7.10 firmware. When restoring the config on the Board One, I can tell I have the bug because I don't get the "Rebooting..." message when the meshtastic --config command finishes running.

I think #265 was probably also the same issue, and not really Windows 11-specific.

If I change the code here:

python/meshtastic/stream_interface.py

Lines 99 to 104 in 3615135

	# win11 might need a bit more time, too
	if self.is_windows11:
	time.sleep(1.0)
	else:
	# we sleep here to give the TBeam a chance to work
	time.sleep(0.1)

And I have it do a 2 second delay on all platforms, then it sends packets slowly enough that my T3S3 can keep up with processing them and I stop losing config data. Also, I can tell it works on the Board One because I do get the Rebooting... message as soon as meshtastic --config is finished.

The right way to solve this is going to require a lot of machinery to wait for acknowledgements from the other end. But just raising the wait time more should help in most cases.