Chindogu

Our locker is made from laser cut plywood and designed using the website called festi.info, where we made a Rounded Box. This made it simpler to assemble the box and allowed the corners to be rounded. We modified the design in AutoCad, were we drev the holes for the OLED, the Buzzer and the power supply. We also drew the shelf in AutoCad with a hole for the chords. Then we printed the box in 6 mm plywood, and engraved the drawings, text and symbol, drawn in Illustrator.

We engraved the QR-code on the front together with the link for the webside. We also engraved our group name, DTU-logo, and course info. On the inside of the locker we engraved “Remember to close me when you’re done” as this is an important step for the closet to function properly. We used a piano hinge, so we were sure the door would be aligned.

• 

• 

We decided to solder the NodeMCU and chords to a perfboard, and soldered the chords connected to the buzzer, the OLED and the other components. We chose to solder everything together, to make sure that everything would stay connected as we were moving it around.

• 

• 

• 

• 

• 

On the inside of the door we mounted a mirror. The electronic part is hidden by a top shelf, so both the lock and OLED is placed at the top. The board and NodeMCU was glued to the shelf, and the OLED and buzzer was glued to the front of the locker.

At last we assembled the front, back, sides and shelf, and tested if our door and the lock fit together. We wanted the OLED screen to have a better appearance, so we laser cut an acrylic plate for the screen. Finally we drilled the holes for the bolt and nuts to mound it on the pegboard in Skylab.

See the finished design here: https://wordpress.com/block-editor/post/chindogu.home.blog/138

By: Aksel N. Ladegaard and Sebastian Mc. Aleer

Aksel:

Today has been the last sprint in finishing the cloud based logic for the IoT Safe. I’d just like to offer a quick overview of the methodology of solving this task and why we chose the solutions we did.

The assignment requirement was 1 safe, which means there isn’t need for a database (which we haven’t been taught about yet) so we have done all dependent on flow variables.

The whole flow is initially triggered by 1 of 2 things:

1. Registering a new user
2. Unlocking the safe

The administrator of the safe has the option of doing a few more things:

1. Manually injecting MQTT commands through the interface on cloudmqtt, which is the broker that we use
2. Manually reset it through nodeRed, where we have made an admin reset button (inject)

The safe is constantly governed by a few flow variables which are set in nodeRed over mqtt, these variables are:

1. Safe
2. Lockerstate
3. Password
4. Email

Safe, can be one of three values: undefined, available & inUse. Depending on this we can check whether the safe is ready for registering a new user, unlocking and so forth.

Lockerstate is initiated from the nodeMcu which changes everytime the lock solenoid is triggered. This is only triggered for around 100ms, so it immediately sends a message over the broker and the flow variable is set in a function node.
This is essential as to detect when the safe is just closed and in use. This can be detected with 2 switches (ie. if else statements).
First one checking the Safe status, if it is in use and it is locked, then the locker has been closed after registering.

Emails: we use 2 flow variables to store the email recipient and the flow password as content.
Our emails are created out from a simple email template with some custom styling which has been written in HTML and CSS. We have then converted it into a single line string. In one example we have made it insert password as a string.
This could also have been done in a template node, but we have used the function node.

Much of the logic and inputs in the flow has been created with trigger nodes, which need to be reset before they can be triggered again. This results in most of the complexity in the system with a dedicated MQTT topic for resetting the system when it’s relevant. There are also smaller resets, for example at the unlocking logic for checking if the password is incorrect.

Some places in the flow, there are a few unintuitive delays, for example before a few password/email resets. This is due to ensure that all relevant emails or other flow variable dependent functions trigger before the reset.

Sebastian:

Todays work has consisted of examining, editing and commenting the NodeRed code. Organising the flow with aligning nodes and branches makes reading and understanding easier. Comments can be read to gain better understanding.

Before the Easter holidays, we wanted to try and finish the project, in order to enjoy our vacation time. Therefore we worked hard during the time in class, and we met up to spend a whole day together working on the project.

During the class we worked with the NodeRed, the NodeMCU code and with incorporating the buzzer. We also made our first locker prototype out of cardboard.

When we meet up on the following sunday, we startede with making a to do list, and then dividing the tasks among us.

We also drew up the user flow in order to get an overview of it. In short the user would come, sign up for the locker, put in their stuff, close it and walk away. When they go to pick their stuff up again and close the door, the locker should reset. But to make a successful locker, there are different cases that we need to account for.

The first scenario is that the user signs up, but then changes their mind, and doesn’t close the locker. We agreed that if the locker was left open, it should reset after 5 minutes, and that the OLED should write “Close me”.

The next scenario is that the use does not come and pick up their stuff. Should the locker reset after 24 hours? 48 hours? or 72 hours? We agreed that it should open and reset after 48 hours, and that we wanted to send an email notification to warn the user 2 hours before the locker would open automatically.

The code

After making the user flow diagram, it got clearer what the NodeMCU should communicate to NodeRed and vise versa. We decided that, based on the function, there should be different topics, so the communication between NodeMCU and NodeRed would become more readable. It also made it easier for us, to implement a function that directly takes the payload from the NodeMCU to the OLED, without printing things unnecessarily for the user. Our whole setup has been made to ease the memory of the NodeMCU and do as much functioning possible inside NodeRED. In one line; the nodeMCU controls the hardware and NodeRed handles the UI and UX.

The code has also been cleaned up, so that only functions, we still use, remain. The text for the OLED was changed, so that it matches the lockers status. It will say “The safe is available” when not in use, “Welcome to the locker” when the user is putting their belongings in, “The safe is in use” when in use, and “Please close me” if it has been open for more than 5 minutes. The different buzzer sounds were also successfully implemented (see separate blog post).

NodeRed

We also continued reorganising the NodeRed. We set up the log-in forms, so the user could fill in their email and password when signing up, and insert their password for unlocking. We wanted the user to receive an email with their chosen password

We had a bit of trouble, with NodeRed remembering the users password and matching it to the e-mail when signing in. No matter what it would just say wrong password. We made the password a flow variable and made a switch (a NodeRed node, a glorified if elif, else statement), where it checks the sign in password against the sign up password.

The emails we created with NodeRed, was a bit simple and they looked very plain. Therefore we made the different emails we needed with HTML and CSS, to give it a nicer, more readable design. There is an email for the sign up, the 2 hours warning email, the reset email after 48 hours, an email for wrong password, an email for correct password, and one for the 5 minutes reset. This could be improved in the future by using NodeRed template nodes.

The locker

The first prototype of the locker was a simple box, with a hole for the OLED and space for at shelf to hide the Node MCU and the breadboard. Both the prototype and the final locker would be laser cut.

During the class we cut the first version of the box, in cardbord, but later we decided to change the design a bit.

We changed the corners to rounded corners, and we added a hole for the buzzer. Read more about the changes in the blog post about the locker assembly.

A code has been completed which outputs little custom melodies to the Piezo buzzer (passive).

In the process of determining which melodies was relevant, we also discussed a lot of overall functions about the locker so that the product produces clear feedback to the user and acts accordingly. As result we came to 5 unique sounds for 5 unique scenarios:

“SUCCESS” = When the closet has been succesfully accessed via email pincode, an anthem plays.

“LOCKED” = When the locker has been locked, a short confirmation tone will be played.

“FAILED” = If accessing the locker fails (wrong password) or timer runs out when the door is open, a failed tone plays to alert the user.

“PING” = When the locker has been open for 30 seconds, a reminder will alert the user that the locker is still open.

“KIM POSSIBLE” = When the rental time has run out (after 48 hours) the Kim Possible signature plays, hopefully to deter any nearby thieves; as thieves fear Kim Possible. It’s common knowledge.

The code was initially set up from code originating from:
https://pastebin.com/jdhs9LXB

The melodies were created and customised within the sketch. Rearrangements and shortening made it ready for implementing it in the main code.

For this week we have four main goals for finishing our smart locker:

• Getting the buzzer to work
• Unlocking via password
• Sending an email notification with text and password
• Assembling the box

The buzzer is the only hardware we need to implement. We know how to make the buzzer work using the bare minimum circuit, so we are working on making the buzzer sounds more appealing. This is done by using som libraries that allow for playing notes and then structuring them into melodies.

We also know how to control the lock using the button in MQTT, but we have yet to figure out how to control the lock via Node Red logic dependent on a password.

By using the node ‘form’ in NodeRed we have succeeded in sending an email to the email address we provided in MQTT. What we need to work on, is getting the text in the email correct – for example adding the chosen password to the email.

We have already made the blue print for the box, so the goal is to laser cut it and glue it together before we go home. The box will be vertical with the OLED screen at the top. The electronics will hidden by an upper plate.

NodeRed is an online coding platform accessed via Cloud IBM (BlueMix). The coding form is to connect the wanted node functions and specify their behavior via programming and various inputs ( such as perhaps Topic, Passcode and Port for MQTT input/output ). Initially NodeRed has been programmed with two functioning “button messages”, so that when they’re clicked on the UI message strings are sent to the MQTT.

Our nodeMCU is subscribed to the Topic and will receive the strings. Now our web client will show the text current on the OLED, now you can know from our web client is the lock is lock or not.

We also set up the web client with to form so it remembers the Email for the confirmation and remember the password. The next step is to set up NodeRed so it remember the password and check the password, when you need to unlock the lock.