First, run the scan properly
If you haven't already, install the tools:
sudo apt install i2c-toolsI2C also has to be switched on in the operating system. Run sudo raspi-config, then Interface Options → I2C → Enable, and reboot. This is switched off by default, and it's far and away the most common reason a correctly-wired device shows nothing.
Then scan:
i2cdetect -y 1The 1 is the bus number — bus 1 is the one on the standard 40-pin header. You shouldn't need sudo on a current Raspberry Pi OS.
A working scan looks something like this, with 77 being the detected device's address:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
...
70: -- -- -- -- -- -- -- 77All dashes means nothing answered. Work down this list.
1. Is it actually powered and grounded?
Obvious, and still the second most common cause. An I2C device needs four connections, not two: VCC, GND, SDA, SCL. A device with data lines connected but no ground shares no voltage reference with the Pi, and simply cannot communicate — it isn't broken, it's deaf.
Measure the module's VCC pin against the Pi's ground with a multimeter. You want to see 3.3V (or 5V, if it's a 5V-tolerant module). Reading 0V means your power wiring is the problem and nothing else on this list matters yet.
2. Are SDA and SCL the right way round?
Swapping the two data lines is easy and produces exactly this symptom. On the Pi's 40-pin header:
- SDA → physical pin 3 (GPIO 2)
- SCL → physical pin 5 (GPIO 3)
They are not interchangeable. If you're not sure which is which on your board, PinTinker will lay out the assignments for you.
3. Voltage mismatch
The Pi's I2C lines run at 3.3V. Most I2C breakout boards are 3.3V-native or have on-board regulation and level shifting, but not all — some cheaper modules are 5V parts on a bare breakout.
A 5V I2C device may not recognise the Pi's 3.3V signals as valid highs, so it never responds. It can also push 5V back onto the Pi's pins, which is the more expensive failure. If your module is 5V, that needs sorting properly — see connecting a 5V sensor to a 3.3V board.
4. Two devices fighting over one address
This one's sneaky, because it only appears once you add a second device. Every device on an I2C bus needs a unique address. Two modules of the same type usually ship with the same default address, and when both respond at once you typically get one of them appearing, neither appearing, or intermittent nonsense.
The fix is on the board itself: most breakouts have a solder jumper or a pad marked something like ADDR that shifts the device to an alternate address. Check the module's documentation for which address it moves to.
5. Pull-up resistors
I2C needs pull-up resistors on both data lines to work. The good news for Pi users: the Raspberry Pi has pull-ups built in on the SDA and SCL header pins, and most breakout boards include their own as well. So on a typical hobby setup this is rarely your problem.
Where it does start to matter is when you have several modules on one bus (each adding its own pull-ups in parallel, lowering the effective resistance) or unusually long wires. If you're running more than a few devices, or wires longer than about 30cm, and the bus is flaky rather than silent, this is worth investigating.
6. The wires themselves
Cheap jumper wires fail internally while looking perfectly fine from the outside — the conductor breaks inside the insulation, usually right at the connector. Test each wire for continuity with a multimeter rather than trusting it. This is covered in more depth in the breadboard troubleshooting guide, because the same fault causes an enormous share of "it worked yesterday" problems.
7. The module is faulty or counterfeit
Last on the list deliberately, because it's where people jump to first and it's rarely the answer. If you've genuinely confirmed power, ground, correct pins, correct voltage and no address clash, then yes — try the module on a different board, or try a different module. Budget marketplace modules do arrive dead often enough to matter.
The short version
- Is I2C enabled in
raspi-config? - Is the module actually getting 3.3V, and is ground connected?
- Are SDA and SCL on pins 3 and 5, the right way round?
- Is it a 5V module on a 3.3V bus?
- Unplug everything else — does it appear alone? (address clash)
- Continuity-test the jumper wires.
- Only then suspect the module.
Seven checks, in that order, and you'll find it. Working from cheapest to most expensive is the whole trick — it's how you avoid replacing a perfectly good sensor because a jumper wire had a broken conductor.
Gear that helps
A basic multimeter is what makes steps 1 and 6 take thirty seconds instead of an evening — see the bench buying guide for what else earns its place.