Hi,
I am using an MQTT connection to communicate with my Cloud. Everything works pretty well I would say, except for the messages coming from the Cloud to my ESP. After I connect successfully to the Cloud with MQTT, I do a MQTTSubscribe (where I pass my message handler for incoming messages from the Cloud) that is successful. And then I do MQTTPublish when I need t post something to the Cloud. The problem is that ESP seems to be processing coming from the Cloud in my message handler only when I do a publish. Which is quite annoying cause I don't publish all the time and this can delay a lot the processing of my message from the Cloud. Any idea why my code could be acting that way? I am using the latest ESP_RTOS_SDK, and following their MQTTEcho example, and I checked on the Cloud side and I am certain the message leaves the Cloud right away when it needs to be sent.
So the problem is definitely on the ESP side...
Thanks for your help!
Only receiving messages from MQTTSubscribe when next MQTTPublish is happening
Only receiving messages from MQTTSubscribe when next MQTTPublish is happening
Postby fmuller-pi » Thu Apr 11, 2019 9:07 am
Re: Only receiving messages from MQTTSubscribe when next MQTTPublish is happening
Postby fmuller-pi » Thu Apr 18, 2019 2:17 am
Anyone having a suggestion on this?
I looked in there SDK, and to me, when looking at the function cycle() in the MQTTCLient.c file, it feels like there are only processing delivered MQTT messages when the switch case PUBLISH happens... Which would validate the behaviour I am observing here. Am I right? Or am I missing something?
Thanks,
I looked in there SDK, and to me, when looking at the function cycle() in the MQTTCLient.c file, it feels like there are only processing delivered MQTT messages when the switch case PUBLISH happens... Which would validate the behaviour I am observing here. Am I right? Or am I missing something?
Thanks,
Re: Only receiving messages from MQTTSubscribe when next MQTTPublish is happening
Postby fmuller-pi » Sat Jul 27, 2019 12:52 am
It has been many months but since no one never answered, I'm going to explain what was the problem and give my solution to it.
NOTE: This is using the ESP8266_RTOS_SDK v3.1
Basically, the problem laid in the fact that I was open my MQTT bridge with an SSL connection. The example from Espressif works just fine when the connection is NOT an SSL one, but with the SSL, a bunch of bugs starts appearing.
So to make it short, because CONFIG_MQTT_RECV_CYCLE == 0 by default, you start hitting timer expired conditions everywhere when reading with the SSL read function incoming messages (even tho the messages are coming in properly). Then, increasing the CONFIG_MQTT_RECV_CYCLE, other delayed issues start to appear because MQTTRun isn't yielding by default to other tasks...
Anyway, in my case, I decided to use MQTTYield instead of starting the MQTTRun task. It gave me more flexibility on how I wanted to set my MQTT flush of incoming messages an all.
Espressif won't fix this since they are working on a new release that isn't using the MQTT Paho library anymore. But in my case, upgrading the SDK at that point in the release of our product wasn't an option, so I had to deal with what I have been done in the SDK v3.1...
Hope that can help others that might have encountered that type of issue.
Cheers
NOTE: This is using the ESP8266_RTOS_SDK v3.1
Basically, the problem laid in the fact that I was open my MQTT bridge with an SSL connection. The example from Espressif works just fine when the connection is NOT an SSL one, but with the SSL, a bunch of bugs starts appearing.
So to make it short, because CONFIG_MQTT_RECV_CYCLE == 0 by default, you start hitting timer expired conditions everywhere when reading with the SSL read function incoming messages (even tho the messages are coming in properly). Then, increasing the CONFIG_MQTT_RECV_CYCLE, other delayed issues start to appear because MQTTRun isn't yielding by default to other tasks...
Anyway, in my case, I decided to use MQTTYield instead of starting the MQTTRun task. It gave me more flexibility on how I wanted to set my MQTT flush of incoming messages an all.
Espressif won't fix this since they are working on a new release that isn't using the MQTT Paho library anymore. But in my case, upgrading the SDK at that point in the release of our product wasn't an option, so I had to deal with what I have been done in the SDK v3.1...
Hope that can help others that might have encountered that type of issue.
Cheers
Who is online
Users browsing this forum: No registered users and 269 guests
Login
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
Latest SDK
Documentation
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!
- All times are UTC+08:00
- Top
- Delete all board cookies
About Us
Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.