Hi everyone,
I’m trying to establish communication to Azure through MQTT, and to handle scheduled publishes. But after a few successful attempts, I get this error on the serial monitor:
[wiring] ERROR: recv error = 104
And from that point onwards, the devices becomes unable to reconnect to MQTT unless a hard reset happens apparently.
The library I’m using is #include <MQTT-TLS.h> , version=0.2.25
I’m on a Boron device OS 5.0.0.
Thank you very much for your comments.
You may want to update to the latest device OS version which may already have fixed some bugs related to that.
Additionally, since your firmware may be the cause it’s impossible for us to tell without seeing it.
Hi Juan and welcome to the community!
I am using the exact same lib version (but on DeviceOS 4.0.2) and it is 100% stable.
Some things to try:
Update deviceOS to latest as suggested above by @ScruffR .
Minimize your firmware, comment out everything so to check that nothing else is impacting MQTT
Downgrade to deviceOS 4.0.2 (though I suspect this is not your issue, but who knows)
Saludos,
Gustavo.
Thank you for your suggestions. I updated the OS to 5.3.1 but I’m still having the same issue, it connects to Azure for a few minutes and does a few publishes, and then disconnects and won’t reconnect back. I’m using client.loop() function every 10 seconds to keep alive MQTT.
This is a view of the serial monitor I’m using for debugging:
I have a routine implemented to detect when we disconnect from Azure, to then retry connecting back by enaling TLS and attempting client.connect(). But after this particular error it won’t connect back.
Before having this ERROR 104, whenever connection was lost by any means, it would successfully reconnect without an issue.
Thank you!
Juan, sorry to derail the thread, but I am curious what is leading you to your decision to use MQTT directly from the edge? Particle doesn't officially support MQTT communication. We recommend using our pub/sub methods (Particle.publish and Particle.subscribe) for edge-to-cloud communication, and webhooks for cloud-to-cloud comms. We have a number of successful customers who pub/sub + webhooks to communicate with Azure.
There are some distinct benefits of using the provided primitives to that I am happy to share if you are interested.
hi @Dan-Kouba
I'm a colleague of @JuanGonzalez working together on this project.
we are using MQTT directly from the edge to avoid sending data through the Particle cloud. we send sensitive, confidential 3rd party data, so we want to have a connection as direct as possible. to our final cloud service.
we have been testing MQTT communication on the Boron for over a year, and this has always been the weak link, a non-consistent connection. the connection can last from a few minutes to a day or two, then it can't connect anymore. We have tried connecting and disconnecting on every MQTT publish (currently we send data every few minutes) or keeping the connection active with a .loop() every few seconds, but nothing seems to work to a reliable steady connection. We are using Borons because some of our locations don't have wifi access available.
Thanks!
-R
Hey @romuloescamilla, appreciate the context.
The description of your use case is quite common across our customer base, and we have a number of security features in our edge-to-cloud communication layer to support them.
At a high level, our pub/sub architecture is E2E encrypted by default and messages are all ephemeral as they pass through the platform — our system is just like a pipe that your device puts data in at one end, and we ferry it to whatever cloud endpoint you set up. This is all handed under-the-hood by DeviceOS and our cloud and doesn't require any security layer in userspace, which is in contrast to the MQTT library you are using which implements encryption in your app.
If you're interested in more details, I am happy to pass along a whitepaper on security that goes through how our system works. Send me your email in a DM and I can send it over.
thanks! I'll DM so you can send me the info.
Another special concern is the data usage. We focus on using Borons with the cellular signal, and it has not been clear how much data and how many payloads we can send per month, but we have run out of the free-tier allowed ones several times with just a few devices connected. When we were contacted by the sales guys from Particle IO, we didn't get the information we were requesting from them.
do you have any other suggestions on how to use the MQTT-TLS library and the loop function for the topic presented by JuanGonzalez?
thanks,
-R
I'll keep an eye out for your message — thanks. Also, I reached out to our sales team to see if we can help get you answers to the questions you had for them.
Sorry you've run over the free tier on the platform. Can you help me understand the frequency of your messaging and what your payloads look like? Our Data Operation system does require a bit of work to optimize your usage, and I am happy to provide some suggestions if you can help me understand your use case more.
Unfortunately, I cannot provide any support for your MQTT library as it is not officially recommended by Particle.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.