Throughout the last year of school, I've had a part-time job as a student developer for IoT research going on in UCI's CS department.
"TIPPERS is a system that manages IoT smart spaces by collecting sensor data, inferring semantically meaningful information from it, and offering such inferences to developers to create smart applications."
More information on TIPPERS can be found here. Generally I describe TIPPERS as a large API focused on security and generality in the types of data to perform cool IoT functions on campus, homes, or even a navy ship.
My role has revolved around doing front-end development for the new applications, creating styling guidelines, and helping integrate authentication functionality in the system.
You can see my name at the bottom!
Right now I'm working on a generalized occupancy application for the system. The goal of this is to showcase a lot of the data that the system collected over the summer of 2019. In the app, you can load onto a campus, building, or floor, and click through to deeper sub-levels, viewing occupancy data each level you go down. It's expected to utilize real-time data, with date ranges available if you wanted to see how an area looked a week ago for example.
Below is an older screenshot of the application, showing the global view of UCI's campus with some dummy data for occupancies.
Working on this application throughout the Fall of 2019 to the present has been one of the more challenging projects that I've taken on. TIPPERS as an API aims to be flexible, and thus the applications built upon it needs to focus less on the names of entities that record data (buildings, campuses, rooms) and more on the hierarchy of the entities. Theoretically you could show anything on this application provided it fits into one of the three categories for data types.
What does this mean? Honestly I've been trying to figure this out myself. Throughout the last month we've generalized the types to the above three. This means you could load the application with a root type, and it would automatically load from there, with availability to click to deeper sub-levels. The best way to see this is to look through the pictures below. (Again using dummy data for now)
Right now we're still in the stage of connecting everything, as some work needs to be done on the API's end before it can be linked up to the application. So far though, I think it's been an interesting architectural design challenge and helped me beef up my experience with React's context API.
T-Portal was the project that I worked on Spring of 2019. It involved authenticating users using a central authentication system, letting users change their security settings, and adding new entity/data/observation types to the TIPPERS system. Challenges for this included deciding a lot of the architecture that went behind building an Authorization server. This was particularly difficult because we want users to be able to set up their own TIPPERS instances (API's and respective T-Portals), but authenticate themselves through one central server.
My partner Tristan Jogminas handled most of the really complicated OAuth stuff, and we worked together to build the base of the T-Portal that's being worked on today
I've contributed to a lot of front-end design work with TIPPERS, which is great because practice makes perfect. Below is the TIPPERS style guideline, as well as the logo I designed for the system that's now used across a lot of it's marketing materials. I made a few of these throughout working at this job.