Hologram "Stuff" Monitor

Project Log

• 11/3/2017 (Fri.) - Parts delivered to office after hours, picking up after the weekend.

• 11/5/2017 (Sat.) - Began project documentation, initial experiments with NodeMCU MQTT brokerage.

• 11/7/2017 (Tue.) - Built first prototype NodeMCU alarm trigger, but ran into problems with ultrasonic sensor.

• 11/13/2017 (Mon.) - Built light-sensing prototype with NodeMCU and Grove Light Sensor from the Arduino 101 - Invent Your Future! contest.

• 11/15/2017 (Wed.) - Built initial sensor stubs for Gyroscope- and Microphone-to-Adafruit IO sensors.

• 11/26/2017 (Sun.) - Mishap fried both my NodeMCU dev board and Gyroscope sensor breakout board.

• 12/3/2017 (Sun.) - Created API wrappers for sending SMS messages via Hologram, Nexmo, and Twilio. Wrote beginnings of MQTT broker based off of the super-easy-to-follow tutorial by the Hologram team.

• 1/15/2018 (Mon.) - Created test utilities for MQTT broker, updated test Twilio integration.

• 1/18/2018 (Thur.) - Implemented full POC on a Raspberry Pi 3 Model B. Began modifying code and setting up the project-dedicated Raspberry Pi Zero W.

• 1/22/2018 (Mon.) - Finished project documentation.

Architecture

Alarm Trigger Sensors

1. Sonar

This is the first prototype of an alarm trigger: an ultrasonic distance-measuring sensor on a breakout board connected to the NodeMCU and communicating with Adafruit's IO platform. Unfortunately the data from this particular sensor is exceptionally noisy, which may render it more trouble than it's worth.

2. Light

This is the second prototype, built by combining the Grove Light Sensor v1.2 sensor board with the NodeMCU. When stashed in a closet, it provides clean data that makes it very obvious when the door has been opened and for how long. Results were good enough and setup so easy that this was actually left live and provided data to Adafruit for two days before any tweaks were made to the Arduino sketch code.

Raspberry Pi Software

What ties all of the sensors together and makes something useful out of them is a simple bit of code written in Python. In short, what it does is connect to an MQTT broker and executes actions when new messages are published to the feed. Depending on what those messages are, it might arm or disarm the alert system, send an SMS alert, or simply print the message to the terminal.

For the sake of easier development (and in the interest of including others who may not have access to Hologram hardware), initial development was done utilizing the Twilio API. This made things a bit easier to start with as the Hologram Nova modem does not currently support MacOS or Windows, rendering on-the-go development a rather cumbersome process. Enabling usage of the Hologram hardware once the software has been cloned to the Raspberry Pi is as simple as changing some imports and pointing the class constructor to the right API wrapper class.

Project Instructions

(Note: These instructions assume a working knowledge of Linux, Raspberry Pi, Git, Python, and APIs. If these instructions remain unclear, please leave a comment and I will do my best to clarify.)

• Flash a MicroSD card with a fresh copy of Raspbian "Jessie." Although this version has (at the time of this writing) already been replaced by a newer version of Raspbian, a number of features do not seem to function properly and complicate things needlessly to have to bypass.

• Set up the Raspberry Pi in headless mode. Highly recommended is to follow the thorough guide written by the Hologram team themselves. By the time you're done you should have the Hologram CLI, Hologram Python SDK, and Paho MQTT broker installed (and running, in the case of Paho).

• Clone the project code repository either directly to your Raspberry Pi or to a second computer and transfer it from there. You will want to copy one of the files (creds.yaml.bak) and rename it (to creds.yaml) so that you can enter specifics about your particular setup. You should only be changing values under mqtt-server and owner unless you lack Hologram hardware and want to use Twilio or Nexmo credentials instead.

• Having gotten the project code repository onto your Raspberry Pi and modified the credentials file, its time to start the alarm server. From a terminal open to the correct directory, run the script using Python 3.x (e.g. python3 security-service.py). It should have connected to your MQTT broker and now be waiting for events!

• You are now ready to configure a NodeMCU with sensor(s) to serve as alarm triggers. A few examples can be found in the project repo, ranging from an ultrasonic distance trigger to a temperature trigger. All of these examples make use of the wonderfully simple Adafruit MQTT Arduino library, but you do not have to use the Adafruit IO service. Just change the relevant lines to connect to your Raspberry Pi's WiFi network and MQTT broker.

• As this project serves as more of a proof-of-concept than a production alarm system, you will need to come up with your own way of arming the alarm system. By default, if _enable_alarm_ or _disable_alarm_ are published to the shared feed, the system will be armed or disarmed respectively. While it's not the most user-friendly interface in the world, you can make use of a Python helper utility script that was written for testing. Refer to the demo video for example usage.

• You're done!

Future Steps

As mentioned in the instructions and demo video, an immediate first step I would like to take is to enable Alexa integration. The reasons for this are two fold: hands-free enablement of the alarm system when walking out the door, and also the ability to utilize the speakers in an Alexa device as an actual alarm to deter would-be thieves. Further refinement might also result in an Alexa "flash briefing" style recap of non-emergency events missed during the day (e.g. temperature fluctuations, noisy neighbors, etc.).

While the project turned out a success, the one-way-only communication architecture did cause me to question whether or not my system was actually functioning properly. Were I to redo my project I would implement an ability to perform a status check from afar (read: the internet) and receive on-demand check-ins from all of my NodeMCU sensors.