I live in the woods in New England, and every fall the critters that enjoyed the warm summers outside decide they need a new warm place for the winter, and that generally means my attic. They just seem to love sneaking in and making nests in the insulation, and I want them out of my house. It's a yearly battle.
Trapping them this time of year is pretty much a necessity, but there are two problems. First, I don't like climbing around in my attic. It's cold, dark, covered in said insulation, and otherwise isn't a very pleasant place. Second, we try to go the humane route and use traps that catch and don't kill. The problem here, however, is that the traps need to be checked regularly or the poor critter will be trapped inside and could potentially not live long. And since we already established I don't like my attic, I need a better way to know when the trap has sprung.
Enter IoT. By strapping a development board (and yes, full disclosure, I am the creator of said development board) to the trap, we can easily get notified when the trap has sprung. We can also keep track of battery life on the traps and monitor if there are any problems. So now, I can stay out of my attic unless I absolutely have to go up there. Great!
What it does
It tracks a set of IoT connected mousetraps and keeps a history of your catches, notifies you when the trap has caught a critter, and can show you real time stats like the battery life and status of your traps. The end-user has an app on their phone and they can track all data through that. It will also send SMS messages to your phone when something has been caught, in real time.
How I built it
I started out with bluz DK, an IoT development board. It works on the Particle cloud and can do some really cool stuff out of the box, like publish webhooks really easily. It is a Bluetooth LE board, so battery life will be nice and long, and it uses a gateway to connect to the cloud.
I picked up some humane mousetraps from Amazon and rigged up a reed switch to them. A reed switch is just a magnetic switch that is normally open, but closes when a magnet is nearby. So gluing the magnet to the door of the trap and the switch to the side makes a really simple way to know when it the traps door is closed. We then wire these up to one of the IO pins on bluz and we are set with our hardware.
Next, we needed to get data from the Particle cloud to AWS for processing. The easiest way there is to send it through a Webhook on Particle. In the bluz DK code, I can publish an event and then setup a Webhook in Particle to call any HTTP endpoint when that is fired. So when the reed switch trips, I publish an even from bluz. I also publish events for the battery status (battery voltage) on a regular interval (every hour) so the app knows how much juice is left in each of the traps, or even when they run out of power.
The code for the firmware and the webhooks can be found in the critter_particle project.
To get the data from the webhook into Kinesis, I wrote a simple API that uses API Gateway/Lambda. I use python and a really awesome project called Zappa to automatically deploy this to the AWS cloud. This API just takes the webhook data and posts it right to my Kinesis stream.
Once in Kinesis, I wrote a consumer Lambda function to process the events. There are two kinds of events we care about most: Trap Triggered events and Battery Voltage events. The trap triggered events need to send an SMS to the user, and also we want to store them to view later. We use SNS for the former and DynamoDB for the latter, storing them based on their device ID. For Voltage events, we simply need to store the latest ones so we know what the current battery level is, as well as when it was received. The firmware in the IoT board sends this event our every hour, and this is also stored in a DynamoDB table.
To now view the data, we need an API to get the history and the device information out to the user. That is solved by another simple API on top of the DynamoDB tables to show device info and event history. Then, we wrap it all up in a nice React Native app so the end user can look at the data. The app polls the users Particle account for the right device ID's, then calls our API to get the data to display.
This is all, of course, a demo project. Shortcuts were taken, especially around user account management. For example, I am using the Particle accounts for the most part, and am not storing any account details on my side. The phone number to send SMS's to is hard coded in the data table. And while the devices support naming, it has to be done directly in the DynamoDB table. All these could be solved, but this is a demo, so we will live with those limitations.
Challenges I ran into
Well, I still have to go into my attic to set the traps and fetch them when I do catch a critter. While that is certainly WAY less often then before, it is still a challenge. If only there was some kind of mousetrap fetching drone....
The project is fully up and running, and working well. I deployed it in my own house with two traps and have been running it for a month or so. Yes, the events in the app shown in the demo video are real, that is actually how many mice I have caught in my attic. It really is wonderful to not have to climb up into my attic twice a day to check the traps. The system has worked flawlessly and I have gotten an SMS each and every time. I can monitor battery life and change them when/if needed. I have even thought of putting alerts on the battery life when it gets low, or if the system goes offline for any reason. These are all continued improvements that can be made.
If you look closely at the code in the consumer, you will also see that I tried a few other types of events, mainly motion detection. My initial thought was to put a PIR sensor in a few places to try and figure out exactly where they are getting into my attic, which is itself a mystery. This didn't go too far, though, as they are pretty good at tunneling in my insulation and hard to detect.
What's next for IoTrap: The Better Mousetrap
Not sure, I will certainly be using it in my house for the foreseeable future. Most of the software side would be scalable to become a product, but the shortcuts would need to be fixed. The app would need a lot more dressing up, it wasn't really styled or created with a lot of UI design. The traps themselves are clearly just a proof of concept, there would need to be real mechanical design to make them an actual product. I have already gotten requests from friends/family to use the traps, so we shall see how far I take it.
No mice where harmed during the making of this project. However, many were relocated...
(o)(o) \../ ( ) m\/m--m----