Experiment 10: Raspberry Pi LED control with MQTT

Objective

Problem

Switch an LED on a Raspberry Pi from a phone, through an MQTT broker, so neither side needs the other’s address.

Interface

broker broker.hivemq.com, topic pdeu/led, payload on or off (plain text).

Behaviour

on → LED on, off → LED off, within a fraction of a second; MQTT Explorer shows the latest value.

Learn

publish/subscribe, brokers and topics, and the security weaknesses of open brokers (asked in the Observation section).

System

Design decisions

What we did

1. Connected the LED anode to a GPIO pin through a current-limiting resistor, cathode to GND.

   Same LED circuit as Exp 1; Pi GPIO is 3.3 V and should stay under about 16 mA per pin, so the resistor is required.

2. Logged in over SSH and installed the Python GPIO and MQTT client libraries.

   The Pi is headless (Exp 9). The program needs a library to speak MQTT and one to drive the pins.

3. Chose the public broker broker.hivemq.com and the topic pdeu/led.

   Every client must agree on broker and topic; the topic is the only “address” in the system.

4. Wrote and ran a Python subscriber: set up the pin, connect, subscribe to pdeu/led, switch the LED on each message.

   It stays in a listening loop; the work happens in the message callback.

5. Created two buttons in the MQTT Dashboard app, both on topic pdeu/led, with values on and off.

   Each press publishes one message.

6. Connected MQTT Explorer on the laptop to the same broker.

   Shows every message on the topic, so you can tell whether a problem is on the publishing or the receiving side.

7. Pressed on/off and watched the LED and MQTT Explorer.

   Checks the whole path end to end.

How MQTT works

One message’s path: the phone sends CONNECT and gets CONNACK, then PUBLISH (topic pdeu/led, payload on). The Pi had earlier sent SUBSCRIBE pdeu/led. The broker matches the topic against its subscriptions and forwards the PUBLISH to the Pi and to MQTT Explorer. The phone never learns who received it.

The subscriber program

• Two callbacks: on_connect runs after the broker accepts the connection; on_message runs for every message on a subscribed topic.
• Subscribe inside on_connect, so a reconnect after a Wi-Fi drop subscribes again automatically.
• Normalise the payload (decode, strip, lower), because the payload is just bytes: “ON”, “on ” and “on” should behave the same.
• loop_forever() handles the network, keepalive pings and reconnects, and calls the callbacks: the same job as ArduinoCloud.update() in Exp 8.

import paho.mqtt.client as mqtt
from gpiozero import LED

led = LED(17)                        # example pin: use the one you wired
BROKER, TOPIC = "broker.hivemq.com", "pdeu/led"

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(TOPIC)          # subscribe again after every reconnect

def on_message(client, userdata, msg):
    cmd = msg.payload.decode().strip().lower()
    if cmd == "on":
        led.on()
    elif cmd == "off":
        led.off()
    print(msg.topic, cmd)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, 60)     # plain TCP, keepalive 60 s
client.loop_forever()

Written for paho-mqtt 2.x. With paho-mqtt 1.x (for example the Debian package), create the client with mqtt.Client() and use on_connect(client, userdata, flags, rc). gpiozero is preinstalled on Raspberry Pi OS and uses BCM pin numbers.

Reading the outputs

• Right: the Raspberry Pi with its display, powered and booted.
• Laptop: MQTT Explorer connected to the broker, with its Publish panel open.
• Phone, held in front: the MQTT Dashboard app with the two buttons.

• The tree is broker ▸ topic levels: broker.hivemq.com ▸ pdeu ▸ led, with the last value on.
• The phone shows two cards, both “Topic: pdeu/led”, with button values on and off. The green cloud icon means the app is connected to the broker.
• The laptop received the phone’s message without knowing the phone exists: publish/subscribe working.

• Same topic, new value off: each publish replaces what the explorer shows as the latest value.
• The Pi, subscribed to the same topic, received the same two messages and switched the LED.

Security of open-source and public MQTT brokers

This is the lab’s Observation question. Learn it as: what is missing, what an attacker does with that, and the fix.

Limits and redesign

• Security: everything in the table above. Redesign: Mosquitto on the Pi or a server with TLS, user accounts and ACLs, or a managed broker with per-device certificates.
• State after restart: the subscriber only knows what it receives. Publish commands with retain, and have the Pi publish its actual state to pdeu/led/state so the dashboard shows the truth.
• Delivery: QoS 0 can lose a message on a bad link. QoS 1 retries until acknowledged; make the command idempotent (“on” twice is still on), which it already is.
• Liveness: set a Last Will message (for example pdeu/led/status = offline) so the dashboard knows when the Pi drops off.
• Running unattended: start the script as a systemd service so it restarts on boot and after a crash.

Say this in the viva

Viva questions