Introduction: Battery Powered Door Sensor With Home Automation Integration, WiFi and ESP-NOW

About: I like to combine electronics like Arduino's, ESP8266 etc with 3D designing and 3D printing.

In this instructable I show you how I made a battery powered door sensor with home automation integration. I have seen some other nice sensors and alarm systems, but I wanted to make one myself.

My goals:

  • A sensor which detects and reports a door opening fast (<5 seconds)
  • A sensor which detects closing of the door
  • A sensor which is battery operated and runs for a few months on a battery

The hardware and software is inspired by

I made a sensor for my frontdoor and my backdoor. The only difference is the led position and the external power switch (on backdoor sensor).

I made several improvements during the development in hardware and software, it can be seen in the photos.

Supplies

I bought the electronic components from Aliexpress, the main parts:

Step 1: Hardware - Circuit

See the attached schemes for the circuit. I soldered the SMD parts on an adapter PCB plate and soldered all components to a double sided perf board. I connected the ESP-01 via female headers, so I could remove it to program it via the adapter shown in step 3 of this Instructable.

The circuit works as follows:

  • When the door is opened, the TPL5111 receives a shot at the DELAY/M_DRV pin and enables the TPS73733 LDO which powers the ESP-01. For this operation, the EN/ONE_SHOT must be pulled low, See the datasheet of the TPL5111.
  • After the program has run (see step Software), the ESP-01 sends a Done signal to the TPL5111 which then disables the TPS73733 resulting in a very low power state for the TPL5111 and the TPS73733.

I use reed switches with both NO and NC connections. I connected the NC lead, since the reed switch must close the circuit when the magnet is removed (door open) and open when the magnet is near (door closed).

For the backdoor sensor I added some condensators and resistors when I discovered some instabilities, however the instablity was caused by the software (esp_now_init) as I discovered later.

Step 2: Hardware - Enclosure

I designed the enclosure in Autodesk Fusion360, inspired by this video by 'the guy with the swiss accent'.

The STL files of the three parts:

  • Box
  • Lid
  • Magnet holder

are published on my Thingiverse page.

Step 3: Software

The program is in my Github.

The flow of the program is shown in the picture. See my other Instructable for the explaination of how I use ESP-NOW.

When the module is powered on, it firstl tries to send the 'OPEN' message via ESP-NOW. If this does not succeed, it swithes to a WiFi and MQTT connection.

I found out that, at least in my setup, the 'CLOSED' message was not send succesfully via ESP-NOW, so I removed this from the program and only use WiFi and MQTT.

During the time the door is opened and the module is waiting for the door to close, it uses this time to connect to WiFi and MQTT, so when the door is closed, it only has to send the measured voltage and a CLOSED message and then it directly goes to sleep.

The program checks whether the closed message is received by the receiver via a listening to a MQTT message on the right topic.

Step 4: Home Automation and Telegram

My door sensors communicates with my Openhab Home Automation on my Raspberry Pi Zero.

Main applications:

  • Read the state of the door: OPEN or CLOSED.
  • Alarm me via telegram if a door is opened (If the Alarm is switched on or the Monitor function is switched on).
  • Read the last time a door was opened or closed.
  • Count the number of openings a door sensor can handle before the battery runs out.

For example, if we are on holiday and the neighbour comes in to water the plants, I get a message. See the video in the intro.

My Openhab items, rules and sitemap files are in my Github. In these files you can also see my door sensor of the shed, which uses a regular wired reed switch and a small contact (end) switch from a 3D printer in the lock opening (see the pictures).

How to use the Telegram action in Openhab is described here.

Step 5: Improvements and Further Improvements

In the past months I made the following improvement.

Handle long door openings via a self-switching pulse signal

In the summertime, we leave the backdoor opened for a few hours when we are at home. The running ESP-01 with a WiFi connection would then unnecessarily drain the battery. Therefor I included an on/off switch to be able to switch off the module in these situations.

However, this sometimes resulted in a permanently switched off module (when I forgot to switch it on) and a drained battery after a few afternoons of a opened door and a running module (When I forgot to switch it off).

Therefor I wanted to be able to switch off the module via the software after the module was on for a predefined time (1 minute).

However, where the ‘DONE’ pulse of the ESP-01 switched off the TPL5111 when the door was closed, I found out that the TPL5111 was not switched of by a 'DONE' pulse while the DELAY/M_DRV pin was HIGH. This HIGH signal on the DELAY/M_DRV pin was caused by the opened door and the NC contact of the reed switch connected to the battery voltage.

So, the signal to the DELAY/M_DRV pin should not be continuously HIGH, but should be pulsed. In the TPL5111 datasheet you can find that it should be a pulse of > 20 ms. I made this self-switching signal via a P-channel mosfet, a capacitor and a 10K and 300K resistor, see the included scheme.

It works as follows:

  • If the NC contact of the reed switch is closed, the Gate is LOW and the Mosfet is switched ON, resulting in a HIGH signal on DELAY/M_DRV pin which activates the module.
  • The capacitor is quickly charged, resulting in a rising voltage on the Gate.
  • After approximately 20 ms, the voltage on the Gate is 97% of the battery voltage (300K/(300K+10K) which is HIGH and the Mosfet is switched off, resulting in a LOW signal on the DELAY/M_DRV pin.
  • When the DELAY/M_DRV pin is LOW, the DONE signal of the ESP-01 results in a shutdown of the module.

This is implemented in the software; a while-loop not only checks if the door is still opened, but also checks if the module is not switched on too long. If switched on too long it publises a NULL value (undefined state of the door). In this case I do not know whether the door is opened or closed and I do not reach all goals mentioned in the intro, but battery life is more important and most times we open the door again later that day, resulting in a confirmed closed state of the door.

It is important to use a P-channel Mosfet which is suitable for the voltage range used here. The Mosfet has to be completely on at a VGS of about - 3.8V and completely off at a VGS of about -0.2 V. I tried several Mosfets and found out that a IRLML6401TRPBF works fine for this goal in combination with the 10K and 300K resistors. A capacitor of 1 uF works fine to get a pulselength of about 20 ms. A larger capacitor results in a longer pulse, which is not necessary, since the TPL5111 was activated. I used my DSO150 oscilloscope to check the voltages and the pulselength.

Planned improvement: OTA update

I plan to incorporate an OTA update via the following procedure, which is already partly included in the current software

  • Via Openhab of NodeRed I publish a retained 'update' message an 'update topic'.
  • If the module is switched on and connected to the MQTT server and subscribed to the 'update topic', it receives the update message.
  • The update message will prevent the module from switching off and starts the HTTPUpdateServer.
  • Via the website of the HTTPUpdateServer, you can update the software.
  • Via Openhab of NodeRed I publish a retained 'empty' message an 'update topic'.

Planned improvement: hardware shutdown after a predefined time.

In the current scheme, I use a 200K resistor between the DELAY/M_DRV and GND of the TPL5111. This switches on the module for more than 2 hours (see 7.5.3. of the TPL5111 datasheet). However, I do not want the module switched on so long, because the battery is then drained. If the software solution (see above) fails to switch off the module, or the update message unintended sets the module in the update mode, the module remains powered on for a long time.

Therefor it is better to use a smaller resistor between the DELAY/M_DRV and GND of the TPL5111, so the module is powered off after a short time, for example a 50K resistor resulting in an on time of 7 minutes.