Author: Niko Gupta

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

As a note to the reader, this past week we decided as a team to change our proposed devices from a combined sensing / smart device into 2 separate devices. One device will do only sensing, and the other will do only “actions”, such as turning a device on or off.

Another thing to note is that we decided to host the webapp locally. This means that one node in the network will be a “master”, and run the webapp. If that device goes down, the network should elect a new master, and then that device should spin up the webapp. As such all devices should have the capability to run the webapp

This past week I did research into how the interaction layer will be designed. In particular, I put a lot of thought into what data our system will contain, and how we might go about storing it in the system. I came to the following conclusions.

The data the system will need:

• Per-node sensor data (for sensing nodes)
• Identifying device information (such as a device id)
• Identifying smart home network information (for commisioning new devices and for reconnencting when a device goes down)
• Device list, and how to access each device (e.g. device IP addresses)
• Code for the webapp
• User’s settings
• Defined interactions, and when each interaction was triggered
  • This list of past interactions can be viewed by the user
• Last known status of a device. If a sensing device, last piece of data. If an actuation device, then whether device is on or off.

In thinking about this data, I came to the conclusion that we can minimize the complexity of our system if we minimize the data that needs to be shared. Here is the breakdown I arrived at:

On each node, modifiable data:

• Sensor data

On each node, hardcoded:

• Device ID
• Code for webapp

Shared across all nodes:

• Network id
• Registered devices list
• User settings
• Defined interactions / past transactions
• Last known device status

The biggest source of complexity here is the shared data. However, it can be further simplified because the majority of the “shared” data is information that will be needed if a device becomes the hoster of the webapp. The only data that needs to be written by all nodes is last known device status and past interactions.

My progress is on schedule.

For next week, I plan to research a few different database solutions using the above information as criteria for their effectiveness. For each, I will use our listed use cases and our metrics from the project proposal to evaluate their effectiveness. I hope to select a database technology, and then prototype how it fits together with the rest of the system.