I2C Device Found, but the Display or Sensor Still Does Not Work

Finding an I2C address with a scanner feels like a big success. It proves that the microcontroller can see something on the bus. But it does not always mean the project will work immediately.

A very common situation is this: the I2C scanner finds an address such as 0x3C, 0x27, 0x68 or 0x48, but the display stays blank, the sensor library reports an error, or the readings make no sense.

This is one of the most frustrating I2C troubleshooting cases because the wiring is not completely wrong, but something is still not right. The good news is that the problem is now usually more specific: wrong address in the sketch, wrong library, wrong chip, wrong display controller, wrong initialization, or a module that only partly matches the product description.

Typical Symptoms

The I2C scanner finds a device, but the display stays blank.
The scanner finds address 0x3C, but the OLED only shows random pixels.
The scanner finds address 0x27, but the 1602 LCD only turns on the backlight.
The scanner finds the RTC at 0x68, but the time is wrong or does not update.
The scanner finds the sensor, but the library says “device not found.”
The sensor returns fixed, impossible or random values.
The example sketch works with a different module, but not with this one.

What the I2C Scanner Proves

An I2C scanner proves only one thing: a device answered at an I2C address.

That is useful, but limited. It does not prove:

That the module contains the chip you think it contains.
That the selected library supports the chip.
That the display controller is correct.
That the module is initialized correctly.
That the sensor is reading valid data.
That the module is wired safely for the voltage you are using.

The scanner is the first step, not the final diagnosis.

Common Cause: The Sketch Uses the Wrong Address

Many example sketches contain a fixed I2C address. If your module uses a different address, the scanner may find the module, but the library still talks to the wrong address.

Common examples:

OLED display: often 0x3C or 0x3D.
1602 / 2004 LCD backpack: often 0x27 or 0x3F.
ADS1115 ADC: often 0x48, but address can be changed.
BMP280 / BME280: often 0x76 or 0x77.
DS3231 RTC: usually 0x68.

If your scanner reports 0x3C, but the example code uses 0x3D, the display will not respond to the sketch even though the scanner sees it.

Common Cause: The Module Has a Different Chip Than Expected

Many small modules look almost identical from the outside, but use different ICs. This is especially common with low-cost display and sensor modules.

Examples:

An OLED module may use SSD1306, SH1106, SSD1315 or another compatible-looking controller.
A pressure sensor module may be sold as BMP280 but actually contain BME280, or the other way around.
A temperature/humidity module may use SHT30, AHT20, HTU21D or a clone chip.
An RTC module may contain DS1307, DS3231 or a compatible clone.
An LCD backpack may use PCF8574, PCF8574A or another I2C expander.

The I2C address alone cannot identify the exact chip. Two different chips can share the same address, and some compatible chips are not truly software-compatible.

Common Cause: Wrong Library

If the hardware is seen by the scanner, but the example sketch does not work, the library is one of the next things to check.

Common library problems include:

The library is written for a different chip.
The library supports only one display controller variant.
The library expects a different screen size.
The library uses a different I2C address by default.
Several libraries with similar names are installed, and the wrong one is being used.
An old library is incompatible with the current board package.

This is why copying a random example sketch from the internet can be risky. The code may be correct for the author’s module, but not for yours.

OLED Example: SSD1306 vs SH1106

A classic example is a 128x64 I2C OLED display.

The scanner may find address 0x3C. Many tutorials then use an SSD1306 library. But some 1.3 inch OLED modules use an SH1106 controller instead of SSD1306.

The result can be:

Blank display.
Image shifted sideways.
Random pixels.
Only part of the image visible.
Text appears corrupted or cut off.

The fix is not changing the I2C address. The fix is using a library and constructor that match the actual display controller.

LCD Example: Backlight Works but No Text Appears

With 1602 or 2004 character LCD modules, the backlight can work even when the LCD is not initialized correctly.

This can happen because the backlight is controlled separately from the LCD data lines.

Typical causes are:

Wrong I2C address.
Wrong LCD library.
Wrong backpack pin mapping.
Contrast potentiometer not adjusted.
Incorrect display size in the sketch.

If the backlight turns on, that only proves the module has power and the backlight circuit works. It does not prove the LCD controller is receiving correct data.

Sensor Example: Device Found but Readings Are Wrong

Sensors can be even more confusing because the scanner may find the chip and the library may even start, but the readings may still be wrong.

Possible causes include:

The wrong sensor type was selected in the code.
The sensor needs calibration.
The sensor is affected by heat from the board.
The sensor is powered from the wrong voltage.
The library reads a different register map than the chip actually uses.
The sensor is mounted in a place where it cannot measure correctly.

For example, a temperature sensor mounted directly above a voltage regulator may read higher than room temperature. That is not an I2C problem. The sensor may simply be measuring heat from the board.

Check the Address in the Code

After running the I2C scanner, compare the found address with the address used in your sketch.

// Example:
#define OLED_ADDRESS 0x3C

or:

display.begin(SSD1306_SWITCHCAPVCC, 0x3C);

If the scanner finds 0x3D, but the code uses 0x3C, change the code to match the scanner result.

Check the Display Size

Many display libraries require the correct resolution or character size.

OLEDs may be 128x64, 128x32, 96x16 or another size.
Character LCDs may be 16x2, 20x4, 16x4 or 8x2.
TFT and graphic LCD displays require the correct controller and pixel resolution.

If the display size is wrong, the display may remain blank, show only part of the output, or write text to unexpected positions.

Check the Constructor

Many libraries use different constructors for different hardware.

For example, with graphic display libraries, the constructor may define:

The display controller.
The screen size.
The I2C address.
The reset pin.
The rotation or memory layout.

If the constructor does not match your module, the sketch may compile perfectly and still show nothing useful.

Check for Multiple Installed Libraries

The Arduino IDE can contain several libraries with similar names. Sometimes the wrong library is selected automatically during compilation.

If you see a compiler message like “Multiple libraries were found for...” check which library is actually being used.

This can cause confusing situations where:

An example sketch comes from one library, but another library is used.
A newer library and an older library conflict.
A library installed manually conflicts with the Library Manager version.

When troubleshooting, remove duplicate or outdated libraries if they are not needed.

Check Whether the Module Needs a Reset Pin

Some displays have a reset pin. Others tie reset to power-on reset. Some libraries require a reset pin definition even when the physical module does not expose one.

Common options include:

Use a real GPIO pin connected to display reset.
Use -1 if the library supports “no reset pin.”
Connect the display reset pin to the microcontroller reset line.
Power-cycle the display if it starts in a bad state.

If reset is handled incorrectly, the display may answer over I2C but never initialize properly.

Check Voltage Compatibility

A device answering on I2C does not automatically mean the voltage levels are safe or reliable.

Many modern microcontrollers use 3.3V logic. This includes ESP32, ESP8266, RP2040, RP2350 and most XIAO-style modules. Many older Arduino boards use 5V logic.

Problems can happen when:

A 5V module pulls SDA and SCL up to 5V.
A 3.3V-only sensor is powered from 5V.
A 5V LCD backpack does not reliably recognize 3.3V logic.
The module has onboard pull-ups to the wrong voltage.

The scanner may still find the device in some cases, but communication can be unreliable or the microcontroller pins can be stressed.

Check Whether the Chip Needs Extra Setup

Some I2C devices do not produce useful data immediately after power-up. They may need configuration before reading.

Examples:

An ADC may need gain and sample rate settings.
A sensor may need measurement mode enabled.
A display needs an initialization sequence before showing pixels.
A real-time clock may need its oscillator enabled.
An I/O expander may need pin direction registers configured.

The scanner only checks for an acknowledge response. It does not configure the device.

Check the Module Documentation, Not Only the Chip Datasheet

The chip datasheet tells you how the IC works, but the module board may add extra parts that change how it behaves.

A module may include:

Voltage regulator.
Level shifters.
Pull-up resistors.
Address jumpers.
Power LED.
Different pin labels.
Extra EEPROM or supporting ICs.

Two modules using the same chip may still require different wiring or different code settings.

Check for Multiple Devices at the Same Address

If the scanner finds one address, but two devices are actually connected at that same address, the result may be confusing.

The scanner may still report the address because at least one device responds. But when the library starts reading and writing registers, both devices may react at the same time.

This can cause:

Wrong sensor readings.
Bus errors.
Display corruption.
Devices that work alone but not together.

Disconnect all other I2C devices and test the questionable module by itself.

Step-by-Step Troubleshooting Method

Run the I2C scanner and write down the detected address.
Check that the sketch uses exactly that address.
Confirm the exact chip or display controller on the module.
Use a library that supports that exact chip.
Use the correct constructor for controller, size and interface.
Test the simplest example included with the library.
Disconnect all other I2C devices.
Check voltage levels and pull-ups.
Try a lower I2C clock speed.
If possible, test the module on another controller board.

Practical Examples

Scanner Result	Module Type	Still Not Working?	Likely Next Check
0x3C	OLED display	Blank or garbage display	SSD1306 vs SH1106 controller, display size, reset pin
0x27	1602 / 2004 LCD backpack	Backlight only, no text	Contrast, backpack pin mapping, LCD constructor
0x68	DS3231 / DS1307 RTC	Wrong time or no ticking	RTC library, oscillator state, backup battery, time setting code
0x48	ADS1115 ADC	Wrong analog values	Gain setting, input range, single-ended vs differential mode
0x76 / 0x77	BMP280 / BME280	Library reports wrong chip	Actual sensor type, library compatibility, address jumper

When the Module May Actually Be Defective

Most problems are wiring, library or configuration issues, but modules can be defective.

A module may be bad if:

It gets unusually hot.
It pulls SDA or SCL permanently low.
It is not detected on any controller board.
It only works when pressure is applied to the PCB or connector.
The same sketch works immediately with another identical module.

Before declaring a module defective, test it with the simplest possible sketch and wiring.

CANABLOX Practical Note

CANABLOX is especially helpful for this type of troubleshooting because it separates the problems into smaller pieces. The standardized I2C wiring makes it easier to tell whether the problem is the module, the address, the library, or the project code.

When using CANABLOX, start with only the controller and the one module you want to test. Run the scanner, confirm the address, then run a simple example for that exact module. Only after that should you add more modules to the system.

Conclusion

If an I2C scanner finds a device but the project still does not work, the basic wiring is probably close enough for communication, but the software may not match the hardware.

Check the detected address, the exact chip, the display controller, the library, the constructor, the voltage level and the presence of other devices on the same bus.

The I2C scanner answers the first question: “Is something there?” The next question is more specific: “Am I talking to the right device in the right way?”

Related Articles