meshtastic
[Bug]: Wi‑Fi reconnects use a new database when the node’s IP changes;
Checklist
-
[x] I have used the search function for OPEN ISSUES to see if someone else has already submitted the same feature request.
-
[x] I have also used the search function for CLOSED ISSUES to see if the feature was already implemented and is just waiting to be released, or if the feature was rejected.
-
[x] I will describe the request with as much detail as possible.
-
[x] This request contains only one single feature, not a list of multiple (related) features.
-
[x] I have read and understood the Contribution Guidelines.
-
[x] I agree to follow this project's Code of Conduct
Contact Details
No response
Feature or improvement you want
-
We currently derive the per-device Room DB name from the saved device address string (e.g. t192.168.4.155).
-
When a Wi‑Fi node obtains a new IP or port, the app generates a brand-new DB hash for that address, so the conversation history appears empty until the node replays everything.
-
BLE connections already land in a separate namespace, so a single physical radio can end up with multiple DBs (BLE MAC, old IP, new IP, etc.).
Expected: BLE and TCP connections to the same radio reuse the same on-device database, even if the IP changes.
Proposal: Move the DB keying to a transport-independent identifier (e.g. node ID / hostname) after a successful handshake, and migrate existing TCP/BLE DBs to the new naming scheme.
Why should this be added?
No response
Screenshots / Drawings / Technical details
No response
I've taken a couple cracks at this but unable to get working so far. Device address is available to us immediately so it is the easiest route. I've been running into sqlite errors. Will continue trying to resolve but putting on the back burner
A configuration screen for equivalent devices could be added. This would allow you to link several device entries to the same physical device. When connecting, instead of using the database associated with the device’s address, the system would check whether an equivalence is configured. If so, it would use the database of, for example, the first registered device (or a similar rule, ie defining a primary device, or the one with the oldest DB date, etc). This way, no changes would be needed in the existing logic. You could also associate different connection types—for example, a node accessible via both Bluetooth and Wi-Fi.
In addition, it might be useful to allow entering a domain name instead of an IP address when connecting to a node over Wi-Fi. With proper configuration on the user’s network, this would let multiple IP addresses point to the same database.
Or maybe, another idea, same logic as now, but not configuration screen, but instead saving node name and DB name (derived form address as now) for every connection in a new table. When connecting for first time to a new address, create new DB by address as now, but when receiving the device name, check if there is any register for a device with the same node name, and if so, disconnect and use the existing DB. Add a new register to this new table, so next time will use the existing DB directly without need to disconnect and connect.