sellonoid wrote:That's very helpful to know. I had that all wrong.
One more question and then I will check into MQTT and everything else you mentioned, and get more familiar with the log.
Does this (small sample) part of the log file actually indicate that it transferred the blink program via WiFi / OTA, even though the operation was a USB flash operation?
Code: Select all
I (4079) ota: Have written image length 1785
I (4079) ota: Have written image length 2321
I (4089) ota: Have written image length 2857
I (4099) ota: Have written image length 3393
I (4109) ota: Have written image length 3929
I (4109) ota: Have written image length 4465
I (4119) ota: Have written image length 5001
I (4119) ota: Have written image length 5537
I (4129) ota: Have written image length 6073
Like I said before, once you successfully burn an OTA partition, as your previous boot log indicated has happened, then USB "make flash" operations don't do anything other than burn to a non-bootable partition. The log text you presented here is an OTA update burning to an OTA partition. i.e. it's an OTA update in progress. It is not indicative of a USB burn. In fact, all the USB burns that you have been doing aren't really accomplishing anything useful once the device is booting from an OTA partition.
Also, I wasn't suggesting that you use MQTT to start an update. I was just listing examples of ways that it could be initiated. You could FTP to an online server and just check to see if a newer bin file is there and start an update.
John A