ESP8266 Community Forum

- Sun Jan 11, 2015 4:11 am #6968

You right Peter,
If you wait and poll for published event, it will block os threads.
I will add publish buffer and publish queue soon

Tuan PM

If publish event take a long time esp can't receive any message from topic.
I think freertos best choice for mqtt. Multitasking could be better for publish or receive event.

ESP8266.com Moderator
Lets get the party started and +1

[url=https://www.banggood.com/custlink/KvGGhGF4wG[/url]

I like ESP8266 and ESP8285 and ESP32

- Sun Jan 11, 2015 8:18 am #6985 I was looking for a MQTT library like this! Thanks Tuanpm!
I have been able to publish single topics from ESP8266 to a local RPI mosquito server on port 1883 (no SSL) and to read with mosquitto_sub. Great!
However when trying to use public test servers like test.mosquitto.org and broker.mqttdashboard.com, I have not been able yet to read out published data.
Has anyone been able to use any of these or other public servers?

Best regards

- Sun Jan 11, 2015 11:34 am #6998

Thinking about it - mqttPublishedCb is no good - so that happens when something is published - and... you publish something else and... it disappears forever. I COULD set a flag in mqttPublishedCb and poll for that - but I'm worried that polling would stop other things from happening. I remember back in the dark ages of Visual Basic we had DOEVENTS which would ensure other stuff was handled while you were stuck in a loop - I've no idea if a similar function exists in the SDK or not..

Where is the problem? Of course when you call publish you will start a timer to notify in case of timeout. So you either get the sent callback (and kill the timer) or you get "not sent timeout" callback and you take proper measures - retry, reconnect, print error or whatever. This works no matter if you publish from a timer or from callback.
Do you say that publishing from the context of the mq callback is not working?

Probably this timeout could be embedded in the MQTT core and all this could be managed by the MQTT source. It already has one ticking timer so making "publishing" timeout is easy.
What do you think about this, Tuan PM? A new argument to the publish API to get a timeout value, and maybe additional argument to the callback so the user knows if this is success or timeout (or any other kind of error, e.g. not connected?).

Edit: buffering is not a solution. How deep buffers will you add? Probably user configurable, fine, but no matter how you make it, the "main" application might get buffer overflow - simply because it doesn't care about the actual processing in the "other" task (the mqtt task).
In other words, it is not possible that the main task runs in 1s periods and makes several publish actions without taking care about the environment - it could be that perfectly running system is deployed in remote area and two weeks later it breaks - because the speed of the internet connection slowed down. Imagine the other case, with callbacks and timeouts - the system will slow down the publishing rate according to the speed to the broker.
Also, imagine the case where you want to go into sleep mode after each measurement and publishing. If you don't use the callback, how will you know that the IP stack has sent the publish? When will you call the sleep function?

- Sun Jan 11, 2015 12:41 pm #7003

In any real world stand alone application we need to know the time - now, subscribing to the time is no problem but right now we can't run a clock.. again - in my christmas wish list, if the board could subscribe a standard "seconds since 1970" timestamp - and anyone can do that, but then store that value somewhere and have the processor handle the 1 second tick. A simple callback routine in user_main would call every second - passing the timestamp to the user code - that would just be SO good.

Hi Peter, I've seen you raise this issue a few times, and I confess I can't see why it would be that useful for the ESP8266s in a system to 'know' and keep track of real time. At least at this initial stage, where the ESP8266s are best used as smart 'endpoints' in a MQTT network. As I see it, the scheduling comes from a central controlling app, and the endpoints are simply required to provide sensor readings to the central controller at a predetermined interval or on command, and to control loads upon command. I believe the ESP8266 has a basic clock system for accurate intervals of up to a few hours, more than adequate for simple timing tasks.

The MQTT protocol has keep-alive pings and this library has implemented them, currently at intervals of 2 minutes. If real time to the ESP8266 endpoints is critical, I suppose you could rewrite that so that every ping from the ESP8266 is instead a request for time. Or the central system simply keeps farting out timestamps and anything that needs to know the real time can subscribe to it.