Introduction
I started using the Raspberry Pi Pico W to handle tasks my main Pi couldn’t juggle. It runs sensors without draining system resources. I connect a DHT11 to read room temperature. I use Thonny to write and upload MicroPython scripts. I send that data to Mosquitto using MQTT. It works even when my Raspberry Pi is logging other data to an SD card.
I keep it simple. The Pico W sits on a breadboard. A USB power bank runs it. I use jumper wires to hook up components like OLED screens and light sensors. The Pico W connects over Wi-Fi, sends values to Adafruit IO, and shows messages on a tiny display. It’s faster than I expected. I can watch values change from my phone. No reboots, no drama.
Key Takeaways
- The Pico W enables wireless communication through MQTT using MicroPython scripts and basic sensor wiring.
- MQTT allows separation between sensor nodes (Pico W) and central controllers (Raspberry Pi), supporting modular sensor networks.
- Breadboarding, I2C routing, and structured topic naming are essential for scalable, low-maintenance setups.
- Visual feedback with displays and LEDs improves debugging and trust in deployment.
- Tools like Thonny, MQTT Explorer, and Node-RED create a full development-to-dashboard workflow.
What Is a Raspberry Pi Companion Board?
A Raspberry Pi companion board operates alongside a main Raspberry Pi unit, providing additional functionality through focused processing or peripheral support. Devices like the Pico W serve as secondary controllers. They manage dedicated tasks such as reading a temperature sensor, controlling a servo motor, or transmitting data via MQTT over Wi-Fi.
A typical companion board connects to the Pi through USB, UART, or wirelessly using brokered messaging systems. In beginner setups, the Pico W runs MicroPython scripts using Thonny IDE. It interacts with sensors (e.g. DHT11 or BME280) and outputs data to a shared MQTT topic. The Raspberry Pi receives that data and logs it, visualizes it on a dashboard, or reacts using GPIO outputs.
Unlike general-purpose computers, companion boards are designed to run specific routines independently. This separation reduces system load and improves reliability in home automation, sensor logging, or environmental monitoring projects. Data flows between devices using structured protocols, often I2C for local buses or MQTT for wireless messaging.
Getting Started With the Raspberry Pi Pico W
The Pico W is a microcontroller that uses the RP2040 dual-core processor and integrates Wi-Fi through the Infineon CYW43439 chip. It’s programmed using MicroPython, uploaded through the Thonny IDE, which acts as both a code editor and device interface.
To flash the device, hold the BOOTSEL button, connect it via USB, and drag the UF2 firmware file into the mass storage device. Once the board resets, Thonny recognizes the Pico W as a target for MicroPython scripts. It supports interfaces like I2C, SPI, and UART for sensor communication.
Wi-Fi setup is done in MicroPython using the network.WLAN() class. You provide SSID and password, and the board retrieves a local IP address. MQTT messages can then be published using umqtt.simple, targeting brokers like Mosquitto or Adafruit IO. Scripts execute directly on the Pico W, isolating functions from the main Raspberry Pi. This division supports better resource control, more stable Wi-Fi operation, and easier debugging via USB serial output.
Connecting Sensors to the Pico W
The Raspberry Pi Pico W uses its GPIO header to receive input from sensors. These include digital, analog, and I2C-based modules. For beginners, common components like the DHT11 (temperature), BME280 (humidity and pressure), or HC-SR04 (distance) are ideal choices.
Sensors connect using jumper wires and a breadboard. The Pico W operates at 3.3V logic, so components must match that level. For I2C devices, GP0 and GP1 are used as the default data and clock lines. Analog sensors connect to ADC-compatible pins like GP26, GP27, or GP28.
Here’s a quick pin reference for typical sensors:
| Sensor Type | Protocol | Pico W Pinout | Power Pin | Ground Pin |
|---|---|---|---|---|
| DHT11 | Digital | GP15 (or any GPIO) | 3V3 | GND |
| BME280 | I2C | GP0 (SDA), GP1 (SCL) | 3V3 | GND |
| HC-SR04 | Digital | GP16 (TRIG), GP17 (ECHO) | 5V (with resistor divider) | GND |
| Light Sensor (LDR) | Analog | GP26 (ADC0) | 3V3 | GND |
MicroPython libraries from Adafruit or the official MicroPython bundle provide methods like sensor.read_temperature() or sensor.pressure. The machine module handles hardware setup, while the time module controls loops.
Sensor values are sent via MQTT using umqtt.simple. The Pico W acts as a publisher, pushing readings to a Mosquitto broker or Adafruit IO. The main Raspberry Pi, subscribed to the topic, logs or responds to the data.
Understanding MQTT in Simple Terms
MQTT is a lightweight messaging protocol used in many beginner IoT projects. It lets devices exchange data by publishing and subscribing to topics. The Pico W sends sensor readings to a broker, which stores and forwards them to subscribers like a Raspberry Pi.
Each device has a role:
| Device | Role | Action |
|---|---|---|
| Pico W | Publisher | Sends sensor data to topic |
| Mosquitto | Broker | Receives and stores published messages |
| Raspberry Pi | Subscriber | Listens for updates on specified topics |
A topic might be named sensor/room1/temp. The Pico W publishes to it using the umqtt.simple module in MicroPython. The message can include structured data like {"temp": 22.5}. The broker, often Mosquitto or Adafruit IO, holds the message until a subscriber requests it.
This setup allows a separation of tasks. The Pico W collects and sends data. The Raspberry Pi logs, displays, or reacts to it. MQTT makes this communication asynchronous, so devices don’t need to stay connected constantly.
Scripts can include error handling, retain flags, and Quality of Service settings. These features increase reliability, especially in home automation or sensor logging setups.
Building a Basic MQTT Project With Pico W
This project uses a Raspberry Pi Pico W to read temperature values from a DHT11 sensor and publish them over MQTT to a Mosquitto broker on a Raspberry Pi. The Pico W handles sensor input and network messaging, while the Raspberry Pi processes and stores incoming data.
Required Parts:
- Raspberry Pi Pico W (microcontroller)
- DHT11 temperature sensor (digital sensor)
- Raspberry Pi with Mosquitto installed (broker server)
- Breadboard, jumper wires, USB power supply
Pin Mapping:
| Function | DHT11 Pin | Pico W GPIO | Power | Ground |
|---|---|---|---|---|
| Data Signal | DATA | GP15 | 3V3 | GND |
Process Overview:
- The microcontroller imports MicroPython modules:
machine,network,umqtt.simple,time, anddht. - It connects to a Wi-Fi network using
network.WLAN()and secures a local IP. - The DHT11 sensor is polled via a digital GPIO pin (GP15).
- The device retrieves temperature and humidity readings using
sensor.temperature()andsensor.humidity(). - Data is encoded into a string or JSON format using MicroPython.
- The MQTT client (
umqtt.simple) publishes this payload to a topic such ashome/sensors/room1.
The Pico W operates independently. It reads input from the DHT11 sensor, formats the values, and sends them over the network. The Mosquitto broker receives the data. The Raspberry Pi subscribes to the same topic and logs or visualizes it using tools like Node-RED or MQTT Explorer.
This structure divides responsibilities: the Pico W controls local sensing, and the Pi manages central data handling. By isolating tasks, the system stays efficient and fault-tolerant — if one device fails, the other can continue.
Using Raspberry Pi and Pico Together
The Raspberry Pi and Pico W operate as separate devices that share data through an MQTT broker. The Pico W publishes sensor data, while the Raspberry Pi subscribes and logs incoming messages. Both devices run their own scripts. The Pico W handles sensors like the BME280 or DHT22, using MicroPython to collect and format readings. The Raspberry Pi, running Mosquitto, acts as a broker host and logging terminal.
Here’s how their roles differ:
| Task | Pico W (Microcontroller) | Raspberry Pi (Main System) |
|---|---|---|
| Runs sensors | Yes | No |
| Hosts MQTT broker | No | Yes |
| Publishes MQTT messages | Yes | No (unless needed) |
| Subscribes to MQTT topics | No | Yes |
| Stores data | No | Yes |
| Displays dashboards | No | Yes (via Node-RED, etc.) |
The Pico W connects to Wi-Fi using the network module. It opens an MQTT connection with the broker and sends payloads like {"humidity": 45} to a topic. The Raspberry Pi listens to that topic using a subscriber script or dashboard app like Node-RED.
Both devices are linked logically through MQTT topics, not physically. This separation allows for flexible placement. The Pico W can monitor air quality in another room while the Pi logs and displays the results in real time. Because the broker retains the latest message, the Pi can recover the last reading even after rebooting.
This model supports scalability. Multiple Pico boards, each with their own sensors and Wi-Fi links, can report to one Pi acting as a central node.
Visual Feedback With Displays and LEDs
The Pico W uses simple hardware outputs to show system status. Two common peripherals are OLED displays and LEDs. These provide local feedback without needing a computer or serial monitor. When the board connects to Wi-Fi, publishes a message, or reads a sensor, it can trigger visual responses using MicroPython.
An SSD1306 OLED module, connected through I2C, displays text-based output. The device links to the Pico W through GP0 (SDA) and GP1 (SCL). The script initializes I2C using machine.I2C(), then loads the ssd1306 library. Values like temperature or humidity from a BME280 sensor are displayed using oled.text() commands.
LEDs provide fast signals. The onboard LED on GP25 turns on or blinks to mark events. The board sets this pin as an output using Pin(25, Pin.OUT) and toggles it with led.toggle(). This gives physical confirmation that code blocks are running or sensor values are crossing thresholds.
Here’s how output matches system actions:
| System Event | Output Type | Feedback |
|---|---|---|
| Wi-Fi connection success | LED | Steady on |
| MQTT message sent | LED | Short blink |
| Sensor data read | OLED | New value appears |
| Broker unavailable | OLED | Connection error |
These feedback signals reduce debugging time and confirm that communication protocols, power supply, and sensor scripts are working. Displays and LEDs tie into broader categories like I2C devices, GPIO outputs, and visual indicators.
Power and Breadboarding Basics
The Pico W is a 3.3V microcontroller that accepts input power through USB, VBUS, or VSYS. When powered via USB, it draws from the VBUS pin, which supplies regulated 5V to the board. The 3V3 pin provides clean output voltage for peripherals like sensors and displays.
Breadboards allow beginners to test circuits without soldering. The Pico W fits onto a half-size board, leaving space on each side for wiring. Jumper wires connect the microcontroller’s GPIO pins to devices. This method supports rapid experimentation with I2C modules, digital inputs, and analog sensors.
Power is routed from the 3V3 pin to modules like the DHT11. Ground is shared via any GND pin. Signal wires connect to GPIOs like GP15 or GP26, depending on the module type. This structure keeps current pathways short and avoids noise.
| Pin Type | Pico W Pin | Common Use | Category |
|---|---|---|---|
| Power Output | 3V3 | Sensor supply voltage | Power Management |
| Ground | GND | Circuit return path | Electrical Grounding |
| Data I/O | GPIO (e.g. GP15) | Signal communication | Digital Interface |
Voltage regulators may be added if powering external devices over 5V. USB splitters can isolate power from data lines when using hubs. These tools fall under power distribution and prototyping accessories.
This setup lets the microcontroller support external circuits safely and flexibly.
Tips for Managing Multiple Devices
In projects with more than one microcontroller, organization prevents signal conflict and communication errors. Each Pico W or sensor node must use a unique MQTT client ID. This identifier lets the broker route messages correctly. Devices should also publish to logically named topics, which represent their location and function. For example, house/kitchen/temp1 refers to a sensor node reporting temperature.
Naming topics this way supports automation tools like Node-RED or Home Assistant, which use topic paths to assign tasks or display data. Without clear topic naming, multiple nodes may overwrite each other’s data or trigger the wrong action.
When using I2C sensors like the BME280, avoid address conflicts by selecting components with configurable addresses or separating them onto distinct buses (e.g. I2C0 for sensor A, I2C1 for sensor B). For identical modules, an I2C multiplexer such as the TCA9548A allows multiple devices with the same address to coexist.
Here’s a device-to-topic map:
| Node Role | Topic Path | Function Type |
|---|---|---|
| Room 1 temp sensor | house/room1/temp | Publisher |
| Basement humidity | house/basement/humidity | Publisher |
| Fan control receiver | house/fan/cmd | Subscriber |
| System heartbeat | house/pico3/status | Retained status update |
The retain flag tells the broker to store the last message, so subscribers can retrieve values after rebooting. This improves recovery in unstable power conditions.
Powering each controller with an isolated USB source prevents voltage drop. Use labeled jumper wires and maintain a diagram that records GPIO use, I2C bus assignments, and topic structure. These practices make scaling reliable when moving from one sensor to many.
Troubleshooting Common Issues
When using the Pico W with MQTT, Wi-Fi networks, or digital sensors, common failures often result from mismatched pin wiring, incorrect topic strings, or misconfigured credentials. Each issue affects a specific subsystem — power, communication, or data exchange — and can be traced using simple diagnostics.
If the sensor node doesn’t report data, confirm that it receives power from the correct 3V3 pin, shares a GND line, and connects its signal wire to the intended GPIO port (e.g. GP15). If the module uses I2C, ensure the SDA and SCL lines connect to active I2C pins like GP0 and GP1.
When the microcontroller fails to connect to Wi-Fi, confirm:
- The access point operates at 2.4GHz
- The SSID and password in the script match the router’s configuration
- The
wlan.isconnected()method returnsTrue
If MQTT messages aren’t received, check the following:
| Issue Category | Likely Cause | Recommended Check |
|---|---|---|
| Wi-Fi Networking | 5GHz-only router, wrong password | Validate 2.4GHz access, retry credentials |
| Broker Connectivity | IP address typo, broker offline | Ping broker, restart Mosquitto or Adafruit IO |
| Topic Publishing | Topic mismatch, missing subscription | Match topic strings exactly on both ends |
| Client ID Conflict | Duplicate ID in use | Assign unique client_id per controller |
| Power Supply | Inadequate current or unstable power | Test with USB meter or alternate source |
Use print statements throughout your MicroPython script to track progress:
- Log Wi-Fi status before MQTT connection
- Print topic and payload during each publish step
- Report sensor values after each read
Connect the controller board to Thonny IDE and use the REPL terminal to observe output in real time. This helps identify whether the script halts during Wi-Fi setup, sensor read, or MQTT publishing.
Adding a status LED or an OLED display can also help visualize which function failed. If no data shows up on screen or the LED doesn’t blink, the device may not be running the loop or may have rebooted due to a voltage dip.
This approach ties the observed failure directly to its subsystem: network, sensor interface, MQTT transport, or power regulation.
Useful Tools and Add-Ons
Several tools and accessories improve how the Pico W functions in sensor-based or MQTT-driven systems. These additions support tasks like writing MicroPython code, testing connections, logging data, or displaying output. Each belongs to a distinct category — software tools, connectivity aids, diagnostics, and physical expansion.
Software for Writing and Uploading Code:
- The Thonny IDE provides a beginner-friendly interface. It connects over USB, uploads MicroPython scripts, and displays live feedback from the REPL.
- Thonny IDE uploads code and shows output from the board.
- Ampy is a terminal utility that sends
.pyfiles directly to the controller. - rshell opens an interactive shell to manage files and run scripts remotely.
Dashboards and MQTT Visualizers:
- Adafruit IO offers a cloud-based MQTT broker with visual dashboards. It maps topic paths to gauges, graphs, and switches.
- Adafruit IO displays values published from the Pico W.
- MQTT Explorer lets users browse broker data in real time, showing which topics are active and what payloads are received.
- Node-RED runs on the Raspberry Pi. It builds automation flows using MQTT messages from connected boards and sensor modules.
Prototyping and Signal Routing Tools:
- The TCA9548A multiplexer connects multiple I2C sensors with identical addresses. It assigns each to its own channel on the same bus.
- The multiplexer routes I2C signals from multiple sensors to a shared controller.
- A USB power meter measures voltage and current to detect brownouts or USB instability.
- The SSD1306 OLED display shows live sensor values or network status using the I2C interface.
Connectivity Helpers and Test Gear:
- USB-to-Serial adapters provide direct communication if the board doesn’t show up as a USB device. These adapters use UART.
- Wi-Fi analysis apps on phones or laptops help identify signal strength issues or crowded channels when the Pico W won’t connect.
Each item improves a different stage in the workflow:
- IDEs manage coding and upload
- Dashboards visualize topic data
- I2C tools solve address problems
- Power meters ensure system stability
These utilities form the practical toolkit for any MQTT-enabled Pico W project.
Final Setup and Deployment Example
This deployment combines the Pico W, DHT22 sensor, OLED display, and an MQTT broker hosted on a Raspberry Pi. The microcontroller publishes sensor readings, displays values on a screen, and communicates wirelessly with a logging system using structured topics.
Hardware Entities Used:
- Controller board: Raspberry Pi Pico W
- Sensor module: DHT22 (temperature and humidity)
- Display interface: SSD1306 OLED (I2C)
- MQTT host: Raspberry Pi with Mosquitto
- Connection medium: Breadboard and jumper wires
Pin Assignment Table:
| Peripheral | Function | Pico W Pin | Signal Type | Category |
|---|---|---|---|---|
| DHT22 VCC | Sensor power | 3V3 | Voltage supply | Power Distribution |
| DHT22 GND | Shared ground | GND | Ground line | Electrical Grounding |
| DHT22 Data | Digital read | GP15 | GPIO | Sensor Interface |
| OLED SDA | I2C data | GP0 | SDA | Display Communication |
| OLED SCL | I2C clock | GP1 | SCL | Display Communication |
Operational Sequence:
- The controller board connects to a 2.4GHz network using
network.WLAN()and confirms status usingwlan.isconnected(). - It reads environmental data from the DHT22 using
sensor.measure()and stores the values. - Sensor data is formatted as a dictionary and transmitted using
client.publish()to the topichome/livingroom/env. - Simultaneously, the values are rendered on the OLED using
oled.text()andoled.show()via I2C. - The status LED on GP25 toggles to confirm each successful data transmission.
Receiving Node (Broker and Logger):
- The Raspberry Pi runs Mosquitto, listening for messages on the
home/livingroom/envtopic. - Node-RED flows process these messages and display the values in dashboard widgets.
- MQTT Explorer or
mosquitto_subconfirms real-time delivery and payload integrity.
Deployment Considerations:
- The power supply must deliver a stable 5V to avoid communication errors. USB wall adapters are more reliable than USB from a PC.
- Scripts should be saved as
main.pyfor automatic execution after reset. - Sensor reading intervals should be throttled to reduce Wi-Fi power drain and prevent overheating the DHT22.
- Label wires with physical tags and store I2C mappings in a printed layout to avoid misrouting.
System Entity Interactions:
- The microcontroller controls environmental sensing and message publication.
- The sensor module supplies real-time atmospheric data.
- The I2C display provides immediate local feedback.
- The broker service receives and distributes sensor updates.
- The automation platform (Node-RED) handles logging, graphing, and conditional responses.
This deployment represents a full IoT loop: sensing, displaying, transmitting, receiving, and logging — all coordinated through standardized topic paths and lightweight data packets.
FAQ
What is the difference between the Pico W and a regular Raspberry Pi?
The Pico W is a microcontroller designed for low-power, real-time tasks. It doesn’t run a full operating system like the Raspberry Pi. Instead, it runs firmware such as MicroPython and uses Wi-Fi for simple communication tasks like MQTT.
Can I use the Pico W with 5V sensors?
No. The Pico W uses 3.3V logic. Always check sensor voltage compatibility. If using 5V sensors, a logic level shifter may be required to prevent damage.
What MQTT broker should beginners use?
Mosquitto is widely recommended. It’s lightweight, easy to install on a Raspberry Pi, and supports both local and remote MQTT communication. Cloud options like Adafruit IO are available but may require internet access.
Why isn’t my OLED display working with the Pico W?
Check that the I2C pins (GP0 for SDA and GP1 for SCL) are connected correctly. Also verify the display’s address (usually 0x3C) and ensure the correct ssd1306.py driver is loaded in your MicroPython filesystem.
What happens if my Wi-Fi drops out during publishing?
If the Pico W loses Wi-Fi, MQTT publishing will fail. You can add reconnect logic in your script to retry connection or use the retain=True flag to hold the last message on the broker once Wi-Fi is restored.
References
- Raspberry Pi Pico W Datasheet
- Mosquitto MQTT Broker
- MicroPython for Pico W
- Adafruit DHT Sensor Library
- Node-RED for Raspberry Pi

