Slashdot Mirror
A Protocol For Home Automation
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."
http://xkcd.com/927/
#927
There are already a few home automation hubs (if I understand what he is suggesting correctly), such as Pytomation.
The main challenge is as far as I can see there is yet a single protocol to bind them all, and even then it would be yet another protocol. For this reason, there have been attempts to create protocol exchanges (not sure the right term), that act as central system that can speak to different sensors and control systems using the specific protocols.
Its not clear what he is offering that existing solutions fail at? It doesn't help that the site doesn't sum things up in one paragraph and instead requires us to parse the whole presentation before understanding what he really is proposing.
Jumpstart the tartan drive.
Please don't re-invent the wheel unless you need to. By that, I mean to say that automation and interconnection of "gadgets" is a well-established field in industry and tech. For example, vehicle ECU and sensor systems, factory automation, and data acquisition systems are all now decades old, and we should have a really solid idea of how to do these things properly.
Of course these existing systems aren't the same as what we're talking about here, with modules that span different physical link layers, protocols, etc. I just hope that we can take the best lessons from existing "gadget integration" attempts to make forward progress more successful and not just something doomed to rapid obsolescence.
For some fun and background, have a look at the old HPIB/GPIB physical/protocol standard (http://en.wikipedia.org/wiki/IEEE-488), which was used in many different pieces of scientific equipment. When that somewhat died out it was replaced by CAN (http://www.team-cag.com/support/theory/chroma/hplc_bas_at/system/cableConnections.html). Agilent uses that for their HPLCs (maybe test equipment, too?), and Waters uses the same physical link, but with a different protocol? Other vendors still work with contact-closure, and USB is becoming more popular, but that pushes so much onto the host computer and really enforces lock-in.
I will personally be watching this closely from the perspective of someone who operates a lot of data-acquisition equipment. Could this be the foundation for better interop between different vendors at the more commercial/research level, in addition to the consumer? I hope so.
I've been attempting to connect, network and control as much of my house as possible with little success. Too many companies are trying (and failing) to offer up an integrated solution, none have the ability to truly integrated across the board.
Key systems that need this:
HVAC - Nest is doing great things for automation and remote control, limited reach however
Lighting - a bunch of half baked solutions out there, each with their own app and control interface
Security - sound, video, motion detection, garage door control, etc...
Appliances - remote control certain appliances, pre-heat your stove, notification when the dryer is done, etc...
Power Monitoring - Semi decent solution out there, however needs better apps and integration
Audio\Video - Remote control
If all of these systems used a common protocol we can focus on developing great apps and home automation, as long as manufacturer dick around with their own setup we'll never move forward.
No sig here...
"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."
I have 1 remote to control every gadget in the house including sonos. It's called Crestron, but AMX can do it as well (The toy stuff called Control 4 can not)
He really needs to learn more about integration because there have been solutions out there for decades.
Do not look at laser with remaining good eye.
Everything in the fridge is melted because I couldn't find the right MIB.
You can have my SIG when you pry it from my cold, dead hands.
This is someone who was ok with ASN.1, OID's, and "walking" tables that had no business in being walked, over an unreliable UDP protocol that initially had effectively zero security.
Someone stop him from developing a home automation protocol before his being "first" relegates that industry to 30 years of pain and suffering.
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.
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.
Modbus is a very low level protocol in which you are manipulating registers or contacts/coils in a PLC. Essentially a register is a 16 bit location in memory (variable) and a contact or coil is a single bit which can read/write physical inputs or outputs or virtual coils or contacts (essentially relays). Modbus is very old and dates back to Modicon who developed it as a simple network protocol for ladder logic programmed PLC's in the late 70's. It is still used today because ladder is still heavily used and it is simple enough to cover most of the needs for industrial automation.
Bacnet is a similar protocol in terms of functionality but can not be passed over modbus because of the primitive simplicity of the modbus protocol. So you either do Bacnet over rs232, IP or another physical link/protocol like RS485/422, LonTalk, Ethernet (raw packets) or possibly over CAN as well.
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....
"I was gratified to be able to answer promptly, and I did. I said I didn't know." -- Mark Twain
Isn't this what zigbee and 802.15.4 was designed for?
Get a web developer
The problem is, x10 has caused people to expect to get "smart" devices for peanuts. Problem is, the reason x10 is so cheap is it's minimally designed. But as a consequence, it's also highly unreliable. SmartHome tried to improve on that, raised the price a bit, but didn't sufficiently solve the reliability problems. Any new series of gadgets will have to be dirt cheap, and given gadget manufacturing costs in China these days, it's doable but takes an upfront investment, is risky and one must survive on thin margins. Not exactly the most attractive opportunity. If he wants to give it a go, more power to him, but if configuration is anywhere near as complicated as SMTP, in fact, if configuration can't be done with a smartphone app in about 2 minutes, it's doomed.