Can MQTT be used to handle data and management instead of Particle.Publish?

@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.

1 Like

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.

1 Like

@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.

1 Like

Yeah reading between the lines on your goals you will probably have more success that way.

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.

Just saw you were not replying to me, but @fvfrenzy. :slight_smile:

1 Like

@picsil good information anyways!

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!

1 Like

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.

Iā€™m also interested.

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ā€

Hah! donā€™t worry, another few years and youā€™ll have picked up more tricks!

I think the ideal solution is:

  • Maintaining the particle cloud link but just use it for OTA and some backup administration functions if MQTT isnā€™t working.
  • Adding MQTT to the mix for bi-directional messaging. Commands inbound, Status outbound. Then you rule your own destiny in terms of reliability.

I did mention years ago itā€™d be nice if Particle cloud had pub/sub connectors. The rest of the IOT world has well and truly moved to MQTT.

3 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.