WiFi Door Sensor

J

jharwinbarrozo

Explain this project to me in details (how it works etc)

flux

I’ll inspect the schematic, connectivity, and component values, then create a detailed project walkthrough covering power, sensing, ESP32 behavior, indicators, programming, and expected operating sequence.

flux

I reviewed the current schematic and confirmed the detailed explanation is already documented in WiFi Door and Window Sensor — Project Explanation.
In short: a single AA battery passes through PMOS reverse-polarity protection and a TPS613221A boost converter to produce 3.3 V. The ESP32-C3 monitors a magnet-operated reed switch, wakes when the door/window changes state, reports the event over WiFi or BLE, briefly uses the RGB LED for status, then returns to deep sleep. The project file includes the complete power path, GPIO mapping, reed-filter circuit, programming process, PCB implementation, firmware sequence, trade-offs, and current design risks.
Review power reliability
Fix stale battery note
Run full design review
Create bring-up plan
Optimize firmware power
Sign up to send

Files

Schematic

Layout

3D View

WiFi vs BLE Runtime Comparison — AA + TPS613221A + ESP32-C3-MINI-1-N4
Summary
This compares the ESP32-C3-MINI-1-N4 door/window sensor battery life when reporting events over WiFi versus Bluetooth LE to a BLE hub.
Bottom line: BLE can be dramatically better, but only if the BLE report event is short. If BLE stays active for the same full 2 seconds as WiFi, the benefit is smaller but still meaningful at low-to-mid BLE TX power.
For a practical 2000 mAh AA, 10 open/close cycles/day, LED off:

Table

ModeRuntime range
WiFi, 2 s eventabout 154-199 days
BLE conservative, 2 s eventabout 297-546 days
BLE optimized, 0.2 s eventabout 1453-2191 days
The BLE optimized case is about 7.9x to 11.0x better than WiFi at 10 cycles/day, depending on TX level and whether R2 is conducting.
Datasheet currents used
WiFi TX currents
From the ESP32-C3-MINI-1-N4 datasheet WiFi table:

Table

WiFi scenarioDatasheet conditionCurrent used
WiFi low802.11n HT20 MCS7 @ 17.5 dBm290 mA
WiFi mid802.11g 54 Mbps @ 18 dBm295 mA
WiFi high802.11b 1 Mbps @ 20.5 dBm350 mA
BLE TX currents
From the ESP32-C3-MINI-1-N4 datasheet Bluetooth LE table:

Table

BLE scenarioDatasheet conditionCurrent used
BLE lowBluetooth LE @ -15 dBm100 mA
BLE midBluetooth LE @ 0 dBm170 mA
BLE highBluetooth LE @ 9 dBm190 mA
BLE max noteBluetooth LE @ 20 dBm340 mA
BLE RXBluetooth LE RX86 mA
The main comparison tables use BLE low/mid/high = -15 / 0 / 9 dBm. The 20 dBm case is included as a worst-case note because it approaches WiFi current.
Sleep and boost converter assumptions

Table

ParameterValue
ESP32-C3 deep sleep5 µA typ
TPS613221A quiescent current into VOUT6.5 µA typ
Base sleep current at 3.3 V11.5 µA
R2 reed pull-up1 MΩ
R2 conducting current3.3 µA
AA capacities shown1500 / 2000 / 2500 mAh
Runtime conversion voltage1.5 V nominal AA
Boost output3.3 V
LEDOff in normal operation
Event assumptions

Table

ModeEvent time assumptionWhy
WiFi2.0 s per open/close reportMatches previous WiFi report assumption.
BLE conservative2.0 s per open/close reportApples-to-apples with WiFi active duration.
BLE optimized0.2 s per open/close reportMore realistic for a local BLE hub if advertising/connection/notification is optimized.
One open/close cycle is two reports: one open event and one close event.
Practical comparison: 2000 mAh AA, 10 cycles/day
This is the most realistic daily-use case.

Table

ModeSleep caseTX currentEvent timeActive mAh/daySleep mAh/dayTotal mAh/dayRuntime @ 2000 mAh
WiFi lowbase sleep290 mA2.0 s9.4520.60710.059199 d / 0.54 y
WiFi lowwith R2290 mA2.0 s9.4520.78110.233195 d / 0.54 y
WiFi midbase sleep295 mA2.0 s9.6150.60710.222196 d / 0.54 y
WiFi midwith R2295 mA2.0 s9.6150.78110.396192 d / 0.53 y
WiFi highbase sleep350 mA2.0 s12.2220.60712.829156 d / 0.43 y
WiFi highwith R2350 mA2.0 s12.2220.78113.003154 d / 0.42 y
BLE conservative -15 dBmbase sleep100 mA2.0 s3.0560.6073.662546 d / 1.50 y
BLE conservative -15 dBmwith R2100 mA2.0 s3.0560.7813.837521 d / 1.43 y
BLE conservative 0 dBmbase sleep170 mA2.0 s5.3280.6075.935337 d / 0.92 y
BLE conservative 0 dBmwith R2170 mA2.0 s5.3280.7816.109327 d / 0.90 y
BLE conservative 9 dBmbase sleep190 mA2.0 s5.9540.6076.561305 d / 0.84 y
BLE conservative 9 dBmwith R2190 mA2.0 s5.9540.7816.735297 d / 0.81 y
BLE conservative 20 dBm maxbase sleep340 mA2.0 s11.8730.60712.480160 d / 0.44 y
BLE conservative 20 dBm maxwith R2340 mA2.0 s11.8730.78112.654158 d / 0.43 y
BLE optimized -15 dBmbase sleep100 mA0.2 s0.3060.6070.9132191 d / 6.00 y
BLE optimized -15 dBmwith R2100 mA0.2 s0.3060.7811.0871840 d / 5.04 y
BLE optimized 0 dBmbase sleep170 mA0.2 s0.5330.6071.1401754 d / 4.81 y
BLE optimized 0 dBmwith R2170 mA0.2 s0.5330.7811.3141522 d / 4.17 y
BLE optimized 9 dBmbase sleep190 mA0.2 s0.5950.6071.2031663 d / 4.56 y
BLE optimized 9 dBmwith R2190 mA0.2 s0.5950.7811.3771453 d / 3.98 y
BLE optimized 20 dBm maxbase sleep340 mA0.2 s1.1870.6071.7941115 d / 3.05 y
BLE optimized 20 dBm maxwith R2340 mA0.2 s1.1870.7811.9691016 d / 2.78 y
BLE optimized improvement factor vs WiFi, 10 cycles/day

Table

LevelSleep caseWiFi mAh/dayBLE optimized mAh/dayImprovement factor
Low: WiFi low vs BLE -15 dBmbase sleep10.0590.91311.02x
Low: WiFi low vs BLE -15 dBmwith R210.2331.0879.41x
Mid: WiFi mid vs BLE 0 dBmbase sleep10.2221.1408.97x
Mid: WiFi mid vs BLE 0 dBmwith R210.3961.3147.91x
High: WiFi high vs BLE 9 dBmbase sleep12.8291.20310.67x
High: WiFi high vs BLE 9 dBmwith R213.0031.3779.44x
BLE optimized improvement range vs WiFi at 10 cycles/day: 7.9x to 11.0x.
Runtime ranges across all AA capacities
These ranges include 1500 / 2000 / 2500 mAh AA capacities and low/mid/high TX levels. BLE 20 dBm max is excluded from the range and treated as a worst-case note.

Table

Cycles/daySleep caseCaseRuntime range
2base sleepWiFi 2 s low-mid-high492-1001 d / 1.35-2.74 y
2base sleepBLE conservative 2 s -15/0/9 dBm834-2052 d / 2.29-5.62 y
2base sleepBLE optimized 0.2 s -15/0/9 dBm2065-3741 d / 5.66-10.25 y
2with R2WiFi 2 s low-mid-high465-936 d / 1.27-2.56 y
2with R2BLE conservative 2 s -15/0/9 dBm761-1795 d / 2.08-4.92 y
2with R2BLE optimized 0.2 s -15/0/9 dBm1666-2967 d / 4.56-8.13 y
5base sleepWiFi 2 s low-mid-high223-469 d / 0.61-1.28 y
5base sleepBLE conservative 2 s -15/0/9 dBm418-1171 d / 1.15-3.21 y
5base sleepBLE optimized 0.2 s -15/0/9 dBm1658-3290 d / 4.54-9.01 y
5with R2WiFi 2 s low-mid-high218-454 d / 0.60-1.24 y
5with R2BLE conservative 2 s -15/0/9 dBm399-1083 d / 1.09-2.97 y
5with R2BLE optimized 0.2 s -15/0/9 dBm1390-2676 d / 3.81-7.33 y
10base sleepWiFi 2 s low-mid-high117-249 d / 0.32-0.68 y
10base sleepBLE conservative 2 s -15/0/9 dBm229-683 d / 0.63-1.87 y
10base sleepBLE optimized 0.2 s -15/0/9 dBm1247-2739 d / 3.42-7.50 y
10with R2WiFi 2 s low-mid-high115-244 d / 0.32-0.67 y
10with R2BLE conservative 2 s -15/0/9 dBm223-652 d / 0.61-1.79 y
10with R2BLE optimized 0.2 s -15/0/9 dBm1089-2300 d / 2.98-6.30 y
20base sleepWiFi 2 s low-mid-high60-128 d / 0.16-0.35 y
20base sleepBLE conservative 2 s -15/0/9 dBm120-372 d / 0.33-1.02 y
20base sleepBLE optimized 0.2 s -15/0/9 dBm834-2052 d / 2.29-5.62 y
20with R2WiFi 2 s low-mid-high59-127 d / 0.16-0.35 y
20with R2BLE conservative 2 s -15/0/9 dBm118-363 d / 0.32-0.99 y
20with R2BLE optimized 0.2 s -15/0/9 dBm761-1795 d / 2.08-4.92 y
Interpretation
If BLE event time is still 2 seconds
BLE still improves runtime at -15 dBm, 0 dBm, and 9 dBm because its TX current is lower than WiFi. But if you run BLE at 20 dBm for the same 2 seconds, the result is close to WiFi high TX because BLE 20 dBm current is 340 mA.
If BLE hub enables short local reporting
This is where BLE becomes very attractive. If the device can wake, advertise or connect, notify the hub, and return to deep sleep in about 0.2 s, then event energy becomes much smaller and sleep current becomes the main lifetime limiter.
For 10 cycles/day and a practical 2000 mAh AA:
  • WiFi: about 154-199 days
  • BLE optimized: about 1453-2191 days
This is a practical improvement of roughly 4 to 6 years versus 5 to 7 months, assuming the hub is close enough for low-to-mid BLE TX power.
Hardware implications
  1. ESP32-C3-MINI-1-N4 is appropriate for BLE hub mode. It supports WiFi and BLE, so the same hardware can support both firmware strategies.
  2. Keep the antenna placement strict. BLE range and packet success directly affect event duration. Poor antenna layout can erase BLE savings through retries.
  3. Keep R2 at 1 MΩ if reliable. With BLE optimized, sleep current matters again; R2 conducting adds 3.3 µA, which is no longer negligible over multi-year targets.
  4. Use low BLE TX power only after range validation. Start with 0 dBm or 9 dBm for margin, then reduce toward -15 dBm if the hub is nearby and packet reliability remains high.
  5. Avoid maintaining a continuous BLE connection if possible. Event-driven advertising/notification followed by deep sleep is the power-saving path.
  6. Battery self-discharge and real-world aging become important. Multi-year runtime estimates may exceed the practical shelf/use life of some alkaline cells under pulse load.
Recommendation
If you can use a local BLE hub, BLE event reporting is strongly preferred over WiFi for this door/window sensor. Design the firmware around:
  1. Deep sleep by default.
  2. Reed/user wake.
  3. Fast BLE advertising or connection to hub.
  4. One small event payload.
  5. Immediate return to deep sleep.
Target 0.2-0.5 s BLE active time. If the firmware can achieve that, BLE should improve battery life by about 8x-11x versus the current 2-second WiFi-event model.

  • Summary

  • Datasheet currents used

  • WiFi TX currents

  • BLE TX currents

  • Sleep and boost converter assumptions

  • Event assumptions

  • Practical comparison: 2000 mAh AA, 10 cycles/day

  • BLE optimized improvement factor vs WiFi, 10 cycles/day

  • Runtime ranges across all AA capacities

  • Interpretation

  • If BLE event time is still 2 seconds

  • If BLE hub enables short local reporting

  • Hardware implications

  • Recommendation