i2c scanner: how to scan the i2c bus

Arduino

Arduino / ESP32 scanner sketch

The classic sketch — it knocks on every legal address and prints whoever answers. Works unchanged on Uno, ESP32, RP2040 cores and anything else with the Wire library:

#include <Wire.h>

void setup() {
  Wire.begin();
  Serial.begin(115200);
  while (!Serial);
  Serial.println("Scanning 0x08-0x77...");
  for (byte addr = 0x08; addr <= 0x77; addr++) {
    Wire.beginTransmission(addr);
    if (Wire.endTransmission() == 0) {
      Serial.print("Device found at 0x");
      Serial.println(addr, HEX);
    }
  }
  Serial.println("Scan complete.");
}

void loop() {}

Raspberry Pi / Linux

i2cdetect: the Raspberry Pi i2c scanner

One package, one command (enable the bus first — here's how):

sudo apt install i2c-tools
i2cdetect -y 1

You get an address grid: a hex number means a live device, -- means silence, and UU means a kernel driver already owns that address (normal for an RTC). The 1 is the bus number — every modern Pi puts the GPIO-header bus on 1.

MicroPython

MicroPython i2c scan: two lines on a Pico

from machine import I2C, Pin
i2c = I2C(0, sda=Pin(0), scl=Pin(1))   # pins vary by board
print([hex(a) for a in i2c.scan()])

CircuitPython is nearly identical (i2c.scan() after locking the bus). Adjust the pin numbers to your board's silkscreen.

How it works

A scan is just 112 polite knocks

There's no magic and no "list devices" command in i2c — the protocol has no such thing. A scanner simply addresses every legal address in turn and watches for an ACK: the receiver pulling SDA low for one clock to say "that's me". Address, ACK, stop. Repeat 112 times. That's the whole algorithm.

Two consequences worth understanding, because they explain nearly every confusing scan:

First, the sweep is 0x08–0x77, not 0x00–0x7F. The spec reserves both ends — 0x00–0x07 and 0x78–0x7F — for the general call, 10-bit addressing and other special functions. That's why i2cdetect's grid has a gap at the start and stops early. It also means a device squatting on a reserved address (some cheap sensors do) is invisible to every standard scanner.

Second, write-probe vs read-probe. The Arduino sketch above does a zero-length write; i2cdetect defaults to a read probe on most addresses. Usually identical results — but a handful of write-only parts answer one and not the other, and a few devices actively dislike being read at random. That's why i2cdetect warns you before running, and why it uses a mixture of both by address range.

Reading the results

What the addresses tell you

A scan gives you presence, not identity — 0x76 could be a BME280 or a BMP280. Match what you found against the i2c address list to identify it, and remember the 0x76 vs 0xEC trap: datasheets sometimes quote the 8-bit shifted form of the same address.

You can go one better than guessing. Most chips have an ID register, so one read turns a maybe into a fact:

# Pi: is that "BME280" really a BME280?
i2cget -y 1 0x76 0xD0
# 0x60 -> BME280   |   0x58 -> BMP280 (no humidity — you got the cheap one)

That single command settles the most common substitution on the market. Our free i2c tool automates the same trick across nineteen chips — it scans, then fingerprints each hit by its WHO_AM_I register rather than guessing from the address.

The limits

Three things a scan will never show you

Knowing what a clean scan doesn't prove saves hours:

1. Devices behind a multiplexer. A TCA9548A or TCA9546A only passes traffic to channels you've opened, so eight sensors behind one scan as nothing — you'll see the mux at 0x70 and an otherwise empty bus, which reads exactly like broken wiring. You have to open each channel and scan again. (The i2c tool's mux command walks all eight for you.)

2. Two devices sharing one address. Both ACK, and two devices pulling SDA low is electrically identical to one doing it. The scan shows a single, healthy-looking address — then reads come back as the bitwise AND of both devices' answers: plausible numbers, quietly wrong. A scan cannot detect this; an ID-register read usually can. The collision roundup lists which real pairs actually clash.

3. A device that's present but unhappy. ACKing an address only proves the chip is powered and its i2c front-end works. It says nothing about whether the sensor is configured, calibrated, or returning sane data — plenty of parts ACK cheerfully while reporting rubbish because they were never initialised.

And in reverse: an empty scan is usually not a dead device. It's a missing pull-up, swapped SDA/SCL, or no power — the 7-step checklist walks those in order of likelihood. If two modules in your pile want the same address, the conflict guide has the fixes.