Smart Home Communications

At its core, the smart home is basically a real-time events engine, accepting updates and requests and actioning them. In this respect it acts like a server and has numerous clients sending it updates, state changes, etc. But it also needs to be able to action things and send out requests to clients, devices and appliances. We define all of these communications as 'events'.

When developing our Home Control System, we very quickly realised we needed a flexible and extensible 'unified communications protocol' to provide a clear structure and framework for these events. In the early days, we simply used comma separated text and then later then moved to XML. Many years ago though, we moved to a format based on JavaScript Object Notation (JSON).

Note: It is these events (and not the technology that is generating them) that are so important to the contextual smart home. They provide to insight to enable intelligent decisions and the timing, sequence and volume are all important. But in order to achieve this, they must be structured, so that they can be 'understood' within the the context of the models used to define the smart home.

Hardware Limitations

Because another key part of our smart home methodology is being technology agnostic, we need a protocol that was light-weight and could be used on a wide range of hardware, from small Arduino to LINUX workstations.

We also need a protocol that would work in client-server situations but, would also work in peer to peer situations, to enable low latency, local control.

Technology Abstraction

Another part of our smart home methodology is technology abstraction, to make the smart home much easier to configure and use. A big part of this is enabled by the 'events' being both machine and human readable. In this respect, JSON is an excellent choice because it is very clear to see what is going on. This makes testing and debugging code so much easier.

Structure

The JSON based approach we are using is fully extensible but each smart home event has a few basic fields which must be present:

type - the event type is defines what this event is about or what type of device it is from. There are also some system types.
zone - the zone to which this event is relevant or coming from.
object - the object that this event relates to.
value - the value or state of the object.

Example: A simple example of the JSON sent from our 'Bathroom Temperature' sensor would be: {"type":"Temperature","zone":"Bathroom","object":"Bathroom Temperature","value":"21.7"}

Some examples of other fields used are:

attribute - the event refers to a named attribute of the referenced object.
brightness - this is a defined attribute used with dimmable, RGB and RGBW lighting.
colour - this is a defined attribute used with colour changing lighting.
slave - this event has come from a particular slave processor.

Example: A simple example of the JSON sent from some of our advanced lighting: {"type":"RGBW","zone":"Conservatory","object":"Conservatory Light","value":"On","brightness":"65","colour":"Warm White"}

In this example we are referencing a colour by name but it could also be defined numerically, e.g. 255,255,255,255 (R,G,B,W). They can be used interchangeably in our smart home.

Security

We have not been overly prescriptive when it comes to security but have employed our own algorithms to enable encrypted communications. Ultimately though, this is just one aspect of smart home security and there are many other things that can be done (for examples at the physical network level), to make your smart home more secure.

We are using some devices that have such limited processing power and memory, that they can't encrypt events. This is OK in some applications but, we try to avoid it as much as possible. Typically, these are on private networks and used for non-critical features.