At our place of employment, we have very nice facilities and offices. In general, our facilities department does a great job keeping things stocked, but occasionally we run into situations where the restrooms are out of supplies (paper towels, soap, etc.).
The current process for getting things serviced is to submit a facilities request to our facilities department. However, this process has many flaws in it:
- How many people remember to contact them by the time they get back to their desk?
- Has the facilities department already been contacted about this?
- Do I email them or call them or what?
Our employer allows engineers to spend one day on a Hackathon project of our choice. Usually, we tackle problems that are in the products we build, the tools we use, or other things which make our job easier. For this Hackathon, we decided to do something to fix this problem.
Initial InvestigationPrior to the Hackathon, we met with our facilities department to determine their process for servicing the restroom and more about the equipment involved. We also learned some useful information to help us scope the problem during the meeting.
At our facility, we have the following:
- 67 Restrooms
- 131 Paper Towel Dispensers
- 275 Soap Dispensers
The restrooms are serviced twice a day and partial rolls of paper towels are moved from lower floors to higher floors to make sure the entire rolls get used. Our facilities department services approximately 17,000 work orders per year, with only about 400 of those being restroom related.
They provided a paper towel dispenser and soap dispenser for us to breakdown. So, we proceeded to see if we could somehow tie some electronics into either of these........
After looking at these, we decided to avoid a solution that required modification of the existing paper towel and soap dispensers. This would create a lot of work for our facilities department in order to implement the changes.
Our First Solution
After extensive brainstorming, we decided to use an Amazon Dash button so that we did not have to build any custom hardware. Also, we were curious how they worked and how programmable they were. So, we purchased a few AWS IoT programmable buttons for use on Hackathon day. We figured we needed 3 notification buttons:
- Paper Towels
- Soap Dispenser
- Plumbing Issue
These buttons would be mounted near the entry/exit of each bathroom and labeled appropriately.
At a cost of $20 per Amazon Dash button, this $60 price tag seemed expensive considering we have 67 Restrooms to outfit with this solution. However, we decided to see if we could make this at least work on Hackathon day since we already had the hardware. To do this, we had to interface with Amazon's AWS services for IoT to implement the rules to generate the facilities request email appropriately.
Another downside to implementing the Amazon Dash button solution was the battery life and ease of replacement. Basically, the Dash button would give you about 2,000 button presses, but then would have to be thrown away because the battery was not replaceable. Based on the use of standard batteries in the other equipment in the bathroom, this did not seem like a good solution.
Our Second Solution
Because of the high cost, lack of battery replacement, and dependence on the AWS Cloud of our first solution, we decided to build our own second solution that required no outside network resources and at a cheaper price point. The ESP8266 immediately came to mind since it was around $10, provided enough inputs for us to have 3 buttons, and could be battery powered.
Our day had arrived and we started work. With a team of four people, we felt we could accomplish both solutions. Two of us proceeded with pursuing the AWS Dash button solution while the other two team members started work on implementing the proposed custom hardware design.
First Solution
After a few hours of modifying the various AWS IoT configuration pages, we finally got an email generated when the button was pressed. With as much work as this required, we realized that replacing the AWS buttons when the batteries ran out (since everything was keyed to the serial number of the physical button when setting up the AWS rules and lambda functions) was not going to be a practical solution. Also, there was no easy way to determine when the request had been serviced since there was no two-way communication that we could implement back to the button.
Second Solution
For the second solution, we had to write several pieces of software to make the entire system work. A few of us worked on the ESP8266 while others worked on the Raspberry Pi side of the system.
ESP8266 Software
On the ESP8266, we wrote the software for button detection and sending notifications to the Raspberry Pi running the MQTT broker. We also had to write software that would recognize notifications from the MQTT broker on the Pi so that it would know when the service request had been completed and to stop flashing the LED near the button. All of this communicated over the WiFi network.
A custom NodeMCU build from NodeMCU-build.com was used to operate the ESP8266 Huzzah board, with the following modules included: bit, enduser_setup, file, gpio, mqtt, net, node, rtcmem, rtctime, sntp, tmr, uart, wifi. Not all of these were put to use in the initial round of development. We felt that the slight reduction in available memory was acceptable given the convenience of not having to reflash the module with another NodeMCU build later when those features were needed.
The code for the ESP8266 is written in LUA, utilizing a multiple-file arrangement which allows us to easily separate the functionality of the code into different stages of operation. The first stage is in init.lua, which is run at startup by the NodeMCU system. The code in this file checks to see if one of the buttons is being held down. If so, it halts the script and returns to the NodeMCU command line. This provided a handy way to prevent code bugs from forcing us to reflash the entire ESP8266 in the event of an infinite loop.
The next stage of operation, startup.lua, connects the ESP8266 to the public WiFi in our building. Once the connection is complete and an IP address is assigned, the final stage of operation is launched.
The third and final stage of operation, notwet.lua, monitors the three front panel buttons for state changes, manages the LED states and also handles MQTT transactions as needed. The unit normally stays in this stage until it is reset or power is removed.
Raspberry Pi
On the Pi, we made use of the open source MQTT broker called Mosquitto (https://mosquitto.org) to handle the sending and receiving of messages. We proceeded with writing a custom python script for receiving the published events from the ESP8266 and then creating an email for the facilities request.
Once we had this operational and detecting the buttons properly, we then realized we needed a way to determine when the service request had been completed and we were no longer out of paper towels, soap, etc. This functionality really served two purposes:
- Inform the person in the bathroom that facilities had already been notified.
- Save battery power on the ESP8266 board since we would quit blinking the LED for the corresponding button.
To do this, we needed a way to poll to determine when the request completes.
Our facilities request system will generate an email back to the reporter once the job has been completed, so we decided to insert an intermediate gmail account that we could poll to determine when the request was completed. This account would be the "reporter" of the request and would receive the response from facilities once the job was done.
The python code on the Raspberry Pi side used Google's gmail API to create the initial facilities request email to our system, including the location of the bathroom and what needed to be serviced. The format of this request email was as follows:
There is a < button name > issue in the bathroom located in room ID: <room ID>
Upon receipt by our facilities request system, an email is generated back to the reporter email ( our intermediate gmail account ) with a unique facilities request number in the subject.
Your Facilities Request #<ID number> has been assigned.
The python script on the Pi then looks for this ID number and then maintains internally the state of this request, correlating the room ID with this new request number. Once a request ID number has been assigned, the python script will not report the same issue from the same room even if the ESP8266 publishes the event again. This prevents multiple requests for going out to the facilities department for the same issue.
Once the job has been completed, another email is generated to the reporter using the same request ID.
Your Facilities Request #<ID number> has been completed.
The python script on the Pi polls for this email to be received and transitions that job to the completed state. It then publishes an event to the MQTT broker indicating the room ID and button name which has been completed. Because the ESP8266 is subscribing to these events, the MQTT broker then publishes this event information to the ESP8266.
Cayenne DashboardWe started looking around for various dashboards that we could use to monitor the requests from the ESP8266 to the Pi and then onward to facilities. After a little research, we decided to use the myDevices Cayenne Dashboard tools to build a dashboard for displaying the various requests made and their state.
To get started with Cayenne, we signed up for an account and installed the Cayenne Raspberry Pi Agent and libraries using the instructions found here.
After verifying connectivity between the Pi and the default Pi Cayenne dashboard widgets, we then proceeded to create a custom dashboard for our project.
For our dashboard, we wanted to view the following statistics:
- Paper Towel requests made, submitted, and completed
- Soap Dispenser requests made, submitted, and completed
- Plumbing Issue requests made, submitted, and completed
In addition to these statistics, we wanted to implement a button on the dashboard that would allow us to remotely reset the state of a requests in case we missed the request completion email in gmail.
To receive statistics from the Cayenne MQTT broker running on the Pi, we had to map out the channel numbers to use for each of the desired statistics.
With this information in hand, we proceeded with building the dashboard in Cayenne.
Completed SolutionAfter completion of our Cayenne dashboard, we tested our solution with the facilities department to verify we could correctly make a request, wait for the request to be serviced, and relay the completion of the request back to the ESP8266 board located in the bathroom.
As shown in the video below, the button presses, submitted requests, and completed requests are accurately tracked in the Cayenne Dashboard.
ConclusionWe believe our custom solution for this problem could be easily implemented in our facility at an affordable price point. We plan on continuing work on this project to see if we can reduce the cost and the power consumption on the ESP8266 part of the design.
Comments