After getting an overview of the different sub-assignments within project 2, we divided into subgroups. Two of us were initially assigned to work on the NodeRed app.
We started with testing the hardware, including the lock and the relay. Here we discovered that the lock was not compatible with our power supply. We instead we decided to add an LED, to simulate whether the lock is open (LED on) or locked (LED off). Since we are not able to build a physical locker, we also added a button that detects whether or not the locker is open or closed - i.e. door pressure on the button.
After testing the hardware and doing the basic coding in Arduino, we decided to elaborate on the functionality of the NodeRed app using a flowchart and a sketch of the interface as seen above. Pardon the Danish.
Coding it
We used some of the coding we had done in the exercises, and further developed it, so it could be used in our project. The email function was developed to save the name and code given in the webapp, and then send that information in an email. Later on we will add information regarding how much time the user has before her locker is unlocked.
We faced some challenges in developing this function. First, we couldn’t receive the email that the app send, since gmail has a filter that doesn’t allow emails from “unsecure apps”. Afterwards, we could only get NodeRed to send the email by pressing inject in the coding, and not by submitting in the App. This was fixed with guidance from Mathias, who showed us that the email function has to be integrated with the coding for the app interface.
We also had to develop code, which would take the state of the hardware button as an input, and use this input to decide the state of the locker as open/closed. This was achieved after experimenting with coding in Jason, and learning how information from hardware can be translated to be used in NodeRed.
A continuing dilemma in the development of the app has been the level of details to go into regarding usability. In a ideal scenario, the user would not be able to make any mistakes, as an example it would not be possible to receive an email if the user had forgotten to close the locker. Another usability aspect is how to prevent a user from booking an already occupied locker. We have decided to develop the most basic system first, and then add usability considerations later.
Moving further on
New day, new rotation - the team pivoted with more hands on deck with respects to NodeRed. We worked on how to compare the login username/password with the earlier chosen signup username/password. First of all - how to save the username and password as global variables? We use a function node to save the output from the sign up form (msg.payload.navn and msg.payload.kode) under a global variable each. This global variable can later be used in another function node, after the login node, to compare the output from the login node with the username and password variables. If they are the same, an ”ok” message will be sent to the MCU, and the lock can be opened. If not, the login app will send a message that the username or password is invalid/incorrect.
Later, we worked on making sure that the username and password could not be overwritten by another user while the locker is locked. We wanted to only display the login app (not the signup app) when a user scans the QR-code while the locker is locked.
Stay tuned for more.