ESP8266 LUA and MQTT

After a few days break wherein work got in the way of interests (not a good thing) I got up early this morning, determined to do some work on my ESP-01 boards while I have a clear weekend ahead of me. I checked for updates for MQTT and there are none – which is fine – that indicates that nothing has gone wrong this week.

On a whim I decided to go check the LUA site. I already new that the latest MQTT had been imported from conversations with Minh  who’s been doing the MQTT work but I was delighted to see signs that also some more work had been done on integration with Eclipse.

Every single time I’ve tried to install the nodemcu LUA code into Eclipse there has been a problem – something not found, some path missing, some issue taking hours to resolve.

Yet this morning I downloaded the latest ZIP file (updated yesterday) and imported it into Eclipse. CLEAN – COMPILE – FLASH…  not a hiccup – it worked perfectly. Not only that but when I tried powering Lua up – it came up straight away without any hint of an issue. This is new for me as I’ve always had some trouble or other. Magic.

Though it is possible to debug Lua code using the simple terminal you can install into the Eclipse environment, I did develop my own serial terminal  and then subsequently discovered ESPLorer.

I powered up ESPlorer and checked the available RAM on my newly installed Lua installation on an ESP-01 (I’m still waiting for my new white board to turn up from China with all the pins available – meanwhile I have ESP-01, ESP-03 and ESP-12 boards to play with).

A quick node.heap() call showed that we’re starting off with 22,144 bytes of working RAM which is a good improvement on the earlier versions especially as MQTT is now incorporated.

First things first, I told the unit about my router and then my MQTT broker which regular readers will know is sitting on a Synology DiskStation and has been sitting there working flawlessly for weeks now despite my attempts to bombard it to death with messages.

I noted when using wifi.sta.getip() that the unit remembered my router from previous experiments (I wish someone would produce a nice graphical memory map to show where these various elements are stored and how to tinker with them). So that was easy.

I followed this example – obviously filling in the bits that apply to my installation..

— init mqtt client with keepalive timer 120sec
m = mqtt.Client("clientid", 120, "user", "password")

— setup Last Will and Testament (optional)
— Broker will publish a message with qos = 0, retain = 0, data = "offline"
— to topic "/lwt" if client don’t send keepalive packet
m:lwt("/lwt", "offline", 0, 0)

m:on("connect", function(con) print ("connected") end)
m:on("offline", function(con) print ("offline") end)

— on publish message receive event
m:on("message", function(conn, topic, data)
  print(topic .. ":" )
  if data ~= nil then

— for secure: m:connect("", 1880, 1)
m:connect("", 1880, 0, function(conn) print("connected") end)

— subscribe topic with qos = 0
m:subscribe("/topic",0, function(conn) print("subscribe success") end)

— publish a message with data = hello, QoS = 0, retain = 0
m:publish("/topic","hello",0,0, function(conn) print("sent") end)

— you can call m:connect again

(again ignore the IP address and port – I filled in my own) – I ran this and… connected no problem. All seemed well.   I had subscribed to “test” rather than “/topic” and had commented out the publish for now.

I tried publishing “test” to see what would happen – nothing. But then I guessed as the last line was “m:close()” I figured it reasonable that the ESP-01 would not be listening and so called the connect line again – after all – there is a comment in there “you can call m:connect again”.

The result (passwords have been changed to protect the innocent):

> m = mqtt.Client("peteluatestid", 120, "xxxxxx", "yyyyyyy")

NodeMCU 0.9.5 build 20150123  powered by Lua 5.1.4
lua: cannot open init.lua

Yes that’s a crash. Oh dear, this is not the first time I’ve seen Lua just die. I can handle error messages but this tendency to just simply reboot…

Meanwhile, my experiments with programming in C, using MQTT directly have, thanks to Minh Tuan’s constant vigilance in fixing things, produced rock-solid results. Indeed I’ve been away since last weekend and I turned off a perfectly working MQTT temperature sensor in order to give Lua another go. I thought the one-wire library in Lua might make the transition to a Dallas DS18B20 a little easier but I’m not going to start another round of failed experiments while Lua so easily crashes.

Incidentally, I had several attempts with this Lua installation – rebooting several times along the way. When I finally managed to get the whole thing to work and in commenting out the CLOSE – as you need the connection open to receive anything, I noted my wonderful 22k of RAM had dropped down to 17.2K.  I really do wish they’d put a little more RAM on that chip.

Having checked that the compilation had included all the modules (app/include/user_config.h) which as far as I can tell the default combination SHOULD do… I thought I’d try the DS18B20 module – the idea being to send an MQTT request – and get an MQTT message back with the temperature in it.

I thought I would avoid experiment and merely check the temperature first.  I duly attached a working SD18B20 unit and pull up resistor to GPIO2 (that’s input 4 according to the table).

The code looked simple enough..

t = nil
ds18b20 = nil

But no..

> t=require("ds18b20")
stdin:1: module ‘ds18b20’ not found:
    no field package.preload[‘ds18b20’]
    no file ‘ds18b20.lua’
    no file ‘’

Oh dear….

Thoughts? Am I missing the point here?

ESP8266 MQTT Publications

The PlanIn my last blog I referred to publishing temperature etc and there is one issue with the existing MQTT library that makes that an issue: The MQTT publications are not queued.

For the benefit of anyone still not into the MQTT thing – by publications I mean “sending a message” comprising a topic and a message. The topic might be “BathroomTemperatureReading” and the message might be “20.6”.

What happens right now – and Tuan has said he’ll fix this… if you send 2 messages out in a row IMMEDIATELY after each other – only the last one will go. Well, that’s fine unless you have to send one message off to a thermometer display and another message off to a humidity display.

So… this evening I wrote a queue. This is possible because of a “callback routine”. When you fire a message off it is handled in the background and when it’s done it calls an empty routine. I’ve trapped that.. the basic idea is this.  

Clear a “done” flag at the start and from there on..

If the done flag is clear, set it and send out a publication. If it is NOT clear, put the message in a queue.

In the callback routine, clear the flag – check a queue, if there is anything to go – send out the publication.

Simple really.

So here’s the code I’ve added to the start of the MQTT package..

#define QUEMAX 10  // 10 messages -  need more? – increase
#define QUESIZE 50 // my topics and messages are never more than 50 chars
struct Queues{
    MQTT_Client* cli;
    char top[QUESIZE];
    char mes[QUESIZE];

struct Queues myQueue[QUEMAX];

int queuein=0;
int queueout=0;
int isPublished=0; // my flag to see if I can publish or need to put in a queue

All simple enough – the queue can be maximum 10 deep (it’s rotary – when I get to the end I roll around to the start). I save the client pointer, the topic text and the message text in an array of simple structs.

At the beginning both the in pointer and out pointers for the queue are cleared and isPublished is clear.

Instead of the main publish routine – I have my own – which checks the flag before sending off a message.

void petesPub(MQTT_Client* cli, char *top, char *mes)
if (isPublished==0)    { isPublished=1; MQTT_Publish(cli, top,mes,strlen(mes), 0, 0); }
    if (++queuein>=QUEMAX) queuein=0;

You can see the message going in the queue unless the flag is clear… and in the callback routine, called when a message has gone…

void mqttPublishedCb(uint32_t *args)
    MQTT_Client* client = (MQTT_Client*)args;
    INFO("MQTT: Published\r\n");
    if (queuein!=queueout)
        if (++queueout>=QUEMAX) queueout=0;

The first two lines were there already – I don’t think I actually need to store the client info – I think it gets passed – however – what I have works for now.

So you can see I clear the published flag, look to see if there is anything in the queue and if there is – publish it. I’m sure there’s a bit of recursion going on there – but it all works.

And that’s me done for the day. Meetings again this week so I’ll not get much more done now until the weekend but DHT22, RTC and message queue – not a bad start for the week.

I’m still begging anyone with assembly skills to look at the WS2812B code to see if they can make an accurate job of it Smile

Eclipse and Node_MCU on Windows

Does anyone know what I’m doing wrong here… I have the full Eclipse set up on my Windows PC and have already imported the MQTT project and tested it – lovely. Like other projects you end up with CLEAN, ALL and FLASH controls to wipe old firmware binaries, compile new code and FLASH the ESP8266 modules – all very civilised and easy to use.    I did exactly the same installation with the node_mcu (ie LUA) software – and… nothing – no apparent way to do any of this within the Eclipse environment. Did I do something really stupid here? Hopefully, getting a solution in here will help others as well. Everything was installed from scratch on my laptop this morning so there is no old code here. It is all the latest downloads – and until Lua all went splendidly smoothly following instructions I’ve referred to in earlier blogs.

Examples – AT code – works fine.

AT Code

Example – MQTT project imported – works fine


See MQTT above – straightforward installation – the 3 buttons ALL, CLEAN and FLASH appear just like the other projects… but in the case of NODE_MCU….


Oh dear.- no buttons!

Also – if someone knows how to rectify this.. they might also be able to answer another question. Somewhere in the above project – I guess in the INCLUDE folder – is the 0.9.5 SDK.  In the other examples in ECLIPSE the best we have is the 0.9.4 SDK.  So, for example, what would one need to copy across, into a copy of the AT example from the nodemcu-firmware example, to be then able to compile the AT example with 0.9.5 SDK?

Any easy tips/answers in there I suspect will help a lot of people as well as myself. I could find all of this out with a lot of wasted time and experimenting, I’m hoping someone has done all of this.

ESP8266 Tuesday Update

esp-03[7]I noted this item on EBAY showing the ESP-03 at well under £2 each.. Not sure about those ceramic antenna – anyone any experience of how they compare to the excellent PCB version on the ESP-01 ??

Another item of note – I see there is a new LUA update out – looking forward to checking that out at the weekend and I’ll do a write up – apparently it’s based on the 0.9.5 version of the SDK. Is this out of BETA – and if it is does anyone have the link? And any updated documentation so we know what’s changed? I have to say that Espressif don’t do the best job when it comes to promoting their own updates.

That’s it for now – later this week I plan to put together a temperature sensor using only the ESP-01 and even consider sticking a lithium and a solar cell on it (I know, not the best time of the year for solar power) – more to have a permanent test rig than anything else sending out MQTT data.  The /TIME/ message I set to run every 10 seconds on my PC 3 days ago using Really Small Message Broker set up as a service, and MQTT-spy – is still ticking away (I can test it in meetings using another copy of MQTT-spy.   You might have noticed I did some frighteningly fast message blasting and everything help up ok. I expect soon to have MQTT traffic running back and forth – I’ve at least 3 locations that need external solar powered temperature and humidity monitoring.   MQTT-spy is due shortly to get some more improvements – looking forward to it – as for RSMB – I can’t think of anything wrong with it!

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?



Feeling MQTT Thick

Oh firstly, after filling in the form with Espressif to keep commercial confidentiality about their SDK info which I’m still waiting for – I discover it’s freely available here –  granted that IS for the 0.9.2 version which is a tad old now..

Tonight as I get ready for a round of meetings in London which will severely hamper my research until later this week, I’m struggling with MQTT-SPY. I should say I’ve had some communication with the designer and he’s been MORE than helpful  – he’s added a demo time script, he’s changed the XML format slightly so it’s readable for the likes of Notepad++ all of which is great, but I want some pre-programmed scripts to send out publications – and can I HELL figure out how to use them.  I’m hoping for an update to the WIKI on that otherwise excellent free program. If nothing else I hope to set off a script every minute to transmit the time on “/time” and I can keep an eye on it while I’m away on business to check for reliability.

I didn’t get a chance today to update the ESP-12, now that the MQTT code works so well in the Windows environment, to add port operations to that as I thought I might use a couple of pins of the board as indicators instead of all that serial info. All I want coming out of the serial is MQTT messages.

My unashamedly Windows-only ESP8266 Facebook page  is doing well and how has over 170 followers which is nice.

Not much else is new. Quite interesting that people made so much noise about the Lua interpreter code going open source – the guys did that and what’s happening? Not  a lot right now.. the Frankenstein code? Nothing for a month….   the beta of the SDK? Nothing new.  Maybe everyone’s having the week off after Christmas.

Here’s hoping for lots of new developments over the weekend. Something I don’t really understand about the Lua code – it’s constantly short of RAM – and yet, those who are trying to understand the chip say that it has a LOT more DRAM than it has RAM… so I wonder if any of that is being used.. perhaps that will remain one of life’s mysteries.

And on a completely unrelated subject – if you’ve been struggling with your old Nexus 7 (2012) – the 5.01 Android update is out -  installed it today (with a lot of wheel-re-inventing) – and.. yes, I think it speeds it up again.

Brief ESP12 MQTT Update

After a little conversation back and forth, the MQTT code now works and the Really Small Message Broker is running just fine as a service, no surprises with the ESP-12 and tomorrow if time permits I’ll import some port control into the package and use a couple of those handy port bits to give out status information.  Tackling input into the serial port is another matter – no idea how to do that yet but how card can it be.

It really would help if Espressif would release the SDK technical docs as I asked. You’d think they didn’t want to sell any chips!

Really Small Message Broker as a Service

Earlier today I mentioned that I was playing with the IBM Really Small Message Broker (RSMB) and that’s working fine but then it occurred to me that having it on the desktop is not the smartest thing to do. Really it needs to be a service – however as that isn’t one of it’s options, I went off in search of ways to “make it so”.

This article describes how to make any program into a service and here is the binary to do just that.  So basically I took their program wins-1.16-bin.exe and renamed it to mymqtt.exe as they suggested we give them meaningful names. I put it in the same directory as my RSMB. It needs an XML file (simple text file) of the same name to tell it what the name of the service will be – and where the executable will be. Here’s what I put in.

  <name>Really Simple Message Broker</name>
  <description>Really Simple Message Broker</description>

I then ran the following…

mymqqt.exe install

mymqtt.exe start

And LO – a service.




Ok, stop and uninstall don’t seem to work but I don’t really need that anyway – I CAN say for sure that the program starts up automatically on on power cycle without any visual interface  –   I suspect the stop argument is rubbish…

ESP8266–a Way Forward

Right, it’s becoming pretty clear how this is going to develop for some of us… I’m not interested in joining someone else’s circus when it comes to home control – I want to do my own thing… but I want inexpensive mechanisms to help me do that and it’s becoming clear that MQTT as a communications mechanism is going to be part of that. It’s also clear that the ESP8266-type boards are also part of that.

So here’s where I think we are right now – but firstly I need to explain MQTT for absolute beginners before they run away:

I’ve been messing with home control over 2 years now, I wasted a year of my life on those AWFUL NRF24L01 boards which can’t even manage a single stone cottage wall and won’t send and receive at the same time. Then I moved onto better radios and even did some work with a friend on the Atmel radio processor boards – and then all of that seemed to change – the ESP8266 WIFI boards came about. Why were they better? Well first off they could use your existing WIFI infrastructure, they had excellent range, they were CHEAP – and by that let me make my position clear – I think spending £30 to turn a 50p lamp on and off is STUPID… it needs to be a LOT cheaper – like “a few quid”. When it comes to complexity – a little WIFI board on it’s own is sometimes all we should need (temperature sensor), or for a more complex item that feeding, say, an Arduino. In the past the problem has been that by the time you add Ethernet libraries and radio libraries to the Arduino you end up with almost no memory left.. and hence my use of the more powerful 1284 chips on custom boards – but that’s not REALLY the answer.. Micro-Arduino boards from China at £2 is REALLY the answer.  So a WIFI board+micro-Arduino for £4 or so – that’ll do.

The ESP-01 board is a perfectly usable board which sadly has a couple of things missing – the link for SLEEPING being one of them – the chip pins are way too small for most of us to solder and so it looks like the slightly more expensive ESP-12 might be an answer – it also has lots of FCC and other stickers to keep those people who care about such things happy.

But how do they all talk together? It seemed at first that the ESP8266 would do it all then reality set in – you can’t be a client, talking TCP/IP to a phone – AND be a web client, getting the time etc. at the SAME TIME – OH DEAR, the dream was starting to come apart. And then along came MQTT.  It’s REALLY simple… you have a machine or service somewhere called an MQTT broker and all it does is this.. everyone logs onto it with a unique name, lets say we call our devices peter and paul. Peter and paul can receive messages from the “broker” and send message – to anyone. So Peter can sent a direct message to paul. Problem solved. But it gets better.

The TOPIC system lets peter only subscribe to messages he’s interested in.  So, if Peter was an external temperature sensor he might only be interested in messages requesting the temperature.  If Paul however is a thermostat control, he might be interested in knowing what Peter’s temperature is – and what the time is . He might also want to know if he’s on PEAK time or not, or what the current requested temperature is. If this is not exciting I’m doing a piss poor job of explanation as it’s got me excited.  So whatever this protocol is it needs to be available on PCs and Linux etc., it also needs to be available on ESP8266 for those projects that use it – and on Arduino for those projects with a hardwired Ethernet connection. Well, as of around now – IT IS!

MQTT is now available on the ESP8266 but BEWARE – the author himself says this is for messing with and not yet for production – so don’t get TOO carried away – a new release came out yesterday with SSL. – my own experience is – it WORKS. I’ve had a little light sitting there dangling from a shelf, listening to the broker and responding – and it just keeps on ticking – loss of power no problem – it picks up where it left of.

But what if the little device is not on all the time – won’t it miss messages? Well no because there are 3 types of message (it’s important this is implemented in whatever you use. Type 0 message means send it and take pot luck if anyone gets it-  type 1 means they are guaranteed to get the message – but they might get it more than once. Type 2 means they will get the message for sure – once only.  This is nothing more for you to worry about than putting a number at the end of a function – 0,1 or 2.

So, let’s backtrack – that time thing. Right now I have an Arduino which calls a web page I wrote to get hte time because I don’t find NTP time servers that reliable (they get a lot of use) and they don’t send me lighting up times etc. I wrote my own PHP page sitting on a public server so I could get what I want, when I want.  And that was fine, it’s in the blog and some of you have used it… but there’s a BETTER way. Given an MQTT server and the common ability of web servers using CPANEL to allow “cron jobs” – WAY more complicated sounding than it is… imagine if I could have the ISP call that page every 15 minutes. Imagine now that the page instead of returning the time and light up times, sends that info to the BROKER!!! (As it will from sometime this afternoon until eternity). NOW the lonely thermostat ESP8266 in the kitchen doesn’t need a whole new protocol to learn – it just subscribes to that message and every 15 minutes it gets the time – SIMPLES!! But by now your ears are probably pricking.. hang on.. if I can do that then… yes, the humble web page now not only can send off the time, but a load of stuff like “lamp 4 in the living room – it’s time to turn on”. Instead of having to write a whole load of shite in a little processor you can have a password protected page on a website with TONS of terms and conditions to setup and you can update them on any old tablet and… well, I’m sure you’re writing code already.

What’s wrong with the above..

The little ESP8266 powers up for the first time, has no idea what your router is called.  So what we need is the MQTT software on the board, COMPLETE with the simplest page…. what is the router called – what is the password and what’s the address, name and password of the MQTT broker. As the ESP8266 can be it’s own access point this could all be done by a mobile phone which talks to the unit which ONLY is an access point if you pull a lead down to ground – or better – only when it actually has no information stored or the info stored does not work. Anyone up for that.

Lua allows people with no engineering degree to interact with the ESP8266 boards – and it’s very nice and there’s one fellow suggesting a way to merge MQTT and LUA – that would be great – but again BEWARE – the Lua installation WILL let you down if you get too ambitious – the implementation is unforgiving when you make mistakes and it EATS RAM.

If we could combine ALL of the above – a Lua interpreter that has it’s own web setup page – and the MQTT client software and maybe a range of temperature sensor libraries (the DHT22 is good – reliable, accurate and gives both temperature and humidity)….

BUT we won’t always be working with the ESP8266 alone – we might want it to be part of a package with an Arduino.. SO –  the unit when it receives messages should always put them out onto the serial line – maybe wrapped in some unique combination of characters – like << and >>or similar so it’s a doddle for the Arduino to pull out the message from any other crap (like the ESPs start-up 78kbaud crap we can’t seem to stop) with the absolute minimum or parsing… so for example if we have a topic peter/stuff and a message “turn something on” – maybe <<peter/stuff:turn something on>>   – see what I mean – look for “<<” – store until the colon in one buffer then till >> in another – and you have 2 buffers – topic and message – SIMPLES!!  But then there’s the slightly more complicated bit – they Arduino would need to send into the serial port two things…. 1. a topic/message in the same format – but ALSO commands to subscribe or unsubscribe to topics…   I honestly think at this point that this is ALL we need from the ESP8266… that of course and the whole thing being in a Windows- Eclipse compatible GITHUB package we can drop in – open up ONE web page in which we put our own special bits – using the Espressif SDK manual which they seem to be rather reticent to part with.

MOSQUITTO is a free MQTT broker (or server if you like) and it’s fine – but it’s all command line and pretty gruesome for beginners to understand. It can run on a PC under Windows… it’s ACTUALLY not that difficult once you’ve used it but messing with that config file is like a trip back into the 20th century – someone needs to make a nice sparkly Windows screen with lots of tick boxes.  When it comes to clients on the PC I’m in love with the free MQTT-SPY – it’s just lovely.  As for Android – really – MyMQTT is awful – if anyone wants to re-write MQTT Spy for Android they would be on my Christmas card list for years.

So there you are – I’m playing with Mosquitto and Rabbit-MQ which looks really nice but I have to say it did collapse when I tried to send a level 2 message out… might just be me not understanding things yet.

From here I’m ready to start coding – there’s enough above to form the basis of a very large and complicated control system –  I’m THAT far off having an internet controlled SAD light for the wife… it’s sitting here waiting for commands but I need something on the phone with nice round, shiny buttons and flashing lights that looks the part – not sure Basic 4 Android is going to do that for me but we’ll give it a whirl.

Let me know if this didn’t make sense – because if it didn’t you’re missing out on lots of potential fun.



Peter Scargill

p.s. The easiest way to get to grips with this MQTT thing – get MOSQUITTO – install it  – ignore usernames and passwords for now.  Get MQTT Spy – tell it about the IP address of the machine with MOSQUITTO (can be same machine) and PLAY… subscribe to arbitrarily named topics – send messages to those topics – within minutes it will all become clear. 

p.p.s. If you’re a Facebook fan and want to read about this stuff ONLY for Windows users who like pretty interfaces like me – head over to