MQTT + Ubidots: Cloud Dashboard and Control

By the end of this project, you will:

• Explain the difference between the request/response model of a web server and the publish/subscribe model of MQTT, and why the second one scales.
• Use the vocabulary every MQTT platform shares: broker, topic, publish, subscribe.
• Send real sensor readings to a cloud service and see them plotted over time.
• Receive a command from the cloud through a callback function, and act on it.
• Keep a network connection alive in loop(), and recover from a drop without rebooting.
• Build a dashboard someone else can use, from anywhere, with no code on their side.

In Projects 5 to 9 the ESP32 was a web server: your phone had to be on the same Wi-Fi and had to keep asking for data. MQTT flips that around. Devices publish messages to a broker, and anyone interested subscribes. It is lightweight and works from anywhere with internet.

1. Sign up for a free Ubidots STEM account at stem.ubidots.com.
2. Open your profile, then API Credentials, and copy the Default token (looks like BBUS-xxxx).
3. No need to create the device by hand: it appears the first time the board publishes.

Install from the Library Manager: Ubidots ESP32 MQTT (pulls in PubSubClient), DHT sensor library, Adafruit Unified Sensor.

Edit the marked block at the top of the sketch: WIFI_SSID, WIFI_PASS, UBIDOTS_TOKEN, and a unique DEVICE_LABEL. Upload, then open Serial Monitor at 115200:

==============================================
 Project 11: ESP32 + MQTT + Ubidots
==============================================
DHT11 data -> GPIO 4
Output      -> GPIO 26
[PUB] temperature: 24.6 C, humidity: 41.0 %
[CLOUD] led -> ON (raw "1")

The first sketch that talks both ways with something outside the room. Here is how it works.

Step 1: One block holds everything platform-specific

const char *WIFI_SSID = "REPLACE_WITH_YOUR_SSID";
const char *WIFI_PASS = "REPLACE_WITH_YOUR_PASSWORD";
const char *UBIDOTS_TOKEN = "REPLACE_WITH_YOUR_UBIDOTS_TOKEN";
const char *DEVICE_LABEL = "esp32-workshop";   // a name for THIS board

const char *VAR_TEMPERATURE = "temperature";
const char *VAR_HUMIDITY    = "humidity";
const char *VAR_LED         = "led";   // the control variable we subscribe to

const int   PUBLISH_EVERY_MS = 5000;   // send readings every 5 seconds

Everything that would change if you moved to another MQTT platform sits in one place. The rest of the sketch reads the same whether the broker is Ubidots, Adafruit IO, or one you run yourself.

Step 2: Two objects, two responsibilities

DHT dht(DHTPIN, DHTTYPE);
Ubidots ubidots(UBIDOTS_TOKEN);

unsigned long lastPublish = 0;

dht is Project 9's sensor object, unchanged. ubidots wraps a Wi-Fi client, an MQTT client (PubSubClient underneath), and Ubidots' topic naming. Handing it the token at construction is what ties this board to your account.

Step 3: callback(), the cloud talking back

void callback(char *topic, byte *payload, unsigned int length) {
  char value[8] = {0};
  unsigned int n = (length < sizeof(value) - 1) ? length : sizeof(value) - 1;
  memcpy(value, payload, n);
  float v = atof(value);

  bool on = (v >= 0.5);          // treat anything from ~1 as "on"
  digitalWrite(LED_PIN, on ? HIGH : LOW);
  Serial.printf("[CLOUD] led -> %s (raw \"%s\")\n", on ? "ON" : "OFF", value);
}

This function is never called by your code. You hand it to the library, and the library calls it whenever a subscribed value arrives. That inversion has a name, callback, and it is how almost all event-driven networking works.

The payload arrives as raw bytes with a length, not a C string, so it has no terminating zero. Copying at most 7 bytes into a zeroed 8-byte buffer guarantees one, which is what makes atof() safe. Without the n guard, a long payload would write past the end of value.

v >= 0.5 rather than v == 1 is defensive: a switch may send 1, 1.0, or 1.000000, and comparing floats for exact equality is a bad habit anyway.

Step 4: setup() connects, then subscribes

ubidots.setDebug(true);                        // prints connection details
ubidots.connectToWifi(WIFI_SSID, WIFI_PASS);
ubidots.setCallback(callback);
ubidots.setup();
ubidots.reconnect();
ubidots.subscribeLastValue(DEVICE_LABEL, VAR_LED);

The order matters. Wi-Fi first, because MQTT needs a network. Then register the callback, so no message can arrive before there is somewhere to deliver it. Then connect to the broker, and only then subscribe.

subscribeLastValue() also asks the broker for the variable's current value, so the board picks up a switch you left on before it booted.

Step 5: loop() keeps the link alive and publishes on a timer

if (!ubidots.connected()) {
  ubidots.reconnect();
  ubidots.subscribeLastValue(DEVICE_LABEL, VAR_LED);
}

if (millis() - lastPublish > PUBLISH_EVERY_MS) {
  float t = dht.readTemperature();
  float h = dht.readHumidity();

  if (isnan(t) || isnan(h)) {
    Serial.println("[DHT] Failed to read, skipping this publish");
  } else {
    ubidots.add(VAR_TEMPERATURE, t);
    ubidots.add(VAR_HUMIDITY, h);
    ubidots.publish(DEVICE_LABEL);
  }
  lastPublish = millis();
}

ubidots.loop();   // lets the library process incoming cloud messages

Three jobs, none of them blocking:

1. Heal the connection. Wi-Fi drops and brokers restart. Re-subscribing after a reconnect is easy to forget, and the symptom (data still uploads, the switch stops working) is confusing.
2. Publish on a schedule, using Project 4's millis() timer. Two add() calls then one publish() sends both readings in a single message.
3. Give the library time to work. ubidots.loop() is where incoming messages are read off the socket and your callback() gets invoked. Miss it and nothing arrives.

Note the isnan() check again: a failed reading skips the publish entirely. Sending garbage to a chart is worse than sending nothing, because the gap is honest and the spike is not.

Key concepts: what each line really does

1. In Devices, confirm your device appeared with temperature and humidity.
2. Add a control variable: open the device, Add Variable, type Raw, name it exactly led.
3. In Data, Dashboards, add a Gauge on temperature, a Line chart on temperature and humidity, and a Switch on led.
4. Flip the switch. The board's LED or relay follows within a few seconds.

This is the project where "connected device" stops meaning "same Wi-Fi as my phone". The key takeaways:

• Publish/subscribe decouples everyone. The board does not know who reads its data and the dashboard does not know where the board is. A broker in the middle is what makes that work from anywhere.
• The loop is now closed: device to cloud (readings) and cloud to device (the led command). A device that only reports is a sensor; one that also listens is an IoT device.
• Callbacks invert control. You write the handler, the library decides when to run it. Keep it short and never block inside it.
• Network code must self-heal. Checking connected() and re-subscribing costs four lines and is the difference between a demo and something that survives a lunch break.
• Non-blocking timing is now mandatory, not a style preference: ubidots.loop() has to run constantly.
• Tokens are passwords. They stay in the edit block, out of screenshots, and out of git.
• Bad data is worse than no data. Skipping a publish leaves an honest gap in the chart.

• Swap the LED for the relay (Project 7) and you are switching mains-style loads from the cloud.
• Add an event in Ubidots (Data, then Events) to email or notify you when temperature crosses a threshold.
• This is the backbone of your capstone.