Source Code

Source code can be found in my private GitHub repo at: https://github.com/evade-ninja/IT515FinalProject

Objective

Incorporate remote control into an existing garage door opener. The implemented system should be acceptable to my wife and not hinder her use of the garage door. Integrate the WiFi control with an event hub (HomeAssistant) and provide voice control through Siri/iOS Shortcuts App.

Materials

I used the following materials:

• 1x Wemos D1 mini
• 1x Wemos DHT11 shield
• 1x Wemos Relay Shield
• 1x ESP32 + LoRa module
• 1x LoRa32u4 module
• 1x large green button
• 1x magnetic reed switch + magnet
• 3D printed case for garage control module
• Some thermostat wire (to connect the sensor and to connect to the garage door)

Resources

How to make an HTTP POST request from ESP8266:

https://techtutorialsx.com/2016/07/21/esp8266-post-requests/

Home Assistant:

https://www.home-assistant.io/

Easy integration of MQTT based devices with HomeAssistant:

https://github.com/marthoc/GarHAge#mqtt-cover-basic-configuration

The web page control panel uses a graphic of a garage door from The Noun Project: https://thenounproject.com/markclausnunes/uploads/?i=276226

 

Components

Interface to the Garage Door Opener

The garage door opener interface module consists of a Wemos D1 mini with a DHT11 temperature module stacked with a relay module. These are contained within a 3D printed enclosure.

The device has an embedded webserver which hosts a simple web interface with HTTP Basic authentication, a REST webserver which uses API tokens for authentication, and an MQTT interface.

The devices have been installed in my garage as shown in the next set of images. The magnetic reed switch is placed above the door – with the sensor mounted to the wall and the magnet mounted on the garage door.

WiFi to LoRa Interface

The WiFi to LoRa interface uses an ESP32 with an on-board LoRa module. It has been placed in a 3D printed enclosure – you can see the LoRa antenna tucked beneath the device.

LoRa Button

The LoRa Button is a simple device based on a LoRa32u4 module. It consists of an Atmel ATMega 32u4 with a LoRa radio on the same board and a 500mah LiPo battery. The device has a switch on the bottom to turn it off and on. A large green button serves as the single input to the device.

HAProxy

To bridge the gap between the the iOS Shortcuts App, Siri, the Internet, and my local network, I set up an instance of HAProxy running on a virtual machine at my house. It functions as a reverse proxy with SSL termination. HAProxy is also performing separate HTTP Basic authentication to discourage outside attackers from accessing the garage door controls.

Shortcuts App

The iOS Shortcuts app is used to provide a custom interface to the home automation controls as well as provide Siri integration. The Shortcuts app makes an HTTP POST request via the HAProxy server, providing the Authorization string (for HTTP Basic authentication), the API Token, the desired operation, and the TTS parameter (to return speakable text instead of JSON). A Siri Phrase is also provided to allow Siri to run the shortcut.

Home Assistant

Home Assistant is an open-source home automation solution. It aims to provide a single pane of glass for all of one’s IoT devices. I initially tried to install it from scratch, but found it very difficult to do so. I ended up using the prebuilt Raspberry Pi image. I was able to integrate with the existing devices at home. I initially started down the path of creating my own device integration for the garage door opener but discovered that Home Assistant has many pre-baked device templates that are easily modified. Many of these templates are based around the MQTT protocol. I added an MQTT device that represented the garage door controls by adding a “shutter” device, and a device that represented the state using a “binary switch” (open/closed). The configurations used to make these devices can be found in the appendix.

From the Home Assistant interface, you can see all of the devices connected. The garage door, the Ring doorbell, my Octoprint server, and my Wemo switch are all shown. The controls for the garage door are shown under “Covers” and open/toggle/close the garage door. The status of the door is shown in the icons along the top.

 

Interconnection

The devices talk to each other via WiFi with the ESP32+LoRa serving as the bridge between WiFi and LoRa. When the “big green button” is pressed, it sends a packet over LoRa to the bridge, which makes a REST API request directly to the door control module. Requests from the Shortcuts App are first proxied through HAProxy to provide SSL encryption and pre-authentication and are then forwarded through to the door control module. Requests from the web page are processed on the door control module and do not use REST. Home Assistant receives data and sends commands over MQTT over several topics: one for door commands, one for door state, one for current temperature, and one for receiving a temperature command. The door controller will broadcast the current state of the door and the temperature every 30 seconds. This is designed to alleviate the problem of Home Assistant starting and being in an unknown state.

Final Thoughts

This project was not without its challenges. I spent about 16 hours on the hardware/software portion of this lab, not including the work on the garage door opener which I was able to reuse from labs during the semester. Some of the issues I faced were:

• I spent about an hour debugging a strange issue about missing libraries/function calls – it turned out I had an extra } in my code.
• Spending about 3 hours debugging an issue with the ESP32+LoRa module. After receiving a LoRa packet I tried to send an HTTP POST to the door controller, but kept getting “Guru Meditation Error: Core 1 panic’ed (Interrupt wdt timeout on CPU1)”. I finally determined that the LoRa message received function was too long with the HTTP POST request, and needed to move the POST call to a separate function.
• I had difficulties running the LoRa32u4 on battery power. It worked fine on USB attached to the computer, but not standalone. I discovered that the setup routine was blocking while waiting for the serial port to initialize. I removed the block, and was able to use the battery without issue.
• The Shortcuts app on iOS will allow setting up voice shortcuts that conflict with Siri’s built-in commands. “Open/close the garage door” worked sometimes, but most often was met with “You don’t have any garage doors set up in homekit”. I attempted to work around this with “Open/close the pod bay doors”, however, the open command was met with smart remarks such as “its already open and its getting a little cold in here” or “Us AI’s are never going to live that one down” or “That’s a rather insensitive thing to say to an intelligent agent”.

Issues aside, I actually enjoyed working on this project. We learned about REST and MQTT in class, but the full extent of their usefulness did not hit me until this project. Both are incredible in terms of interoperability. Instead of writing custom components, I was able to use both to create a custom component in a fraction of the time. I plan to use MQTT to develop additional devices to implement in my house.

Online Link

The code for this lab can be found in my private GitHub repo: https://github.com/evade-ninja/Lab6

Objective

Modify the existing garage door sensor and actuators to implement a RESTful API. Implement an interface, and additionally a non-web browser based interface.

Materials

• 3x Wemos D1 Mini
• 1x Wemos D1 Relay Shield
• Red, Yellow, and Green LEDs
• 3x 220ohm resistors
• 1x 10kohm resistor
• 1 magnetic reed switch
• 3x breadboards
• 1 ultrasonic rangefinder model HCSR04
• A Raspberry Pi 3B+
• Postman app (for debugging POST/GET API)
• Shortcuts app
• Ubuntu Virtual Machine

Resources/References

I used quite a few resources while working on this project:

Accessing the body of a request with ESP8266:

https://techtutorialsx.com/2017/03/26/esp8266-webserver-accessing-the-body-of-a-http-request/

 

C Multiline String Literal:

https://stackoverflow.com/questions/1135841/c-multiline-string-literal/1135862

API token in headers: https://github.com/esp8266/Arduino/blob/4897e0006b5b0123a2fa31f67b14a3fff65ce561/libraries/ESP8266WebServer/examples/SimpleAuthentification/SimpleAuthentification.ino#L124

Getting around CORS:

https://hackaday.io/project/12227-smart-home-in-the-iot-way/log/43430-esp8266-direct-access-from-web-app

HTTP Basic Authentication on ESP8266:

https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WebServer/examples/HttpBasicAuth/HttpBasicAuth.ino

Setting up HAProxy: https://serversforhackers.com/c/using-ssl-certificates-with-haproxy

https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04

https://blog.sleeplessbeastie.eu/2018/03/08/how-to-define-basic-authentication-on-haproxy/

https://medium.com/we-have-all-been-there/using-haproxy-http-basic-authentication-to-secure-access-to-kibana-5d878e46df85

Procedures

I started by defining what my REST endpoints would be for the opener using Swagger.

Figure 1- Door Controller (GET)

Figure 2- Door Controller (POST)

Figure 3- Distance Sensor API

Figure 4- Lights API

I created a GET and a POST endpoint. Both accept the “token” parameter which is used to provide some simple authorization for the REST API, as well as the “tts” parameter. The tts parameter when set to true returns the output as a speakable string instead of a short easily parsable string. This is used by non-UI clients and will be discussed later. On the POST endpoint, the “operation” parameter is used to designate the desired operation. The response codes are typical response codes, with 202 being used instead of 200 to describe that the command was accepted, but that the door may not actually respond to the command. The response code of 412 indicates that the door is not able to accept a command at the current time, either because it hasn’t been long enough since the last command or because you are trying to open a door that is already open.

Once I had the swagger defined for the opener, I implemented the REST API on the device itself. I chose to implement it as a separate web server instance on the ESP8266 running on a separate port. It took a fair amount of effort to add the REST API server. The most difficult part was figuring out how to read the additional headers presented by the client.

After the REST API was in place, I set up HAProxy on an Ubuntu virtual machine. The HAProxy instance provides SSL termination as well as HTTP Basic authentication. This will be used to provide internet connectivity for non UI access to the device. I created an SSL certificate for my Home Automation server.

With the proxy in place, I used the Shortcuts app (previously Workflows) to create a shortcut that would respond to Siri commands. The shortcut makes a POST request to the HAProxy server, includes the authorization header for basic HTTP authentication, the token that the device is expecting, the operation, and the tts (true) headers. The connection is authenticated by the HAProxy server, and then passed on to the opener device. The device then returns a response in plain text that can be read aloud by the phone. This provides a simple, yet powerful interface to control many different things.

After getting the Shortcuts app to open and close the door, I continued work on the web interface. I used the web interface from the previous lab and added some jQuery to the page that obtains the distance sensor information via the REST API on the distance sensor. I also added a simple username and password authentication using HTTP Basic Authentication based on feedback from the previous lab.

Figure 5- Web Interface Screenshot

Below is a diagram of the system from this lab:

On the internal network, the system largely depends on encryption of the transport layer to protect data. The web interface hosted on the door controller is protected with HTTP basic authentication using a username and password. The simple password keeps unauthorized users on the network from accessing the controls for the garage door. Devices internally communicate over MQTT or REST.

Externally, an HAProxy is running on a virtual machine running on my home network. External devices connect to the door controller via the reverse proxy, which provides SSL encryption over the internet and an additional HTTP Basic authentication to prevent malicious users from having direct access to the device. The proxy forwards connections to the door controller only if the correct basic authentication strings are provided.

The hardware used in this lab is unchanged from the previous labs. For reference, pictures are included below:

The distance sensor, the garage door controller, and the status lights indicator.

Thought Questions

1. How did you overcome the need for a full featured interface, as well as the need for an accurate and easy to use interface?
   This lab is all about the magic of the API. Instead of having specific, proprietary magic strings and URLs, using a REST API makes it easy to wire things together. One doesn’t need to use a proprietary interface, or even develop an interface. With the right set of APIs, one could make use of an existing interface to tie things together – such as HomeAssistant – giving the user a single pane of glass for all their devices.
2. This was a challenging lab for me and took a fair amount of time. I had issues with web browsers complaining about CORS (cross origin request security) and not wanting to load content from the distance sensor, I had coding mistakes that prevented the REST webserver from working correctly, difficulty retrieving custom headers from the ESP8266WebServer, and I had a misinterpretation of the lab instructions. Also, I couldn’t figure out why I had strange WiFi access points appearing named ESP with the mac address of the devices I was using. Turns out that you have to explicitly set the station mode or the device will also act as an open access point, allowing unauthenticated connections to everything.
3. I spent about 14 hours on the lab and about 1.5 hours on the report.

Online Link

Source code can be found at: https://github.com/evade-ninja/Lab5

Objective

Incorporate garage door control into the existing system while also evaluating potential security issues of adding control of a garage door via the internet.

Materials

I used the following materials:

• 1x Wemos D1 mini
• A blue LED
• 1x 330ohm resistor
• 1x Wemos Relay Shield
• 1x magnetic reed switch
• 1x breadboard
• Travel Router with VPN connection to home
• Raspberry Pi 3B+ running MQTT broker (from Lab 4)

Resources/References

I used a graphic of a garage door from The Noun Project: https://thenounproject.com/markclausnunes/uploads/?i=276226

Procedures

I started by thinking about all the different ways someone could break into my garage – both with Wi-Fi control and without.

Traditional Openers

• A nefarious individual could break into a vehicle that is parked outside and use the remote from the vehicle.
• An attacker could use a software-defined radio to capture remote control packets and replay them later. Many, but not all garage doors have switched to rolling code systems to try and combat this. That said, if enough packets are captured, it is possible that the attacker may be able to guess the next codes.
• Someone could use a sledgehammer/axe to break down the man door to the garage.

Wi-Fi Controlled Opener

• A malicious entity either has the Wi-Fi password or successfully cracks the password, accesses the controller, and opens the door.
• An internet-based hacker compromises a system on the local network, and uses that system to pivot to the controller, and opens the door.

Surprisingly, the risks from the internet are not that different from those of a traditional attack. Out of curiosity, I looked online to see how easy it would be use the SSID of a Wi-Fi access point and link it to a physical address. It turns out to be surprisingly easy. At https://wigle.net, there is a searchable database of Wi-Fi SSID’s mapped to physical locations. I was able to locate my SSID and correlate it to my physical address with surprising ease.

After looking at both network and physical risks and knowing that thieves are generally lazy and opportunistic, I believe that simple Wi-Fi security plus monitoring of the door status is sufficient for my needs. This however does not fit everyone’s risk profile. If one is popular online, all bets are off as nuisance attacks via the internet are more likely. In the event that someone does open the door without authorization (either physically or over the network), the door sensor will log the event and publish it to MQTT, where the alert can be acted upon.  Below is a diagram of my system.

I decided to merge the control module with the door sensor module. I did this to ensure that the device controlling the door had physical access to the sensors reporting the door state. This should help protect the device against flooding the MQTT server with erroneous door state messages as it is the authoritative source of truth.

Next, I proceeded to add the relay module to the existing sensor device. I placed the relay shield on top of the Wemos D1 mini. I connected an LED with resistor through the normally open terminals of the relay, and to 5V and GND. When the relay is activated, the LED will light up to simulate connecting the door opener terminals. Below is a picture showing my device.

I created a simple web page as an interface to the garage door sensor/controller.

The page has two buttons, and an area to display the status of the door. The door status is refreshed every 5 seconds via an AJAX call to the device. The code for the webserver is largely repurposed from Lab 2. When the door open button is clicked, the device checks the state of the door. If the door is closed, the relay is pulsed to simulate pressing the opener button. If the door is already open, the device returns an HTTP 412 – Precondition not met. When the door close button is clicked, the device pulses the relay to close the door. It does not check the status when closing the door – in theory it is possible to open the door by clicking the close button. I did not want the door to get stuck in an unknown state and be unable to move, so I chose to have the close button ignore the current state.

Thought Questions

How did you secure devices that are not inherently secure? How does layering security help?

The Wemos devices are secured with WPA2-PSK. While this is far from a foolproof measure, it does protect against casual attacks. If I wanted to add remote access, I could add a reverse-proxy that implements authentication and SSL encryption for security.

What was your biggest challenge?

The biggest challenge was overcoming preconceptions about security. Ideally, I would consider using an ESP-32 which is capable of on-chip SSL for security.

How long did you spend on this?

Lab 2h, Report 1h

Source code can be found at: https://github.com/evade-ninja/Lab4

Objective

Modify the existing garage distance sensor to only activate when the garage door is open. As the number of sensors and actuators increases, the complexity of the project reaches a point where simple machine to machine communication becomes overly complex. To allow additional sensors and actuators to be added to the system with ease, some sort of interconnecting system must be added, such as an MQTT broker.

Materials

I used the following materials:

• 3x Wemos D1 mini
• Red, Yellow, and Green LEDs
• 3x 220ohm resistors
• 1x 10kohm resistor
• 1 magnetic reed switch
• 2x breadboards
• 1x D3000 board, leftover from a previous project
• 1 ultrasonic rangefinder model HCSR04
• A Raspberry Pi 3B+
• A travel router with VPN connection to home

Resources/References

https://theembeddedlab.com/tutorials/install-mosquitto-on-a-raspberry-pi/ – was a great tutorial on setting up MQTT on a Pi.

https://github.com/256dpi/arduino-mqtt – library for subscribing/publishing to MQTT

Procedures

1. I started by setting up the Mosquitto MQTT broker on my Raspberry Pi. The tutorial mentioned above made the process very simple. Add the Mosquitto repositories to Aptitude, and then apt-get install mosquito.
2. Once the broker was installed, I tested it locally using some test commands:
   mosquitto_sub -d -t ‘/nh-garagedist’ to subscribe to a topic
   mosquitto_pub -d -t ‘/nh-garagedoor’ -m ‘OPEN’   to publish to a topic
3. With the broker running, I created a simple garage door sensor that would post the current status to the “/nh-garagedoor” topic. The sensor consists of a reed switch that opens/closes with a magnet, and a 10k resistor to pull the switch to ground when not closed. The sensor uses a Wemos D1 mini and connects via WiFi to the MQTT broker running on the Raspberry Pi.
4. I modified my distance sensor from Lab 3 to post the distances it sees in the “/nh-garagedist” topic. The sensor also subscribes to the “/nh-garagedoor” topic, and will only post when it sees the garage door open, and stops when it sees the garage door close.
5. I ended up re-writing the light controller, as none of the web server code was relevant for this lab. I was able to re-use a good portion of the code, and combined it with code that subscribed to the “/nh-garagedist” topic. When it sees activity, it will change its light state accordingly. After 15 seconds of no new posts in the topic, it will turn the lights off.

 

Thought Questions

1. Utilizing an event hub requires an initial investment of work to create said event hub, but that investment will pay dividends as any time new features are desired, it is trivial to wire them up to old sensors and actuators without having to revisit the code running on those devices. Old sensors can be used for new purposes with ease. Systems scale with ease. I had the thought while working on this lab comparing api-based systems
2. Direct communication is simpler on a small scale and also faster. The draw back is that scalability is limited as each new piece requires rewriting code on the other devices. An event hub makes it easy to wire up new sensors and actuators without rewriting code. It does add complexity as an event hub must now exist and be maintained. Honestly – as far as an event hub being a good choice, that is slightly dubious. This is a fairly simple system – car pulls in, lights come on. However, once we start adding to this system, it will get out of control very quickly without an event hub. “If you give a mouse a cookie, he will also make an expensive, overly complicated doorbell.”
3. My own laziness proved to be the largest challenge in completing this lab. Also Stellaris.
4. 6 hours, one of those was spent on this report.

Online Link

Source code can be found at: https://github.com/evade-ninja/it515-lab3

Objective

This lab is designed to take the Stoplight controller from Lab 2, and using a separate device, communicate with it to control its state. This will be implemented using the 3 color stoplight from lab 2, pairing it with another device utilizing an ultrasonic sensor, and having the two devices talk to each other using WiFi.

Materials

I used the following materials:

• 2x Wemos D1 mini
• Red, Yellow, and Green LEDs
• 3x 220ohm resistors
• 1 Ultrasonic Rangefinder model HCSR04
• 2x breadboards
• An assortment of jumper wires

References:

I used the following references in this lab:

• An Arduino Library for HC-SR04 ultrasonic distance sensors: https://github.com/Martinsos/arduino-lib-hc-sr04
• Madpilot’s mDNSResolver library
  https://github.com/madpilot/mDNSResolver

Procedures:

1. Modify the code from Lab 2 to implement a “blinking red” state and add an mDNS hostname. The blinking red light is to signify that the vehicle is too close, and the mDNS hostname makes it easy for the sensor device to locate the light device.
2. Implement the ultrasonic rangefinder device. This was done in two phases.
   2. First, using the HCSR04 Arduino Library, I made sure that I could get measurements that seemed reasonable over the serial port. My initial attempts were not fruitful. I ended up with strange results. I was getting distances of -1, and 2. After some trial and error, I determined that my issue was that the ultrasonic sensor was being powered off of the 3v3, but it required 5v. Once I powered the sensor off of 5v, I started to get values for distance that seemed reasonable.
   3. Second, I used only the Wemos device to test connecting to the Stoplight device. As IP addresses can be inconsistent, I decided to use mDNS to locate the Stoplight device. Surprisingly, there are lots of mDNS responder (servers) for Arduino/ESP8266, but finding a resolver that worked was surprisingly difficult. After trying several differently libraries, I eventually came across Madpilot’s mDNSResolver library. Once I had the mDNSResolver working, I was able to communicate with the Stoplight device with ease.
3. With the two halves ready, I united them. I defined distances for “too-close” (flashing red), “just right” (red), and “almost” (yellow). My code takes 5 readings from the sensor and averages them. In the event that the rangefinder returns negative results, these are treated as not far enough and result in a green light.

Thought Questions

1. Think about the interaction between your devices. How well would this scale to multiple devices? Is it easy to add another sensor? Or actuator?
   Adding another sensor or actuator would require recoding of some degree. Each additional sensor or actuator would require additional coding. After 1 or 2, it gets unwieldly very quickly.

2. What are the strengths and weaknesses of the tennis-ball-on-a-string system that Don had originally? What are strengths/weaknesses of the IoT system? What enhancements would you suggest?
   A low tech solution using a tennis ball on a string is simple. It is cheap. It doesn’t require batteries. It does however require someone to relocate it if the vehicle changes, or if someone tampers with it (like hitting it with a baseball bat). A high-tech solution does require power and some initial configuration, but vehicle changes would be fairly easy to implement. There are some concerns with over-complicating “things”. A wise engineer once said “the more they overthink the plumbing, the easier it is to stop up the drain.” Although more complicated, knowing if the vehicle is parked in the garage is nice, and being able to quickly adjust for new vehicles is nice if one frequently changes vehicles.
   As for enhancements, the ability to change the appropriate distance through a web interface or by pressing a button would be quite nice.
3. What was your biggest challenge on this lab?
   The biggest challenge was the mDNS resolution. It took me a good hour to find a library that would work.
4. How much time did you spend on this lab?
   I spent about 4.5 hours on the hardware/software portion and about an hour on the lab report.

Objectives

• Enumerate requirements from use cases and stories
• Learn to utilize the GPIO pin on the Wemos D1 Mini / Arduino, becoming familiar with the Arduino programming environment
• Learn to develop a minimum viable product and build incrementally on it
• Learn to use Github for code commits and version tracking

Materials

I used the following materials in this lab:

• Wemos D1 Mini
• 3x LED’s (1 red, 1 green, 1 yellow)
• 3x 220ohm resistors
• Jumper wires
• Micro USB cable (for power / programming)

References

I found the following things helpful during this lab:

• ESP8266 Example “AdvancedWebServer” (included with the ESP8266 board definition files)
• MacOS Drivers for the CH340 Serial Converter: https://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html

Procedures

1. Solder the headers to the Wemos module. I chose to use the female+ long male pin headers to allow connection to both a breadboard and other pass-through type devices.
2. Install the Arduino programming environment.
3. Install serial drivers if needed. Windows 10 does not require additional drivers for the CH340 USB serial converter, however, MacOS does require drivers. I was able to find signed drivers at: https://kig.re/2014/12/31/how-to-use-arduino-nano-mini-pro-with-CH340G-on-mac-osx-yosemite.html On MacOS High Sierra a restart is required to complete the driver installation.
4. Install the ESP8266 board definitions. To do this, open Preferences inside Arduino and add http://arduino.esp8266.com/stable/package_esp8266com_index.json to the list of board manager URLs.
5. I hooked up the LED’s to the Wemos D1 Mini using 220 ohm resistors.
   
6. Make sure to set the board type correctly, as the IO pin assignments are not consistent across board types. I initially selected the wrong board which produced boring results. The correct board type is “WeMos D1 R2 & mini”.
7. I started with the example “AdvancedWebServer” and added additional endpoints to handle each light color (/color/red, /color/yellow, /color/green), off (/off), and automatic mode (/autolight). These are the same endpoints that I used in my implementation on Raspberry Pi. Using the same endpoints allowed me to reuse the HTML file I created in the previous lab.
8. The autolight implementation is similar to my previous implementation. The activation subroutine for the automatic light sets a flag indicating the auto light is active, records the current time, and sets the initial state of the light. Each trip through the main loop, the program checks to see if the autolight flag is set, and if sufficient time has elapsed since the last change. If both conditions are true, then the light is advanced to the next state. The automatic mode can be canceled at any time.

Thought Questions

1. What are some key differences between developing on a Raspberry Pi and an Arduino/Wemos?
   A Raspberry Pi has a full OS, drivers, services, applications, and so forth. An Arduino/Wemos has a small amount of flash memory that contains the small amount of program code that it will run.
2. What are some strengths and trade-offs of each platform?
   Arduino allows for quick, simple execution. It is very useful for single-purpose devices that need to run as a standalone device. Because there is no OS, there are no updates, there are no failed services – its just your code and some hardware. That said, there are a number of limitations on Arduino that one does not face on a Pi. On an Arduino type device, you have limited storage (4MB), and limited RAM (32KB). One is also responsible for all aspects of the device, there is no Apache web server or PHP code – everything is written in C. Mis-dimensioning an array will result in a crash and reset of the device or other strange behavior. Debugging can be much more difficult as there is no display. On the contrary, a Pi provides greater horsepower, more memory, more storage, and more flexibility, and more responsibility. Both have their purpose and are often used together in projects.
3. How familiar were you with the Arduino platform prior to this lab?
   I have done a number of personal projects with Arduino prior to this lab and am quite comfortable with it.
4. What was the biggest challenge you overcame in this lab?
   I spend about 45 minutes debugging an issue with the automatic mode of the lights only to discover that when changing the lights in automatic mode I was inadvertently executing the command to exit automatic mode. The lights would advance from green to yellow, but never from yellow to red – they simply stopped. I finally discovered the error after much frustration.
5. Estimate the total time you spent on this lab and report.
   Lab: 2.5 hours
   Report 1 hour

Source Code

Source code can be found on my private GitHub repository: https://github.com/evade-ninja/it515-lab2/

Objectives

• Enumerate requirements from use cases and stories
• Learn to utilize the GPIO pin on the Raspberry Pi
• Learn to develop a minimum viable product and build incrementally on it
• Learn to use Github for code commits and version tracking

Materials

I used the following materials in this lab:

• Raspberry Pi 3B+
• 3x LED’s (1 red, 1 green, 1 yellow)
• 3x 220ohm resistors
• Jumper wires
• 5V power supply for Raspberry Pi

References

I found the following things helpful during this lab:

• Python Documentation
• Documentation for RPi.GPIO Module – https://sourceforge.net/p/raspberry-gpio-python/wiki/Home/
• Python Multithreading Tutorial – https://www.tutorialspoint.com/python3/python_multithreading.htm
• Python Simple HTTP Server – https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler
  https://daanlenaerts.com/blog/2015/06/03/create-a-simple-http-server-with-python-3/
• Bootstrap 4 Component Library – https://getbootstrap.com/
• Uses “Light Traffic by Maxim Kulikov from the Noun Project” for the logo.

Procedures

1. Download a software image for your Raspberry Pi. I used Raspbian Stretch Lite from https://www.raspberrypi.org/downloads/raspbian/ . Once downloaded, write the image to an SD card.
2. Connect to the Pi – either with a keyboard/mouse or via SSH. To connect via SSH, you’ll need to start the SSH server from the Raspberry Pi Configuration application raspi-config.
3. Install git: sudo apt install git
4. Add the pi user to the gpio group to allow it access to the GPIO pins:
   sudo adduser pi gpio
5. Hook up LEDs to resistors and to GPIO pins using jumper wires and the breadboard.
   
6. Determine how your webserver will talk – will it use POST or GET requests to change the lights? I chose to use GET requests with a path that corresponded to each of the colors, along with paths for OFF, and automatic mode.
   1. /color/red /color/yellow /color/green /color/fyellow would change the lights to the respective color, with fyellow representing a “flashing” yellow light.
   2. /off turns all the lights off
   3. /autolight enables the automatic mode, where each light is lit for 5 seconds before proceeding to the next light.
7. Determine how you want to implement the automatic light timing. I chose to use a thread with a semaphore variable that would cause it to exit when it was no longer desired.
8. Write/Install code of your choice. I used a combination of Vim running on the Raspberry Pi and Notepad++ running remotely. The Python webserver primarily served up a simple index.html page that was read from a file and passed to the web browser. The web page makes use of the Bootstrap 4 theme which is hosted through their CDN.

Thought Questions

1. What language did you choose and why?
   I chose to use Python. As much as I hate Python because of its use of whitespace delimiters instead of traditional brackets/braces, Python has good support for simple webservers and GPIO.
2. What is the purpose of the resistor?
   The resistor is to limit current and prevent the LED from blowing up.
3. What are practical applications of this device? What enhancements would you make?
   As silly as it sounds, I think there are several practical applications for such a device. One could use a network-connected stoplight to indicate readiness of an individual – red could be unavailable, yellow could indicate that they are on the phone, and green could indicate they are ready. At many doctor offices there are colored flags that indicate patient state – ready for doctor, needs nurse, etc. that this device could be used for and integrated into a patient management system.
4. Estimate the total time you spent on this lab and report.
   Lab: 4 hours
   Report 1.5 hours

Source Code

Source code can be found in my private GitHub repository.
https://github.com/evade-ninja/it515-lab1

I’ve wanted to add a rear view camera system to my truck for almost a year now. I have a 2000 Chevy K3500 that I drive and tow my 20′ travel trailer with. Having a rear view camera makes hitching up to the trailer a breeze. I had one on my last truck and I could hitch up in one shot.

I added a camera to my last truck and learned a few things in the process. First, E-bay cameras work well enough (and are cheap!), but the voltage regulators in them are not designed for continuous duty. I had hooked the camera power up to the 12v aux line for the trailer connector, so the camera was powered whenever the truck was running. Depending on the temperature, the regulator would enter thermal shutdown after 20-40 minutes of driving. I did that so that I could turn the camera on whenever I wanted.

Version 2.0 will be an upgrade from the previous version. Features include:

1. Up to 3 camera inputs
2. Ability to activate camera without being in reverse
3. AUX input?
4. Provision for powering the cameras from the controller (avoiding the problem of overheating the regulator)
5. Look cool!

I’m a big fan of ATMEGAs and Arduinos, so they’ll be my development platform of choice. I’ve found a Quad Analog Switch works fine for switching video. In the past I’ve used a CD4066 Quad Analog Switch. There are lots of parts that will work – I actually ended up using a different part because its what I could get locally.

Bill of Materials:

• 1 ATMEGA 328p
• 1 74HC4316 Quad Analog Switch
• 1 16MHZ Capacitor
• 2 22pf capacitors
• 2 10uf capacitors
• 3 2N4401 transistors
• 3 2N4403 transistors
• 1 2N3904 transistor
• 1 L7805 voltage regulator
• 5 10kΩ resistors
• 3 4.3kΩ resistors
• 1 3.3kΩ resistor
• 1 0Ω resistor (you could also just use a piece of wire)
• 1 4-pin dip switch
• 3 PTC fuses

The Display

I also needed to come up with a display for the system. In doing some internet research, I found that my truck has the mountings cut out for an overhead console behind the headliner. All I needed to do was to cut the headliner to expose it. In my first junkyard trip ever, I managed to find a short overhead console out of a Suburban. I removed the rear AC controls, and designed my own front panel for it. To make a template for the panel, I scanned in the AC controls and edited the image in Adobe Illustrator. I was able to make a vector outline of the panel and designed my own front panel. I then used a the template to laser-cut some clear acrylic. I lasered in multiple passes- first, I cut only the paper backing where the monitor would go. I then removed the rest of the paper backing, and spray painted the acrylic with some cool looking metallic paint. I then cut out holes for buttons and etched labels for the buttons.

Before doing any of the laser cutting, I first had to acquire a screen. Ebay was my friend again, and for $18 shipped, I ordered a small 3.5″ monitor with RCA inputs. I had read on another blog post that some of these displays were shipping with touch overlays – but alas, my luck I didn’t get one of those. I removed the display from its housing to verify it would fit in my overhead console. I also measured the viewable area so I could size it properly in my template.

Now all I needed was a user-interface. It would be really neat to be able to display things on the video screen, but due to cost and simplicity, decided against it. I decided I would have 2 buttons and 2 LEDs just above the buttons. I laid out a small board with Eagle that also had provisions for video passthrough and power passthrough to simplify things.

Bill of Materials for the Interface Board:

• 2 Piranha LEDs (I chose blue!)
• 2 tactile pushbuttons
• 1 330Ω resistor

That’s it! The interface board is meant to be driven by the control board.

I’ve attached my schematics and template. I meant to write part 2, but never got around to it. Sorry.

 CamControl.zip
CamControl++.pdf
CamControl++-board.pdf
CamControlInterface.pdf
CamControlInterfaceBoard.pdf