Really Small Message Broker under Test

I’m working with the fellow who made MQTT-SPY and I have to say he’s being really helpful and improving the program as we go along.. in a day or so it’ll be just fine…

So, having discovered how to make a SCRIPT which can be automated…. and as it is obvious we’ll be wanting a lot of these running, I thought I’d put it to the test.

Here is MQTT-SPY talking to RSMB which is running as a SERVICE (I described all of this in previous posts – yet another day gone by with NO problems from RSMB acting as a service on my PC).

I’m running the script to send a TIME message  (I would think most likely we’d have it send a message every minute in a typical device – so your little on the wall thermostat control might want to NOT have to have a bloody great time library but instead just keep a simple set of variables for the time – in which case, having it’s time updated every minute would be nice… If the internet connection falls over no problem it would keep ticking.

To test both MQTT-SPY and RSMB, I’ve set the script to update every 5ms.  I can hear you say “ridiculous” – BUT there might be 10 messages going on and a poor little ANDROID phone trying to get real time updates for a slider or something – it really is important this works smoothly and quickly.

Well once I got past the default setting of only storing 5,000 messages in MQTT-SPY and set it to 50,000 messages (that kept me going for a while).. here it is – flat out NO problem… note in the yellow box I’m up to over 25,000 messages in very short order (very bottom picture)

More’s the point – how is this hammering my PC?… a quick trip to task manager.

Broker is using almost nothing.




and MQTT-SPY is using almost nothing.client



Ok that was slightly over the top – but in one of my Android Apps I have 10  buttons on screen with refresh of the indicators every 200ms – that’s an actual call for info every 20ms.  Clearly before committing to this – and using this for months or years on end in, say the house – we need to be sure this is reliable – and I have to say – it LOOKS LIKE IT IS.

Next needed is a modification of the MQTT code for the ESP8266 (which was fixed yesterday and looks good) – to include monitoring a /TIME/ subscription and update an internal real time clock… (first part trivial, second part not too difficult) and also some IO and DHT-22 handling (not DHT11 – they are really crap and the Dallas one wire chips don’t do humidity). 

So a really simple nice gadget which used ONLY an ESP8266 device might be a thermostat… keep the output LOW (remember GPIO-2 really needs to be + referenced as you don’t want to pull it down on power-up) if the temperature is less than X or Y degrees….else high…   and X or Y will depend on 2 times of the day!! Hence the need for the time ( in reality I’d want weekend settings as well and a fallback (cool) option for empty buildings).  The unit should also respond to message requests for /TEMPERATURE/ and /HUMIDITY/ – given that you might have more than one you might want to make that /KITCHEN/TEMPERATURE/ etc…

Well, for now I’m almost out of time for a few days (work getting in the way of pleasure) but it’s great to see that – by the look of it – the BROKER is fine and the TEST CLIENT is almost fine (just needs a fix so that publications (ie scripts) restart if the program itself is restarted) … next thing the above – then Android APP and the whole thing starts to come together – hopefully. Did any of that make sense?




7 thoughts on “Really Small Message Broker under Test

  1. Yes, sounds good to me ….. the basis for an all round system that is low cost, robust, simplistic in nature and flexible. Off to try your broker setup now! Rpi still plodding away…..
    Enjoy your meetings!


  2. You deleted the post while I was writing the reply, probably you already found the answer but here it is anyway:
    The code for DHT22 comes with Eclipse that you installed some days ago.
    There are 2 examples and both works. I tested them!
    Project: dht11_22 and dht22
    If for some reason you don’t have them I can send you.

  3. You are absolutely correct Jaoa – and thanks for (a) looking in and (b) offering solutions. I did find some code – perhaps you might comment if this will do the job – it LOOKS like it will but I’m in meetings right now on London so I can’t get the soldering iron out and give it a shot…
    I’d seen DHT11 code but in my experience they’re not very accurate or repeatable – the DHT22 on the other hand seem fine.

    I don’t want the code to tie up any time – it’s not clear from this code if it will.

    I’ve modified the code to simply output the temperature and humidity to the serial for now but clearly they’ll form an MQTT message going out on request.

    This look ok?

    readDHT(void *arg)
    int counter = 0;
    int laststate = 1;
    int i = 0;
    int j = 0;
    int checksum = 0;
    //int bitidx = 0;
    //int bits[250];

    int data[100];

    data[0] = data[1] = data[2] = data[3] = data[4] = 0;

    GPIO_OUTPUT_SET(2, 1);
    GPIO_OUTPUT_SET(2, 0);
    GPIO_OUTPUT_SET(2, 1);

    // wait for pin to drop?
    while (GPIO_INPUT_GET(2) == 1 && i<100000) {


    // read data!

    for (i = 0; i 3) && (i%2 == 0)) {
    // shove each bit into the storage bytes
    data[j/8] < BREAKTIME)
    data[j/8] |= 1;

    float temp_p, hum_p;
    if (j >= 39) {
    checksum = (data[0] + data[1] + data[2] + data[3]) & 0xFF;
    if (data[4] == checksum) {
    /* yay! checksum is valid */

    hum_p = data[0] * 256 + data[1];
    hum_p /= 10;

    temp_p = (data[2] & 0x7F)* 256 + data[3];
    temp_p /= 10.0;
    if (data[2] & 0x80)
    temp_p *= -1;
    os_printf(“Temp = %d *C, Hum = %d \%\n”, (int)(temp_p*100), (int)(hum_p*100));


  4. Actually I’m looking at this code and thinking…. NOOOOOOO Every time you call the function, there’s a 45ms delay at the start – holding up anything else like polling serial or WIFI etc… surely there’s a better way? I’d hate to come up with communications issue only to find that polling the temperature sensor was causing other items to get lost?

    • Actually it is 250 ms + 20 ms + … , not 45 ms.
      This code is not efficient, it’s all pooling. Don’t expect state machines/interrupts. This is just like the typical code for Arduino.
      For now I think this is more than enough, latter I could try to make a better version.
      Some results with sensor AM2302 (DHT22):
      Temperature: 21.10 *C, Humidity: 52.20 %
      Temperature: 21.10 *C, Humidity: 52.50 %
      Temperature: 21.0 *C, Humidity: 52.20 %
      Temperature: 21.0 *C, Humidity: 52.20 %
      Temperature: 20.89 *C, Humidity: 52.20 %
      Temperature: 20.79 *C, Humidity: 52.20 %

      I have more than 10 MiWi Transceiver Modules to make a home network. After reading your posts I decided to forget MiWi and give a try to ESP with MQTT.
      I’m starting to learn MQTT. Tomorrow I will try to add the MQTT project to Eclipse and start working on this.
      What MQTT client are you using for the ESP? Is the “tuanpmt/esp_mqtt”?

  5. A full and frank conversation (:-)) on this when I’m not in business meegtings. You are most likely right – I underestimated the time – either way it is FAR too long to tie up the processor so we need a better (yet simple) way.

    MQTT – I could be WAY off base here but I think many of use are converging on the idea of MQTT – it just seems to work and allows a full network mesh of little cheap ESP-based radios.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s