Dev decided to use new technology to upgrade the wireless water alarm system he had constructed nearly a decade ago. While he was at it, he figured he’d create a complete home security system with water alarms, smoke alarms, motion sensors and door sensors. He also added an interface to a Raspberry Pi with the potential for sending remote alerts to cell phones and other devices.
Nearly a decade ago, my cellar was flooded in quick succession by a cracked boiler and a leaking hot water tank, so I was inspired to design and build a wireless water alarm. This was based on an interdigital transducer that used the conductance of water as a sensing principle. I used a simple on-off -key transmission protocol on what was then an empty 914MHz radio band. I described this system in my article, “Build an Inexpensive Wireless Water Alarm” (Circuit Cellar 283, February, 2014). This system worked well for many years, but eventually it started to give some false alarms.
The false alarms were caused by the gradual use of the radio band by such things as doorbells and automotive remotes. These devices produced signals on that radio band that defeated the simple expedient of my using amplitude detection of a radio signal to trigger an alarm. Since the original circuit was built using a Microchip Technology PIC microcontroller (MCU), I was able to reprogram it to look for a sequence of pulses of a particular width, and this eliminated the false alarms. Although my water sensor was once again working, I decided to take advantage of inexpensive wireless components that were currently available to build a more robust system. As I started work on this system, I saw that a little more effort would lead to a home security system with capability far beyond water alarming.
Although the interdigital transducer of my original water alarm worked well, I’m always willing to experiment with different technologies. I decided to examine an optical water sensing approach illustrated in Figure 1. It’s based on the idea that light, internally reflected at the edges of a prism, will escape when the prism is in contact with liquid water. This is a good method for liquid-level sensing, and it will also act as a water alarm when one of the prism edges is angled close to the ground, or when there’s a sponge alongside to draw water toward the prism.
Light is reflected from the sides of the prism, because of the high reflectivity of the interface between the Plexiglas prism and air. This reflection exists because the refractive index of Plexiglas, 1.49, is much higher than that of air, 1.00. Water has a refractive index of 1.33, and this makes the Plexiglas-water interface much less reflective. Since the beam width of the LED is nearly 100 degrees, its light floods the prism edge to the extent that more water in contact with the prism leads to reduced light at a phototransistor. I verified this fact by experiment, and the results are shown in the graph in Figure 1, in which the voltage was read at its collector when connected to 5V through a 100kΩ resistor.
While I did get my new water alarm to function with this optical sensor, I decided that my readers wouldn’t want to go through the trouble of making the prism and aligning the LED light source and the phototransistor. The final version uses an interdigital sensor, simply formed by the bifilar winding of two lengths of AWG 22 bare copper wire.
For the wireless implementation, I decided to use the popular HC-12 transceiver module operating near 433MHz. This module, available from various sources, transmits and receives digital signals at line-of-sight distances of up to a kilometer in a hundred different channels in the frequency range of 433.4MHz to 473.0MHz. A link to the Amazon page for the Comidox HC-12 unit I purchased is at . For the home security application, we need less than a few tens of meters transmission through walls and other structures, and this device works under these limitations in my own house.
Some people may want to monitor out-buildings, such as non-attached garages and tool sheds, and this wireless module seems up to this task. It does work at my distant roadside mailbox, as I’ll describe later. The HC-12 will work when powered in the range 3.2 to 5.5V, though it’s cautioned not to use the device above about 4.25V in transmission for extended periods of time. The battery-conserving protocol that I implemented powers the device at about 5V for short intervals.
I especially enjoyed the simplicity of configuring the HC-12 for communication, since it has a command set that’s reminiscent of the Hayes AT protocol that was used in computer modems. The HC-12 has a “set” pin, and bringing this pin low enables it to receive configuration messages using ASCII text. Table 1 is a summary of the most important commands, which are all sent with a trailing carriage return (ASCII 13) and line feed (ASCII 10).
PIC WITH HARDWARE UART
I chose a Microchip PIC16F688 MCU for the home security system, because it contains a hardware UART for serial communication with the HC-12 and the many I/O pins needed for such things as selecting the device number and sounding a piezoelectric alarm. One consideration in battery-operated devices is the power consumption. The schematic diagram of the water alarm circuit (Figure 2) shows how power is applied to the HC-12 only when it’s needed. The PNP transistor applies power to the HC-12 only when the PIC GPIO pin is in the proper state. The PIC software keeps the device in a low-power sleep state, it checks for water at intervals, and it powers the HC-12 only when there’s a need to transmit a signal.
In the sleep state, the current draw of the device is just 3µA. The three alkaline AA cells that power the device have a capacity of more than 1,000 mAhour, so battery life is many years at this current drain. Nonetheless, the batteries will need to be replaced eventually, so a battery-monitoring capability is included. One problem with using the PIC’s on-board ADC to monitor the battery voltage is that the voltage reference for the ADC is the battery, itself. A trick to circumvent this problem is to add a nonlinear network, built from a series-connection of diodes, to make the ADC input signal differ from the reference signal. The performance of this network is shown in Table 2. Figure 3 is a detailed image of the interdigital transducer that’s mounted on the bottom of the case.
I wrote the software for the water sensor and the other PIC components using the PICBASIC PRO Compiler, available from ME Labs. I write most of my serious desktop applications in C, but I’ve used this compiler for two decades; it works well, and old habits die hard. I presently run it from an older MS Windows system in a virtual machine on my Linux desktop computer. I use a functional approach to writing code, so I organize my BASIC code into subroutines. This makes it easy to translate the source code to your favorite language.
Good diagnostic tools are an immense help in doing circuit design, especially when the design includes a software component. Early in my design phase I decided that I needed a way to monitor and generate HC-12 signals. For that purpose, I built the circuit shown in Figure 4 that connects an HC-12 wireless module to a DC-9 serial port connector. This interface is powered by a USB 5V supply. To simplify construction, the set pin state is changed by an on-board jumper. Few modern computers have the once-common DB-9 serial port. In my case, I used one of the many available USB-to-serial adapters and the CuteCom graphical serial terminal on my Linux desktop to access the device at port /dev/ttyUSB0. Another option is to use a Raspberry Pi, as I’ll explain later.
The water sensor and the other alarm sensors described later communicate with a base unit that displays status and alarm messages on a 4-line, 20-character LCD display from RioRand. The display uses the standard HD44780 interface, and the circuit board was designed for a one-to-one correspondence between the display pinout and the circuit-board connections. This makes for easier mounting in the enclosure, since only the display needs to be mounted with the circuit board attached to its back. Since the number of I/O pins is limited, the display interface uses the 4-data-bit protocol. The base unit also includes a piezoelectric speaker as an alert alarm, and a multi-function toggle switch for scrolling through the events and arming the system.
Since our I/O is limited, the toggle switch, which is momentary-contact single-pole, double-throw (SPDT) center-off, serves several purposes. If it’s depressed in the scroll-down state when power is first applied, all data from the event memory is cleared. In normal operation, this switch allows scrolling to view older events. Some events will trigger an incessant warning beep, but scrolling up or down will silence this audible warning.
Depressing the scroll switch up or down longer than the 2 seconds it takes to update the display will set the system into an armed or disarmed state that determines whether the system issues warning beeps or not. More on this function later. The base unit is powered by a 5V DC wall transformer. Figure 5 is the schematic diagram for the base station, and Figure 6 shows the internal components of the base station and the appearance of the LCD display during normal operation.
DOOR AND MOTION ALARMS
The circuitry for the door, motion and smoke alarms is slightly different from that for the water sensor. It still uses the same PIC 16F688 MCU and it has the same power management for the HC-12 wireless module. However, the sensing is done with a digital pin, and not by analog-to-digital conversion. GPIO Port A on the PIC has an interrupt-on-change feature that allows the MCU to wake from its low-power sleep state when the state of an input pin changes from one to zero, or zero to one. This pin connects to a magnetic reed switch for the door sensor. The schematic diagram for the door sensor circuit is shown as Figure 7, and the magnetic reed switch attachment is shown in Figure 8. A magnet on the door keeps this switch closed when the door is closed, and it’s opened when the door is opened. This allows detection of the door state on demand.
The door sensor is powered by a smaller complement of three AAA cells that still offer long battery life. I build everything with through-hole components, since they’re easier to solder, but this is one circuit that should be improved by using a smaller PCB with surface-mount components. This would allow use of an enclosure half the size, which would be less visible at the top door frame where the box is mounted. The magnet is attached to the door. A series combination of two CR2035 coin cells will give about 6V, which is too high a voltage. A Zener diode would be used in that case, to drop the supply voltage to a safe level.
The motion alarm uses the same circuit board and connects to the wireless interface electronics through an opto-isolator. I used an opto-isolator, because it proved to be a good solution for interfacing a smoke alarm, as explained below. Many inexpensive motion sensor modules are available. The one that I used is the Onyehn IR Pyroelectric Infrared PIR Motion Sensor Detector Module that’s advertised as being Arduino compatible. What that means is that it’s really easy to use. It’s powered by the same battery supply as the wireless interface board, and I measured the current requirement of this module in its quiescent state at just 15µA. This means that battery life for motion sensing is still long. The module, itself, has limited drive capability, so I needed to add a field-effect transistor (FET) to drive the opto-isolator LED. The interface to the same circuit board as used for the door sensor is shown in Figure 9.
The smoke alarm uses the same opto-isolator as the motion sensor, and the connection is to a commercial smoke alarm. I purchased this alarm, a Kidde Model i9040 Fire Sentry Battery Operated 4” Smoke Alarm, for less than $5 at my local Walmart, and the 9V battery was included. Examining its circuitry with my oscilloscope and voltmeter revealed that its piezoelectric sounder was driven by an AC voltage greater than the 9V battery’s voltage, so it was likely generated by something like an “H-Bridge.” Connection of this driver voltage to the opto-isolator LED, as shown in Figure 9, was simplified, since there is no need to maintain polarity. However, most LEDs don’t like to be reverse biased, so I added a protection diode to clamp the reverse voltage. My connections to the smoke alarm are shown in Figure 10.
This smoke alarm, like most others, chirps when its battery is low. Since it’s easy to distinguish this 50ms chirp from the alert signal (0.5 seconds on, 0.5 seconds off), I was able to detect this low-voltage state for transmission to the base unit. One caveat for the smoke alarm is that attaching your own wires to a commercial circuit is always problematic, since it might somehow affect its operation. The usual warning is, “No user serviceable parts inside.” For this reason, you should always use a modified alarm as an adjunct to an unmodified alarm.
Detecting the low-battery condition is useful in my own house, where I have a smoke alarm in my garage. Unless I’m in the garage for an extended period, I would never hear the chirp. However, you might question the need to send an alarm signal to the base unit for an actual smoke condition, since the smoke alarm’s internal sounder is loud enough to be heard anywhere. Some people have non-attached garages, tool sheds and even barns, for which a smoke alarm and the low-battery chirp can’t be heard from inside their houses. These can benefit from having a wireless alarm.
PROTOCOLS AND COLLISIONS
To conserve battery power, data transmission from the sensors to the base unit is as short as possible. It consists of a lead character ($), followed by two hexadecimal digits encoding a byte of data, terminated by a carriage-return/line-feed sequence. The construction of the data byte is shown in Figure 11. The data byte specifies the sensor type in b6-b7, the sensor number in b4-b5, an alert bit at b3 and a status code at b0-b2.
To ensure proper communication, the base unit repeats its received codes to signal to the sensor units that the data byte was received. If a sensor does not get the correct response, it will attempt transmission again four times at random intervals. One reason for a failed transmission is a network collision when two sensors transmit at the same time. This should be a rare occurrence, however, since transmission times are very short. Having retransmissions from these sensors at different, random times should allow recovery from such a network collision.
As an added check, all the alarm modules “phone home” once each day to signal an OK status on the display. The OK status is also displayed when power is provided to an alarm module when batteries are initially attached, and when the reset switch is pressed. The water sensor has the simple expedient of having a normally closed switch that interrupts power when pressed, but the other sensors use a normally open switch on the PIC reset pin.
As I wrote earlier, you can use the scroll switch to place the base unit into an armed or disarmed state. It would be annoying to have the base unit beep at you during the daytime when doors are constantly being opened and closed, and there’s motion everywhere. When the unit is armed—during the night, for example—alert beeps will always happen. When the base unit is disarmed, only the water and smoke alarms will cause a beep alert, as will my door sensor #3 and motion sensor #3. Door sensor #3 is at my mailbox, and I use this module to signal when mail has been delivered. This module was built into a shallow case that’s hidden under the mailbox. My roadside mailbox is 90′ from my base unit, and data transmission has always been reliable. Motion sensor #3 is at my front porch, and it signals events such as a package delivery.
RASPBERRY PI AND REMOTE MESSAGING
The utility of a home security system is enhanced when there’s an option for remote alerting to devices such as a smartphone. The first task to accomplish this is to get the alarm signals onto your home’s internal network, and the easiest way to do that is with a Raspberry Pi with wireless connectivity. The Raspberry Pi Zero-W is quite slow compared with a Raspberry Pi Model 4, but it’s small, inexpensive, has built-in Wi-Fi and is fast enough for most simple tasks.
Figure 12 is a schematic diagram for connecting the wireless module to the Raspberry Pi. I soldered the GPIO connector on the bottom of the Raspberry Pi, rather than at its usual place at the top. This allowed it to mate with a female receptacle on the circuit board. One important note is that the logic-level converter that’s required to go from the 3.3V logic of the RaspberryPi to the 5V logic of the wireless module has different pinouts from different vendors. I powered the Raspberry Pi through its GPIO pins and not its USB power connector. This is allowed if you’re using a well-regulated power supply.
While the circuitry is simple, the software takes a little more time. The first thing to do is to load the Raspberry Pi Operating System (OS) onto an SD card. Since we don’t need software applications such as LibreOffice, choose the version without the extra applications, but don’t use Raspberry Pi OS Lite, which has no GUI. For a start, you will need to connect to your wireless router, enable the serial pins on the GPIO and disable the terminal logging. You will then install the Apache2 web server and its PHP component using the following commands:
sudo apt install apache2 -y
sudo apt install php libapache2-mod-php -y
I wrote a web interface program that allows viewing recent events on the web browser of local devices (Figure 13). This depends on a simple Python application security.py that’s placed in a folder named security on the Raspberry Pi desktop. This Python program logs the data from the HC-12 wireless module to a file datalog.txt in the same folder. To enable the web interface, place security.php and security_logo.png in the html directory at /var/www/html/. Then create a symbolic link inside that directory to the datalog.txt file:
ln -s /home/pi/Desktop/security/datalog.txt /var/www/html/datalog.txt
To automatically start event logging at every boot, we need to add this line at the end of the text file at /etc/profile:
python /home/pi/Desktop/security/security.py &
At that point, the security.py program will automatically run at each boot. If something goes haywire, you can always open the SD card contents on another computer using root access for editing and removing modifications. If you want to show an image file of the last four events on the desktop screen, you need to install the Eye of MATE (eom) image viewer using the command line:
sudo apt install eom -y
To get the image viewer to load automatically at boot, create an autostart folder in /home/pi/.config/ and create a text file security_image.desktop there with these contents:[
Exec=eom -f /home/pi/Desktop/security/image.svg
This will automatically open the image.svg file full screen on your desktop. At first use, you will need to have a dummy image.svg file in the security directory.
Someone more skilled than I can find a way to send text messages to a cell phone from this point, but having an image of the four most recent alerting events might enable an easy method of remote signaling on the Internet. I haven’t done this, but I’ll explain how it might be done.
Some home security camera systems allow remote viewing on your smartphone, and these are easy to install. These systems are usually triggered by motion. The approach that I envision for my system, but haven’t tried, is to substitute the video output of the Raspberry Pi for one of the cameras. The image created from the Python program would be updated automatically in eom on the Raspberry Pi desktop when it’s changed. Such an image change would appear as motion to the camera system. You would need to disable the screensaver on the Raspberry Pi. Having cameras at your home also allows verification that there’s a true alarm condition. I haven’t tried this, myself, so you’ll need to experiment. However, the essentials are there.
Smoke alarm boxes usually have text explaining that you shouldn’t cancel your fire insurance just because you’ve bought a smoke detector. The same reasoning applies to this home security system. Although this system functions to my satisfaction, this is a hobby project, and it hasn’t been subjected to the more extensive testing that we expect from a commercial product.
 Comidox 433Mhz HC-12 SI4463 Wireless Serial Port Module at https://www.amazon.com/Comidox-433Mhz-Wireless-Replace-Bluetooth/dp/B07KD4GR18/
PIC 16F688 Data Sheet from Microchip Technology
PIC Basic is available from ME Labs (https://melabs.com
Raspberry Pi OS Download Page https://www.raspberrypi.org/software/operating-systems
RioRand LCD Module for Arduino 20 x 4, White on Blue
http://www.riorand.com/electronics/active-components/riorandtm-lcd-module-for-arduino-20-x-4-white-on-blue.html Source for purchase: https://www.amazon.com/RioRand-Module-Arduino-White-Blue/dp/B00GZ6GK7A
ME Labs | www.melabs.com
Microchip Technology | www.microchip.com
Raspberry Pi Foundation | www.raspberrypi.org
RioRand | www.riorand.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • AUGUST 2021 #373 – Get a PDF of the issueSponsor this Article
Dev Gualtieri received his PhD. in Solid State Science and Technology from Syracuse University in 1974. He had a 30-year career in research and technology at a major aerospace company and is now retired. Dr. Gualtieri writes a science and technology blog at www.tikalon.com/blog/blog.php. He is the author of three science fiction novels, and books about science and mathematics. See www.tikalonpress.com for details.