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.