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.