Project Logs

Collapse

• Goals

  Azdle • 04/25/2016 at 01:49 • 0 comments

  Before I get into the nitty-gritty details of my initial plan for how the system will be implemented I want to specifically state what my goals are and, more importantly, are not for the final system. Some of these goals will be reached during the HaD prize and some won't, but I think it's likely to be important for others to know my final goals so that they might be able to understand some of the decisions that I make along the way. With that in mind, let's talk about what the internet of things is now.

  What is the current state of internet of things?

  First and foremost, the internet of things (or IoT) is a buzzword and an "emerging market" where everyone is scrambling to get a piece of the pie. Secondly, it's nothing new. Before it was called "IoT", it was "M2M" (Machine to Machine), before that it was "Connected Devices", and before that it was "an embedded device that we stuck a POTS modem on". Now that's not to say that there's nothing new going on in the space, with all the flurry of recent activity there is much going on, some good, some bad.

  Yes, there really is some good happening. The internet of things as a whole becoming much more prevalent, which in my book is a good thing. People are becoming more aware of the technology and are getting access to devices that make their lives easier, at least in theory. There's also been a great focusing on security, which is going to be extremely important in a future where our homes, offices, shops, and communal spaces are controlled by internet connected devices. This focus on the need for security is coming to light due to real-world security vulnerabilities in real devices, which, fortunately, are still early enough that there is no real dependence on them, so it should be possible to fix these problems before a time when such a vulnerabilities pose threats that are more than just a mild inconvenience.

  Unfortunately that's actually entirely true, that is because these security vulnerabilities are in real, working, systems that are in people's homes and could be used to leak information, something as simple as whether someone is home or exposing your wifi network credentials, or they could be used to annoy the users of these devices, flipping their lights on and off or messing with a thermostat, but they could even conceivably be used to break into a house without leaving any evidence that someone, who shouldn't have been, was there.

  Those are all very obviously things that will need to be fixed before iot can and even should become something that most people rely on for their everyday needs, but there are a few more issues that you may or may not be thinking about when it comes to the current state of iot.

  One issue that is very important and may even be causing problems for the current users of existing iot systems is that of openness and interoperability. The fact that its very much in vogue for creators of current iot devices to create a custom, mostly proprietary, platform for their devices to exist on is rather unfortunate. Sure, many of these platforms will have some form of API or integration with other's platforms, but they are not open platforms and they will never be able to integrate with every other platform out there. This seems to be caused by the fact that most of the players in this space have delusions of grandeur, thinking that they will become the center of all of the future iot ecosystem. Even those that don't think this way have very little incentive to make their platforms open, once they have you as a customer it's almost always in their best interest to coerce you into investing your time and money into configuring and customizing your setup within the walls of their platform as much as is possible.

  With the proliferation of all of these various walled gardens it gets harder to make all the devices you buy from various vendors interact with each other. Maybe you want your smart bed cover to work with your smart lights to wake you up naturally at the right...

  Read more »

• Beginnings

  Azdle • 04/17/2016 at 03:31 • 0 comments

  The guiding goal with the design of Virga is ruthless simplicity while attaining the minimum needed specification or as Albert Einstein probably never said, “Everything should be made as simple as possible, but no simpler.” To take a step back, I should probably answer the question of "What is Virga?"
  

  What is Virga?
  

  I've described Virga as a "system" in various places so far, but to be more specific it's a protocol specification and reference implementation for a fully distributed, cloud-free, internet of things network.
  

  Okay, What Does that Mean?
  

  Most people are familiar with the internet of things in one way or another. Some might view it through the promise of home automation and be looking forward to finally getting to live through the promises that The Jetsons made, while others might have a more cynical view, seeing only the invasions of privacy and near constant news of security vulnerabilities that it has brought so far. My goal with Virga is to make the vision of the first group a possibility while designing a protocol that takes as many precautions as possible to satisfy the worries of the second group.

  
  My vision is for a protocol that is local first, and thus "internet-optional", while being able to be distributed in such a way that it's possible for you and only you to access your home devices from anywhere you have an internet connection without any of your data flowing through any third-party services that want to profit from your personal data.
  
  Additionally, it's a protocol that isn't over specified, but is able to grow and evolve with whatever it ends up being used for. While having a protocol that is completely and totally specified for every thing you want to use it for would be great for zero-config interoperability, it's just not practical and would make for a specification so large that no one would ever be able to fully implement it. It's my opinion that it's better to make the protocol flexible enough that it can be used for almost anything, but specified enough so that any specific configurations are very simple and only needed near the edge where the data is acted upon. This way others can build on it in very simple ways only in the areas that are needed.
  
  My intention, especially in the case of the reference implementation, is to not use new, novel, technology, except in the case of a couple areas that I view as being especially helpful to the end goals, but to use tech that is well established and well understood. I want to use technology that most will already be familiar with and already have available in their homes. To that end everything in the specification will build on top of IP, there won't be any obscure or proprietary protocols connecting the devices. The reference implementation devices will all connect using WiFi or ethernet since those will be available in any house that is likely to want any of these types of devices. The hardware used will be on things that are familiar to the users of Hackaday, Raspberry Pi's running Linux and ESP8266's running Arduino.
  
  Again, the goal is to be simple and flexible.
  

  Okay, so When Can I See Something?
  

  The full implementation is going to span the whole of the Hackaday Prize 2016 competition. What you're reading now is part of the first of five stages of the competition. Each stage fits with a separate piece of the overall project. The first stage is going to be all about laying out the rough blueprint for what is going to be implemented in the rest of the stages. During this time I'm also working on laying some ground work for some of the software that will be written in the later stages, mostly writing libraries and tools that I think I will need.

  
  The second stage will be dedicated to fully specifying the protocol that will be implemented as well as creating a relatively heavyweight reference implementation of the basic protocol intended for use on relatively powerful hardware such as a desktop computer or a Raspberry Pi. The rest of the stages will...

  Read more »

View all 2 project logs