IAMSEC (Indoor Air Monitor & Security) 24/7 Housesitter
Things used in this project
|Raspberry Pi 3 Model B||× 1|
|Raspberry Pi T-Cobbler||× 1|
|Adafruit STEMMA Soil Sensor||× 1|
|JST PH 4-pin to female socket cable, I2C||× 1|
|5v 2.5A switching power supply w/ 20AWG MICROUSB||× 1|
|SORACOM Air Global IoT SIM||× 1|
|Huawei USB dongle||× 1|
Software apps and online services
|Python 3||× 1|
|SORACOM Harvest||× 1|
|AWS SNS||× 1|
Hand tools and fabrication machines
|Soldering iron (generic)||× 1|
|Breadboard, Plastic||× 1|
|Solder Wire, Lead Free||× 1|
|Solder Flux, Soldering||× 1|
|Desoldering Braid, Dri-Wick||× 1|
Many internet of things devices for surveillance are not designed to report information on buildings, soil, and other land features. For example, a rental property investor who is unaware one of his vacant units is flooded due to storm damage may catch on right as he tries to bring in a new tenant. The vacant unit has no way of connecting to the outside world via wifi or Bluetooth. Therefore, a cellular IoT device can monitor the environment can prevent non-repairable damage and save the owner money.
Utilizing advanced MEMS sensors and various instrumentation owners can monitor soil moisture in indoor agricultural applications, detect dangerous mold and excess moisture in vacant residential units or commercial spaces, and receive updates and trends from temperature, humidity, moisture, Volatile Organic Compounds (VOCs) and physical presences such as intruders. Distant properties will use cellular IoT technology as it's communication medium to report sensor data (eyes and ears). I've chosen three key sensor technologies to monitor indoor conditions on a property, remotely, utilizing the Soracom 3G SIM and the Huawei usb dongle to send data to the he Soracom Harvest and Amazon SNS cloud services for user notification and graphical representation. The brains of the system is a Rasbperry Pi 3B. I followed the Soracom starter kit getting starter guide on the Soracom website to setup and configure my account:https://www.soracom.io/iot-starter-kit/. I then registered my amazon aws account, added a topic (arn) and generated access and secure access keys: https://aws.amazon.com. All three are needed in the main python program.
Developing the IAMSEC house-sitter required multiple python libraries to enable three different sensing technologies to work while still being user friendly and allowing a home owner to get useful data. The STEMMA soil sensor is the easiest to configure and gives a moisture reading from 0 (very dry) to very wet ~2000. When exposed to moisture such as water, the sensor will jump above 1015. This can be useful for homeowners to monitor their property for flooding when used in-conjunction with the humidity sensor on the BME 680. Further, the STEMMA sensor is resistant to rust, making it a robust 'set-and-forget' option. I've also chosen to utilize the temperature sensor on board to fuse with the BME680 data.
The BME680 was chosen due to monitoring of VOC, or harmful gases in the air from combustion, paints, solvents, and even mold. This VOC sensor also comes with humidity and pressure sensors. I've utilized the VOC and humidity readouts and created an algorithm that will send the user notification if threshold limits are reached (fusing the STEMMA soil sensor temperature reading also) so that the homeowner can best judge their indoor conditions based on either a 2 out of 3 or 3 out of 3 criteria for poor or very poor indoor property conditions, respectively.
This algorithm threshold criteria is what notifies the user via amazon SNS. The end user can have access to Soracom Harvest to view trends, say moisture levels during rainy seasons, or ensure humidity and temperature trends are low to avoid mold and excess moisture indoors in humid environments. The BME680 from Adafruit has known issues (documented in the Git as well as their forums) where the VOC levels will get stuck at a number and not move. I've experienced the issue myself which manifests when readings dip below 185,000. Unfortunately, I was not able to contact Adafruit to resolve this issue in time.
Lastly, I thought a cool Time of Flight sensor could serve a purpose in this project. It can read distance very accurately up to 4 meters. The VL53L1X can be used for security purposes, or perhaps to monitor how often a plant has been watered? There are a multitude of uses, but for this specific application i've used it as a security trigger event which sends a text notification via Amazon SNS that movement has been detected. The sensor's output can also be read on Soracom Harvest for graphical trends.
Due to security concerns, this IoT device has no camera or microphone capabilities. End users will be advised to change all default usernames and passwords. Additionally, it is recommended that the Raspberry Pi has wifi and Bluetooth disabled after complete setup. I've attached a library install .sh script in the code section to install all necessary libraries. It is advisable to push updates to the device via Soracom sending SMS commands to update or re-configure and the Pi checking for those updates periodically through cron jobs. I've semi configured a cron job setup in the will allow software engineers to provide update commands to the Pi as well as library updates. The sensors on aboard have a less intrusive data set than most IoT devices. Utilizing 3G through Soracom's SIM card, I don't see too many issues with security as long as the device doesn't have Wifi or Bluetooth enabled. Most network vulnerabilities exist in wireless IP networks. Since the sensors in this device are not intrusive, a hacker would only be able to see environmental data. Nothing else would be running on the Pi such as IP cams or microphones.
Scalability should not be too difficult. A 3d printed case would suffice as an enclosure. The BME680 stuck reading issue would have to be resolved before going full rate production. The STEMMA sensor seems robust thus far as does the VL53L1X. The STEMMA sensor could dangle via a flexible connection or be housed partially by the enclosure with the tip sticking out from the under side.
Scaling to a production level would mean VOC burn in and testing most likely to ensure good sensor performance. Determining VOC level threshold zones would be the result of testing in various environments with varying conditions. Sensor hardware costs approximately $70 all together (including some wiring and connectors). Perhaps a production model would cost closer to $100 when manufactured at a full rate. The sensor technologies could be consolidated on to a single PCB with the onboard System on a Chip. This low cost is a great benefit for end users who are protecting a real estate asset and the benefits would far outweigh the costs in most if not all cases. End users would of course get their own Soracom accounts and would have access to the data sets. The Amazon Web Services side would be abstracted away from the user all-together, but the end user would still get SMS to their phone for critical updates. The Amazon account would be managed by the vendor/system admin to include access and secure access keys. The management of keys and cost of SNS services would be taken into account for the end user's bill.
What is the impact of this device on a large scale? Indoor air quality is not a metric that cities, counties, or states can monitor: it is too much of a burden on resources. However, with many IAMSECS running simultaneously we can better determine indoor air conditions in apartment buildings, condos, and small city blocks. The data can then be used to assess overall conditions to get a localized look at a collective of indoor enivronments to determine commonalities, detect anomolies, and assess trends. This would be the big picture arguement for these sensors that would apply to a much larger audience than property owners monitoring their vacant buildings and houses.
Overall, in leveraging the three technologies I've tried to give the end user multiple options and several ways to interface with this IoT device without sacrificing personal data or playing into the most common wireless vulnerabilities.