@justicefreed_amper the challenge isnt in the data collection, rather than mgmt. I would love to handle the data via mqtt, however, where these would sit in the network we would be cut off from the particle cloud. managing the firmware becomes a challenge.
i also have a challenge with EAP-TLS on the Argon, but i think that could be worked through easier than my cloud mgmt issue.
You can technically roll your own firmware update over mqtt. Just a lot of work and testing to make sure itās reliable. If you really donāt need the particle cloud, itās possible other solutions might ultimately make more sense, too
I am working on that type of solution myself. Itās not active right now, but Iāve been testing a combination of MQTT over TLS to AWS IoT and HTTPS for OTA updates. The MQTT-TLS and TlsTcpClient libraries are very memory hungry and donāt play well together, but Iām testing a method for OTA updates that kills the MQTT connection and frees the object, then instantiates TlsTcpClient to update the firmware over HTTPS. Currently not working, but I havenāt been paying much attention to that lately. @fvfrenzy Something similar might work for you. I have a thread here on my progress on OTA updates over HTTPS that may be of interest.
Why HTTPS? that seems like unnecessary overhead. Canāt you just send chunks of the firmware binary over MQTT at your max supported size? Then just save the chunks to an SD card as they come in and then initiate the update using the SD card as the firmware source.
I regularly send data over MQTT in the kB range per message with no issues.
@picsil I agree that would be interesting! Unfortunately I donāt have the skills or time to devote to that system. Right now Iām exploring on-prem device mgmt solutions like balena and upswift, and swapping the particle boards for rpi zeroās.
I use HTTPS rather than MQTT-TLS because I do not have or want local storage that could hold a firmware update, but rather stream it over the HTTPS socket.
Itās not a problem killing the MQTT connection and disposing of the object for my application, since the device will need to reboot anyway after updating. It updates the cloud only twice an hour unless thereās an alarm condition, and timing on those updates isnāt critical.
Iām interested in ditching particle publish in favour of MQTT - I am hoping to cut down on times when the device is offline and not receiving/sending messages due to reestablishing the cloud connection. Can anyone advise how best to do this? Thank you!
In my case, I had to switch away from particle altogether for my use case, due to specific security concerns and the inability to manage in the cloud.
If you are good with managing the device in the particle cloud, then you could pull mqtt libraries from the web IDE and publish your data. I canāt recall the exact library I used for a basic test of this. Iāll try to find it. I want to say the user āBearā(?) has one that could be setup using particle variables to set the broker IP and topic.
The question is, what happens if you have a fleet of photons out there? I thought the private cloud option would require you to physically change the association over and flash your new server keys to the device?
MQTT for status and Particle cloud for OTA would be a great middle ground. Sidestep the frequent Particle cloud issues, but keep Particle for OTA that can be a best effort service and then avoid changing the device association keys.
Is there anything impossible in what Iām suggesting?
@mterrill@daneboomer
I wish I wasnāt such a novice at this stuff and had an answer for ya. In my case, with the security challenges that I have, if I could pass data and mgmt frames via mqtt instead of particle pub/sub, then I could pivot my way through the maze to reach the particle cloud. That would be interesting.
Or if we could encapsulate the particle pub/sub into mqtt packets and they built a connector for us. That might work?
I wish I could go back to the college me and say ālearn to program, learn electronics, learn everything, bc your world is gonna encompass a whole lot more in 15 yearsā