Day 13: Subscribing to Remote Commands via MQTT (Control Devices Remotely)

Welcome back to our IoT adventure!
So far:

• Day 11 → MQTT basics + why it’s the WhatsApp of IoT.
• Day 12 → Publishing sensor data like a champ (temperature + humidity).

Today → We flip the coin. Instead of just talking, our IoT devices will start listening… and even obeying. Yep, today is about remote commands via MQTT.

Why Do Devices Need to “Listen”?

Publishing sensor data is cool (like tweeting what your cat ate ).
But IoT gets really powerful when devices respond to commands from afar:

• “Plant monitor, please water the basil.”
• “Smart light, dim to romantic mode (don’t ask why).”
• “ESP32, self-destruct in 5…4…3…” (okay, maybe not that last one).

That’s where subscribing comes in → devices subscribe to a topic (like tuning into a radio channel ) and wait for instructions.

Command Subscription: Topics + Patterns

We already know MQTT works on topics (like chat groups).
To control a smart bulb, you might use:

home/livingroom/light/command

Now the device listens there. If the broker delivers "ON", boom .
You can also get fancy with wildcards:

• home/+/light/command → control lights in all rooms.
• home/# → control all devices in the house (scary, but cool).

Tuning into MQTT topics

Remote Control Architecture

When a command arrives, a device must:

1. Validate → Is this a legit command or just gibberish?
2. Process → Execute the action (turn fan ON).
3. Acknowledge → “Command received, boss .”
4. Report status → “Fan is now ON.”

It’s like ordering food online:

• You place the order ,
• Chef checks if it makes sense (no “lasagna in a milkshake” please),
• They cook it,
• Then you get updates: “Order received → Preparing → Out for delivery → Delivered.”

Security Considerations

Big responsibility here: what if anyone can yell at your smart bulb “Turn ON at 3 AM”?

That’s why we need:

• Authentication → Only trusted users can send commands.
• Access Control → Thermostat ≠ Toaster. (Don’t let Alexa set your oven to 1000°C).
• Input Sanitization → Don’t accept random nonsense like "danceMode=true".

Command Types

Not all commands are equal. They fall into 3 buckets:

1. Immediate Actions → “Turn ON now.”
2. Scheduled Tasks → “Water plants tomorrow at 8 AM.”
3. Configuration Changes → “Set soil moisture threshold = 500.”

Think of it like talking to your roommate:

• “Switch off the fan right now!” (immediate)
• “Please water the plants when I’m back tomorrow.” (scheduled)
• “Stop leaving the AC at 18°C, set it to 24°C permanently.” (config)

Get Shikhar Shrivastav’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Response Handling

Commands are a two-way street. Devices shouldn’t just nod silently — they need to respond.

• Success → “Light is ON.”
• Failure → “Error: Bulb not found.”
• Status → “Battery: 78%.”

Without this feedback, you’re just yelling into the void.

source: mqtt-explorer

Scalability Patterns

When you scale up from 1 device → 100 devices → 10,000 devices, things get spicy:

• Multiple devices → Each one has its own topic.
• Broadcasting → One command goes to many devices (home/all/lights/command).
• Device groups → Control only a subset (e.g., farm/section1/pumps/#).

Imagine being a teacher :

• “Everyone, stop talking!” (broadcast).
• “Group A, come to the front.” (device grouping).
• “You, John, sit down!” (individual).

Integration Examples with MQTT

Now let’s imagine extending our Smart Plant Monitor using MQTT (Message Queuing Telemetry Transport) — a lightweight messaging protocol perfect for IoT. With MQTT, your Arduino (or ESP32) can publish sensor data and subscribe to control commands in real-time.

1. Mobile App

• The plant monitor publishes soil moisture readings (topic: plant/soil) to an MQTT broker (like Mosquitto or HiveMQ).
• A custom mobile app subscribes to this topic and displays live data.
• From the app, you can send commands back (topic: plant/fan) to turn a cooling fan ON/OFF remotely.
• Example: Tap “OFF” in the app → MQTT sends fan=0 → Arduino switches relay off.

2. Web Dashboard

• A web dashboard (Node-RED, ThingsBoard, or custom HTML + MQTT.js) subscribes to sensor topics:
• plant/moisture → shows percentage bar.
• plant/light → shows live graph.
• Dashboards can also log data into a database (InfluxDB, MongoDB) for long-term tracking.
• You can view trends like: “Soil moisture drops every 3 days → time to water!”

3. Voice Assistant

• Link MQTT topics with Google Assistant or Alexa via services like IFTTT or Home Assistant.

Example workflow

You say: “Hey Google, water my basil.”

Assistant sends a command to MQTT topic plant/pump with message ON.

Arduino receives it and triggers a small water pump relay.

• The assistant can also query status: “Alexa, how’s my basil?” → reads back the latest soil moisture data from MQTT.

In short: MQTT acts like the middleman between your Arduino and any app, dashboard, or assistant. It keeps everything lightweight, fast, and scalable — whether you’re monitoring one basil plant or a full greenhouse.

smart home dashboard (source: dribble.com)

Wrapping Up

Today, you saw how IoT devices can:

• Subscribe to topics,
• Validate & execute commands,
• Respond with confirmations,
• Stay secure,
• And scale to fleets of devices.

Tomorrow? We’ll take this further into… well, let’s keep it a surprise, see y’all :)