How to build a homemade fire alert system prototype
An article you’re about to read will show you how to build a prototype for a simple fire alerting system. Before we even start, you might ask yourself: “Why in the world would I be doing that on my own?” The best answer I have is: To geek out a little bit.
To make it happen, we’ll use Arduino and Infobip API. By the end of the article, you will be able to build the same (& more) on your own. The solution is available on my GitHub repository.
To build anything more robust than what is already in the GitHub repo, you will need a basic knowledge of C++ and Arduino. If you’re following my lead, go to the Infobip signup page and create an account (or use an existing one) — you’ll need it.
Storytime!
A couple of years back, I lived with my parents. *shock*
During one summer, a lot happened in the area. There was a car that caught fire, a shooting, two floods caused by installation failure, AND an apartment that went in flames. While all had their causes, we’ll focus this article on the last fire.
With parents out, a couple of kids were preparing for a movie night. Their closed-off balcony was the projection room, and yes, there were some candles lit around. What they figured is that some of them (being kids) were down on some snacks that a few were particularly keen to have. Soooo, off to the grocery store — all of them.
Now, the balcony portal was half open; the wind was blowing and moving curtains a little bit, the candles were burning… I think you got the picture of what happened next. Luckily, no one got injured, but the apartment went in flames.
Could that have been averted — I have no idea, but here is my thought process.
Thought process
Most apartments where I live have no alerting whatsoever. Most of them are not even insured. So, usually, if there is any damage, the owner is the one who covers it.
For the argument, let’s say there was some fire detection sensor around. How that works is that the device sensor is connected to emits audio-visual signaling when something off is detected. That helps only the close-nearby ones by alerting something is wrong.
There must be a way to make it better right?
The geek show playground
I’m a techie. I code, own an Arduino setup and work for Infobip — a company that excels in building Communication APIs. It sounds like I am set for success, so I hit it off.
Now, bluntly said, Infobip is enabling software developers to integrate communication features into their apps. And the easiest to set up of them all is SMS. So that was what I was going to do first!
I’ll set up my Arduino UNO WiFi Rev2, connect a flame-detection sensor and some LEDs & buzzers, and connect it all via breadboard with wires. Then, whenever a flame is detected, I’ll alert myself by triggering an HTTP call to Infobip that will send me an SMS. Easy, right?
Code through the flames
What to code now? Here is our use case.
There is a setup that checks for flame in an infinite loop.
If a flame is detected, a 🔴 LED flashes along with the buzzer.
If there is no flame, a 🟢 LED flashes.
Here is what a default Arduino program looks like. It has two default methods. One you use for the initial setup of the components you’ll be using, and the other runs in an infinite loop as long as there is a power supply to your device.
To get things started, we need to write code that will use basic sensor alerting. What we need is to create a fireDetectionAlertSystem.ino file, and initialize which digital pin of our Arduino corresponds to our components (buzzer and the LEDs mentioned above). We need to set the initial fireDetection flag to false. And we need to define the sensor input and output pins for the loop readings. Then we determine the data rate, and that is it for the setup.
What happens next is that Arduino runs our loop() method infinitely. That is where we want to do the flame detection checks and all the activity we want to come out of those check results.
We want to check the sensor reading on every iteration. Depending on the sensor reading, we want to update the status of our buzzer and LED components and the fireDetection flag for future iterations.
That’s it. Our setup is now able to flash and buzz!
Keep our secrets
To make the code a little bit cleaner, we’ll create an ArduinoSecrets.h file containing all the things we don’t want to have exposed directly in our code. That includes WiFi SSID and credentials, API-related credentials, and SMS-related fields. We will include ArduinoSecrets.h in all relevant files, including the base fireDetectionAlertSystem.ino file.
What do we do now?
Let’s Connect
Sending an SMS via HTTP request means that we need to connect to the internet and the Infobip API server. So let’s first connect to the local WiFi.
To do that properly, we will use the WiFiNINA library. It enables network connection (local and internet) with several Arduino devices, including the Arduino UNO WiFi Rev2 we’re using here.
First, we’ll scan the available networks to check whether the one we predefined in ArduinoSecrets.h file is available. If/when we find it, we’ll use the included library to call a proper method. Code speaks louder than words, so here is how we do that.
For the above code to work, we’ll have to include it in our main .ino file and invoke the connectToWiFi() method call. Now that we know how to connect to WiFi (and disconnect from it), we can use that connection to invoke an HTTP request that sends an SMS when the flame detector gets a new state.
Send me a message
To invoke an HTTP request, we will use the ArduinoHttpClient library. For SMS sending, we are going to use Infobip API. To keep it aligned with the GitHub solution, we’ll showcase how to send an SMS with GET request and query params. NOTE that I recommend you send SMS using POST and request body. Hence as soon as I find time to improve this solution, the article will also be updated. Or you can fork it and create a pull request for me. 😉
And that is it! We need to update the main file to invoke proper method calls when and where required. Here is what our main .ino file looks like after all the updates.
Note that we used only the basic params for sending SMS (a sender, a recipient, and an actual text of the message). If you’d like to do something else and have, e.g., periodic updates on whether sensor readings are as expected or do some analytics… read the docs linked above and use any of the fields that might help you solve that challenge.
Ah yes, does this even work?
Hell yeah, it does!
What comes next?
It’s straightforward to build on top of this because what we showcased is only the simplest scenario. A sensor detects whether there are(or not) any flames around, a set of LEDs plus a buzzer, and we send an SMS with only the basic info available.
I own the stuff, and it is fun to play with it even when the core use case is simple. There are plenty of different use cases and features you might use for your solution to make it more robust. Including different types of sensors, different API calls to pull stats and analytics, adding some failover, or upgrading that GET approach I used to a proper one.
Wanna give it a shot? If you don’t have one already, go and create that Infobip account.
