Native MQTT client library for ESP8266

Chat freely about anything...
 Reply

User avatar

Re: Native MQTT client library for ESP8266

By scargill
- Sat Jan 10, 2015 12:27 pm #6917 Not too bothered about efficiency having tested over 1000 packages a second. Not familiar with or how to use the function you mention - and I HATE using callbacks.


Do this
wait until done
Do next

Might be wasteful but it's a LOT easier than setting up a callback and passing stuff to it - especially as there are not many examples around to follow right now and we don't exactly have a manual. I think I'd like the OPTION to have buffering or for it to return when done...

Pete.


gicho wrote:I also saw that buffering doesn't work but maybe it shouldn't ... you have "void mqttPublishedCb(uint32_t *args)" to know when first publishing is ready so you can proceed (e.g. to the next value from this sensor or to the next sensor that needs to be served). This is the concept of "event", asynchronous programming. This way there is no need of huge buffers.

My point is that sending small chunks of separate topics is not the most efficient way to work on the embedded device.
What I've used on other IoT boards (but not yet on the ESP8266) is to put either JSON or type-lenght-value encoded blocks in one report. This fits in your scenario where you get both readings (temp and humidity) at the same time. It is also logical if you have and "object" (DHT11 sensor) with more than one properties. This will save you (and the broker, and the network) the overhead of multiple messages and processings. Also, no need to worry if both readings are from the same time.
JSON parser is available in the SDK, sometimes it is heavy on RAM (heap) but no matter it is probably a good alternative to the additional buffers.

I believe that most nodes in fact follow a simple sequence - startup/wakeup, read from sensor(s), optionally check if there is a change in the value since last reading, that send the data, Than maybe check for retained command message (subscribe) to execute something - e.g. change wakeup rate from 10s to 180s, or enter continuous mode (e.g. for configuration).
User avatar

Re: Native MQTT client library for ESP8266

By scargill
- Sat Jan 10, 2015 12:33 pm #6918 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..

gicho wrote:I also saw that buffering doesn't work but maybe it shouldn't ... you have "void mqttPublishedCb(uint32_t *args)" to know when first publishing is ready so you can proceed (e.g. to the next value from this sensor or to the next sensor that needs to be served). This is the concept of "event", asynchronous programming. This way there is no need of huge buffers.

My point is that sending small chunks of separate topics is not the most efficient way to work on the embedded device.
What I've used on other IoT boards (but not yet on the ESP8266) is to put either JSON or type-lenght-value encoded blocks in one report. This fits in your scenario where you get both readings (temp and humidity) at the same time. It is also logical if you have and "object" (DHT11 sensor) with more than one properties. This will save you (and the broker, and the network) the overhead of multiple messages and processings. Also, no need to worry if both readings are from the same time.
JSON parser is available in the SDK, sometimes it is heavy on RAM (heap) but no matter it is probably a good alternative to the additional buffers.

I believe that most nodes in fact follow a simple sequence - startup/wakeup, read from sensor(s), optionally check if there is a change in the value since last reading, that send the data, Than maybe check for retained command message (subscribe) to execute something - e.g. change wakeup rate from 10s to 180s, or enter continuous mode (e.g. for configuration).
 Reply
Return to General Discussions