SmartPhix is a small smart home project. The goal is to monitor temperatures in houses, offices and other interior rooms. It is currently being prototyped using Phidget components.
IoT and home automation projects have been on my to-do list for a couple of years. Recently, my co-workers set up a home automation channel on our Discord server to discuss their latest inventions. It made sense for me to join in and start my own project.
I had a few ideas, mostly revolving around smart LED lights or similar. I saw a cool project where a temperature sensor is used to set the color of the lights in the room based on the current temperature. I thought it was pretty neat and wanted to do something similar. My first thought was to use the Philips Hue lights. I am a big fan of Razer peripherals, and recently Philips and Razer have teamed up with some cool integrations between their products and SDKs.
As for the temperature sensor, I was given a Phidget board and sensor at University for the project. However, this project had two problems:
- Considering that this was also a project for University coursework, it would be difficult to demo it
- It felt too simple and too easy (even if the APIs were somehow horrible to work with, I was confident that it wouldn't take too long to complete)
So I decided to take the project a step further and make a simple Android app to display the current temperature. That alone would make the scope of the project change drastically, as I had to consider how the app was going to communicate with the Phidgets, in addition to how everything would work with the smart LED lights.
The main idea so far is:
- A Phidget will provide the current temperature from its sensor via a RESTful API server with endpoints such as `GET /temperature`
- An Android app will hit the API server with requests to display the current temperature (in Celsius and Fahrenheit)
- Based on the current temperature, interior lights (smart LED lights such as Philips Hue) will change color
The project is divided into several components.
Phidget and temperature sensor
Phidgets Inc offers a range of I/O boards, digital and analog I/O components, and many other hardware components used for rapid prototyping of a wide variety of projects.
I am using a Phidget 1018 I/O board along with a Phidget 1124 precision temperature sensor module. A digital input cable (?) connects the two components together. The main 1018 I/O board can be plugged in to any computer device via a USB cable. Currently, I am using my Arch Linux PC to develop on. Soon I will have it connected to a Raspberry Pi also running Arch Linux.
Libraries and drivers can be downloaded from the official Phidgets website, and are easy to set up for development. Devices can be accessed remotely by using the Phidget Network Server. "The Network Server exports the channels of each attached Phidget over the network. Using the Phidget22 API, clients on remote computers, phones, and Single Board Computers can attach to Phidget devices as if they were local."
The temperature sensor can measure temperatures in the range of -30°C to +80°C with a typical error of ±0.75°C in the 0°C to 80°C range. The temperature sensor component is rated at -50°C to +150°C, but the other components on the board, the connector and the cable are rated at -30°C to +80°C. According to the product page, in a fast prototyping environment the temperature sensor board can be pushed to the ratings of the sensor component.
I chose to use the Python API to communicate with the Phidgets because it is quite easy and quick to use for prototyping. I have a lot of experience using Python and it seems to be used fairly regularly in home automation projects. Additionally, I needed something that I could quickly run (and leave running) on a Raspberry Pi running a Linux distro, so I didn't want to deal with compiling C or C++ code, or installing a JDK for Java.
A HTTP server written in Python will provide a very simple REST API for the app to get data from the Phidget. For now, it will only have GET endpoints. In the future, I may consider introducing PUT and POST endpoints for things such as setting a sensor's name (see below for more future plans and improvements).
Some endpoint examples:
- GET /temperature
- GET /avg_temperature
- GET /min_temperature
- GET /max_temperature
The reason I chose to have a standalone server to deal with grabbing the sensor data is so that I can, in the future, make the server accessible remotely (and securely!) so I can monitor my house temperature while I'm at work or elsewhere.
The Android app will be written in Java, as I am more familiar with it than Kotlin. To start with, its sole purpose will be to display the temperature from a single sensor on the network. For the first stage, it should be fine to hardcode the IP address of the server on the app (or specify one in a textfield in the app). Later on, I can expand the server side of the project to include some kind of broadcast service that the app can discover and connect to, most likely using a protocol such as SSDP.
Smart LED integration
I have not yet decided where the integration with the smart LED lights will happen. In theory, it could be done with the app, by sending API requests to smart lights on the network. However, this might not be the best place to do it from, and may even be a separate background application that monitors the temperature on its own and sets the light colors at a pre-determined interval.
Future plans / improvements
- There will be a database that stores details about different sensors in a home (or other local) network
- The app will access the database and display a list of all available sensors
- When a user selects a sensor, more information about it is displayed (e.g. min, max and average temperature, room name, etc)
- The database mentioned above should also securely store user login details
- The app should make use of this feature to allow users to register user accounts and login
- This enhances security and allows the user to be in control of who can access their sensors
- API requests to get the temperature should make use of a secure token that is generated when the user logs in, and expired when they log out (or after a certain amount of time).
- SSDP broadcast and discovery
- Securing Phidgets on a network