Connect a Virtual Smart Light to the Cloud with Iotery via MQTT and HTTP

Photo by NASA on Unsplash

Getting started with connecting a custom device to the cloud can be quite daunting. You generally need firmware to run on your device, cloud infrastructure to accept connections and manage data, and a client interface (e.g. a web browser or voice assistant) to communicate user intent. If you’ve got an idea that you would like to bring to a Proof of Concept stage, anything that makes that process faster and easier is definitely attractive.

There are a lot of technologies that can be used to orchestrate communication between the different moving parts, but we’ll be focusing on MQTT and good ole’ HTTP. That way we get robust data transfer (HTTP) along with live updates for time-critical applications (MQTT). We’ll use Iotery, which is a managed IoT service that provides a RESTful API (over HTTP) and a MQTT broker to securely connect to. Iotery also has a Smart Light Emulator that can be used to act as our device firmware.

Get started with Iotery

In order to use Iotery’s Smart Light Emulator, we first need to make a free account here.

Iotery account creation
Iotery Registration Page

Next you’ll need to create a team. Feel free to choose whatever name you would like.

Iotery team creation

Now we can make a virtual smart light. You can find the emulator at You should see something like this:

Iotery Smart Light Emulator
Iotery Smart Light Emulator

If you click the “connect” button in the top right corner, you’ll see a dialog pop up that says “Connect Smart Light to Iotery”.

Smart Light Connect Dialog
Smart Light Connect Dialog

Given the wide array of applications possible within the world of IoT, Iotery has to be configured to match your use case. Fortunately, this emulator can handle all of that configuration for us. Click the “Still need to configure Iotery?” link at the bottom left of the dialog box to start the auto-configuration process. You’ll be asked for your Team API Key, which you can find on the Iotery System page:

After going through the configuration process, you will have setup the following records:

  • Device Type: Smart Light
  • Data Type: On/Off State
  • Command Types: Turn Light On and Turn Light Off
  • Device: My Iotery Smart Light

You should be back to the “Connect Smart Light to Iotery” dialog with the device credentials already entered for you. The emulator will use these credentials (Team UUID as well as Device Serial, Key, and Secret) in order to log the device into Iotery. Note that a UUID is just a unique ID made up of digits 0–9 and a-f. Every record created within Iotery will have its own UUID. Go ahead and press the “submit” button to connect.

Interacting with the virtual smart light

At this point you should see that your virtual smart light is connected. There will be a green pulsing light that says “online” and the light bulb icon will have a darkened background.

Emulator Online

This emulator represents a physical smart lightbulb that could be in your home. The firmware is written in JavaScript and runs inside of the browser. However, it uses the exact same REST API (HTTP) and MQTT connection that you could put on a physical board, such as a Raspberry Pi or Arduino. This also means that you can use firmware written an any programming language that you want, as long as it uses the same REST API and MQTT connection, the cloud will interpret everything else the same. We’ll go into more details on these interfaces later. For now, let’s actuate our connected light bulb via the cloud!

You can click the “Iotery Dashboard” link underneath the lightbulb icon, which will take you to your device’s commands page:

Iotery Dashboard Device Commands Page

Press the “Execute command” button next to IOTERY_TURN_LIGHT_ON, and you should see your smart light activate (i.e. Light State ON).

It’s the device’s responsibility to serve as the ultimate source of truth regarding On/Off State. So in response to receiving a Turn On Command, the smart light emulator switches on and afterwards reports its new state back to the cloud. This can be viewed on the Information Tab for the device in the Iotery dashboard under Live Data:

Iotery Dashboard Device Information Page

You can see that the IOTERY_ON_OFF_STATE has a value of 1 for ON. Try toggling the light bulb directly by clicking the icon in the emulator. You’ll see the Live Data update to show a value of 0 for OFF. So regardless of if the command is initiated by a client (e.g. the Iotery Dashboard) through the web or directly on the device, the system remains in sync.

So now we’ve interacted with both a virtual device (Iotery Smart Light Emulator) and a cloud-connected client (Iotery Dashboard). Next we’ll discuss the overall cloud architecture and how everything connects together.

Cloud Architecture

Up to this point, we haven’t really seen how the different pieces of this system are linked together. The three main components are (1) the device, (2) the Iotery cloud, and (3) the client interface. The Iotery Smart Light Emulator is our device and the Iotery Dashboard is our client interface. The Iotery cloud has been acting behind the scenes to serve as the glue connecting the two.

Iotery Cloud Architecture


The two main technologies used for communication to and from the cloud are REST (over HTTP) and MQTT. The Iotery cloud supports a RESTful API through its endpoint at REST is more or less a set of conventions that can be built on top of HTTP that use its standard methods of GET, POST, PUT, PATCH and DELETE in order to manage data resources accessed by different URLs. If you’d like to read more on REST, check out the article below.

Iotery has extensive documentation on its REST APIs that you can find at While HTTP provides a robust solution for data transfer, its inherit request-response protocol makes each connection through the REST API short-lived. So if you wanted “live data updates” for your device, you would have to constantly pool the cloud, which is wasteful and slow. Welcome MQTT to the rescue! We’re only going to cover the surface, but if you would like a more in-depth look at MQTT, here’s a great article.

MQTT stands for Message Queue Telemetry Transport and is built on top of the TCP layer, just like HTTP. However, unlike using HTTP via REST, which opens and closes TCP sockets on each connection, MQTT maintains a constant connection and automatically reconnects upon interruptions. MQTT is a lightweight publish-subscribe network protocol that has three types of actors: (1) a broker, (2) a publisher, and (3) a subscriber. Data is also organized into different topics. For example, the topic used for our Turn On Command is ‘devices/+deviceUuid/commands’, where ‘+deviceUuid’ is the device UUID for your smart light. Publishers can push data to a topic on the MQTT broker and subscribers of that topic will receive the data almost immediately.

Putting it all together

So now that we have a general idea of how everything is connected, let’s walk through the actual flow of information that happened when we connected our Smart Light Emulator to the cloud and began to actuate it from the Iotery Dashboard.

1. Device Login

A device login requires four pieces of information:

  • Team UUID
  • Device Serial
  • Device Key
  • Device Secret

When you created your team through the Iotery Dashboard, a UUID was generated to identify that team. The auto-configuration process in the emulator then took you through the steps to generate a device record and used the secret you provided while automatically assigning a device serial and key. The serial and key are just two more pieces of information used to identify the device in the cloud.

The login process utilizes the following Embedded REST route in Iotery. The HTTP Request body is what goes from the device to Iotery and the HTTP Response Body is what gets sent from Iotery back to the device.

POST HTTP Request Body
"teamUuid": "e9f6fa1a-f015-11e9-bef3-a02aef343366",
"serial": "5077D843",
"key": "1496BD8860D2",
"secret": "secret"
HTTP Response Body
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJlYTNkZDBjYS1mMDE1LTExZTktYmVmMy1hMDJhZWYzNDMzNjYiLCJpYXQiOjE1NzEyMzEyNTQsImV4cCI6MTU3MzgyMzI1NH0.Pgk9Ia1g_sZIaS7GSza11rdpX0ZJf7Ca1jEVeRNqbmI", "expiration": 1573823254,
"device": {
"uuid": "ea3dd0ca-f015-11e9-bef3-a02aef343366",
"deviceTypeUuid": "ea15c666-f015-11e9-bef3-a02aef343366",
"key": "1496BD8860D2",
"serial": "5077D843",
"name": "My Iotery Smart Light",

The request and response bodies are provided in JSON format. You can see that in the response body of the route, Iotery provides a JWT token, which has a specific expiration time and is used for authorization to other REST API calls and MQTT connections. The Smart Light Emulator then stores this token and uses it along with its other credentials to subscribe to the ‘devices/+deviceUuid/commands’ topic on the MQTT broker. At this point, the green light is on and the emulator shows that it is “connected”.

2. Generate a Command Instance

When you registered and logged into the Iotery Dashboard, your browser went through a similar process as the emulator (i.e. using the REST API to obtain a JWT token). From the device commands page in the dashboard, you were then able to generate command instances in the cloud via the following REST route:


That HTTP POST, tells Iotery to generate a command instance of the command type you chose (e.g. Turn Light On), which then gets published by the cloud to the ‘devices/+deviceUuid/commands’ topic on the MQTT broker. Since the Smart Light Emulator (device) is an MQTT subscriber to that topic, it sees the command almost instantly and handles it appropriately.

3. Device/Cloud Synchronization

After a device receives and handles a command instance from the cloud, it needs to let the cloud know that the command has been executed and notify the cloud of its new state.

The device informs the cloud that a command has been executed through the following REST route:


After that, the device should report its On/Off State by posting to its data REST route:


This full-circle communication provides a history of command instance execution and device state, all stored within Iotery, which can be viewed an analyzed at a later time. If the device is commanded directly, such as when we toggled the light on and off in the Smart Light Emulator, the device also needs to communicate this back to Iotery. Initially this is done through the a REST route to register an already executed command instance:


Afterwards the same REST route for posting device data is used to inform of the new device state.


All of these device state data posts are viewable instantly from the Device Information Page in the Iotery Dashboard under Live Data like we saw before. As you’ve probably already guessed, we can thank MQTT for providing this data live to the Iotery Dashboard (AKA client interface). This is done through a ‘devices/+deviceUuid/data’ topic.

Closing Remarks

We’ve gone through working demo of connecting a virtual smart light to the cloud and controlling it, all through Iotery. You’ve been given a brief introduction to Iotery’s cloud architecture, which is built on top of REST (over HTTP) and MQTT. I hope you’ve had some fun an learned a little bit along the way!

Now that you have the power of Iotery at your finger tips, you can work on connecting whatever device you have in mind to the cloud without having to build everything from the ground up. Iotery provides the cloud infrastructure and a client-interface for you start using immediately. If you want to connect your own device, all that needs to be done is to write your device firmware and communicate via the appropriate REST API routes and subscribe to your desired MQTT topics.

If you’re interesting in seeing another IoT project that uses Iotery, here’s a great tutorial on how to connect a Raspberry Pi using Python.

Until next time.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store