Here’s our final report for iDoorlock. Despite all the remote difficulties, we’re proud of what we accomplished this semester.
Ever hate fumbling through your keys in your bag, or losing them and having to mold and cast new ones? Modernize your home with the iDoorlock! All you need is your phone and to register a lock. Our fast and secure solution uses NFC to securely authenticate users to unlock doors. An app controls what locks your phone can unlock, and also shows lock history. The lock also comes with nice LED indicators, and a button to lock the door again. All you need to do is swipe your unlocked phone! Think Apple Pay security and speed, but for your door!
Final Demo Video: https://youtu.be/eWi8j9th0b4
Since the last update, I’ve been going back and forth between TechSpark and my home nearly constantly, and I think I’ve had a 3D printing job always running. But after these past 14 days, we finally have a shell that wasn’t marred by the TechSpark printers and a working servo motor horn (thanks to TA Mobolaji for helping with some prints!). I’ve also added extra LED functionality for the final project as an indicator for the user. I’m excited to put everything together, and we’ve spent the time since Monday’s demo making sure that our final video will showcase the project well and that our final slides reflect our testing we’ve been doing.
Open issues: now that everything physical has been finished, all that’s left are the slide deck, video, and final live presentation.
Photos: final shell design, examples of printer issues 🙁
This week, I worked on the integration with both Alex’s and we completed the housing integration with the locking mechanism and RPi + NFC reader. I also began working on the final report and presentation slide deck as the presentation is coming up next week.
Next week, I’ll be delivering the final presentation and working on the video and final report. We have no more work for integration so I will be able to focus all of my time into both deliverables. We will definitely be able to get those done by their respective deadlines.
No issues to report, integration is done and we just have to complete the deliverables now, which should be simple. As we have already recorded the locking mechanism for the video, there shouldn’t be any need for us to meet in person anymore, which is good timing as we are all going home this weekend.
This week I made minimal changes to my code. My portion of the project has already been completed, so I just combined the parts together. I also helped test and verify the LED and button functionality, which were simple because we just needed to signal the LEDs on success/fail, and the button acted as an auto success. The logic was already there, so we just signaled the GPIO pins on the RPi to indicate statuses. The fully combined product had some issues automatically running, but I was able to fix that part.
For the video, I took clips of a full run through, from the user opening the app for the first time and registering a name, to swiping the phone for authentication. We recorded every possibility including failure. We will not be together in person, so we made sure we had the clips we needed for the product.
There isn’t much specific to discuss in this post, because all the technical details were already ironed out in the past week. Next week I will be working on the video and documentation. I should be able to finish the presentation by tomorrow.
This week we finished our product and integration. Alex Xu finished the component housing, and we combined our original reader+RPi with the housing and LEDs. The total amount of work here was not that much because our respective parts were working well and there weren’t many bugs.
We also started working on the presentation, final report, and video. For the video, we recorded clips of unlocking and failure to use in our final video. We will be going home next week, so we did this portion early. For our presentation, we are planning to finish Sunday, but everything is put together and we know what type of user story we want to present. For the final report, we plan to work on it throughout this week.
There weren’t many issues present this week surprisingly, because we expected there to be many bugs when combining the parts. We put extra time towards doing the other assignments, and we hope to have the documents and video done by next week.
This week I worked on the final features and integrations for the app. For functionality, I tested and made changes to the phone to server interactions. This includes being able to register a lock with a lock ID, where a POST request will be sent to the server and a phone’s unique ID will be added to the lock’s accepted phone IDs. Phone IDs are generated by the server, where upon opening of the app, a GET request will be sent to the server for a randomly generated phone ID (unique). Anyone with a link can get a phone ID, but actual authentication passes the phone ID to the NFC reader for authentication, which sends phone ID and lock ID to server for authentication. This ensures that anyone with the app will need to register a lock ID before authenticating. Because HTTPS is used, middlemen should not be worried about. Another feature planned was to do remote lock/unlock, where a similar scheme of exchanges are used, except instead of using NFC to send the phoneID, an endpoint will be set up for the Raspberry Pi and the phone will make HTTPS requests to send the phone ID. The endpoint still needs to be set up, we are trying to configure certificates and setting up to accept HTTPS requests. This feature may not be included in our final product, because functionally if the user wanted to lock the door using this feature, he/she would need to open the app and it would defeat the whole purpose of NFC’s quick and easy message passing. We considered a separate PN532 chip on the other side of the lock for locking, but this is not feasible as RPi does not support this. We are finally considering a button used as a lock measure, which will be easy to add because we are done with all of basic work and integration. For the remote lock, to elaborate, using it remotely also may cause problems with power consumption, because setting up the raspberry pi as an endpoint is wasteful in terms of energy.
We are on track because we are done with a prototype aside from the component housing. Next week we should have the final product ready, and will be considering additional features to improve the ease of use of our product.
This week, we have made a large amount of progress in integrating our parts together. Alex Xu has been making great progress with the CAD designs for the motor horn and RPi housing, and the Android app has been fully integrated with the server API calls. Since we’ve already integrated the RPi with the server calls, our system should be completely connected. Adding additional features should be fairly simple as well, as the code required for Android is relatively simple and adding a new endpoint would be easy as well.
For next week, we will be performing end-to-end integration testing to ensure that our entire system functions properly. We don’t anticipate that this will take too much time, since we’ve already been able to turn the lock and send messages successfully. We also are considering which additional features would be valuable to add, and have not yet come to any decisions.
One possible issue we may run into is TechSpark closing after Thanksgiving break. We plan to use a third-party 3D printing service in case we are not able to complete our prototyping before the break. We also know some friends who have 3D printers who we can ask as well, so we don’t anticipate TechSpark closing to impact our schedule significantly. Given that our integration is basically complete, we have a decent amount of slack to cover for the prototyping.
This week, I completed integration of the REST API endpoints with the Android phone application. The phone is now able to register a new lock and other users are able to get permissions for the lock if they have the secret lock ID. The phone is assigned a unique phone ID that it passes to the RPi whenever it scans the reader, and it is sent securely to the server to see if the user has permissions to open the lock. Now that the Android app is integrated with the server, the server integration is complete. For next week, I will be working on the overall system integration to hopefully complete our project before Thanksgiving. We just need the 3D printed case to be completed and then we can integrate everything together. I will also be working on verifying the security setup we currently have for the REST API. AWS API Gateway provides our REST API calls with HTTPS protocol, and we will be using the same method with authenticating with secret keys, so the security setup should be as secure as it was with the previous WebSocket iteration.
No issues to report. The server side is complete and everything is working properly per the tests that Alex Li and I have run on the API calls.
This week I 3D printed the servo motor horn that we’ll use in our setup. I originally planned on printing it in 2 parts due to horn shape concerns, and after 4 print attempts over 3 days I managed to get both parts functioning. The bottom mounts on the servo motor, while the top fits the lock tailpiece. The durability should last, but if it doesn’t it isn’t the worst to 3D print more parts out as I believe TechSpark is open after Thanksgiving. Once secured, the custom horn does its job of allowing the servo motor to open the door. I’ve also begun doing some CAD on the demo shell we plan to use. I’m going with an open top box design for now (subject to change), and the current issues revolve around making sure measurements will be precise enough to fit everything inside well.
Open issues: finishing the remainder of the 3D design and printing the last few things we need. Ideally I think I’ll be able to get the parts printed before Thanksgiving, and that’s all I’ll be focusing on next week.