Subscribing to control commands in IOT Protocols - Step-by-Step Execution

Process Flow - Subscribing to control commands

Start Client

↓

Connect to Broker

↓

Subscribe to Topic

↓

Wait for Messages

↓

Receive Control Command

↓

Process Command

↓

Acknowledge/Act

↓

Continue Listening or Disconnect

The client starts, connects to the broker, subscribes to a topic, waits for control commands, processes them, and then continues listening.

Execution Sample

IOT Protocols

client.connect(broker_url)
client.subscribe('device/control')
client.on_message = handle_command
client.loop_forever()

Connects to broker, subscribes to control topic, sets message handler, and listens indefinitely.

Process Table

Step	Action	State Change	Output/Result
1	Client starts and connects to broker	Connected = True	Connection established
2	Subscribe to 'device/control' topic	SubscribedTopics = ['device/control']	Subscription confirmed
3	Wait for incoming messages	Listening = True	No output yet
4	Receive control command message	MessageReceived = True	Message payload received
5	Process command in handler	CommandProcessed = True	Command executed or acknowledged
6	Continue listening for more commands	Listening = True	Ready for next message
7	Client disconnects (optional)	Connected = False	Disconnected from broker

💡 Client stops listening or disconnects, ending subscription.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Connected	False	True	True	True	True	True	False
SubscribedTopics	[]	[]	['device/control']	['device/control']	['device/control']	['device/control']	['device/control']
Listening	False	False	False	True	True	True	False
MessageReceived	False	False	False	False	True	True	False
CommandProcessed	False	False	False	False	False	True	False

Key Moments - 3 Insights

Why does the client keep listening after processing a command?

Because the client is designed to continuously listen for new control commands, as shown in steps 5 and 6 where Listening remains True to handle future messages.

What happens if the client is not connected to the broker?

Without connection (step 1), subscription and message reception cannot happen, so SubscribedTopics stays empty and no commands are received, as seen in the variable tracker.

How does the client know a control command has arrived?

When a message arrives on the subscribed topic, MessageReceived changes to True at step 4, triggering the command processing handler.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of 'SubscribedTopics' after step 2?

A []

B ['device/control']

C ['device/data']

D ['control/device']

💡 Hint

Check the 'SubscribedTopics' value in the variable_tracker after step 2.

At which step does the client receive a control command message?

A Step 4

B Step 3

C Step 5

D Step 6

💡 Hint

Look at the 'MessageReceived' variable change in the variable_tracker and the execution_table action.

If the client disconnects at step 7, what happens to the 'Connected' variable?

A Remains True

B Changes to Null

C Changes to False

D No change

💡 Hint

Refer to the variable_tracker 'Connected' value at the final step.

Concept Snapshot

Subscribing to control commands:
- Connect client to broker
- Subscribe to control topic
- Listen for messages
- On message, process command
- Continue listening or disconnect
Use persistent connection for real-time control.

Full Transcript

This visual execution shows how an IoT client subscribes to control commands. First, the client connects to the broker. Then it subscribes to the 'device/control' topic. The client waits and listens for incoming messages. When a control command message arrives, the client processes it in a handler function. After processing, the client continues listening for more commands or disconnects if needed. Variables like Connected, SubscribedTopics, Listening, MessageReceived, and CommandProcessed change state step-by-step to reflect this flow.

Practice

1. What is the main purpose of subscribing to control commands in IoT devices?

easy

A. To update the device firmware manually

B. To listen and respond automatically to commands sent from a controller

C. To send data continuously to the cloud

D. To disconnect the device from the network

Solution

1. Step 1: Understand the role of subscribing

   Subscribing means the device listens for messages or commands sent to it.

2. Step 2: Identify the purpose of control commands

   Control commands tell the device what actions to perform automatically.

3. Final Answer:

   To listen and respond automatically to commands sent from a controller -> Option B

4. Quick Check:

   Subscribing = Listening for commands [OK]

Hint: Subscribing means listening for commands to act automatically [OK]

Common Mistakes:

• Confusing subscribing with sending data
• Thinking subscribing updates firmware
• Assuming subscribing disconnects device

2. Which of the following is the correct syntax to subscribe to a topic named device/control using an MQTT client in Python?

easy

A. client.subscribe('device/control')

B. client.sub('device/control')

C. subscribe(client, 'device/control')

D. client.listen('device/control')

Solution

1. Step 1: Recall MQTT client subscription method

   The standard method to subscribe is client.subscribe(topic).

2. Step 2: Match the correct syntax

   client.subscribe('device/control') uses the correct method and topic string format.

3. Final Answer:

   client.subscribe('device/control') -> Option A

4. Quick Check:

   Subscribe method = client.subscribe(topic) [OK]

Hint: Use client.subscribe('topic') to subscribe in MQTT Python [OK]

Common Mistakes:

• Using incorrect method names like sub or listen
• Passing client as first argument to subscribe
• Using wrong topic string format

3. Given this Python MQTT subscription code snippet, what will be printed when a message with payload ON arrives on topic device/control?

def on_message(client, userdata, message):
    if message.payload.decode() == 'ON':
        print('Turning device ON')
    else:
        print('Unknown command')

client.subscribe('device/control')
client.on_message = on_message

medium

A. Turning device ON

B. Unknown command

C. Error: decode() not found

D. No output

Solution

1. Step 1: Decode the message payload

   The payload is decoded to string and compared to 'ON'.

2. Step 2: Check the condition and output

   Since payload is 'ON', it matches the if condition and prints 'Turning device ON'.

3. Final Answer:

   Turning device ON -> Option A

4. Quick Check:

   Payload 'ON' triggers print 'Turning device ON' [OK]

Hint: Decode payload and compare string to decide output [OK]

Common Mistakes:

• Forgetting to decode payload bytes
• Assuming payload is already string
• Ignoring else branch output

4. Identify the error in this MQTT subscription code snippet that prevents receiving messages:

client = mqtt.Client()
client.on_message = on_message
client.subscribe('device/control')
client.loop_start()

medium

A. loop_start() should be loop_forever()

B. Incorrect topic name format

C. Missing client.connect() call before subscribing

D. on_message function not defined

Solution

1. Step 1: Check connection setup

   MQTT client must connect to broker before subscribing.

2. Step 2: Identify missing connect call

   The code lacks client.connect(), so subscription won't work.

3. Final Answer:

   Missing client.connect() call before subscribing -> Option C

4. Quick Check:

   Connect before subscribe to receive messages [OK]

Hint: Always connect client before subscribing to topics [OK]

Common Mistakes:

• Skipping client.connect() call
• Assuming subscribe works without connection
• Confusing loop_start() with connection

5. You want your IoT device to subscribe to control commands on topic home/lights/command and turn lights ON or OFF accordingly. Which code snippet correctly subscribes and handles these commands in Python using MQTT?

hard

A. client = mqtt.Client()
client.connect('broker.hivemq.com')
client.subscribe('home/lights/command')
client.loop_forever()

B. client = mqtt.Client()
client.subscribe('home/lights/command')
client.on_message = lambda c,u,m: print('Lights ON' if m.payload == 'ON' else 'Lights OFF')
client.loop_start()

C. def on_message(client, userdata, message):
if message.payload == 'ON':
print('Lights ON')
client = mqtt.Client()
client.connect('broker.hivemq.com')
client.subscribe('home/lights/command')
client.on_message = on_message
client.loop_forever()

D. def on_message(client, userdata, message):
cmd = message.payload.decode()
if cmd == 'ON':
print('Lights ON')
elif cmd == 'OFF':
print('Lights OFF')
client = mqtt.Client()
client.connect('broker.hivemq.com')
client.subscribe('home/lights/command')
client.on_message = on_message
client.loop_forever()

Solution

1. Step 1: Verify subscription and connection

   def on_message(client, userdata, message): cmd = message.payload.decode() if cmd == 'ON': print('Lights ON') elif cmd == 'OFF': print('Lights OFF') client = mqtt.Client() client.connect('broker.hivemq.com') client.subscribe('home/lights/command') client.on_message = on_message client.loop_forever() connects to broker, subscribes to correct topic, and sets message handler.

2. Step 2: Check message handling logic

   It decodes payload and handles both 'ON' and 'OFF' commands properly.

3. Final Answer:

   Complete subscription with connection and proper message handling -> Option D

4. Quick Check:

   Connect, subscribe, decode payload, handle ON/OFF [OK]

Hint: Connect, subscribe, decode payload, handle commands in on_message [OK]

Common Mistakes:

• Not decoding payload bytes to string
• Missing client.connect() call
• Ignoring OFF command handling
• Not assigning on_message callback