Article Summary

A SPIKE Prime port is not a set of general purpose pins, so the wiring and code in many older guides do not work. This guide covers the routes that do work in 2026, through Pybricks or by emulating a LEGO sensor, the 3.3V rule for the port, and when a Raspberry Pi is the simpler answer.

Status, October 2026: LEGO Education stopped selling SPIKE Prime and SPIKE Essential on June 30, 2026, and supports the SPIKE App until June 30, 2031. Hubs already in classrooms and homes keep working, and everything below applies to them.

A SPIKE Prime port is not a row of Arduino pins. It is a LEGO Powered Up port that talks to motors and sensors over a serial protocol at 3.3V, so wiring an HC-SR04 or an MPU6050 to it through a voltage divider and reading it in Python does not work, whatever older guides show. Third-party sensors can still reach a SPIKE hub, through a board that speaks LEGO's protocol, through Pybricks, or by moving them to a Raspberry Pi. This guide covers each route and the one wiring rule that protects the hub.

Quick answer: put the sensor on a small 3.3V microcontroller such as the LMS-ESP32 and have it present itself as a LEGO device; read it with Pybricks, or with the SPIKE App if it imitates a LEGO sensor exactly. For your own serial protocol, use Pybricks' UARTDevice. For many sensors at once, a Raspberry Pi with the Build HAT is simpler.

Why direct wiring does not work

Each SPIKE port carries motor power, a supply and two signal lines. When a LEGO device is plugged in, the hub and the device identify each other over those signal lines and then exchange data in LEGO's protocol (often called LPF2 or LUMP). A bare sensor never identifies itself, so the hub's normal sensor functions do not see it, and the SPIKE App's Python has no function for reading a raw pin. Feeding a port a 5V signal can damage the hub.

Pybricks documents the two signal pins: pin 5 is the hub's transmit line and pin 6 its receive line, both at 3.3V. Its documentation warns that turning on power to the pins from code is at your own risk. Anything you connect should be 3.3V logic, or go through a level shifter.

Route 1: a board that speaks LEGO's protocol

The most practical route is a microcontroller board with a LEGO connector that reads your sensors and presents the result to the hub as a LEGO device. The LMS-ESP32 from Anton's Mindstorms is built for this and runs MicroPython with the PUPRemote library. The ESP32 handles the sensor wiring (I2C for an IMU, a GPIO pin for an ultrasonic sensor) and the hub only sees a well-behaved device.

On the board, from the PUPRemote documentation:

from pupremote import PUPRemoteSensor

p = PUPRemoteSensor(power=True, max_packet_size=16)
p.add_command('msg', "repr", "repr")
p.add_channel('one_w', to_hub_fmt="bbb")

while True:
    p.update_channel('one_w', 1, 2, 3)
    p.process()

On the hub, running Pybricks:

from pupremote_hub import PUPRemoteHub
from pybricks.parameters import Port

p = PUPRemoteHub(Port.A)
p.add_command('msg', "repr", "repr")
p.add_channel('one_w', to_hub_fmt="bbb")

print(p.call('one_w'))

Replace the fixed values with your sensor readings on the board side. The channel names and formats must match on both ends.

With the official SPIKE App

The SPIKE App's own Python is stricter. The PUPRemote documentation notes that with the SPIKE 3 software a board has to exactly emulate an existing LEGO sensor; it then appears to the app as that sensor and you read it with the normal sensor functions. That suits a substitute for a LEGO sensor, such as a different distance sensor, more than a new kind of measurement.

Route 2: your own microcontroller over serial with Pybricks

Pybricks can also treat a port as a plain serial line with UARTDevice, which it supports on every port of a Powered Up hub. A 3.3V microcontroller wired to pins 5 and 6 (and ground) can then send readings in any format you choose: 

from pybricks.hubs import PrimeHub
from pybricks.iodevices import UARTDevice
from pybricks.parameters import Port

hub = PrimeHub()
ser = UARTDevice(Port.A, baudrate=115200)

ser.write(b"read\n")
print(ser.read_all())

read(length) waits for a given number of bytes and raises an error if a timeout you set runs out; read_all() returns whatever has arrived. Pybricks' PUPDevice class does the opposite job, reading the modes of anything that already speaks LEGO's protocol.

Route 3: put the sensors on a Raspberry Pi

If a project needs several third-party sensors, a camera or a network connection, it is often simpler to let a Raspberry Pi read the sensors on its own I2C and GPIO pins and drive the LEGO motors through the Build HAT. Our Raspberry Pi Build HAT guide covers the setup and the Python library.

Competition rules

FIRST LEGO League requires the robot to be built from LEGO-made parts, with sensors of the approved LEGO types, so third-party sensors are a project for home or class rather than the robot game. Check the current season's Robot Game Rulebook, and the rules of any other competition, before adding non-LEGO electronics.

Which route to choose

  • One or two extra sensors on a SPIKE robot, Pybricks firmware: an LMS-ESP32 with PUPRemote.
  • The SPIKE App, a sensor LEGO already makes a version of: a board that emulates that LEGO sensor exactly.
  • Your own microcontroller and protocol: Pybricks UARTDevice on pins 5 and 6 at 3.3V.
  • Many sensors, a camera or Wi-Fi: a Raspberry Pi with the Build HAT.

If you are choosing between LEGO's software and Pybricks in the first place, see Pybricks vs LEGO firmware, and for what is still on sale now that SPIKE has ended, SPIKE Prime vs MINDSTORMS Robot Inventor.

Updated October 2026. Pin and API details are from the Pybricks documentation and the PUPRemote documentation; product status is from LEGO Education.