i2c address conflicts
Two chips answering the same address is the most common way an i2c project stalls. Four fixes, cheapest first.
Fix 1 · free
Use the address-select pins
Many boards expose an address pin or solder jumper — bridge it and the device moves to an alternate address, no code changes beyond the constructor argument. If you're still choosing hardware, prefer parts with selectable addresses whenever you might want two.
From our dataset
Boards with selectable addresses
Fix 2 · free, sometimes
Reassign the address in software
A minority of parts accept a new address over the bus itself. The classic is the VL53L0X: every unit boots at 0x29, but each has an XSHUT (shutdown) pin — hold all but one in reset, give the live one a new address, then bring up the next. Costs one GPIO per extra sensor and a few lines of startup code, and the address lives in RAM so the sequence must re-run at every boot. The VL53L0X tutorial walks the whole trick with code. Check your part's datasheet before counting on this; most sensors can't do it.
Fix 3 · ~$7, scales to 8
i2c multiplexer (TCA9548A)
The general-purpose answer. The TCA9548A sits at 0x70–0x77 and fans out to eight isolated downstream channels; you select a channel, then talk to whatever lives there. Eight identical sensors keep identical addresses, each on its own channel — and since each channel is electrically separate, it also resets the combined pull-up load on big chains. Its own address is selectable, so multiplexers even stack.
One trap worth knowing before you reach for a multiplexer: the 0x70–0x77 block isn't as free as it looks. Every PCA9685 servo driver answers 0x70 from power-up via its LED All Call address, whatever its own address is set to — so a mux and a servo driver fight by default. The real-world collision roundup covers that and the other pairings that actually bite.
Fix 4 · free pins, more code
A second i2c bus
Most microcontrollers have more than one i2c peripheral (an ESP32 has two; a Raspberry Pi can enable extras in the device tree, and RP2040 boards have two). Putting the clashing device on its own bus sidesteps the problem entirely — at the cost of two more pins and a second bus object in code.
Questions
Address conflict FAQ
Can two i2c devices have the same address on one bus?
Not directly — both would answer every transaction at once and the replies collide. You have to separate them: change one device's address (jumper or software), put them behind an i2c multiplexer, or move one to a second bus.
How does the TCA9548A multiplexer fix address conflicts?
It sits on your bus at its own address (0x70–0x77) and exposes eight downstream i2c channels. You tell it which channel to open, then talk to the device there — so eight identical sensors can keep the identical address, each on its own channel. It also level-shifts between the host side and each channel.
Can I change a sensor's i2c address in software?
Some parts support it. The VL53L0X boots at 0x29 but accepts a new address over i2c — hold each extra unit in reset via its XSHUT pin, release them one at a time, and assign each a unique address at startup. Most sensors, though, only offer hardware selection (address pins/jumpers) or nothing at all.
How do I know which addresses are already taken?
Scan the bus: i2cdetect -y 1 on a Raspberry Pi, or the i2c Scanner sketch on Arduino. Compare the results against our i2c address list to identify what's what before you add a new board.