Publishing sensor data in IOT Protocols - Step-by-Step Execution

Process Flow - Publishing sensor data

Sensor reads data

↓

Format data as message

↓

Connect to broker/server

↓

Publish message to topic

↓

Broker receives and forwards

↓

Subscribers receive data

↓

Done

The sensor reads data, formats it, connects to a broker, publishes the message, and subscribers receive it.

Execution Sample

IOT Protocols

sensor_data = 25.3
message = f"temperature:{sensor_data}"
broker.connect()
broker.publish("home/sensor/temp", message)

This code reads a temperature, formats it, connects to the broker, and publishes the data.

Process Table

Step	Action	Data/Variable	Result/State Change	Output
1	Sensor reads data	sensor_data	sensor_data = 25.3
2	Format data as message	message	message = "temperature:25.3"
3	Connect to broker	broker.connection	broker.connection = True
4	Publish message	topic, message	Message sent to topic 'home/sensor/temp'
5	Broker forwards message	broker	Subscribers notified
6	Subscribers receive data	subscribers	Data received: 'temperature:25.3'
7	End		Publishing complete

💡 Publishing process completes after subscribers receive the data.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
sensor_data	undefined	25.3	25.3	25.3	25.3	25.3
message	undefined	undefined	temperature:25.3	temperature:25.3	temperature:25.3	temperature:25.3
broker.connection	False	False	False	True	True	True

Key Moments - 3 Insights

Why do we format the sensor data into a message before publishing?

Because the broker and subscribers expect data in a specific message format, as shown in step 2 of the execution_table where sensor_data is converted to a string message.

What happens if the broker connection is not established before publishing?

Publishing will fail because the broker.connection variable must be True before sending messages, as seen in step 3 and 4 where connection is established before publishing.

How do subscribers get the sensor data after publishing?

The broker forwards the message to all subscribers subscribed to the topic, shown in steps 5 and 6 where subscribers receive the data after broker forwards it.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'message' after step 2?

A undefined

B "temperature:25.3"

C 25.3

D "sensor_data"

💡 Hint

Check the 'Data/Variable' column for step 2 in the execution_table.

At which step does the broker connection become True?

A Step 3

B Step 1

C Step 4

D Step 5

💡 Hint

Look at the 'Result/State Change' column for broker.connection in the execution_table.

If the sensor_data was 30.0 instead of 25.3, how would the message change after step 2?

A 30.0

B "temperature:25.3"

C "temperature:30.0"

D "sensor_data"

💡 Hint

Refer to the variable_tracker for 'message' after step 2 and how it depends on sensor_data.

Concept Snapshot

Publishing sensor data:
1. Sensor reads data (e.g., temperature).
2. Format data as a message string.
3. Connect to broker/server.
4. Publish message to a topic.
5. Broker forwards to subscribers.
6. Subscribers receive the data.

Full Transcript

Publishing sensor data involves reading the sensor value, formatting it into a message, connecting to a broker, publishing the message to a topic, and then subscribers receive the data. The process ensures data flows from sensor to interested receivers reliably.

Practice

1. What is the main purpose of publishing sensor data in IoT protocols?

easy

A. To send sensor data to a topic so others can receive it

B. To store sensor data locally on the device

C. To encrypt sensor data before sending

D. To delete old sensor data from the cloud

Solution

1. Step 1: Understand publishing in IoT

   Publishing means sending data from a sensor to a topic so other devices can get it.

2. Step 2: Identify the main goal

   The goal is to share sensor data, not store or delete it locally or encrypt it by default.

3. Final Answer:

   To send sensor data to a topic so others can receive it -> Option A

4. Quick Check:

   Publishing = sending data to topic [OK]

Hint: Publishing means sending data to a topic for others [OK]

Common Mistakes:

• Confusing publishing with storing data locally
• Thinking publishing encrypts data automatically
• Assuming publishing deletes old data

2. Which MQTT publish command syntax is correct for sending temperature data to topic home/livingroom/temp?

easy

A. mqtt.publish('home/livingroom/temp', '22.5')

B. publish('home/livingroom/temp', temperature=22.5)

C. mqtt.publish('home/livingroom/temp')

D. publish('home/livingroom/temp', 22.5)

Solution

1. Step 1: Check MQTT publish method syntax

   The correct syntax uses the client object (e.g., mqtt) and calls publish with topic and message as string.

2. Step 2: Validate options

   mqtt.publish('home/livingroom/temp', '22.5') uses mqtt.publish with topic and string message, which is correct. publish('home/livingroom/temp', 22.5) misses client object, C misses message, B uses invalid keyword argument.

3. Final Answer:

   mqtt.publish('home/livingroom/temp', '22.5') -> Option A

4. Quick Check:

   mqtt.publish(topic, message) = correct syntax [OK]

Hint: Use client.publish(topic, message) with message as string [OK]

Common Mistakes:

• Omitting the client object before publish
• Not providing the message argument
• Using keyword arguments not supported by publish

3. Given this Python MQTT publish code snippet, what will be printed?

import paho.mqtt.client as mqtt
client = mqtt.Client()
client.connect('broker.hivemq.com', 1883)
result = client.publish('sensor/room1/humidity', '45')
print(result.rc)

medium

A. 1

B. 0

C. null

D. Error

Solution

1. Step 1: Understand publish return value

   client.publish returns a MQTTMessageInfo object with rc attribute showing result code: 0 means success.

2. Step 2: Check printed value

   Printing result.rc will print 0 if publish succeeded without error.

3. Final Answer:

   0 -> Option B

4. Quick Check:

   Publish success code = 0 [OK]

Hint: Publish returns rc=0 on success, print result.rc to see it [OK]

Common Mistakes:

• Assuming publish returns null
• Expecting printed message payload
• Confusing rc with error code

4. You wrote this MQTT publish code but no data appears on the subscriber side:

client.publish('sensor/temp', 25)

What is the likely problem?

medium

A. QoS level is missing and defaults to 2

B. The topic name is invalid

C. The message payload must be a string or bytes, not an integer

D. The client must call subscribe before publish

Solution

1. Step 1: Check payload data type

   MQTT publish requires message payload as string or bytes, not integer directly.

2. Step 2: Identify issue with given code

   Passing 25 as integer causes publish to fail silently or send empty data, so subscriber gets nothing.

3. Final Answer:

   The message payload must be a string or bytes, not an integer -> Option C

4. Quick Check:

   Payload must be string/bytes, not int [OK]

Hint: Always convert payload to string or bytes before publishing [OK]

Common Mistakes:

• Sending integer payload without conversion
• Thinking subscribe is needed before publish
• Assuming topic name is invalid without checking

5. You want to publish temperature data that stays available for new subscribers and is delivered reliably. Which MQTT publish options should you set?

hard

A. Set QoS=0 and retain=false

B. Set QoS=0 and retain=true

C. Set QoS=2 and retain=false

D. Set QoS=1 and retain=true

Solution

1. Step 1: Understand QoS levels

   QoS=1 ensures message delivery at least once, making it reliable.

2. Step 2: Understand retain flag

   retain=true keeps the last message on the broker so new subscribers get it immediately.

3. Step 3: Combine for reliable and persistent data

   Setting QoS=1 and retain=true meets both requirements.

4. Final Answer:

   Set QoS=1 and retain=true -> Option D

5. Quick Check:

   QoS=1 + retain=true = reliable & persistent [OK]

Hint: Use QoS=1 and retain=true for reliable, persistent data [OK]

Common Mistakes:

• Using QoS=0 which is unreliable
• Not setting retain so new subscribers miss data
• Confusing QoS=2 as always best choice