Posted on

Alex Li’s status report for 11/21/2020

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.

Posted on

Team status update for 11/21/2020

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.

Posted on

Michael Chen’s status report for 11/21/2020

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.

Posted on

Alex Xu’s status report for 11/21/2020

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.

Posted on

Team status update for 11/14/2020

This week, we were able to prevent our subsystems in our MVP during our project demo. Alex Li worked on Android app UI development and functionality, Alex Xu worked on lock mechanism and casing CAD design, and Michael worked on transitioning to REST API and developing its security. We met briefly for our project demo to show off our work so far to Vyas and Jiaqi, and we also talked about how to adhere to our remaining schedule as we wrap up the capstone project.

One risk we need to factor in is the delay in TechSpark services that may crop up as we approach the end of the semester. The self-serve 3D printers are mostly unaffected, but just to be safe, we’d like to get as much of the CAD designing done as soon as possible to avoid any pitfalls. The COVID-19 case at TechSpark unfortunately limits working as closely as we would have liked with TechSpark staff, but we will try our best to work with what we have left. We think that optimistically we’ll still be okay in following our schedule despite these potential delays.

A minor change to the existing design of the system was the addition of the REST API to our system. It will take the place of where we originally wanted to open a WebSocket connection. This change was necessary due to a couple of compatability issues WebSockets were causing to the remainder of our system, and we’re confident that this switch can be done within a fast timeframe and maintain the same level of security and speed we previously had aimed for.

Next week, we plan to finish the two aforementioned tasks related to REST API and CAD, and we’ll also develop functionality and implement a better UI to our Android application.

Posted on

Alex Li’s status report for 11/14/2020

This week I wasn’t able to get as much work done as I intended due to job interviews and coursework. I originally intended to complete the UI development + all the app functionality for this week, but was not able to. Today, tomorrow, and Monday, I expect to complete all the UI development.

Here is an image of the app so far. I have a simple home screen which should display all the locks by name as buttons to click on and get more information. Clicks on the lock buttons will bring up a new Activity, where Username and time of unlock will be provided in a list for the past 30 days. At the bottom of the home Activity, there will be 2 buttons, 1 being lock and the other being unlock. These will provide functionality to unlock and lock the door remotely. I have not yet implemented these portions yet, but they should all be complete in the next few days because I will be working extensively on these parts. There is a plus button in the top right representing lock registration, which will bring up the Register Lock activity.

Here is the lock registration. There are a few text fields to fill out. This sends HTTPS requests to the local AWS server for these fields to be created. This should create data fields on the AWS server for a specific lock. I have not yet tested out the HTTPS requests yet, but will get to that tomorrow when me and Michael will work together to verify that the correct information is being inputted. There can be multiple errors, which will cause an error message to pop up right above the register lock button. For example, if the fields are not all filled out or if the lock ID is already registered, there will be an error message. After the request, there will be a response from the server with success or fail, and the user will be sent back to the home screen. I will also add a back button, which should take minimal time.

Overall, I am a bit behind schedule, but I plan to catch up this weekend and on Monday. I should be done with everything soon, and I have a really clear picture of what to implement and how.

Posted on

Michael Chen’s status report for 11/14/2020

This week was a rough week for me since I got sick, so I was not able to get as much work done as I was hoping. Since we made the switch from WebSocket to REST API, I was able to implement a couple of endpoints for the RPi to communicate with the web server and retrieve a response letting it know if should open the door or not. I also worked on the REST API security to make it the same as it was for the WebSocket. We require that any request appends two IAM tokens that the server authenticates before doing any further processing.

Next week, I will be working with Alex Li to get the server communication set up from the phone. We will be implementing the phone and lock registration endpoints so the phone can contact the web server securely and register new phones and locks. Once registration is set up, the core functionality of the server should be complete and we can begin looking at any additional features we’d like to implement.

No risks to report for now, I believe we are on good track to finish and work on stretch goals as well.

 

Posted on

Alex Xu’s status report for 11/14/2020

This week I helped my group ensure that the demo went smoothly on Wednesday. After that, I had originally wanted to go into TechSpark to further discuss my 3D printing-related plans, but I was told that there was a positive COVID-19 case in TechSpark, so I instead went back to Autodesk CAD and watched tutorials. A friend of mine mentioned that making the parts may be more easily done in Autodesk Inventor and told me that connecting the motor horn could be done more easily by melting the plastic printed part and molding it with the motor horn base, and I plan on talking more with him about a better adhesion method as he’s done this before. I think running by the overall box housing by him as well would be a good idea too.

Open issues: going from CAD/Inventor to 3D printing. I’d like to create at least one of the two as a prototype, assuming the self-serve 3D printers still work. I’ll prioritize the motor horn/motor horn connector first, as that’d allow for a proper lock mechanism, and the aesthetics can come later.

Next week: 3D printing. Preferably both of these being done as prototypes so I will have images next week, but if not at least getting the motor horn (connector) will get us significantly closer to what our project will be.

Posted on

Michael Chen’s status update for 11/7/2020

This week, I worked with Alex Li and Alex Xu to integrate the server communication code onto the RPi with the NFC reader and servo motor code. We are now able to send information from the RPi that is received from scanning the phone to the server, and the server will reference this data against the database to see if the user is permitted to open the door. If they are, then the server sends a message telling the RPi that it should unlock the door, and it drives the motor to unlock the deadbolt. I also added IAM authentication to the WebSocket connection so that any client that wants to connect to the WebSocket must send valid and authorized IAM keys as query string parameters. If these keys are missing or invalid, then the WebSocket will reject the connection.

Now that our project is fully integrated, there is a lot of work to do for polishing the design. Next week, I plan to refine the server code to make it more robust in case of failure or unexpected parameters. I also plan on working with Alex Li on the WebSocket connection code to ensure that the connection is stable and reconnects on disconnect without overloading the WebSocket as well as the prototype design with everyone else.

Once again, there aren’t many major risks to report. We’ve been making good progress, and I believe we have more than enough time to refine our design and component housing prototypes by the time the end of the semester comes.

Posted on

Team status update for 11/7/2020

This week, we were able to finish our subsystems needed for MVP. Alex Li worked on finishing reader + host card emulation code, Alex Xu worked on motor code and combining the motor and the lock, and Michael worked on client server code for simple authentication. The project is mainly combined now for the demo, aside from the last client server code integration which Alex Li is working on to finish (should be done today).

Our potential MVP basically works by hardcoding a phone ID onto our phone (auth token will be given by server later on), swiping our phone to the reader which reads the token via NFC, then sending the token to the server for authentication, which will respond with yes or no, and starting the motor based on yes or no. Based of this MVP, we simply need to add layers of security for web/phone side, and for the lock side we just need to create a component housing.

The only changes were to the client server code, where Alex Li rewrote the client code in C, but using the same logic as the code in Python that Michael wrote. Because we set up everything correctly, adding layers of software security should not pose any significant risks. A potential risk is part failure, but we anticipated this so we bought a few extra parts.

Next week, we plan to finish security for web/phone app with secure authentication using certificates. The housing is also being worked on, so it should be complete by next week. Alex Li will work on the phone app UI as well, and by the end of next week, our project should be complete. In the weeks following, we have slack time to do things like polish our prototype or find and fix holes in security.