Light-sensor interface repair
Repair a light-sensor interface so its signal can reach an ESP32 and relay.

Physics Phoebe
Predict which checkpoint will change, then test the connection.
IoT Ideator
Design StudioRepair a light-sensor interface so its signal can reach an ESP32 and relay.
Open the prepared mission; follow the guide and live checkpoints.
Open this design in the Design Studio (new tab)Steps
Step 1
- Do
- In the Site canvas, select the light sensor and inspect its I2C connection to the ESP32.
- You will see
- The prepared connection shows an I2C distance warning because it exceeds the model’s 1 m limit.
- Why it matters
- The chapter treats I2C as a shared link for nearby parts. Cable length is one piece of evidence when a bus fails.

Step 1 · IoT Ideator; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 2
- Do
- In the Site canvas, drag the light sensor toward ESP32 until Physical placement shows a cable length below 1 m.
- You will see
- Physical placement reports less than 1 m, and the I2C distance warning clears.
- Why it matters
- Moving one part isolates the length condition. The chapter also checks pull-ups, clock speed, and signal integrity before declaring a bus usable.

Step 2 · IoT Ideator; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 3
- Do
- In the Communication panel, add Bidirectional Logic-Level Shifter and place it between ESP32 and the relay on the Site canvas.
- You will see
- The shifter appears with separate low-voltage and high-voltage digital ports.
- Why it matters
- GPIO provides a direct control line. The chapter’s logic-threshold checks explain why that line must meet the receiving input’s electrical limits.

Step 3 · IoT Ideator; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 4
- Do
- In the Site canvas, replace the direct ESP32–relay link with ESP32 GPIO–shifter 3.3 V and shifter 5 V–relay control links.
- You will see
- The controller connects to the shifter’s 3.3 V side, and the relay control connects to its 5 V side.
- Why it matters
- The two sides make the voltage boundary visible in the design. A drawn link still needs the chapter’s electrical checks on real hardware.

Step 4 · IoT Ideator; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 5
- Do
- In the Scenarios panel, read the connected-shifter, complete-control-path, and valid-link checkpoints.
- You will see
- All three checkpoints pass for the sensor–controller–relay route. They do not report a measured light threshold.
- Why it matters
- A complete path establishes which parts can exchange the modelled signals. The chapter also records raw data, units, timing, and error state to support interpretation.

Step 5 · IoT Ideator; numbered callout added to a real capture. Enlarge screenshot (new tab) Step 6
- Do
- In a browser tab, open the linked chapter knowledge check and answer the address-conflict and bus-selection questions.
- You will see
- The questions test I2C addresses and interface choices separately from the model’s cable and voltage checks.
- Why it matters
- I2C uses addresses to distinguish parts sharing its lines. Fixing cable length or logic levels does not assign different addresses to conflicting devices.

Step 6 · IoT Ideator; numbered callout added to a real capture. Enlarge screenshot (new tab)
Chapter checks
These questions refer to the chapter’s examples. Use the return links to review their answers.
An ESP32 has three I2C sensors: BMP280 (0x76), BH1750 (0x23), and SHT31 (0x44). After adding a second BMP280 for redundancy, both pressure readings return identical values. What is the most likely cause?
Return to the chapter’s knowledge checkYou need to read data from an SD card at 2 MB/s and also connect a BME280 environmental sensor. Which protocol combination is most appropriate?
Return to the chapter’s knowledge check
Return to Protocol Diagnostics and Bus Design · Browse Tutorials