Innaccurate system info

[jkrafft]

It's now the second time I encounter the problem, not a big issue, but still puzzling.
The pistomp is connected to my home wifi and I'm connected to it with my laptop also connected to my home wifi.
When going into system info, it says hotspot is on with ip address 172.24.1.1

When connected via ssh command "ip address" show ip address 192.168.0.49 (connected to my home wifi).
I didn't activate the hotspot and it's not active.
However if rebooted, it will be activated.
Then if I disable the hotspot, the hotspot will be disabled, the pistomp will be connected to my wifi but system info will show hotspot deactivated but ip address is still 172.24.1.1 even though it's 192.168.0.49 as seen in ssh.

I'd file an issue on github but I'd rather do it right giving also logs (which one), screenshots or whatever's needed to sort this out.

thx

[Randall (Admin)]

If your last networking mode was WiFi, then upon boot, it should try to connect to your router.  If it cannot (spotty reception, etc.), then it automatically goes into Hotspot mode, presenting it's own hotspot for you to connect to.  Perhaps that's what you're seeing? 

Regarding it showing the wrong IP, I believe that's an asynchronous issue.  The IP is fetched when the pi-Stomp service starts, and sometimes that might be before the network connection is fully established.  In that case, the IP shown is stale.  We could change the software so that the IP fetch is executed when the info page is navigated to.  But it's a fairly slow operation (takes maybe 2 or 3 seconds), so it would likely need to be blank for a bit, then filled in.  Another option might be to schedule a fetch maybe 15 seconds or so after the pi-stomp service starts to give the networking time to settle.

[jkrafft]

Being litteraly less than 2 meters from the wifi router rules out spotty reception. I'll make some checks just to be sure the pistomp doesn't have diffuculties connecting to that particular router.

Scheduling a fetch 10-15 seconds after the pi-stomp service start might be the easiest and fastest fix on that issue, given that it's not critical at that point.