Last seen 447d for nodes received now

[adingbatponder]

What is the cause of spurious ‘last seen’ time indications in the Android app. I have it on two Station G2 devices. First one and then shortly after the other. Both have a node DB reset just before. The number was 47d also at one point.

This was not happening in the last week on either device.
The nodes in the example were new and so should say “now” not 447d.

Reports coming in of this happening on Heltec V3 following flashing new firmwear.
(In my case no new firmwear was flashed before it happened).

Seems to have to do with NodeDB reset.

Partial solution in Android (from Sascha K. DE ) : go to
settings - storage
and clear cache

but the problem returns!

or got to settings - apps - Meshtastic - storage - clear cache

Reports from SK are that using fixed position is enough to cause the problem and switching off fixed position solves it. My tests are not as clear as that.

Following a node DB reset:

and then setting fixed position on all 3 devices

On Android 9 avoids this altogether.

Android 8.1.0 seems not to care about fixed position setting and behaves mainly ok if I clear app data too - but one node is still stuck on 49d so double reset that DB to remove that datum.

Android 12 has this problem repeatedly and switching off fixed position seems to remove the problem, as does having fixed position on but 0.0 in each field thereof, but after many DB resets (following a cache clearing) seems to behave again even when fixed position is used.

Thus DB reset over and over seems to have cured the Android 12 device. Will report here if the error returns.

All these effects are new to my nodes today and they have been running on the above hardware for some time though not sure if 2.4.4 was new auto-updated today 5-9-24

Meshtastic App version 2.4.4

To stop automatic updates in an Android device, which might help eliminate issues with your app behaving differently suddenly:

1. Go to play store
2. Click on your circular user ico top right
3. Settings
4. Network Preferences
5. Auto-update apps…
6. Don’t auto update apps

[GetOutdoors]

“Don’t auto update apps” is the answer. i finally have a network that has been running without problems for almost two years, because none of its nodes or EUDs have any access to the internet, MQTT, or anything else that I don’t control. They get used constantly, but the client devices are never exposed to the internet.

[barryhunter]

It sounds like when you preform the reset, the device looses the time.

So the node info timestamps are way in the past.

When you disable fixed position, you effectively enable DNS. This allows the device to receive a timestamp from position packets (ultimately from GPS) - either a local GPS or a location shared from the connected phone/tablet.

… which allows its internal clock to be corrected quickly.

Suspect the android differences, are just down to how quickly the position can be reported to the node, the android version is a bit of red-herring.

(clearing phone cache, is causing to fetch a fresh nodelist from the actaal device. So it get fresh last-heard data. Without that, even those the device corrected its own clock, the incorrect data is still ‘cached’ in the phone app)

[adingbatponder]

The Station G2 has no GPS and never had this issue since I bought them months ago. I may try

(1) without a node DB reset

(a) enabling position permission on the phone app (which I normally have off), letting the node use the GPS position from the phone, and then

(b) disabling the phone position permission again and switching on the fixed position

to see if the problem goes away immediately in step (a) and comes back at some time after step (b)

and then (2)

with a node DB reset do
(a) then
(b)
to see again.

[adingbatponder]

So far in car Station G2 (which has no GPS itself) a node DB reset suffices to get times correct again for the nodes that pop up again - but in the car is another node with GPS and this node is detected first after a DB reset before other nodes appear in the node list.