Programming the Raspberry Pi 5 for I2C Sensor and Relay Control

When programming the Raspberry Pi for reliable embedded hardware control in 2026, the default stack for general-purpose I2C and GPIO tasks is the Raspberry Pi 5 4GB running Raspberry Pi OS (Bookworm) with Python 3.11, utilizing the gpiozero and smbus2 libraries. This combination leverages the Pi 5's dedicated RP1 southbridge chip for stable, low-jitter pin toggling while maintaining backward compatibility with decades of Python hardware scripts.

The Decision Tree: Which Pi and Language for Embedded Control?

Before writing a single line of code, you must match the hardware to the physical constraints of your deployment. Use this decision matrix to select your board and language stack. If your project does not strictly require video processing or extreme low-power sleep states, default to the bolded recommendation.

If your project requires...	Choose this Board	Choose this Language/Stack
Computer vision or local LLM inference	Raspberry Pi 5 8GB	C++ / Rust with OpenCV
Battery-powered remote logging (sleep states)	Raspberry Pi Zero 2 W	MicroPython or C
Robust GPIO/I2C relay & sensor control (Default)	Raspberry Pi 5 4GB	Python 3.11 (gpiozero + smbus2)

Hardware Spec Sheet and Pin Mapping

The Raspberry Pi 5 operates its GPIO and I2C buses strictly at 3.3V logic. Feeding 5V logic back into the RP1 chip will permanently destroy the southbridge. Therefore, we are using a 3.3V-compatible active-low relay module rather than a standard 5V optocoupler relay.

Pin Mapping Table

Pi 5 Physical Pin	BCM / Function	Target Component	Wire Color (Standard)
Pin 1	3.3V Power	BME280 VIN	Red
Pin 3	GPIO 2 (I2C SDA)	BME280 SDI	Blue
Pin 5	GPIO 3 (I2C SCL)	BME280 SCK	Yellow
Pin 6	Ground	BME280 GND	Black
Pin 2	5V Power	Relay VCC (Coil Power)	Red (Thick)
Pin 9	Ground	Relay GND	Black (Thick)
Pin 29	GPIO 5	Relay IN1 (Logic Trigger)	Green

Step-by-Step: Wiring and Environment Setup

Before programming the Raspberry Pi, you must enable the I2C bus and install the correct Python bindings. The Pi 5 uses the lgpio backend for GPIO access under the hood, which gpiozero handles automatically on Bookworm.

1. De-energize: Unplug the Pi 5 USB-C power supply before connecting any GPIO wires.
2. Wire the I2C Bus: Connect the BME280 to Pins 1, 3, 5, and 6 as per the table above.
3. Wire the Relay: Connect the relay VCC to Pin 2 (5V) to provide adequate current for the coils, but connect the IN1 logic pin to Pin 29 (GPIO 5). Do not connect 5V to the IN1 pin.
4. Boot and Enable I2C: Power on the Pi, open a terminal, and run sudo raspi-config. Navigate to Interface Options -> I2C and enable it.
5. Install Dependencies: Run the following commands to install the I2C tools and Python libraries:

   sudo apt update && sudo apt install -y i2c-tools python3-smbus2 python3-gpiozero

6. Verify Hardware: Run i2cdetect -y 1. You should see 76 or 77 in the grid, confirming the BME280 is acknowledged on the bus.

The Code: BME280 I2C Verification and Relay Switching

The following Python 3 script targets the Raspberry Pi 5 4GB. Instead of importing heavy, dependency-prone sensor libraries that frequently break across OS updates, this script reads the BME280's hard-coded Chip ID register (0xD0) using raw smbus2 calls to verify I2C integrity, then toggles the relay. This is a bulletproof pattern for embedded proof-of-life testing.

import smbus2
from gpiozero import OutputDevice
import time
import sys

# --- PIN & ADDRESS DEFINITIONS ---
I2C_BUS = 1
BME_ADDR = 0x76  # Default Adafruit BME280 address (0x77 if SDO tied to VIN)
RELAY_PIN = 5     # BCM GPIO 5 (Physical Pin 29)
BME_CHIP_ID_REG = 0xD0
EXPECTED_CHIP_ID = 0x60

# --- HARDWARE INITIALIZATION ---
# active_high=False because standard relay modules trigger on LOW (0V)
relay = OutputDevice(RELAY_PIN, active_high=False, initial_value=False)
bus = smbus2.SMBus(I2C_BUS)

def verify_sensor():
    """Reads the BME280 Chip ID register to verify I2C communication."""
    try:
        chip_id = bus.read_byte_data(BME_ADDR, BME_CHIP_ID_REG)
        if chip_id != EXPECTED_CHIP_ID:
            raise ValueError(f'Incorrect Chip ID: Expected 0x{EXPECTED_CHIP_ID:02X}, got 0x{chip_id:02X}')
        print(f'Sensor verified. Chip ID: 0x{chip_id:02X}')
    except OSError as e:
        print(f'CRITICAL I2C ERROR: {e}')
        print('Check wiring, pull-up resistors, and i2cdetect output.')
        sys.exit(1)

def main_loop():
    verify_sensor()
    print('Starting relay control loop. Press Ctrl+C to exit.')
    try:
        while True:
            relay.on()  # Pulls GPIO LOW to trigger active-low relay
            print('Relay ENGAGED')
            time.sleep(2)
            
            relay.off() # Releases GPIO to HIGH (3.3V)
            print('Relay DISENGAGED')
            time.sleep(2)
            
    except KeyboardInterrupt:
        print('\nInterrupt received. Safely shutting down GPIO.')
    finally:
        relay.off()
        relay.close()
        bus.close()

if __name__ == '__main__':
    main_loop()

Debugging: Fixing Remote I/O and GPIO Failures

When programming the Raspberry Pi for hardware interfacing, you will inevitably hit bus lockups or permission errors. Here is how to resolve the two most common embedded blockers.

Error 1: OSError: [Errno 121] Remote I/O error

This exact string means the Linux kernel attempted an I2C transaction, but the slave device did not acknowledge (NACK) the address. Ranked causes:

1. Incorrect Address: The BME280 SDO pin is floating or tied high, shifting the address to 0x77. Fix: Run i2cdetect -y 1 and update BME_ADDR in the code.
2. Missing Pull-up Resistors: The Adafruit breakout has onboard 10k pull-ups, but if you are using a raw sensor module, the I2C bus requires 4.7kΩ pull-up resistors to 3.3V on both SDA and SCL. Fix: Solder 4.7kΩ resistors between VCC and the data lines.
3. Wire Length/Capacitance: I2C bus capacitance exceeds 400pF (usually >30cm of wire). Fix: Shorten wires or drop the I2C baud rate in /boot/firmware/config.txt by adding dtparam=i2c_baudrate=50000.

Error 2: RuntimeError: Failed to add edge detection or GPIO lockups

While this script uses output, if you modify it for inputs, you may see this error. On the Pi 5, this usually stems from the RP1 chip's strict pin multiplexing.

1. Ghost Processes: A previous Python script crashed without running the finally block, leaving the pin locked. Fix: Run sudo killall python3 and reboot.
2. PWM Conflict: GPIO 5 is sometimes reserved for specific audio/PWM overlays. Fix: Move the relay to GPIO 17 (Pin 11).

Scaling the Build: Extend or Simplify

Once the baseline I2C verification and relay toggling are stable, you must decide how to adapt the node for your specific environment.

How to Extend (Production Ready)

To turn this bench test into a deployment-ready environmental controller, integrate the Paho MQTT library. Wrap the verify_sensor() function in a loop that reads the actual temperature/pressure registers (detailed in the Bosch BME280 Datasheet), formats the payload as JSON, and publishes it to a local Mosquitto broker. Add a software watchdog using the Pi 5's hardware watchdog timer (systemd watchdog integration) to automatically reboot the board if the I2C bus locks up for more than 60 seconds.

How to Simplify (Educational / Quick Test)

If you only need to verify that programming the Raspberry Pi's GPIO works and do not care about environmental data, drop the BME280 entirely. Remove the smbus2 imports, delete the verify_sensor() call, and wire a standard 3.3V LED with a 330Ω current-limiting resistor to GPIO 5. This reduces the hardware cost to under $70 and eliminates all I2C bus capacitance variables, leaving you with a pure GPIO software test.