Samuel Bowman
Problem
In a perfect world, all connected devices would implement one protocol and communicate with each other to do whatever the user desires. This isn't a perfect world. Many manufacturers implement their own proprietary protocols in an effort to create a monopoly, where the user is forced to use only their products because any other product would use a different, incompatible protocol and not work with any of the other devices the user already has. This is especially a problem now since many devices are beginning to ship with connected features.
For example, let's say Bob has purchased many connected light bulbs and outlets to automatically turn on when he is at home and off when he is not using them to save electricity. Bob then decides to buy a new coffee maker that is a connected device so he can automatically turn it on and off just like his other devices. However the company that makes coffee makers is different from the company that makes connected light bulbs and outlets and also implements a different protocol. Now the connected functionality that Bob paid for in his new coffee maker is rendered useless since it cannot communicate with the existing network and must be controlled separately which defeats the purpose of automation.
This can be frustrating to tech savvy users who understand the principles of protocol compatibility and incompatibility. Non techie users are left just as frustrated but also clueless as to why their devices can't work together. This forms a major obstacle in the path to the widespread adoption of the internet of things if users can't use their devices in the way they want to and are hindered by competing companies that have their own interests in mind instead of the people using their products.
Solution
For this problem to be solved, there must be a way to allow devices implementing different protocols to seamlessly communicate with each other. The way I will implement this is through software that acts as a proxy where data reaches the proxy and is translated to other protocols. This way even though devices implement different protocols, they will still be able to communicate. This XKCD comic describes what Common Ground would be like if protocols were different cable connectors.
Fig. 1 XKCD comic 1406: Universal Converter Box
Modularity
While Common Ground could be written as a simple program which translates a few protocols, this would eventually turn into a similar problem where only Common Ground compatible devices can be used together in a system. Instead, Common Ground instead supports different protocols through modules. A module is an independent piece of code that is responsible for both interpreting a protocol and sending translated data back over the protocol. This allows the user to add their own support for new protocols.
Methodology
Common Ground works by translating protocols on a common proxy accessed by all devices that need translations, hence the name common ground. When data from a protocol reaches the proxy, it is first converted to a intermediary "mezzanine" object internal to the proxy. This mezzanine object is then passed to different modules, to be translated into their respective protocols and sent to the devices that need the translated data.
Open Source
Common Ground is open source. This gives users the freedom to make changes and improvements to the software to make it more versatile and usable to themselves and others. This also allows the software to be more secure since its code can be seen and analysed by others to remove vulnerabilities. Remember, all data that needs to be translated must pass through the proxy so security is important to protect people's data and the devices connected to the proxy.
arduinocelentano
Azdle
Startec Innovations
Shah Selbe