This one is about the wire, not the chip. Nothing below changes with the board you picked, which is why the chip and language switches are not on it. They come back on the ESP32 pages this one sits underneath.
I2C on a shared bus
Nothing on an I2C bus can drive a line high — a resistor does that, and every module you plug in brings another one. Too few and the line never arrives in time; too many and no device can pull it down. Both failures appear suddenly, and neither is in your code.
Add modules, lengthen the wire, then unsolder all but one pair. The bus fails in two opposite directions.
The line rises slowly and falls fast
An open-drain output is a switch to ground. Closing it pulls the line to 0 V in nanoseconds. Opening it does nothing at all — the pull-up resistor then has to charge the capacitance of every centimetre of wire and every pin hanging off it, and that takes time.
The I2C spec puts a number on it: the line must climb from 0.3 to 0.7 of the supply in under 1 µs at 100 kHz, or 300 ns in fast mode. Miss it and the clock does not wait — the receiver samples a line still on its way up and reads a 0 that was meant to be a 1.
Rise time is roughly 0.85 × R × C. Both terms are yours to set: R is the
pull-ups in parallel, C is how much wire and how many devices.
More resistors is a stronger pull-up, not a weaker one
Every breakout ships its own pull-up pair, usually 4.7 kΩ or 10 kΩ, sometimes 2.2 kΩ. Plug in five 4.7 kΩ modules and they are all in parallel: 940 Ω. The rise time gets better. What breaks is the other side.
When a chip pulls the line low it has to sink whatever the pull-up pushes. 3.3 V through 940 Ω is 3.5 mA, and an I2C device is only specified to sink 3 mA while staying below 0.4 V. Past that it cannot pull the line low enough to count as a 0.
So "the third module broke everything" is a real bug with the wrong explanation. Nothing weakened. The bus got too strong to pull down, and the module you plugged in last is simply the one that was in your hand. Boards with 2.2 kΩ pairs are already at the limit with two of them; 4.7 kΩ boards get there at five.
The fix is a soldering iron, not a library. Remove the pull-up pair from every module but one — the breakouts mark them, usually as a pair next to the SDA and SCL pins — and keep a single pair on the bus.
The opposite failure
Rely on the chip's internal pull-ups and the bus is around 45 kΩ, ten times too weak. It will work on a breadboard with one sensor and short jumpers, and stop working the day you move the sensor 40 cm away. Internal pull-ups are for buttons. A bus needs a real resistor.
Long wires fail the same way from the other end: capacitance grows with length, and beyond half a metre or so I2C stops being the right answer. That is what UART and RS-485 are for.
What a struggling bus looks like
- Works at 100 kHz, fails at 400 kHz. Rise time. Slow it down and check the resistors.
- Works with two modules, fails with three. Sink current, or an address clash — run the scanner first, because it tells you which.
- Works cold, fails warm, or works only when you touch the wires. Marginal rise time. You are living inside the tolerance.
- One device disappears from the scan when another is plugged in. Almost always two devices at one address.
The short version
One pull-up pair per bus, 4.7 kΩ, wires under 30 cm, and run the scanner after every wiring change. That covers essentially every I2C project you will build, and the graph above tells you which way you left the window when it does not.
Three pages of protocol, now with the ESP32's own driver, its pins and the scanner sketch that finds what you wired.
I2C →Edit this page — content/esp32/i2c-on-a-shared-bus.mdx
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.