My progress over the last week has been steady research and thinking about how we are going to solve many of the problems with the hardware of this project. I’ve been out of town this whole past week for the UAA Swimming and Diving Championships in at the University of Chicago, and have only had intermittent time to do work in between swimming. I also forgot to start reading The Pentium Chronicles before the deadline, because I didn’t realize I had to be finished with those section a week before we discussed them. I will be working hard this week to catch up on the book for the discussions and to get all of the design down in writing.
The first problem I’ve been thinking about is what “devices” to use to demo our project and what our MVP should be. I’ve been writing down lists of home appliances, devices, and kitchen gadgets and trying to think about how to turn those into smart devices using a raspberry pi and also what interactions those devices can have with each other. Actually, what just popped into my head was that we can make one or more devices sensor devices that drive this systems interactions with humans. Maybe that could work. Without much more thought into that, I’ve narrowed down our MVP scope to a breadboard with “sensors” and “actuators”, LEDs and buttons. I think that this is a good decision because it allows us to put two people on the initial interaction layer work for the majority of our first phase. I think the datastore on the devices is going to be the hardest and most crucial piece of the project, and having two people on that will make problem solving a little bit easier. I also think that, since our system is device ambiguous, we won’t need to have specific devices to show an MVP.
The second problem I’ve been thinking about is how we’ll be storing the data. From past work, I’ve learned that key-value stores are much better than relational databases for storing sensor data or polled data. Because of this, I’m leaning towards using Redis as a data-store on these devices. Niko should be looking into other databases and how they might fit in to the project as well. Redis is a big player in log storage and has recently pushed into the IoT field. The problem doesn’t necessarily stop with that decision though, because there’s many, many ways to store data in Redis, and we shouldn’t be too hasty in deciding that. I’m still split between using Redis in a cluster among all the devices and having the webapp request from that cluster everytime it needs data, and having a Redis instance on each device and writing a distributed protocol for all these nodes to act as one system. The first option allows us to use built in functionality of redis, but will take significantly less effort, and the second option will take significantly more effort but will show that we did more work. I think I’m going to have a conversation with our TA about this one, because I’d really like to use the built in functionality and then build on top of that, but it might not be considered enough work to be a full project. I’m also not 100% sure how much work either of these design decisions will be and have to look into that.
