Smart Light Demo

    Software and Programming Languages:

  • HTML/CSS/JS (Basic Webpage and interfacing with the API)
  • NodeJS (API middleman to allow clients to interface with the server)
  • Python (Scripts called from the API to control GPIO pins)
  • Apache2 (Used to host the webpage)
  • Cron (Used to call a bash script to start the API on boot)
  • systemctl (used to start Apache2 on boot)

    • Hardware:

  • Raspberry Pi 4B
  • Breadboard
  • 2 Jumper Wires
  • 1000 Ohm Ressistor
  • White LED

Basic Functionality

The main goal of this project was to create an interface that multiple users/clients could access and control simultaneously. In this case we are controlling a light from a webpage and relaying the current status to all clients.

Build Process and Hurdles

CORS which stands for Cross Origin Resource Sharing initially threw an error from non-localhost clients. Upon further research this standard is used for some amount of screening as a permision system of sorts. It looks for where the incoming requests are coming from and either allows or denies the request based on their IP and MAC addresses. To fix this error I set request permissions to all domains which can be found in index.js line 12. This allowed for client devices to send requests to the raspberry pi via the buttons on event feature regardless of where they are coming from (LAN, WAN, etc) (External use could be achieved with port forwarding or a vpn).

Before the current iteration of the light status on the webpage the implemented system had each client asking the API for the status on loading the webpage and every .8 seconds. This system floaded the API with requests and was very inefficient. A lot of the time the status hadn’t changed, creating multiple redundant requests. The more clients added to this time based system, the more inefficient it became. (especially when some of the mobile clients kept pinging if they weren’t closed but were open in the background). The current implementation makes the API responsible for keeping the clients up to date instead of the clients sending individual requests. This is really convenient because we can send all of the clients an update on the current status everytime we get a request to change the light (on or off) reducing the amount of pinging to the API significantly. (The system above doesn’t solve the problem of the initial loading of the website so it still sends a request on load for the current status).

First half: Two clients the one on the right shows requests sent to the API and the one on the left shows messages from the API to the client.

Second half: Two clients with the API's output looping through and broadcasting the light state change to update the current status for all clients.

Potential Vulnerabilities

Snooping: Since this is using HTTP and not HTTPS none of the data is encrypted and it is transmitted in plain text so anyone trying to listen in will easily be able to read the data transmitted.

Spoofing and unauthorized requests: No type of permission system or authorization is setup for this so any device could send viable requests without any screening and potentially setup a man-in-the-middle attack with data poisoning. (With the small scope of this it’s not very destructive or useful but definetly something to keep in mind if you’re setting up something that collects more user input/data).

DDOS's: This setup could easily be flooded with enough requests to be inaccessible this could be fixed with a reverse-proxy, a segmented network, setting up CORS correctly, and limiting traffic to only authorized people or devices.