This past week, I decided to use sqlite as the database for storing the local data on each device. We are aiming to make our code footprint as light as possible while still keeping the system fast, and sqlite helps to accomplish both those goals.
I also set up 2 raspberry pi 4’s that I have lying around at home. I had never set one up before, so it took a lot longer than I had initially expected. After getting all the parts I needed, I loaded up the Raspbian OS. I then connected them to the local network and set up sqlite on each of them, and spent some time figuring out how to read from and write to the database. After that, I figured out how to designate one of the pis as an MQTT broker, and then set up processes on both pis and on my laptop to act as clients. I was able to get all of the processes to subscribe to channels and receive published messages.
In terms of our schedule, I am a bit behind where I had intended to be. Most of this week was spent on design, and so I’m not as far into prototyping as I would like. I also had a couple projects and an exam this week for my other classes, which took time away from capstone.
In order to get caught up, I plan to spend most of Tuesday and Wednesday working on prototyping, since all my other work is due by Tuesday morning, and I leave for spring break Wednesday night.
The main thing I want to accomplish in the next few days is to finish thinking through our design. Our design review brought up a couple potential issues with our proposed solution that as a group we need to address. We still have time to do so over the weekend before our final design is due Monday night. I also would like to work on prototyping the system, and to have some barebones system functional.
Here are the problems in our design that we have found over the past week / were brought up in our design review:
- Look into nano board – often used in IoT applications, potentially powerful enough for our use case, and far cheaper than a raspberry pi
- Think more about security of the data, maybe encrypt data when on the the wire and in the db
- We would like to achieve maximum 1 second delay between device interactions. However, our master failover rate is 3 seconds – so in the case of a master node going down, that 1 second requirement is violated.
- Consider other master selection techniques than “lowest serial number”
- Maybe host broker on different device than webapp to take load off master
- Need more granular failure testing than just “chaos testing”. Things can go wrong in interactions between devices too, not just on device uptime.
- Hardest part about distributed systems is resiliency – should really think more about it
- After a device fails and a new master is
selected, need to think more about how devices will be forwarded to the new webapp host, since it will be at a different IP address. - How will devices outside of the network access the node hosting the webapp, since it’s in a private network? Look into static IP addresses
- Low energy pub / sub: ESP8266 + ESP32
