Hi everyone! I have been enjoying Meshtastic a lot lately, but I have noticed an issue that’s becoming more of an issue as time goes on.
I recently added a Wisblock as a router on my mesh. It initially came named as “Repeater” when I plugged it in to the computer to flash. What I noticed when I renamed it and then firmware updated it, it created a duplicate node seen by my Android app connected to a Heltec. Then every time I made a change to the Wisblock, it created another duplicate. If I force close the Android App, it disappears to all but two of them, but it shows “3 of 41 online” in the notification area, when there are only really a half dozen real ones. Every morning I wake up I see a duplicate reappear in the list, force close it, and it disappears to only two of them again.
I also had a lot of problems getting the Wisblock to keep settings changed from the Python CLI as well. It would straight up ignore some setting changes and had to change them over the Android App, but that’s another issue.
I was wondering what I could do to fix all the weird behaviors in Android regarding this node. I think maybe somehow the MAC address changed after I factory reset it. I see two different ones with the same name when looking at the list from the Python script. I know there is a long term goal to remove specific nodes from the node db, so I can’t really do anything about that. But these ghost duplicates that seem to appear and disappear in the Android App seem to be a different issue. How can I fix this without losing data?
Indeed it is due to that there is another node with the same node number in your mesh. The firmware will then choose a random new node number to avoid conflict. However, it seems to do this on every reboot; I just opened a Pull Request to avoid this.
Only after a factory reset it will then still choose a new random number when it detects the other node again, however I’m not sure if there’s anything we can do about that apart from hard-coding a different node number.
That explains it! Would it be a bad idea to have it configurable?
What can I do about the nodes that the Android App thinks it knows about but doesn’t show up in the list? It currently thinks there are 41 nodes it has seen, but only about 12 are in my list, with only 4 actually active. I see there’s an update coming where I can remove nodes from the nodedb, but if they don’t show up, I don’t know how I would remove them. I don’t want to lose message history by resetting the app either.
Humans are generally bad at coming up with random numbers, so I think normally this should just be based on the MAC address. It seems you’re unlucky and have nodes with nearly the same BLE MAC address in your mesh. It should be solved after this PR, until you factory reset the node, but that’s generally not needed.
I see there’s an update coming where I can remove nodes from the nodedb
Yes, I believe in the latest version of the Android app (2.3.4) you can remove individual nodes. You can now already remove all nodes at once (they will populate again if you’re in range of them again for a while) with Radio Configuration → NodeDB reset.
I think you’re right about humans being bad about coming up with random numbers. However, I was thinking in the case of a configuration export, it could retain the MAC or random number chosen, so that a factory reset and then a config import would preserve that node number again. The default behavior shouldn’t change otherwise.
Wouldn’t the NodeDB reset clear all the message history? And would it actually clear the nodes that don’t appear in the list but the app thinks exist?
I think I might try and plug it into my computer and read the node list from the Python script, and see if all 41 are listed there. If that’s the case, is there a plan to allow removal of individual nodes from the Python script as well?
However, I was thinking in the case of a configuration export, it could retain the MAC or random number chosen, so that a factory reset and then a config import would preserve that node number again. The default behavior shouldn’t change otherwise.
I wouldn’t know how this could be done properly. You then want it to never send out a packet until it gets a proper node number, because you don’t want it to change. However, it doesn’t know when it can use the MAC address or when you need to wait for a user to configure it (after a factory reset it doesn’t know any nodes yet, so it wouldn’t know if its number is already in use).
If you’re comfortable with building firmware, another option for you is to hardcode a random node number where it currently reads the MAC address.
It don’t believe it will clear the message history, only the nodes themselves. However, indeed the nodes the app think exist might still remain there.
is there a plan to allow removal of individual nodes from the Python script as well?
This was added 20 hours ago, so should be in the next release.
Does it not send out a packet if the region is unset after a factory reset? I assumed that was the default behavior. How does it currently know how to change the node number if it detects a conflict? I don’t think that should change, other than the changes you have in the pull request. The only change would be that the node number becomes part of the export, and then part of the import again. How it arrived at that node number initially would be based on the current logic. The end goal being that factory resets and config restorations wouldn’t potentially result in a new node number. Am I missing something here?
When booting, it checks whether another node in its database has this node number already.
Then you will get it based on the MAC address, which in your case results in a conflict. But you’re right, currently it will also do that after a factory reset and it will only be fixed the first reboot after it found the conflicting node.
The only change would be that the node number becomes part of the export, and then part of the import again.
So then you have to make it configurable, but then anyone can choose what they want and I’m not sure that’s desired only to solve this very specific problem. Maybe you can open a feature request on GitHub to get opinions from others.
I’m sorry but I think the solution for you is to not do a factory reset (which is generally not needed anyway) after it got itself a new random number, or to hard-code a new random number.
Thanks for the consideration. Personally I don’t think it’s a problem exposing advanced configuration options but discouraging it for most people. I don’t plan on doing a factory reset, but it could be necessary if something bad happens. Only making it available under the Python script, for example, would mean that casual users would not encounter it.
But I understand your reasons and I won’t press it further.
Thanks again for your help here, it’s much appreciated!