The following situation: I am developing a system in which Particle Electrons will be used. However, the instance in the cloud is essentially not the Particle Cloud but it is a own MQTT broker. The whole product and device management of Particle is absolutely great, but I really do not need it. On the other hand, the data volume is critical. To achieve savings here, I would like to leave the connection to Particle Cloud completely outside. The only feature that I miss is the OTA flashing.
Now to my question: Is there a way, even without the Particle Cloud, to perform OTA updates. Preferably directly to the public IP address of the Electron. This schould be able to send via MQTT to my broker.
Or maybe someone else has other ideas.
Would be great to receive feedback regarding this.
@rickkas7 Has code that will update the Electron from a program that is stored on an SD card.
He has FTP code also that allows you to upload code from an Electron or Photon to an FTP server but no code to download from an FTP server.
I’m needing reliable code to Download files to SD card via HTTP transfer or FTP also for downloading other product update files but as of now, I can’t find a reliable library out there that allows this. I’m waiting for the day though.
The Electron doesn’t have a persistent public IP address, and it can’t be a TCP server, as explained in this note.
However, it is possible to upgrade firmware, from user firmware. The SD card method that RWB mentioned could easily be adapted to work over TCP, so you could have the Electron make an outbound HTTP connection and download firmware, for example.
The other way is you leave the Electron cloud-disconnected most of the time, but when you want to OTA update them, you tell them via some other channel (like MQTT) to cloud connect. I’ve used that method with Photons and it works well.
No, I tried making a quick modification of some existing HTTP code I had to save to SD card, but it started to get kind of messy, so I decided that an actual generic high performance HTTP client was a better way to do it, but I haven't gotten around to writing it yet.
The method described by @rickkas7 would have been my idea if there are no alternatives:
I solved it that way now. I am now working with SYSTEM_THREAD(ENABLED) and SYSTEM_MODE(SEMI_AUTOMATIC). A permanent connection is therefore only to my MQTT broker. At the startup and also via an MQTT event, the electron connects to the Particle Cloud. Connections are always killed by a timer after 10 minutes.
Previous tests have gone very well with this setup!
Nevertheless, it would be great to have a chance to do OTA Flashes completely without Particle Cloud. Even if a web server or something like that is necessary. Even though the electron does not have a persistent IP, it has to work somehow. It also works with the Particle Cloud...
On doing an OTA without Particle cloud with the SD card update tool:
@rickkas7 are you saying that you would download the files over HTTP to the SD card and then follow this flashing technique?
OR, would you do this without an SD card?
By using the Particle system_update.h, are they verifying the integrity of the files used to update, or is this something you would do with another routine?
You download by HTTP into the OTA flash sector directly using the system update API. When the system reboots, it will verify the CRC32 on the image and if valid, will swap it into the active flash image space. No SD card required, and you don’t even really need to validate it when you download.
If your concern with Particle Cloud is cost, they do have an open source version that you could host yourself, though it’s pretty old and I have no idea how close it is to working with an Electron. Our product is one that we do not believe will be able to command a recurring fee, so Particle’s Cloud pricing beyond 100 devices just won’t work for us. When we near that point, I am hoping we can find a way to make the open source server work for us (with Photons). https://github.com/spark/spark-server
I’d love to hear about your product and use case, we want to provide the best tools, and be the best choice for building connected products, and I’d love to learn about constraints that might make that difficult for you cost wise.
I am also very interested in using this capability. Lots of devices such as my voice router try to download a firmware upgrade at startup via TFTP. If the file is there, then you can upgrade millions of devices whenever they wake up. If there is no file, then startup proceeds as usual. This would be very useful to me since I am working on a family of devices that spend most of their time in deep sleep, and flashing OTA would need to be timed really carefully.
Hi! I can confirm that is possible to OTA flash using TCP client. I’ve made a simple OTA updater (with no security) that reads a firmware from a server and update particle electron. I’ve read @rickkas7example to know hot to manage calls to system update API, as he explains above. The main thing is parse html header to know content size, start API update then update downloaded data changing chunk size as data is received… and finally finish.
Next step will be flash system too.
I will try to make an example, I have to search more time (I did it on a sunny sunday ) …
) …