Soil-sensing path with reserve power

Connect reserve power while preserving the soil sensor path through a gateway to the cloud.

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 Working View canvas, select Soil Moisture Sensor and inspect its analogue output and supply requirements.
    You will see
    Input: Selected Soil Moisture Sensor (Capacitive v1.2) in Working View. Observed: The catalogue shows an analogue output linked to ESP32 at 0.750 m. Expected: A capacitive probe needs a compatible controller input and supply. Interpretation: No real soil-moisture reading or calibration is shown.
    Why it matters
    Evidence: The component and 0.750 m link are Ideator design-model values. Boundary: Catalogue output type is not a field moisture measurement. Reason: Soil and installation conditions affect raw probe readings. Next check: Trace the controller path toward the cloud service.

  2. Step 2

    Do
    In the Working View canvas, select ESP32 and inspect its BLE connection to Protocol Translation Gateway.
    You will see
    Input: Selected ESP32 DevKit V1 and traced its BLE edge to Protocol Translation Gateway. Observed: Physical placement lists the gateway link at 10.000 m. Expected: The soil path should continue through an edge gateway to ThingsBoard. Interpretation: The prepared design has that modelled service route.
    Why it matters
    Evidence: The canvas labels the ESP32-to-gateway link BLE. Boundary: The route does not establish radio reliability or soil accuracy in a field. Reason: A decision depends on both data quality and the path carrying it. Next check: Add the missing reserve power component.

  3. Step 3

    Do
    In the Power panel, add Li-Po Battery to the canvas.
    You will see
    Input: Added Li-Po Battery (3.7V, 2000mAh) from Power to the canvas. Observed: The battery is a separate node; Connect the Li-Po reserve remains Not met yet. Expected: The reserve checkpoint requires a power link to ESP32. Interpretation: Merely adding the battery does not power the modelled controller.
    Why it matters
    Evidence: The before-connection mission checkpoint stayed incomplete. Boundary: A named battery is not a verified power path. Reason: The supply must be paired with the controller input. Next check: Link battery power_out to ESP32 power_in.

  4. Step 4

    Do
    In the canvas, link the Li-Po Battery power output to the ESP32 power input.
    You will see
    Input: Connected Li-Po battery power_out to ESP32 power_in as a Power edge. Observed: The app reports a connected 7.4 Wh Li-Po reserve. Expected: The connected-reserve mission checkpoint should turn met. Interpretation: It passes, while regulator choice and field runtime remain untested.
    Why it matters
    Evidence: 7.4 Wh is the catalogue reserve reported by the live app. Boundary: The connection does not simulate measured battery discharge. Reason: Supply voltage, regulator losses, and radio bursts still need tests. Next check: Read route and valid-link checkpoints together.

  5. Step 5

    Do
    In the Scenarios panel, read the connected-reserve, edge-to-cloud-route, and valid-link checkpoints.
    You will see
    Input: Read the three Scenarios checkpoints after connecting the reserve. Observed: Reserve, soil-to-cloud through gateway, and valid telemetry links all pass. Expected: The path should terminate at CoAP-capable ThingsBoard. Interpretation: The greenhouse scenario shows 5 of 5 lab checks met.
    Why it matters
    Evidence: The app names ThingsBoard and the protocol gateway in its route result. Boundary: A passing route is not a calibrated moisture observation. Reason: The full datasheet and installed conditions remain part of the claim. Next check: Use the linked chapter review question on changed conditions.

  6. Step 6

    Do
    In a browser tab, open the linked chapter knowledge check and identify which changed installation condition needs another test.
    You will see
    Input: Opened the linked Datasheet Review Record question and chose answer A. Observed: The browser says Correct when the planned temperature lies outside the accuracy condition. Expected: Record the mismatch, then validate, calibrate, or reject the sensor. Interpretation: A successful bench communication test cannot extend a datasheet accuracy claim.
    Why it matters
    Evidence: The chapter check addresses conditions on the stated accuracy value. Boundary: The quiz does not validate this soil probe in its installation. Reason: A changed enclosure, cable, calibration, or environment reopens review. Next check: Document the exact field condition and retest trigger.

Chapter checks

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

  1. A sensor works in a quick bench demo, but the datasheet says the accuracy claim depends on a narrower temperature condition than the planned installation. What should the practitioner do?

    Return to the chapter’s knowledge check

  2. Why should a datasheet review include retest triggers after the sensor is selected?

    Return to the chapter’s knowledge check

Return to How to Read Sensor Datasheets · Browse Tutorials