Subscribing to control topics in Raspberry Pi - Time & Space Complexity

Time Complexity: Subscribing to control topics

O(n)

Understanding Time Complexity

When subscribing to control topics on a Raspberry Pi, it is important to understand how the time to process messages grows as more topics or messages are involved.

We want to know how the program's work changes when the number of subscribed topics or incoming messages increases.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

import paho.mqtt.client as mqtt

def on_message(client, userdata, message):
    print(f"Received message: {message.payload.decode()}")

client = mqtt.Client()
topics = ["control/led", "control/motor", "control/sensor"]

for topic in topics:
    client.subscribe(topic)

client.on_message = on_message
client.loop_start()
    

This code subscribes to a list of control topics and prints messages received on them.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Loop over the list of topics to subscribe.
• How many times: Once for each topic in the list.

How Execution Grows With Input

As the number of topics increases, the number of subscribe calls grows directly with it.

Input Size (n)	Approx. Operations
3	3 subscribe calls
10	10 subscribe calls
100	100 subscribe calls

Pattern observation: The work grows in a straight line with the number of topics.

Final Time Complexity

Time Complexity: O(n)

This means the time to subscribe grows directly with the number of topics you want to listen to.

Common Mistake

[X] Wrong: "Subscribing to multiple topics happens all at once and takes the same time no matter how many topics there are."

[OK] Correct: Each topic requires a separate subscribe call, so more topics mean more work and more time.

Interview Connect

Understanding how subscribing scales helps you design efficient IoT applications on Raspberry Pi, showing you can think about performance as your projects grow.

Self-Check

"What if we batch subscribe to all topics in one call? How would the time complexity change?"

Practice

1. What is the main purpose of subscribing to control topics on a Raspberry Pi using MQTT?

easy

A. To send commands from the Raspberry Pi to other devices

B. To update the Raspberry Pi operating system automatically

C. To store data locally on the Raspberry Pi

D. To listen and react to control commands sent to the Raspberry Pi

Solution

1. Step 1: Understand MQTT subscription

   Subscribing means the Raspberry Pi listens to messages on a topic.

2. Step 2: Identify the purpose of control topics

   Control topics send commands that the Raspberry Pi should react to.

3. Final Answer:

   To listen and react to control commands sent to the Raspberry Pi -> Option D

4. Quick Check:

   Subscribing = Listening to commands [OK]

Hint: Subscribing means listening, not sending commands [OK]

Common Mistakes:

• Confusing subscribing with publishing
• Thinking subscription stores data
• Assuming it updates the OS

2. Which of the following is the correct Python syntax to subscribe to an MQTT topic named "home/lights/control" using the Paho MQTT client?

easy

A. client.connect("home/lights/control")

B. client.sub("home/lights/control")

C. client.subscribe("home/lights/control")

D. client.listen("home/lights/control")

Solution

1. Step 1: Recall Paho MQTT subscribe method

   The method to subscribe to a topic is subscribe().

2. Step 2: Match the correct syntax

   Using client.subscribe("home/lights/control") is correct syntax.

3. Final Answer:

   client.subscribe("home/lights/control") -> Option C

4. Quick Check:

   Subscribe method is subscribe() [OK]

Hint: Subscribe uses .subscribe(), not .sub() or .listen() [OK]

Common Mistakes:

• Using .sub() instead of .subscribe()
• Confusing subscribe with connect
• Using non-existent methods like .listen()

3. Given the following code snippet, what will be printed when a message with payload "ON" is received on the topic "home/lights/control"?

def on_message(client, userdata, message):
    if message.payload.decode() == "ON":
        print("Turning lights ON")
    else:
        print("Turning lights OFF")

client.subscribe("home/lights/control")
client.on_message = on_message

medium

A. Turning lights ON

B. Turning lights OFF

C. No output

D. Error: decode() not found

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 print output

   Since payload is "ON", it prints "Turning lights ON".

3. Final Answer:

   Turning lights ON -> Option A

4. Quick Check:

   Payload "ON" triggers print "Turning lights ON" [OK]

Hint: Decode payload before comparing strings [OK]

Common Mistakes:

• Not decoding payload before comparison
• Assuming no output without explicit print
• Thinking decode() causes error

4. Identify the error in this MQTT subscription code snippet for Raspberry Pi:

def on_message(client, userdata, message):
    print(message.payload)

client.on_message = on_message
client.subscribe("home/lights/control")
client.loop_start()

medium

A. Incorrect callback function name

B. Missing client.connect() before subscribing

C. Using loop_start() instead of loop_forever()

D. No error, code is correct

Solution

1. Step 1: Check connection setup

   Before subscribing, the client must connect to the MQTT broker.

2. Step 2: Identify missing connect call

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

3. Final Answer:

   Missing client.connect() before subscribing -> Option B

4. Quick Check:

   Must connect before subscribe [OK]

Hint: Always connect client before subscribing [OK]

Common Mistakes:

• Skipping client.connect() call
• Confusing callback function names
• Thinking loop_start() is wrong here

5. You want your Raspberry Pi to subscribe to multiple control topics: "home/lights/control" and "home/thermostat/control". Which code snippet correctly subscribes to both and handles messages differently based on the topic?

hard

A. client.subscribe(["home/lights/control", "home/thermostat/control"])
def on_message(client, userdata, message):
topic = message.topic
if topic == "home/lights/control":
print("Light control received")
elif topic == "home/thermostat/control":
print("Thermostat control received")
client.on_message = on_message

B. client.subscribe("home/lights/control")
client.subscribe("home/thermostat/control")
def on_message(client, userdata, message):
if message.payload == "light":
print("Light control")
else:
print("Thermostat control")
client.on_message = on_message

C. client.subscribe("home/lights/control", "home/thermostat/control")
def on_message(client, userdata, message):
print("Control received")
client.on_message = on_message

D. client.subscribe("home/lights/control")
def on_message(client, userdata, message):
print("Control received")
client.on_message = on_message
client.subscribe("home/thermostat/control")

Solution

1. Step 1: Subscribe to multiple topics correctly

   client.subscribe(["home/lights/control", "home/thermostat/control"]) def on_message(client, userdata, message): topic = message.topic if topic == "home/lights/control": print("Light control received") elif topic == "home/thermostat/control": print("Thermostat control received") client.on_message = on_message uses a list to subscribe to both topics at once, which is valid.

2. Step 2: Handle messages based on topic

   The on_message function checks message.topic to differentiate actions.

3. Final Answer:

   correctly subscribes to both topics and handles them separately -> Option A

4. Quick Check:

   Subscribe list + topic check = correct [OK]

Hint: Subscribe with list and check message.topic [OK]

Common Mistakes:

• Passing multiple topics as separate arguments
• Checking payload instead of topic for routing
• Subscribing after setting callback incorrectly