[BUG] Meshmonitor changes the device ID

[Sashoid-x]

When changing device settings, Meshmonitor changes the device ID, but the keys remain the same. This results in clones of the same device with different IDs being created on the network. Firmware 2.7.19, Meshmonitor 3.9.5

[Yeraze]

Need more details:

• Deployment type - Wifi, bridged, HAT
• Hardware - Heltec V4? G2?
• Deployment - Docker, Windows, LXC

[Sashoid-x]

Docker on debian, connect via wi-fi, hardware Seeed Xiao ESP32S3, The neighboring city's network has the same problem with Heltec v4.
The last time this happened was when changing a LoRa preset. Before that, it happened with other settings, but I can't remember which ones. That was over a week ago, so the Meshmonitor version was lower.

[yaLexus]

I have the same problem, it happens multiple times on different devices. Heltec v3/v4. Meshmonitor different versions, latest docker, latest Linux Mint, network connection.
Last time it happens today when I reboot Heltec v4 via Meshmonitor.

[Yeraze]

If you have a device you can reliably replicate this on, it would be useful to get both Device Logs & docker container logs when this happens. I've had it happen myself once, but I can't reliably reproduce it to see what's causing it.

AFAIK, the NodeID is completely an internal-to-firmware thing that can't be changed by MeshMonitor.. so I'm a bit puzzled by how this is happening.

[pjao]

I can share an additional observation from my side.

After changing these parameters:

• MESHTASTIC_CONNECT_TIMEOUT_MS=60000
• MESHTASTIC_RECONNECT_INITIAL_DELAY_MS=60000
• MESHTASTIC_RECONNECT_MAX_DELAY_MS=60000
• MESHTASTIC_MODULE_CONFIG_DELAY_MS=1000

the situation improved significantly for me.

Also, when using mqtt-proxy, I have not seen the same problem so far, although I am still testing. If that remains consistent, it may suggest that the issue is more related to the node firmware itself when using direct MQTT over WiFi, rather than when MQTT is handled through the proxy path.

That said, it still looks like there is some trigger causing the Node ID to change, and that trigger appears to be related in some way to MeshMonitor interaction, especially when changing settings.

So at least from my testing:

• increasing the connect/reconnect timing helps a lot
• mqtt-proxy seems more stable so far
• the Node ID change still appears to be triggered by some MeshMonitor-related action or sequence

[Yeraze]

I suspect I'm tickling some issue/bug in the 2.7.19 firmware because that seemed to be the beginning of this problem.. But I haven't been able to nail down exactly what's causing it.

[pjao]

I suspect I'm tickling some issue/bug in the 2.7.19 firmware because that seemed to be the beginning of this problem.. But I haven't been able to nail down exactly what's causing it.

I also tested with firmware 2.7.15.567b8ea Beta, and I saw the same behavior there.

So from my side, this does not seem to be limited to 2.7.19 specifically.

That may suggest either:

• the underlying issue was already present in earlier firmware
• or MeshMonitor is triggering a firmware-side bug that is not unique to 2.7.19

[yaLexus]

For information
I use the firmware from here: https://mrekin.duckdns.org/flasher/?src=m1nl
M1nl v2.7.19.a13d0a4.daily on v4
and M1nl v2.7.16.d55da25c6 on v3

[gbdabomb]

I suspect I'm tickling some issue/bug in the 2.7.19 firmware because that seemed to be the beginning of this problem.. But I haven't been able to nail down exactly what's causing it.

I was on 2.7.16 firmware with the issue.

[Yeraze]

Has anyone succeeded in collecting logs when this happens?

Can anyone share detalis on what they were doing when it happened? MM Upgrade? Firmware update? Saving settings?

[gbdabomb]

When changing device settings, Meshmonitor changes the device ID, but the keys remain the same. This results in clones of the same device with different IDs being created on the network. Firmware 2.7.19, Meshmonitor 3.9.5

I've had this issue occur due to a reboot of the node without any configuration changes applied.