Subscribing to control commands in IOT Protocols - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output when subscribing to a control topic with QoS 1?

You subscribe to the MQTT topic device/control with QoS level 1. The broker sends a retained message with payload ON. What will the client receive?

IOT Protocols

client.subscribe('device/control', qos=1)
# Broker sends retained message 'ON' on 'device/control'

A The client receives the message 'ON' multiple times without acknowledgment.

B The client receives the message 'ON' exactly once and sends PUBACK to broker.

C The client does not receive any message because QoS 1 ignores retained messages.

D The client receives the message 'ON' but does not send any acknowledgment.

💡 Hint

QoS 1 guarantees message delivery at least once with acknowledgment.

QoS 1 ensures the client receives the message at least once and sends PUBACK to confirm receipt. Retained messages are sent immediately upon subscription.

❓ Configuration

intermediate

Which MQTT client configuration enables automatic resubscription after reconnect?

You want your MQTT client to automatically resubscribe to control topics after a network reconnect. Which configuration option should you enable?

A Set <code>qos</code> to 0 to avoid resending messages.

B Set <code>keep_alive</code> to 0 to disable session expiration.

C Set <code>retain</code> to true to keep messages on the broker.

D Set <code>clean_session</code> to false to keep subscriptions after reconnect.

💡 Hint

Session persistence controls subscription retention.

Setting clean_session to false tells the broker to keep the session and subscriptions after disconnect, enabling automatic resubscription.

❓ Troubleshoot

advanced

Why does the client not receive control commands after reconnect?

An MQTT client subscribes to device/control with QoS 1 and clean_session=true. After a network drop and reconnect, the client does not receive any control commands sent during offline. Why?

A Because <code>clean_session=true</code> clears subscriptions on disconnect, so no resubscription occurs.

B Because QoS 1 does not guarantee message delivery after reconnect.

C Because the broker does not support retained messages on this topic.

D Because the client did not send PUBACK for previous messages.

💡 Hint

Check session persistence settings.

With clean_session=true, the broker deletes the session and subscriptions on disconnect, so the client must resubscribe manually after reconnect to receive messages.

🔀 Workflow

advanced

Order the steps for subscribing and receiving control commands via MQTT

Arrange the following steps in the correct order for an MQTT client to subscribe and receive control commands reliably.

A 1,3,2,4

B 2,1,3,4

C 1,2,3,4

D 2,3,1,4

💡 Hint

Think about connection before subscription.

First connect with session persistence, then subscribe, receive messages, and acknowledge them to ensure reliable delivery.

✅ Best Practice

expert

Which practice ensures reliable control command delivery in MQTT for IoT devices?

Select the best practice to ensure IoT devices reliably receive control commands even after temporary disconnections.

A Use persistent sessions (clean_session=false), subscribe with QoS 1 or 2, and use retained messages for last known command.

B Use clean_session=true and QoS 0 to minimize network traffic and avoid duplicates.

C Subscribe with QoS 0 and rely on the device to poll the broker for missed commands.

D Disable retained messages and use QoS 2 with clean_session=true for guaranteed delivery.

💡 Hint

Think about session persistence and message delivery guarantees.

Persistent sessions keep subscriptions active, QoS 1 or 2 ensures delivery, and retained messages provide the last command on reconnect.

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