Light-sensor interface repair

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

Physics Phoebe, your practice guide

Physics Phoebe
Predict which checkpoint will change, then test the connection.

IoT Ideator

Design Studio

Simulation — built in · No account

Version tested: 36435f99ff6788e8acd2e3d1fb9309cd97b4f2e4. Date: 2026-09-05.

Open the prepared mission; follow the guide and live checkpoints.

Open this design in the Design Studio (new tab)

Steps

Screens captured against IoT Ideator 36435f99ff6788e8acd2e3d1fb9309cd97b4f2e4 on 2026-09-05; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    In the Site canvas, select the light sensor and inspect its I2C connection to the ESP32.
    You will see
    Input: Selected Light Sensor (BH1750) in Site view. Observed: Physical placement shows a configured 1.5 m I²C cable to ESP32. Expected: The mission’s I²C teaching maximum is 1 m. Interpretation: The prepared link is 0.5 m over that limit and warns Over max length.
    Why it matters
    Evidence: The value is the Ideator cable field and model warning. Boundary: A drawn I²C line does not establish usable bus signalling. Reason: Shared-bus wiring has length and electrical conditions. Next check: Move the sensor closer while leaving the other parts in place.

  2. 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
    Input: Dragged the light sensor toward ESP32 on the Site canvas. Observed: Physical placement changed the cable field from 1.5 m to 0.65 m. Expected: The model requires less than 1 m for this I²C link. Interpretation: The distance warning clears with 0.35 m of model margin.
    Why it matters
    Evidence: Only the sensor placement changed for this before-and-after check. Boundary: The app has not measured bus rise time, pull-ups, or address conflicts. Reason: A shorter cable removes one stated source of failure. Next check: Inspect the relay voltage boundary separately.

  3. 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
    Input: Added Bidirectional Logic-Level Shifter (3.3V / 5V) from Communication in Site view. Observed: The selected component shows separate low_gpio and high_gpio ports. Expected: The controller and 5 V relay need distinct sides of the shifter. Interpretation: The new part names the voltage boundary before reconnection.
    Why it matters
    Evidence: The catalogue describes a 3.3 V controller-to-5 V logic interface. Boundary: Adding a component alone does not complete the control path. Reason: A direct ESP32-to-relay link had incompatible logic levels. Next check: Connect GPIO through the low and high ports, then read the verdict.

  4. 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
    Input: Replaced the direct relay edge with ESP32 gpio to low_gpio and high_gpio to relay control. Observed: Ideator accepts the first link at 3 V and 2.100 m, and the second at 5 V and 1.031 m. Expected: The low side faces ESP32 and the high side faces the 5 V relay input. Interpretation: The connected-shifter and control-path checks now pass.
    Why it matters
    Evidence: The app labels the replacement edges Data/GPIO and Control/GPIO. Boundary: Its accepted voltage pairing is a catalogue design result. Reason: The shifter makes the 3.3 V-to-5 V boundary explicit in the path. Next check: Verify the model’s remaining physical-link check.

  5. Step 5

    Do
    In the Scenarios panel, read the connected-shifter, complete-control-path, and valid-link checkpoints.
    You will see
    Input: Read all three Scenarios checkpoints after the shifter repair. Observed: Connected shifter, sensor-to-actuator path, and physically valid links all pass. Expected: BH1750 reaches the relay through ESP32 and the shifter. Interpretation: The associated breadboard scenario shows 5 of 5 lab checks met.
    Why it matters
    Evidence: The app says I²C is short enough and digital levels overlap. Boundary: No measured light threshold or real GPIO waveform is reported. Reason: Topology and voltage compatibility are only part of interface validation. Next check: Answer the chapter’s address and bus-selection questions.

  6. 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
    Input: Opened the linked Protocol Diagnostics check and answered the first two questions. Observed: Answer D identifies duplicate BMP280 address 0x76; the page marks it Correct. Observed: Answer C selects SPI for SD card and I²C for BME280; the page marks it Correct. Interpretation: Cable repair and address selection are distinct I²C checks.
    Why it matters
    Evidence: Both answers were submitted in the real chapter browser page. Boundary: The quiz does not probe this BH1750 on physical hardware. Reason: Duplicate bus addresses can corrupt readings even with a short cable. Next check: Inspect pull-ups, timing, and device address assignments in a build.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. 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 check

  2. An SD card must transfer at 2 MB/s. A BME280 also needs a connection, and GPIO pins are limited. Which protocol combination meets the throughput while keeping the sensor connection pin-efficient?

    Return to the chapter’s knowledge check

Return to Protocol Diagnostics and Bus Design · Browse Tutorials