Skip to content

Wire and test access-control indicators

Trace the controller’s two active-low buttons and four indicators, then compare identity recognition with a zone access decision.

Shield Shelly: I want you to trace the button, the identity, and the permission before trusting the green light., your practice guide

Shield Shelly: I want you to trace the button, the identity, and the permission before trusting the green light.
Predict the reading, then compare it with the measurement.

Wokwi ESP32

Third party Tool

Tier 1 · Web · No account

Version tested: Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-09. Date: 2026-09-09.

Open the ESP32 editor, paste diagram.json, then paste sketch.ino.

Open Wokwi to paste in the files (new tab)

Get the files

Use both prepared files. This is a paste-in setup; saving a project requires a Wokwi account.

diagram.json

3,375 bytes · Circuit connections

Download

sketch.ino

13,675 bytes · ESP32 program

Download

  1. Use the launch button above to open the ESP32 editor in Wokwi.
  2. Select the editor’s diagram.json tab and replace all its text with the supplied diagram.json.
  3. Select the sketch.ino tab, replace all its text with the supplied sketch.ino, then click Start Simulation.

Steps

Screens captured against Wokwi ESP32 Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-09 on 2026-09-09; the tool may have moved on — the text steps are the contract.

  1. 1 Step 1

    Do
    In Wokwi's project editor, paste the supplied diagram.json and sketch.ino into a new Wokwi ESP32 project. Trace each LED back to its GPIO and ground.
    You will see
    Input: inspect the running Wokwi diagram and its four LED paths. Green, red, yellow, and blue LEDs are visible above the ESP32. Each LED has a series 220 Ω resistor on the shared ground return. The sketch's GPIO 2, 4, 5, and 18 leads run to those indicators.
    Why it matters
    The four colours make controller outcomes observable in the model. The resistor limits simulated LED current in each path. The live Serial Monitor shows the access-control startup heading. A lit indicator can be compared with a later access decision.
    Step 1: Four coloured LED paths connect to the ESP32 through resistors. The ring marks the green, red, yellow, and blue LEDs and their 220 ohm resistors.
    Step 1 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  2. 2 Step 2

    Do
    On the Wokwi circuit canvas, trace the two pushbuttons and buzzer before starting.
    You will see
    Buzzer pin 2 connects to ESP32 GPIO19; pin 1 returns to ground (diagram.json lines 201, 207). Select-card button connects ESP32 GPIO15 to ground when pressed (diagram.json lines 213, 219). Request-access button connects ESP32 RX2/GPIO16 to ground when pressed (diagram.json lines 225, 231). The two buttons use separate input paths (diagram.json lines 213, 225).
    Why it matters
    The two grounded buttons make card selection and access requests separate later actions. The buzzer has its own GPIO19 output and ground return, so an audible decision can be checked independently of the four LEDs.
    Step 2: Select card and Request access buttons and the buzzer are wired to the ESP32. The ring marks the buzzer and both labelled buttons.
    Step 2 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  3. 3 Step 3

    Do
    Start the simulation. Send STATUS in Serial Monitor at 115200 baud.
    You will see
    Input: send STATUS in the real Wokwi Serial Monitor. Startup heading: IoT ACCESS CONTROL SYSTEM v1.0. STATUS response: Locked: NO | Fails: 0 | Card: RFID_ADMIN_001. The circuit and this response appear together in the new capture.
    Why it matters
    The run begins unlocked with zero failures. The selected fictional card is RFID_ADMIN_001. STATUS identifies the current actor before a zone decision. The response is simulator output, not a real credential check.
    Step 3: Locked: NO | Fails: 0 | Card: RFID_ADMIN_001 appears below the startup heading. The ring marks the STATUS response.
    Step 3 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  4. 4 Step 4

    Do
    On the Wokwi circuit canvas, briefly click Request access and release it.
    You will see
    ACCESS GRANTED: Alice Admin -> Server Room appears, with green and blue LED feedback.
    Why it matters
    The initial admin identity has the required role. Seeing a grant tests the complete input-to-output path, not just a successful lookup.
    Step 4: ACCESS GRANTED: Alice Admin - width= Server Room appears after clicking Request access. The ring marks the grant message." loading="lazy">
    Step 4 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  5. 5 Step 5

    Do
    On the Wokwi circuit canvas, briefly click Select card once and release it; wait for Card selected: RFID_USER_001, then click Request access.
    You will see
    The selected card is recognized, but ACCESS DENIED: Charlie User has USER, needs ADMIN appears and the red LED flashes.
    Why it matters
    This is the host’s central distinction: authenticating Charlie does not authorize Charlie for every door.
    Step 5: ACCESS DENIED: Charlie User has USER, needs ADMIN appears after selecting the user card and requesting access. The ring marks the authorization denial.
    Step 5 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  6. 6 Step 6

    Do
    Send ZONE 1 in Serial Monitor while the user card is selected.
    You will see
    Input: select the user card, then send ZONE 1 in Serial Monitor. The request names RFID_USER_001 and Office Area. Serial Monitor: Office Area requires USER access. Result: ACCESS GRANTED: Charlie User -> Office Area.
    Why it matters
    The selected user card meets this zone's USER requirement. The green grant indicator is lit in the capture. The decision is scoped to Office Area, not every zone. The real browser run distinguishes card selection from authorization.
    Step 6: ACCESS GRANTED: Charlie User - width= Office Area appears. The ring marks the grant for the same identity in a different zone." loading="lazy">
    Step 6 · Wokwi ESP32; numbered callout added to a real capture. Enlarge screenshot (new tab)
  7. 7 Step 7

    Do
    In Wokwi's Serial Monitor, send LOG, inspect the grant and denial entries, then stop and restart the simulation and send LOG again.
    You will see
    The first log contains ACCESS_GRANTED and ACCESS_DENIED_AUTHZ rows. After restart only the SECURITY AUDIT LOG heading appears because the in-memory entries were cleared.
    Why it matters
    Evidence must survive the event it explains. This setup uses replayable fictional card strings and volatile logs; it does not implement the host’s fresh-nonce challenge-response protocol.
    Step 7: After restart the SECURITY AUDIT LOG heading has no entries below it; the earlier grant and denial rows were cleared. The ring marks the empty restarted audit log heading.
    Step 7 · Wokwi ESP32; 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.

  1. A smart-building controller correctly verifies every user's certificate, but once verified, every user can unlock every door and reconfigure the HVAC. Which control is missing?

    Return to the chapter’s knowledge check
  2. A challenge-response scheme uses HMAC over a strong 256-bit per-device key, but the verifier reuses the same challenge nonce for every device every hour. Why is this insecure despite the long key?

    Return to the chapter’s knowledge check

Caution

This setup combines the chapter’s definitions with runtime functions from its linked implementation companion. Keep the 220 Ω resistors and common ground. Briefly click and release buttons: holding Select repeats card selection after 250 ms. All cards are fictional, replayable teaching identifiers; do not use this firmware for a real lock. The comparison is not a vetted constant-time primitive, logs disappear on reset, and the source menu’s USERS and ZONES commands are not implemented.

Return to Authentication and Authorization · Browse Labs