Author: rlyster

This week I mainly worked on the final presentation. I will be presenting so I wanted to take the lead on formatting the presentation and the content. I decided to use a presentation format called assertion/evidence because I’m a little bored with the “Solution Approach” slide titles I keep seeing in every presentation.

I also helped Niko figure out some bugs he had in the interaction layer that came to light after integration and deployment. I control the emulator and whether or not it’s running, so anytime he’s debug I have to be involved for the most part. I think that’s a good thing to have to have two people involved with the debugging. It’s certainly helped us figure stuff out a little quicker.

This week I finished the first version of the hardware emulator. I’ve been working pretty much the whole day for the past couple days to get this all working together. The first version will use the Django admin page as a frontend and uses the Django REST framework as an interface between the hardware library on Niko’s interaction layer and the emulator webapp. I’m really excited to demo this, because it’s actually able to handle all different kinds of devices, with multiple pieces of hardware (sensors/actuators) simulated in it.

We also got the full system integrated from end to end. This is however with some minor errors but nothing that overshadows the actual purpose. We can go in to Richards webapp, create a new device and bring that up in Niko’s interaction layer, and then see details of that device in my emulator. I’m very excited to see how the demo to our advisors goes.

this week I haven’t done much on this project. I’ve kept up with what Richard and Niko are doing but that’s about it. I know that having something ready for the demo next week is going to be tough, but I’ve had a lot of other things due and I have been lacking on motivation. I’ll work to have something working for next week.

This week I started The hardware emulator. I decided to use Django, a python framework, because Niko is building the interaction layer in python and integration might be simpler if we use the same language.

For the emulator, I plan on first getting a basic webapp with data models up and running and then working on the library that Niko will use in his interaction layer nodes. Once these two are talking, I want to implement the full communication API. I found a REST framework that works with Django and I think I might use that. I’m debating whether or not to actually have a frontend or to use the Django admin page that Django provides as a means to view the data. For now I’m going to use the admin page.

This past week I thought a little bit more about what the interface between the interaction layer and the hardware layer will look like. I started with a few assumption:

• The devices running the interaction layer will need to register their device type and their functionalities
• The interaction layer will need to access and control the device hardware
• The device should be identifiable at the hardware layer, so that the interaction layer can self identify if the power is cut out or the interaction layer is messed up

From this I thought about how the device would be commission. I want setup to use standard interfaces, so a json setup file will be sent from the interaction layer on the device to the hardware layer. This will tell the hardware layer everything about the physical setup, where sensors are plugged in, how they’re interfaced with, etc..

From there the hardware layer will store that profile and offer standard interfaces for each sensor or actuator. For example, there will be a read temp function a thermistor. I think this type of dynamic interface will be really intuitive to use for the interaction layer and will easily scale to many devices, whether it be with hardware or in a software domain like this project is.

I want to start working on this layer this week, and create more block diagrams to explain this more specifically. I think this online system can be used as a testbed if this system ever gets put on to actual hardware.

We’ve discussed how this project is going to progress and I’m confident in the outcome. I’ll be creating a hardware emulator using react and nodejs. The interaction layer will interact with it through the same interface that I had planned for the original hardware. I don’t have that interface planned, but I’d like to start experimenting with different ideas, of which I don’t have right now.

This is a diagram of the original vs new hardware layer. It summarizes the changes to the hardware layer better than I can explain it.

We’re still discussing what will happen with the interaction layer, and how we’ll virtualize that. I think we should use Qemu to emulate the RPi hardware and run that in AWS, but that might be overcomplicated, since we are likely doing all of this using a higher level language. I would be okay with using a few aws instances and treating each instance as a device, but I like the idea of Qemu and I think Niko can do it.

Richard’s part doesn’t really change at all, which is good because he’s got a pretty good web app going already.

By next week I want to think a little bit more about how this interface is going to work.

Got news that we won’t be going back to physical classes. While this is upsetting, I’m thankful that this project isn’t super dependent on hardware. While we would like to test this on real hardware, we can get by without. I’m not sure what that will look like yet though. For now, I’m focused on driving back up to PGH and getting all my stuff. I’m going to try to pick up some of our parts too. I hope I’ll still be able to. I don’t think we need them, but I wanted some of those for personal use.

I’m unsure as to how the next week will look, and I don’t think the course staff is sure either. I still want to complete this project, so I don’t want to change it too much. We need to sit and discuss how to do this without being together or having any physical hardware. For now, that’s about all that’s on our plates due to the circumstances.

This week I finalized the parts list with my groupmates and ordered the parts. I admittedly didn’t do much else. I’m starting to think a little bit about how I’m going to interface with the interaction layer, but not in much depth. it’s probably a little bit late to be thinking vaguely about that.

Next week we’ll be on spring break so I don’t expect to do much. I’ll be with both of my groupmates over spring break, so if anything comes up we can handle it. We should get our parts in the middle of spring break so I’m excited for that.

This week I took notes in the design review and worked on the design presentation. I’ve been thinking about some of the comments we got back regarding privacy too.

In our presentation, we claim that having all your data locally helps with privacy, but we don’t mention privacy again. We forgot about privacy for the most part during our initial designs and I’ve been thinking of ways to incorporate that into our design. What I think I’d like to do is encrypt the consumers data that is produced in our system with a customer key. That way, only the consumer that has registered these devices can access that data and holds all permissions.

This past week I spent time working on the design of the hardware for our system. It was not very difficult to realize that we didn’t want to hack processors on consumer IoT devices. That would be time consuming and would not have a guaranteed outcome if we ended up not being able to load our software onto those devices. What I think we really need is a standardized platform to build all of these devices on. What immediately came to mind, and what we’ll be using, is a raspberry pi. Being a single board computer (SBC), it’s small and has the ability to run a complex linux kernel. It is also one of the most documented SBCs on the market.

As far as individual devices go, I believe that most of the device that we are going to have in our ecosystem can be created using solderable RPI headers, that will house the simple circuits and components we need for the alarm clock, the light, and the sensor device. For the coffee pot, we want control it with the a relay over a power cable. The reason being that we don’t feel like creating a whole set of electronics for a coffee pot is within the scope of this project, and we want to accomplish control of the coffee pot in the simplest way possible. For the MVP, we’d like to have this all implemented in breadboards, but for the final I’d like to have it all on headers and connected to the board.