This past week, I was focused on implementing more of the Web Application that will be used for controlling the system devices and interactions.
Specifically, I fleshed out the interactions page. Each interaction is represented by a condition, a device, and an action. When users visit the interaction manager page, they can view their current interactions as well as define new ones.
As a group, we decided that we would host the web application on one of the raspberry pi’s. Since all our simulation devices are on raspberry pi’s, we thought it didn’t really matter which device the webapp was hosted on, so our delegation for which one actually hosted was pretty shallow: the host would just be the device with the lowest serial number in the system. After the feedback from the presentation on Monday, we realized it might be beneficial to have a slightly more involved process for deciding which device gets to host the webapp, especially in the case of a node going down.
In terms of our schedule, I’m slightly behind, as I have not begun work on the backend yet. The backend depends highly on the models that the databases on the devices will employ, so while my team is working up to that point, I will continue work on the frontend.
In the next few days, I want to mount the web application on a raspberry pi through docker, timing how long it takes for it to become live. I also want to see how automated this process could be, because while it ideally should be fully automated, I suspect it will be a little harder than it seems.
During the design review, our TA Jiaqi told us about an alternative to the raspberry pi board: a nano board often used for IOT applications. This board can connect via WIFI, has a processor, can host a simple server, and is a lot cheaper than the pi’s. We are considering switching to use this board, and if we do decide this, I’ll have to figure out how to mount the web app on this as well.
