Skip to content
Tutorial
14 min read
October 17, 2026

NodeMCU ESP8266 MQTT LED Control with Mosquitto

Control a NodeMCU ESP8266 LED by publishing ON/OFF commands to Mosquitto over MQTT. Configure command and reported-state topics, wire an external LED, test with command-line clients and troubleshoot broker access.

NodeMCU ESP8266 MQTT LED Control with Mosquitto

This project lets a NodeMCU ESP8266 change an external LED when it receives an MQTT command. The board subscribes to a command topic, validates ON or OFF, updates the GPIO and publishes a separate state message. That last step matters: the command expresses what a controller requested, while the state topic reports what the firmware applied.

Use this low-voltage example to test the complete path—broker, Wi-Fi, topic, callback and GPIO—before adding relays or other actuators. This is a plain MQTT demonstration for a trusted lab network; use authentication and an appropriately secured transport for untrusted links.

Image pending: Image placeholder: NodeMCU ESP8266 subscribes to Mosquitto command topic, toggles an external LED and publishes reported state on a separate topic.

Hardware and topics

Use a NodeMCU ESP8266, LED, series resistor, breadboard, jumper wires and USB cable. This example uses D5/GPIO14 for the LED; verify the pin mapping on your board. Connect GPIO to the LED through a resistor and connect the LED's cathode to GND.

Use:

  • solderhub/lab/nodemcu01/command/led — controller publishes ON or OFF;
  • solderhub/lab/nodemcu01/state/led — firmware reports applied state.

Do not retain one-shot command messages. A reconnecting client should not unexpectedly replay an old ON command unless that is explicitly intended.

Image pending: Image placeholder: NodeMCU wiring diagram with D5/GPIO14 through a resistor and LED to GND. Clearly label external LED and resistor.

1. Configure the broker first

Before uploading firmware, confirm Mosquitto is reachable from the NodeMCU's network. A local-only default listener will not accept a remote board via the Pi's LAN address until remote listening is configured. Create an authenticated broker account and give it only the topics needed for this project.

This article's firmware uses username/password authentication. Keep these credentials local; never commit them to a public repository. Start with Install Mosquitto on Raspberry Pi 5 and test the broker with Test MQTT without Hardware.

Image pending: Image placeholder: Mosquitto service and topic setup on Raspberry Pi with a test account and the command/state topic pair. Hide the password.

2. Upload the NodeMCU sketch

Install ESP8266 board support and the PubSubClient library in Arduino IDE. Replace credentials and broker address locally. The code resubscribes after a successful connection, rejects payloads other than ON/OFF, and publishes the GPIO state. It uses a simple retry interval; see the non-blocking reconnect guide for broader Wi-Fi recovery and backoff patterns.

C++
Image pending: Image placeholder: Arduino IDE sketch with broker/user/password placeholders, fixed topics and ON/OFF validation. No real secrets.

3. Test with command-line clients

Subscribe to the reported state from a machine that can reach the broker:

mosquitto_sub -h BROKER_LAN_IP -t 'solderhub/lab/nodemcu01/state/led' -u TEST_USER -P 'TEST_PASSWORD' -v

Publish a command:

mosquitto_pub -h BROKER_LAN_IP -t 'solderhub/lab/nodemcu01/command/led' -u TEST_USER -P 'TEST_PASSWORD' -m 'ON'

Use your real local host and test credentials; never paste production passwords into screenshots or publish them in shell history. The state subscriber should show ON after a valid command. Then publish OFF and verify both physical LED and reported state.

Image pending: Image placeholder: MQTT client terminal showing ON command and separate reported-state message, alongside NodeMCU LED test setup.

State, retained messages and safety

The firmware publishes reported state as retained so a new subscriber can learn the latest output state. This is appropriate for current state in this simple example; it is not a full event history. Command messages are not retained. The board's retained report represents firmware-applied GPIO state, not independent proof that an external load physically changed.

Before adapting this to a relay, determine input polarity, driver rating, boot behavior and safe offline state. Do not connect mains loads on a breadboard or use a dashboard/MQTT message as the only safety interlock.

Troubleshooting

No connection: confirm Wi-Fi, broker LAN address, port, credentials and listener configuration.

Command arrives but LED stays off: verify the exact topic, D5/GPIO14 mapping, LED polarity and serial output.

State topic never changes: verify subscription callback and broker ACL for publishing the state topic.

Board disconnects repeatedly: check unique client ID, signal strength and broker logs. For a resilient loop, use Non-Blocking MQTT Auto-Reconnect on ESP32 as a pattern and adapt it to ESP8266 networking APIs.

Signal In

Built from what makers search for

The lookups piling up in SolderHub's search bar every day shape what we publish next — new component pages, board guides, and firmware notes, sent out as they go live.

By subscribing you agree to our Privacy Policy. Unsubscribe anytime.