A Protocol For Home Automation 116
jfruh writes "Marshall Rose, one of the creators of the SNMP protocol, has a beef with current home automation gadgets: it's very, very difficult to get them to talk to each other, and you often end up needing a pile of remote controls to operate them. To fix these problems, he's proposed the Thing System, which will serve as an intermediary on your home automation network. The Thing System aims to help integrate gadgets already on the market, which may help it take off."
It's Intentional (Score:4, Interesting)
Home automation gadgets are incompatible because the vendors want it that way. Selling you a $50 light bulb is the "gateway drug" to selling you a $20 a month service to manage it from your smart phone. If the protocol is proprietary, there is no competition. A/V components have been this way for so long that the world has just accepted that IR is the only way to talk to them.
It will change when a system gets so much market share that the component vendors see more value in staying a component vendor than they see in establishing themselves as a system vendor. At that point the problem is that the system vendor will want to protect their market by locking up their protocol.
Re:Pick an existing building automation standard. (Score:2, Interesting)
Either of those would work quite well for automation considering it is what they are designed for. I would pick bacnet because of the auto discovery that modbus lacks.
The real problem is cost per item plus line run (wireless can cut that labor/cost but adds others). Lets say you want to control 50 things. Each one needs a controller at the endpoint. Even at 5-10 dollars a control point it adds up pretty quickly.
Then each of the automation systems out there are somewhat compatible but not really. Then you need another 100-500 for a master controller. Then someone to set the whole thing up.
There is also setup. For many it is a pain to setup. If you use a protocol like modbus you basically have to tell the system something exists. Instead of 'hey this exists'.
Even if you have auto discovery. The 'what does it do' bit is a pain. As there are several good ideas on how to do that but none that are cheap enough for people to say 'yeah I want that' vs 'I can turn the switch on/off myself'.
I work in a similar field which has many of the same issues. The real thing is not the protocol on the bottom stack. That is a fairly well solved issue. The issue is the control software and cost.
It seems to be something everyone 'wants' but is not totally sure what it (home automation) even means. Until we can clearly define what it means we will get tons of one off solutions. Also since what it means is nebulous it has produced a solid thud on people who may even think hey I want that.
Then of the off the shelf solutions out there many want to charge you by the month to use it. Meaning you dont really own it. For people who buy houses they want to assume they 'own' the wires. Making the thing a interesting selling point on the house. However as a buyer I would be like 'wait this is another bill I have to pay just to turn the lights on and off?' meh...
This is currently squarely in the DIY court or people who have enough cash to buy a capable system.
Did he learn from SNMP? (Score:4, Interesting)
I had a quick look at the website, and can't find any low-level detail, just a lot of pictures...
That said, he seems to use HTTPS/SSH and certificate-based access.
It is useless to sign the certificates, since we are in a lan, not on the internet, and I doubt your house devices will have a full dns name...
I'm more interested in the packet structure and to the data format, as it always gives more insight on the protocol that big, colored images...
Its said to use websockets, but I doubt that will be the case in SSH-based access.
There seems to be the option to use UDP multicast for the sensors..
The HTTP traffic is exchanged via websockets and json... This is nice, since the programmers can use all the http server/client and json libraries they want, and it usually is fairly simple.... BUT we are talking about home automation, arduino boards and in general "things" with very little computational power/memory etc...
I really don't understand why we want all on HTTP, the efficiency is very low and now you require an HTTP server and client to communicate with something just to flip a switch...
Maybe if SNMP was done the right way, without OIDs and security from the start we would not need this, but I digress...
I don't like the fact that there seem to be a lot of new definitions... apprentices, stewards, and ... "things"... couldn't dumb it down more even if he tried -.-''
But the nice thing is that it seems to be able to include 3rd-party modules and protocols fairly easily... Which IMHO is not a small thing and can in fact help this protocol a lot.
And whatever he does, he can't do as badly as DPWS. If he manages to make it general enough we might even put an end to the horror that is DPWS and WS-* standards....