web
The Web Application
The goal was to create a web app that would be simple, easy to use on any device, and would be potentially extendable. At the time, we did not yet know how the locking mechanism would work, how the weight sensor would function, or what would be going on behind the scenes.
This meant starting with the user interface. The goal to be mobile friendly and simple lead to the use of Bootstrap, an open-source front-end web framework. Originally, most of the site was using the Bootstrap framework to quickly and easily build a top and horizontal navigation, followed by a middle-centered control block of buttons. Most of the Bootstrap has been disregarded in the final build, but some of it remains in the buttons and spacing. Google Fonts/Icons were also used for style. JavaScript and Ajax (Asynchronous JavaScript And XML) allow the box to monitor the buttons.
When clicked, the buttons run the code to lock or unlock the box without having to reload the page. This is done by adding two event listeners on the two buttons, and code to handle each scenario which uses a small amount of Ajax to build and send the request. This method of implementation of the web app allowed us to adhere to the overall goal of simplicity and extendibility.
From the site’s perspective, the site needs to know when something is placed inside the box, and needs to be able to tell the box when to lock or unlock. Nothing should be stalling or waiting unnecessarily--especially not the site. The user should not be hindered in their use of the site as they wait for a package to be put in. The site and the user should come first with a seemingly direct control over the box. The first order of action was to get the web server up and running. Normally this would be easy, but doing so on a Raspberry Pi and dealing with moving the Raspberry Pi to any wi-fi network -- and being able to access it from any network around the world -- required a more advanced tool: Dataplicity.
The site needed the ability to do more than just front end HTML/CSS/JavaScript. The client (or web page the user accesses) needed to send off information to the server, and then the server should act and reply. A framework would help save a lot of time and handle a lot of the work. Because the locking and weight sensor scripts were in Python, the group used Flask, a Python framework.
Dataplicity acts like a middleman for managing wi-fi networks, and has support for hosting a website with relative ease. According to the Dataplicity website, “Dataplicity Wormhole allows you to host a website from your Raspberry Pi, regardless of where it is installed, at a specific address: https://.dataplicity.io/. Port forwarding, firewall exceptions and Dynamic DNS are no longer required” (Dataplicity). This was the solution needed to connect the Raspberry Pi to host the web app. All that was left was to install the Dataplicity client and its dependencies, and follow the steps to enable Dataplicity Wormhole.
The site needed the ability to do more than just front end HTML/CSS/JavaScript. The client (or web page the user accesses) needed to send off information to the server, and then the server should act and reply. A framework would help save a lot of time and handle a lot of the work. Because the locking and weight sensor scripts were in Python, the group used Flask, a Python framework.
Flask is a microframework for Python. It has a built-in development server and debugger, integrated unit testing support, is Unicode based, and is extensively documented. It has been used to create a diverse array of apps from twitter-like websites, to blogs, to many Raspberry Pi hosted websites. The most important feature of Flask is the RESTful request dispatching. This allows a client to make a request for a page, handle the request with ease and use any needed functions, and then return and render the view. Dataplicity is nicely compatible with Flask as well.
To summarize, this step enabled the user to set both the port the device would use and the script to listen to. Migrating the static website developed earlier into one using Flask was the next step. Flask works by having the Python .py script which stores the functionality and starts the webserver, and then in a folder within the same directory called “templates” we have our view files ending with .html. In the same directory, we have our static folder with CSS and JavaScript files, our weight sensor script to communicate with the server script, and more. For each view we have, we have a route mapping the view to a function. So, when a user clicks on the “status” button, they are routed to the status function in the .py script. The function reads the data the weight sensor has written, updates variables, and sends those variables off to the view by redirecting to the status.html view.
The following steps to connect everything came with relative ease thanks to Flask because all the source code was written in Python. Earlier on, the group had taken a moment to debate putting the source code in the web application’s Python script. Instead, the group decided to have all other code call the methods inside of the script. This allowed the other scripts to use the site. For instance, when the load cell script decides to send a notification to the user, it simply calls the notify function in the server’s script. The notify function uses the SMTP established by using the Flask-Mail interface to send an email to the user on record; however, the connection was not completely there for everything we wanted to do.
We could use a database, or even use additional frameworks and tools, but we decided to keep our simple methodology going and have the weight sensor and the server pass messages through a file. Anytime the box is locked or unlocked, that state change is written to the state file. Anytime the box senses a weight change, the weight is written to a state file for the weight as well. This allows both scripts to run in parallel and not be hindered by what the other is doing, and communicate by reading or writing messages. This approach was only further encouraged and reinforced by the implementation of the locking mechanisms, and how the group was writing to a file to change the locks to be either locked or unlocked.
At this point, the Raspberry Pi can start up the web server, start the weight sensor script, and now the box can do everything it needs to. Something can be set in the box, the user is notified, and they can then access the site and with a click of the button lock the box. They can see the weight of what is inside, see whether the box is currently unlocked or locked, and unlock it when they want to. The box does what it is intended to, however, the product idea did not include the user having to remotely log into the machine and start up the server every time the box was powered on. As a result, a bashrc script was written to run on startup, calling a Python script that cleans up the environment and starts the webserver.
From here the goal is to improve the site, fix some of the styling and add styled SweetAlert notifications for when the user locks or unlocks the box. SweetAlert is a CSS and JavaScript package that modifies the default JavaScript notification.