Pybytes Upgrade Firmware process

[dnear1]

What exactly happens when you click the button to Update firmware from the Pybytes platform? How does that differ from the process that happens when I click "Save and upload"?

My Pycom devices are "always connected" to Wifi. but for some reason, they frequently show offline. Each device does a sensor reading (a process that takes maybe 30-45 seconds) and pushes that out, then does time.sleep(300). Do I need to do something different during sleep to stay online and ready to accept an update?

Is there some time interval between clicking update or save and upload in which the message is queued for a device, or does the website just immediately fire off a packet and not care whether it's received or not? Sometimes I have to click the button multiple times to get it to happen.. or at least it seems that way.

I've got close to 30 devices now and was hoping to double that or more next year. It would be great if the process was more seamless and reliable.

[dnear1]

@dnear1 Of course, a watched pot never boils... and seemingly, setting pybytes to a higher debug level seems to make firmware updates succeed..

Packet sent. (Length: 49)
Packet sent. (Length: 49)
Packet sent. (Length: 49)
Packet sent. (Length: 49)
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)
This is PybytesProtocol.__process_recv_message()
This is PybytesLibrary.unpack_message(message=b'\x06\x03')
receiving FCOTA request
Sending FCOTA ping back:
__pack_message: b'0670'
MQTT Protocol
Packet sent. (Length: 49)

[dnear1]

@troy-salt I just ran across that post. My code is only about 52k, is that large? Strictly Python code

[troy salt]

@dnear1 I've experienced a similar REPL command line issue with the Pymakr before. Here is a post I made on it a while back https://forum.pycom.io/topic/6495/pybytes-pymakr-terminal-no-longer-working/2?_=1608763008148

If you have your Pycom plugged into ATOM so that you can see the readout of what's going on, and you try to open up pymakr tab and send a command, do you get an error like I did? If so, it could be your filesystem is too large and you may need to cut down (an issue I've been complaining about all over the forum for a while now).

As for latest firmware, have you tried using the update firmware in the configuration tab of the device yet? Thats the only way it works for me.

Best,
The salty one

[dnear1]

Yes, I'm pushing 13 different data points using Send_Signal every ~5 minutes.

I tried changing time.sleep(300) to

c=0
while (c<10):
  c=c+1
  pybytes.send_ping_message()
  time.sleep(30)

But that didn't fix my issue. It shows more frequent "last connection" updates, but won't take the latest firmware and since some point between 1.18 and 1.20, the REPL commandline when using the Pymakr tab in the browser won't accept or respond to any commands.

[troy salt]

Updating the firmware means you are updating the base firmware like operating system of the Pycom. That is code the Pycom develops. The upload code feature is for you to upload the sketch that you wrote.

To be honest, the recent firmware (1.20.2.r2) is pretty riddled with bugs, so I wouldn't update right now anyways. I've found that if your system is working as you'd like, a firmware update has more of a shot at messing things up than improving performance. When I updated to 1.20.2.r2 recently, it made all my sensors crash critically, and I had to go out to the field and downgrade all of them manually to get them back and running. It was quite a mess considering I have sensors all over the world. I see they just released 1.20.2.r3, maybe they fixed some bugs?

I've had difficulty using the update firmware feature from the checkbox though. Actually I've had no luck with it at all. When I want to update firmware OTA, I have found that it only works if you go to the configuration tab of the device within pybytes, go to OTA firmware update, and apply the update from there.

If youre pinging the server every 30 seconds it should stay connected. Is your sensor pushing data to pybytes every measurement? If not, you can use the send_ping command to stay in contact. I've found that if I don't make frequent enough communication, the device becomes unreachable from pybytes.

As for the time of upload, I think it just fires off immediately, however it can take a few minutes. Just give it time. d