[solved] Pybytes auto reconnect?

[protean]

Recently I left a device on-site with a client, and within an hour of leaving the site, the FiPy was no longer online according to the Pybytes web interface.

My first question is, does wifi automatically reconnect if their AP is unstable, for example? I don't believe it does... Because initially I was using my cell phone as an AP for the device, and if I didn't turn on the AP before booting the FiPy, it would never connect to the AP. The only way to get it to connect would be if the AP was available prior to booting the FiPy.

What could cause the device to go offline after such a short amount of time (less than an hour)? I did not have this problem while testing originally here at my home office, but my AP is more stable than theirs. I had intended to use OTA features of Pybytes to push code changes later, since the device is currently running vanilla Pybytes firwmare.

This same concern will be valid, also, once cellular connections are supported for Pybytes in Q2. Assuming the cell network switches, etc... will the device automatically reconnect to Pybytes?

Either the wifi isn't reconnecting, or Pybytes isn't reconnecting. Either way, what is the best solution here? We will be deploying hundreds of these devices, and hopefully more as time goes on, but if we need to build watchdog threads to reconnect, I need to know.

If Pybytes does not support auto reconnection, and I'm using Pybytes to setup the initial connection via the config json, and not setting up the connection manually, how should I ensure the connection remains up over a long period of time? For development purposes, I can ask someone to power cycle it in the office, but this will not be feasible for our end-users.

[protean]

Perhaps related: https://forum.pycom.io/topic/3416/urgent-pycom-firmware-hardware-freezes-after-some-hours/

Does the Pybytes firwmare seriously not already do this internally for the backend MQTT connections? If I use Pybytes to setup the wifi or cell connection, and to connect to Pybytes MQTT, etc... I shouldn't have to reboot the whole device just to get connectivity again, right?

Seems like this should be a feature built into Pybytes firmware already... and we shouldn't need to reboot the device just to get connectivity, it should simply reconnect to the network and pybytes.

[jirkakrepl]

Hi @protean
I moved your post to Pybytes section.

You're right, there're few problems with wifi connection.
We should fix it in February.

If you boot up a device without online AP, a device will end up Pybytes library program and will do nothing, until it is restarted.
We need to discuss this in the office with @Xykon.

I was testing long term wifi connections myself and I noticed the strange memory usage. Sometimes the device crashed and after the restart wasn't able to reconnect to Pybytes.

We will address and fix these issues and put update notes here: https://forum.pycom.io/category/49/announcements-news

[protean]

@jirkakrepl said in Pybytes auto reconnect?:

If you boot up a device without online AP, a device will end up Pybytes library program and will do nothing, until it is restarted.
We need to discuss this in the office with @Xykon.

Does this mean main.py never executes? If I use WDT and poll a remote network resource on a 5 minute loop, and set a 5 and a half minute timeout, can I expect the device to continually reboot every 5:30 until the wifi is present?

Thanks for your help.

[jirkakrepl]

Hi, @protean yes using watchdog (WDT) https://docs.pycom.io/firmwareapi/pycom/machine/wdt.html should fix these issues.

We will probably create the example code so the pybytes library is more stable when using watchdog

[protean]

@jirkakrepl thanks for the info.

I would like to use wifi while also using the modem, for example, to send AT commands. Is it normal for the device to lose all network connectivity if one simply instantiates the LTE class? I'm not sure what's happening here, but I have wifi setup as primary, then LTE configured as a fallback. It's easy to reproduce: lte = LTE() over the Pybytes REPL and the device will lose connectivity immediately. I thought perhaps only Pybytes was losing connectivity, but the watchdog loses connectivity too, and thankfully the device resets after a few minutes.

I took a peek at the code, and it looks to me like simply instantiating the LTE module sets up a network interface on the stack... which causes the existing network to drop.
https://github.com/pycom/pycom-micropython-sigfox/blob/c7efa88baaf8d5cba1a985e737789590b75f5d2f/esp32/mods/modlte.c#L339

Shouldn't the network interface only be created when attach() is called on the LTE instance? Hmm... It also makes no sense to me that network connections are dropped on mutation of mod_network_nic_list.

I've chased this down into usocket code (socket_select_nic), and it still doesn't make sense to me that appending to mod_network_nic_list would terminate existing socket connections.

[jirkakrepl]

Hi @protean, I am firmware developer. I'll forward your question to @Xykon and @iwahdan

[jirkakrepl]

@protean WiFi connection should now be much more stable in the new firmware 1.18.2.r2. https://forum.pycom.io/topic/4446/update-to-pybytes-firmware-1-18-2-r2-solving-device-wifi-connectivity-issues

Please update your device!