Home Automation Is Hung Up On Software

Home automation is a favorite in sci-fi, from Tony Stark’s Jarvis, to Rosie the robotic maid on the Jetsons, and even the sliding doors pulled by a stagehand Star Trek. In fact, most people have a favorite technology that should be just about ready to make an appearance in their own home. So where are these things? We asked you a few weeks ago and the overwhelming answer was that the software just isn’t there yet.

We’re toddling through the smart home years, having been able to buy Internet-connected garage doors and thermostats for some time now. But for the most part all of these systems are islands under one roof. Automation is the topic of the current challenge for the 2016 Hackaday Prize. Developing the glue that can hold all of these pieces together would make a great entry. Why doesn’t that glue yet exist?

I think the problem is really twofold. On the one hand, there isn’t a clear way to make many devices work under one software. Second, there really isn’t an obvious example of great user experience when it comes to home automation. Let’s look at why and talk about what will eventually get us there.

Human Interface

Home Automation boils down to adding an automated layer between the people in the house and the human interfaces that control the house. This is actually a pretty hard sell. Do you lights need to be automated? Isn’t it just lazy that you can’t get up and press a light switch that works instantly without need of anything other than reliable mains power?

That’s a tough question. Is your dishwasher a symbol of your laziness? After all, you still need to scrape any leftovers off, load the rack, run the thing, and empty it again. Now that I think of it, automating a dishwasher further would be a great entry too. But my point is that before widespread adoption a lot of people must have thought that needing an automatic dishwasher was lazy but now they’re highly desired. For smart homes to become widespread we need to make the benefits much greater than the pain of the transition.

A Tale of Two Switches

WeMo WiFi light switch to the left of two "dumb" switches
WeMo WiFi light switch to the left of two “dumb” switches

I happen to have two smarter-than-average light switches in my house. One is an actual Internet of Things Thing — a WeMo Light Switch — the other is a non-connected switch with some fancy features. The WeMo controls my porch light which I want it to turn on at dusk and turn off at 11pm. For six years I used a switch with a programmable display that was a huge pain to set and reset as the length of days and time offset changed. It finally died (which a switch should never do) and I bought this one that has WiFi but the software is horrible and as much of a pain as the old switch. After the stock setup didn’t work I was thankfully able to get reliable service by switching to IFTTT to control it and haven’t touched it since. After that experience I don’t want to.

Earlier this summer I upgraded to LED recessed lighting in my living room. It’s waaaaay too bright and I needed a dimmer. I knew this was going to be an issue so I considered opting for a Wink Hub and the recessed lights and switch that go with it. I ended up with non-radio-controlled (normal) lights and a Lutron Maestro dimmer switch. This thing is awesome! You can easily set its min and max brightness for your lights, but you don’t have to. Use a double-tap for full brightness when you turn it on but it still remembers your dimmer setting. A long-press to shut off gives you about a minute to get out of the room before shutting down.

Lutron Mestro dimmer is not dumb but not quite smart
Lutron Mestro dimmer is not dumb but not quite smart

A think the WeMo switch hardware is excellent. But considering the two switches, I love the Lutron and have a bad opinion of the WeMo for no other reason than a bad software setup experience. This is the core of the problem with Home Automation: the user can’t separate a bad software experience from the hardware, and since they pay good money for the hardware they are likely to be turned off to any further automation adventures.

Hardware Lock-In

The concept that hardware costs money and software doesn’t is part of the bigger problem. Hardware manufacturers have every incentive to build software that only works with their hardware — they make no money if you use their free app/website/etc. to run another manufacturer’s hardware. This is a pretty tough issue to tackle.

But it does go beyond that. Let’s say a hardware manufacturer were to allow third party hardware to run with their system. If that third party stuff works poorly it may sour the consumer’s opinion of the entire system. Again, this issue doesn’t have a clear solution.

I want to hear what you think about it — is the power of the pocket book (what technologies we buy and don’t buy) the only leverage we have in this situation? What can we do to encourage manufacturers not to lock down their hardware systems to a proprietary ecosystem?

We’ve Solved This Before

Look to the PC industry. You can run the same program on a Dell, Acer, Asus, or Toshiba laptop. You can even change the operating system you run on those machines, and for that matter, software companies can make their products work on Macs. It’s because there are standards for defining what hardware is in these computers so that compilers may be built, and standards for how these computers communicate with the outside world (USB, Ethernet, WiFi, etc.). We need this for non-computer computing devices like lights, light switches, refrigerators, security cameras, doorbells, robot maids, and the like.

We Need a Software Champion

We need to separate hardware from software so the hardware companies can do what they’re best at — build affordable devices that work reliably year in and year out. I don’t think this can happen until a clear software champion (or group of champions) appears. This means an intuitive interface that your average human can understand, configure, and intuitively operate at the same level you can operate a light switch.

This is a really hard problem. How do you think it should be approached? What is the incentive for someone to build these software tools? Get the conversation started below. As with the last installment I’ll pick out some of the most interesting comments and send out Hackaday t-shirts. From the last discussion we sent shirts out to [aleksclark], [DaveW], [Dax], [fountside], [Ian Lee], [j0z0r], [jan], [maxzillian], [Neil Cherry], and [sangwiss].

Are you into DIY home automation? Now’s a great time to show off some of your work. Enter your project now for the Automation challenge of the 2016 Hackaday Prize. Twenty entries will win $1000 each and go on to the vie for the grand prize of $150,000.

98 thoughts on “Home Automation Is Hung Up On Software

  1. near as I can tell, currently at least. The glue to hold everything together does exist, it’s android/ios and *gasp* the cloud.. each of these islands of automation are islands in the same ocean of the internet and the smart phone (or alexa in amazon’s case, because they can’t make a phone to save their lives) is the method to communicate between them.

    I was thinking about this very thing the other day.. I always wanted an all in one automation solution myself.. but I don’t want to write and rewrite the code for the firmware/security/updates/upgrades.. i want it to exist already for me to tinker with. which is pretty much (barring some closed systems out there.. kwikset*cough*) what we have today.

    i feel what we need is some form of industry standard for the “internet of crap” that says, if service x goes buh-bye, firmware/hardware is open sourced.. basically saying, if you fail at an idea, let the next guy take a crack at it.. while also saying.. hey buy my stuff, because even if we fail, you are still good mr joe consumer. THAT i think is the only thing REALLY missing.

    1. american lawmakers do not represent normal regular people anymore. what you ask is something for the people.

      don’t hold your breath watiing for such things to happen.

      now, if this was phrased as a benefit to big business, it would happen tomorrow or even yesterday.

  2. The idea of the cloud controlling my physical devices is an unpleasant thought. Also, there has been things like X10 for decades. To me the value of automation is being able to do unusual/artistic things that might well be best done with code.

    So I build my own open source automation system based on “events” that say “if this line ever evaluates true do this”, where both the trigger and action are python code.

    For UI there’s simple HTML from mako templates with a library to handle creating widgets like sliders to control things in realtime.

    And all of this can be edited through the web interface via https.

    The advantage here is that the system supports literally anything python does because it’s basically a python/html web IDE.

  3. The switch example certainly doesn’t need any “software champion”. All that it needs is a simple photoresistor (LDR) and a few jellybean parts. Turning a porch light on at dusk and turning it off at dawn really doesn’t need IoT, smartphone integration and complex programming. The ambient light will do that just fine.

    If we stop thinking that every stupid piece of electronics has to have a “cloud” and be “smart” the world would be a lot better place.

    1. IoT is 99% run by marketing guys who want to data mine.

      once you realize that, everything becomes a bit more clearer.

      not any more desireable, of course. but the intention is more clear. just like when you are the product to google. once you understand your place in the ecosystem, you can make more informed choices (like, choosing not to play.)

      1. I have been working for some time on a “massively distributed” IOT approach where there is not a huge sucking sound as all your data is vacuumed up into the cloud for others to make money from. The problem is that everyone and their dog are getting on the bandwagon with cloud based IOT systems as that is where the money is. What is needed is an open, distributed system with full interoperability but there is little incentive for hardware manufacturers to do that. They want hardware and software lock in.

        My approach is to work with large businesses that will lose out substantially if, as can be expected, a small number of companies end up controlling the IOT cloud. It is a rare case where what is good for individuals, is good for a lot of businesses also.

        From a technical point of view, the approach makes IOT objects “self aware” such that they know who owns them, This uses crypo technology. Then the owners of the objects get to say who can see the data and who can access and control the objects. Local hubs under control of the object owners (you) communicate directly with your devices, such as smart phones without any intervening cloud servers. The cloud only provides services, such as, say, the weather forecast.. There is much more to it than that, but that gives a flavor. I am mainly using CoAP and MQTT at the lower levels (within my house) and I am working on the semantic model for communications. Think of this as starting with a “real world” concept model which knows what, for example, a washing macine is and how it operates. From this, a set of standard, but extensible, message structures can be defined for use by all washing machine manufacturers so that you can use IOT objects from any source. Then you can have a truly safe, secure, resiliant and open IOT system. There is is a lot of work to do so it will be several months before I can demonstrate such a truly open system but progress is being made.

        1. You just described what could be the ideal scenario for the user and the cloud in general, a personal ‘cloud’ server. The main issue I see there is that we tried home servers a couple times and consumers don’t much like them. One appeal of the cloud is that you as teh consumer don’t need to maintain it, that’s the job of the IT nerds.
          But that costs money to feed the geeks and to make that money, the companies sell the data consumers are so willing to give up.

          1. IoT != Home Automation

            I have no interest in IoT but I am interested in network enabled devices that I can control. Siri, Amazon Alexa, Google Home, Nest, etc are just data and bandwidth thieves masquarading as home automation devices.

            I’m really perplexed with products like Alexa. From past experience Alexa Toolbar is just drive-by malware that hijacks your internet connection and sends 100% of your internet traffic to remote servers to be indexed, quantified and sold. Benefit to the user? A filled up hard drive, sluggish computer and slow internet.

            Why on earth would somebody want to buy a dedicated computer running Alexa spyware to leave it running 24/7 on their home network?

        2. Hey Dave, I’m trying to get a project off the ground that can act as an enabler of Smart-Home capabilities for home device manufacturers that (as you mentioned) doesn’t (necessarily) require an internet connection and is fundamentally compatible with most home automation devices out there. It doesn’t seem like what I’m working on directly overlaps with your description, but I do feel our thoughts complement each other. Do you think we could get in touch somehow?

        3. Hey Dave, I’m trying to get a project off the ground that can act as an enabler of Smart-Home capabilities for home device manufacturers that (as you mentioned) doesn’t (necessarily) require an internet connection and is fundamentally compatible with most home automation devices out there. It doesn’t seem like what I’m working on directly overlaps with your description, but I do feel our thoughts complement each other. Do you think we could get in touch somehow? sean dot nijjar at gmail dot com

    2. What’s the point? I can look outside and see that it is dusk and turn on the light myself. We don’t need any of it. We don’t even need electricity, humans got along fine without it for several years…

      If an external sensor can report the light level, I can set the software to turn on the light when I want it. If the fixture can report when the bulb has died, I can change it. In an intelligently automated home why would I want dumb disconnected systems running things?

      Also, I will never embrace “cloud” technology. Honestly anyone who willingly gives control of their house to the internet is a fool. I don’t even like using onenote and it is one of the few useful use cases for the cloud.

      1. Several things need to happen, and from every system I have seen it is done wrong.

        > No cloud. Why would you open yourself up to a random company, be reliant on them maintaining services, or be reliant on your internet service?!?
        > No ecosystem lock in hubs or devices. With the proliferation of cheap low power single board computers there exists no reason you can’t have a computer system on 24/7. We need a single (non-cloud) system that can run it all. In fact I would look at making it a web app so the only requirement is a web server.
        > Use WIFI. Anyone looking at doing home automation has WIFI, or should. I don’t need a bunch of crazy new radio-waves flying through the house.
        > Use an API from the web server hosting the app to build any other interfaces. The API changes in only one place and as such easier to manage updates and understand backwards compatibility break changes.
        > No dumb devices and no disconnected “smart” devices.
        > It should obviously all be standardized. Probably the best system would involve devices saying the standard features that they provide from a base set(like bluetooth or android’s intent system inverted). Then you have a “driver” system for those standard services. So their function and control could be upgraded. This driver system would also allow for exotic devices to be integrated later on.

        The design likely should be event driven.
        I think an example of where we need to go would be tracking people in the house and manage lights. You trigger a motion sensor it turns on the light in that room, you trigger a motion sensor leaving that room and it starts looking for motion in the room and turns off the lights if none is found. Obviously this could go much further using heat sensors or what ever.

        In addition we need to combine everything under one umbrella. Security, fire, flood, weather alert, thermostat, mailbox, voice control all working together. We are starting to have the voice recognition and speech synthesis that our house should be Jarvis.

        Or at least that is my 2 cents.

        1. You’re right from my experience.

          My home automation logic is written in PHP.
          Little raspberry with apache and PHP is that umbrella where it all combines.
          All devices are polling in intervals defined by server.

          “I don’t need a bunch of crazy new radio-waves flying through the house.”

          Sometimes You need them – wifi is power hungry, but now BLE can be new standard, it is getting cheaper every day.

        2. Wi-Fi has limitations (I say WeNo (WeMo joke)) for HA devices. Limited number of IP addresses on a subnet, and sub-GHz signals travel better through walls and mesh-networks are superior for reliability. So even using something proprietary like Z-Wave is a better choice for HA than WiFi since it uses 908.42 MHz.

          1. He said on a subnet. Granted, setting up your own tiny subnets is a pretty rare scenario for a home user. Personally my problems with WiFi for HA devices stem from the logistics of having so many devices. Network congestion, firewall rules, pages upon pages of cruft in my logs. Oh, you need to change your WPA passphrase? Hope you have 2 hours to reconfigure 50 devices.

        3. Neuntoter wins. Spot on breakdown of what is needed. I have been working on a solution that achieves these goals. As a home automation consumer, I want to be connected to my home systems when I’m away, but without my data (and access to my home) being routed through a commercial website, or the internet for that matter. I want my home automation system off the public Internet but accessible wherever I am. Machine-2-Machine cellular networks seem to be a logical path. Connect my local network at home to my smart phone. Current M2M data networks might not allow for this, but I think it could be on the horizon. Amazon doesn’t need to know when my garage door opens.

    3. So I’m using a simple LDR and some jellybeans. Then for some reason, one night I don’t want the porch light on for a little while, so I flip the switch off. Now I get distracted and forget to turn it back on…what happens the next night?

      If we stop thinking that our minimal use cases affect everyone, and that some people don’t see value in different applications, then the world would be a lot better place.

      If the ‘smart’ light switch does not add value to in your case, then don’t use it, but realize that others may value features differently, and they are free to implement a solution without being chastised by others who clearly don’t understand the big picture.

      1. Well, you won’t have light next night until you walk up to the switch and flip it on again. Big effin’ deal. The smart switch would not read your mind neither, at best you will be able to fish out your phone and turn the thing on remotely instead of walking the few meters to the button. How did we survive without these gizmos until now …

        This is the entire problem with this IoT stuff – it is designed for an obscure use case that you need once in a blue moon and can well live without otherwise. Unfortunately that extra complexity cannot be enabled only when you need it – it is always there. And so we have every week a new security hole, another product being turned into a useless brick because essential some cloud service somewhere is being discontinued, twenty different and mutually incompatible types of remote controlled lightbulbs, etc.

        This isn’t about being a Luddite, this is about poor engineering – an overcomplicated solution requiring complex setup, IoT gateway, some sort of cloud service and a phone (or a computer) just to make the light go on and off. And it *still* performs worse than the LDR, because the Sun doesn’t set and rise at the same time every day. So you need a service to look up the times, correct for geographical location, etc. That’s not really any progress, that’s technology for the sake of technology, IMO.

        Oh and if you want to avoid the entire problem, use a $2 PIR sensor – most of these porch lights come with these already. That will turn on only when there is actually someone there and won’t be burning electricity the entire night for no reason.

  4. running into the same issue with multiple devices that dont talk to each other or need multiple hubs (hue, wink, Smarthings).. The key is to select devices that will be hub independent (like most Zwave and some zigbee devices), so if the hub co goes belly up (like Revo) or just does not work properly (Staples connect) you can move to another hub and still retain most of your HA investment. Think of HA similar to your PC and plan to upgrade every few years (yes its a pain to replace the in wall switches so stick with the common zwave ones)
    Currently using Stringify to tie most of my disperse HA devices into a single platform. Its not perfect, but with Stringify and Amazon Echo, i’m almost there..

  5. Standard, Protocol, API however you want to call it. As long as maker of IoT keep their protocol hidden and force me to use hideous App then I’ll never be able to address those device from my own code/script, let alone integrate all of them in a software master hub that will make them work in concert.

  6. Home automation has been around since the 80’s easily. Unity Systems is still around from then, Elan G is an option, Lutron is an option, and for those who want a bit more than a “oh look my lights turn on and off” there is Crestron.
    No IoT and all those vulnerabilities, no smartphone and python apps by a company that won’t support it in a year; instead these are actual professional level systems.

    1. At professional level prices. Typically these systems cost 10% of the home’s price and they tend to be in the $1M+ homes. Definitely not for the DIY’r and a lot of times the installers/maintainers consider the whole system their proprietary information that they won’t share with the home owner. Talk about locking.

      Those systems are at the far end of the consumer spectrum.

      1. Meh, I never hold my code hostage….You bought the system, you bought my time to code it, the code is yours.

        All these things people are talking about taking up enormous amounts of time to develop new solutions that are buggy, or reliant upon some API that you don’t have control over that may change, then you have to rejigger completely in a couple years….yikes.

        I can do most of it without a huge amount of fuss.

        Want to turn on the lights at astronomical dawn and dusk? No problem. All I have to do is tell my program what your latitude and longitude are. Want the music to follow you though the house? Neat, I can track your location with BTLE and PIR sensors. Want the doorbell ring to turn down your music, notify you on your phone, then give you a picture on your phone, television, and other interfaces in the house? Cake.

        If it’s electronic, I can get it to integrate. Period. It may require me to hack some relays in, but I can code around pretty much every problem you have.

        And now, it’s getting even more open to learn. Crestron is moving into a C# based language. AMX is doing wonderful things with Java, Extron (that’s more commercial) is about to roll out a python-based language, and Bang&Olufsen is using Lua Scripting along with a pretty slick architecture.

        Yeah, my hardware is a bit more expensive, but I only have one throat to choke when something breaks, and what you are paying for is phenominal tech support anyway.

        Source: Residential and Commercial Automation programmer for 10 years.

    2. All of the Top Level systems installations I have seen from Savant, Crestron, Lutron and Control4 are never really implemented with any “automation” unless you count lighting scenes or being able to press Watch TV button and have several actions execute on different devices. Real Home Automation is being tested, achieved, and lived by the DIY crowd. I think mainly because to have to live with it to really discover valid use-cases, and then you work to find a way to make it happen reliably.

      I am guessing their AV guys don’t want to offer geo-fencing or proximity triggers due to the liability concerns for a $12-30 mill estate. Older PC-based systems I have seen still in use offer ways of tracking occupants around a large home using occupancy sensors, but they didn’t turn on the hallway lights based on movement or anything. Being able to talk to your house (Amazon Echo or other) is completely worth the price of admission but you don’t see the Top Level systems doing it yet. They just want to sell you their over priced touchscreens and have you pay a programmer weekend-rated when your system chokes the night of your big party. The real benefit of Jarvis was that Tony Stark could fix it himself.

      1. Just because you see lots of shitty systems doesn’t mean there aren’t those of us that don’t use real automation.

        Typically, when I’ve done large residential installations, we live with the family for several weeks during implementation, so we and the client can see how they begin to use the system, then model our code based on their living situation. I use geofencing, BTLE, and PIR to determine position and manage system actions in that method.

        It’s 2AM. Homeowner gets up and walks into the hall. They are thirsty. Hall lights up to 20%, kitchen up 20%, but not until they get there. 6AM in the summer, same thing happens. 6AM in the winter…it’s already bright out, so we just light the hall up.

        User 1 and 2 are playing music in different rooms of the house. User 1 leaves the room and goes to the adjaicent room. Music follows. User 2 enters the room as well. Both users get prompts on their phone, and they get to decide who has precedence, unless they’ve already set music priority in the global configuration.

        It bugs me just as much when I see expensive automation systems used as fancy universal remote controls. It’s up to the programmer to be capable enough to actually program the system, and so many home automation programmers come from an AV background rather than from a traditional development background.

    1. I am a big fan of HomeSeer. I just works. I have over 70 devices from switches, plugs, water detectors, door locks all under programmable control. I can and have a customized Android interface for my tablet and phone. it interfaces with my Alexa. I have both Zwave, Onewire, Insteon, X10 Wireless, Sonos speakers and Webcams that seamlessly interface and are control-able. They have a published API and so a number of independent developers adding extensions. I can find the best device for what I want and use it with almost no regard to what system it uses. for instance the best wireless remote that I have found for general use is the PalmPad for X10 Wireless etc..

      So let me step back from my fanboy reply and say that it Homeseer is a relativly small outfit and while it is being regularly supported with updates, sometimes the updates that I care about are a little slow to arrive. Still all-in-all a great experience.

      1. I dove headily down the Homeseer rabbit hole and to be honest, it’s quite a surprise that most of the time it works.

        Homeseer 2 was written by self-taught VB programmers and the underlying design is atrocious. I know they say “hell is other people’s code” but this was really bad. Their API was inconsistent, confusing, and poorly documented. Really poor use of object oriented design, with unnecessary variables being passed around for no good reason. Data handling internally was handicapped to fit the X10 paradigm and it took some creative interpretation to make it fit other data types. Then to make things worse, the documentation described what functions did but not how to use them in the overall scheme, and took me months of trial and error to build a decent plugin template that I could then reuse going forwards.

        They had a chance to fix it in Homeseer 3 and instead kept most of the original design PLUS added a layer of remoting complexity, but then still managed to break backwards compatibility with several of the original functions. There was a sample plugin template provided that absolutely did my head in, with about 4 layers of unnecessary indirection and multiple orphaned variables. Months later I figured out a simpler way of implementing the same thing with about 30% of the code, once again with little help from the API documentation which has barely been updated to reflect the new complexities.

        If you can stick with the official plugins where someone has already gone though this pain for you then yes, it works OK. But if you want to work outside the box on some custom hardware, it’s a real struggle.

        Same goes for for the user interface. If you stick with the standard HSTouch template it works OK, but if you want to do customer graphics it’s riddled with bugs on basic features, and just when you have sorted out a workaround something else regresses in a new release. It’s a constant uphill struggle.

        Whilst this all seems bad, I have been fairly impressed with some of the things I’ve been able to manage on my homeseer system. I just wish the journey had been less frustrating.

        1. I have an all singing, all dancing system (including a highly customized HSTouch interface) through Homeseer. It is absolutely amazing. But, I will agree, it is not for the “average Joe” and does require some VB coding capabilities to write scripts to make some real magic happen.

          1. I concur with all of the above comments. Homeseer is very powerful, quite frustrating at times, yet very capable of achieving true home automation. Homeseer is not for the faint of heart. It is not easy and straightforward software to implement nor to perfect. One should be quite geeky at heart in order to succeed with homeseer. If the thought of programming a DVR scare or turn you off, stay away from homeseer. In order to reach its full potential in implementation, I have invested countless hours writing custom code. For the most part, these days the system works as designed. Yet, to get the Jetson like automation experience, extensive application development and tweaking have taken place over the course of several years. I have done every ounce of the implementation and integration myself, because I am quite capable of such feats. I actually enjoy the challenges that come with such a project. In reality, the masses are not prepared for such a development effort. For most, the cost would be prohibitive to hire someone with the expertise to do.

  7. Hardware will always come with software in some form. In the PC example, your Acer/Dell/Lenovo/etc comes with Windows and a bunch of prebundled software. Usually it’s bad software, and it’s up to the user to install what they really want. I think if we saw hardware manufacturers releasing open APIs with their hardware, then it would be easy for anyone to write code to interface with the hardware, even if the company goes bust. This would be a benefit to the hardware manufacturer since it would make it easy for them to integrate with popular services like IFTTT and it would help attract the tech savvy early adopters who want to make their devices do custom things (within limits). I would think it would also make it easier for the manufacturer to design a nice user interface as they could abstract the front end from the back end. Perhaps then over time you’d see third party UI/UX software which could be distributed as apps (free w/ paid upgrade?) to provide a better experience than the stock software. Eventually this could be sold to manufacturers either exclusively or simply licensed to make it the stock software used. Seems like the ball is in the court of the hardware manufacturers though. There’s little you can do if everything is completely closed source.

    1. Home Control is “do stuff with your smartphone”, while Home Automation is your curtains closing automatically to reduce heat gain and faded carpet and furniture based on the astronomical position of the sun in relation to your house.

  8. “Home Automation” is hung-up on Commercial “Solutions” that are not only insecure, but share your (and your family’s) privacy with not only the “Service Provider”, but (more and more these days) Big Government.

    If you don’t “Subscribe” to a Home Automation “Licensed and/or Regulated” Solution Provider that is Government Approved, and installed only by Unionized Installers, then your Homeowner’s Insurance is NULL AND VOID. [In some places just touching the wiring in your own home without a Unionized “Electrician” present is Illegal!]

    So go ahead, call some “Service Provider” to Legally install your Home Automation system, then give up your privacy, shackle yourself to a never-ending ball-and-chain “Contract”, and pay out the [bleep] every month for the outrageous subscription and “Maintenance” fees.

    Or – Do it yourself! – And risk losing everything you’ve invested in the Home you OWN (or “Used To” Own!)

    This “Rant” does not apply (IMO) to living spaces (even if you “Own” it) that are physically separate but SHARED as a Building by others, such a Condominium Unit. It also does not apply to any stand-alone home or apartment you rent from a separate Owner. For obvious reasons, NEVER modify the as-is wiring in a property you rent or lease when you occupied it without written consent from the Owner and written Proof of Compliance with local Building Codes!

    1. Sorry for the Self-Reply – but I forgot one IMPORTANT thing:

      Once you accept and saddle yourself (and your family) with a Government approved and installed Home Automation System – What happens if you want to cancel the Service?

      Your air conditioner/heater stops working properly? Your refrigerator turns off? You can’t turn your lights on or off? If-so, You are a “Hostage” of corrupt regulation gone out of control!

      Then there’s this: Multiply this by 100’s of Millions of households that get “Hacked” by “Unidentified External Actors”, and this gets Big – doesn’t it?

  9. Several things need to happen, and from every system I have seen it is done wrong.

    > No cloud. Why would you open yourself up to a random company, be reliant on them maintaining services, or be reliant on your internet service?!?
    > No ecosystem lock in hubs or devices. With the proliferation of cheap low power single board computers there exists no reason you can’t have a computer system on 24/7. We need a single (non-cloud) system that can run it all. In fact I would look at making it a web app so the only requirement is a web server.
    > Use WIFI. Anyone looking at doing home automation has WIFI, or should. I don’t need a bunch of crazy new radio-waves flying through the house.
    > Use an API from the web server hosting the app to build any other interfaces. The API changes in only one place and as such easier to manage updates and understand backwards compatibility break changes.
    > No dumb devices and no disconnected “smart” devices.
    > It should obviously all be standardized. Probably the best system would involve devices saying the standard features that they provide from a base set(like bluetooth or android’s intent system inverted). Then you have a “driver” system for those standard services. So their function and control could be upgraded. This driver system would also allow for exotic devices to be integrated later on.

    The design likely should be event driven.
    I think an example of where we need to go would be tracking people in the house and manage lights. You trigger a motion sensor it turns on the light in that room, you trigger a motion sensor leaving that room and it starts looking for motion in the room and turns off the lights if none is found. Obviously this could go much further using heat sensors or what ever.

    In addition we need to combine everything under one umbrella. Security, fire, flood, weather alert, thermostat, mailbox, voice control all working together. We are starting to have the voice recognition and speech synthesis that our house should be Jarvis.

    Or at least that is my 2 cents

  10. reminds me of the early problems with networking.

    as we all know by now, that was solved by a large committee of companies to develop common standards. (IEEE)

    until something like that happens for automation hardware/software, everyone is going to keep trying to do their own thing.

  11. Home automation is fun, it presents lot’s of challenges and requires us to change a little. In other words we need to accept the changes. Change does not come quickly. I someone invents the solution to solve all home automation problems then it will take at least another 5-10 years before it becomes mainstream.

    Mainstream, or everybody using it, is what this article is all about. When will we all have automated homes?
    30 years ago, I had a computer, my friends considered me as technologically advanced, a little strange and non standard. Computers were for nerds (and that felt good). Now the same people, who feared computers 30 years ago are holding/carrying their phone all day and are communicating in ways they could never imagine 30 years ago. Without knowing it they have embrased technology, they are using computers.
    Although not very constructively, they are using it. And to be honest… I fear that technology, it is taking over life, phones are intruding my personal space. My friends and family expect me to be available through my phone and expect me to respond immediately. I do no want that.

    It took people 30 years to change people with computer fears into heavy users. Although they still don’t really understand how it works, they are using it.
    Home automation must go through the same cycle, it must work right out of the box without knowing how it works. And times are changing. Here in the Netherlands they are trying to sell smart thermostats and powermeters to the masses. Once these are installed, these devices control the heating and in time the lights and shades/blinds or whatever. Change goes slowly.

    Funny though, what we call progress is causing lot’s of problems and frustration. And every 2 steps ahead, we wil go one step back. For instance, my television tuner-box gives me crystal clear images and sound…. but although it updates regularly it sometimes fails to synchronise sound and video. And if I want to record a TV-show I must go through some buggy menu and hope the recording will happen (and the recording can only be planned max. 7 days ahead). Then if I cancel my description from the settopbox company, all my recordings are gone. 10 years ago I and everyone I know had a VCR, quality was as good as TV could show it and we could fully control the recordings and even could plan a year ahead (which was nonsense, but it could). The images and sound were always in sync. and whatever happened to the VCR the recordings stayed on the tape. We had radios with cassetterecorders, if we heard a song we’d liked we could instantly record it. But now when we hear something we don’t even know a way any more to quickly record… This no longer seems required and we all have accepted that, funny isn’t it. Still I like progress, but not as much as I used to, I guess I’m getting old.

  12. It’s simple Money Talks and BS walks. The companies want to make money. If they open-source their systems, Someone will hack it and do evil to their system. Who is responsible? Placing access to things to the cloud IMHO is the worst thing you can do. I would prefer to get up and do it myself for my own safety.

    What happens if your IoT Thermostat is set for 100 degrees and overheats your furnace and burns down your house. Who pays?

    Just a bit of background on me. I work for a retail Security Company designing Alarm Systems. People always find a way around them. That’s why I am still employed.

    Automation is fine, It would just need to be monitored and secure and that cost money.

  13. Here some glue to tie different things together:
    http://www.openhab.org
    -Lots of Bindings for different Hardware (and Software)
    -Java based (platform independent)
    -Can run on a Raspberry Pi, as long as the setup is not too big
    -Smartphone Interface
    -Web Interface
    -Can use some cloud features via MyOpenHAB (I just use VPN to access my Webinterface from Outside)
    -Open Source
    -Stable
    -Lots of ways to integrate other Hardware (REST, MQTT, HTTP-Requests, …)

    Another one:
    http://fhem.de/fhem.html
    A little more lightweight because its Perl based. Stable. Open Source.
    Cannot say more because I use OpenHAB.

    1. Arguably one of the best open source options that exist! Home Assistant is generating excitement as well. I prefer OH because of the amount of things that work with it! I’m using Wemo, Insteon, home made devices with mqtt, Yamaha receiver, and Kodi are just some of my devices. All tied into a single interface and NO cloud!! My house is MY house even if my Internet is down. And I can limit exposure to Alexa as desired. And with the REST API I can use Tasker on Android to trigger events. Seriously, the closed source stuff doesn’t have the options that OpenHAB can and does have.

      1. I use FHEM on a Raspi B+. It works great for nearly two years now. It has a Webinterface and also an App for my Android-phone.
        With the FHEM-Server and an connected Arduino I control 5 MAX-Thermostats and a lot of 433Mhz-Power-Sockets.
        There are corners of the house, where the Signal of the 443Mhz-transmitter ist too weak. So I use a Particle Photon with another transmitter, which is controlled over IFTTT from the FHEM-Server.
        With the wake-on-lan module and ssh I can also start und shutdown my NAS remotely.
        So for me, there is no need for a new software, that can control my IOT-Devices, because it’s already there.

    2. >Java
      Oh god no, I want to solve a problem, not create a problem factory…
      Why is it such a problem to compile for 3 to 4 major OS’s? Most larger-scale open-source projects are capable of doing this, so there’s no excuse for not doing it as well.
      This way each can receive tweaks that will make it more stable/less resource intensive/more responsive on a given system instead of having to go through all the crap of using Java in ways it was never meant to be used.

      Only the server really needs to run as executable code, everything else will do just fine with something like http (with varying levels of bells and whistles, depending on what version of http the device can run), as it can be kept very simple and yet have lot’s of both cross-platform and backwards compatibility…

      If a device can’t do http because it’s something not IP-based – use a bridge that does.
      With software radio constantly advancing and becoming cheaper every day, it should not be such a problem to create a sub-$200 ethernet-capable device that can be modified by a SW plugin to do some new fancy (or old and proven) wireless protocol without having to even having dust off the physical thing. GNU radio could easily be used for this.
      Simple web interface that allows for setting up what is what and where should it send the data and you’re golden. The same web interface can be used to upload GNU radio blocks and “connect” them to the existing ones.
      If the bridge can do everything, it should not matter who you bought it from.

  14. I work in the commercial building automation sector and everything there has gone open protocol Bacnet of some version for the most part not sure why home automation has not gone the same route. There are tons of devices and software available even Bacnet over Zigbee. I have used these products to automate things in my home because there is just no standard yet in residential.d

  15. Mass appeal is what is holding HA back right now. To continue with the pc analogy from the article we are kinda in like the pre gui days still in terms of UX with HA right now. We need a major leap in UX that makes HA easy to use and interact with for the average person. And we are on that track with things like the echo but until a company makes the ‘windows 95’ of HA os’s that opens it up to the broader public and becomes so popular that the hardware people are forced to support it, i dont think we are going to see much progress in unifying a standard.

    With mass market appeal we can also start to see some cost reduction in the hardware side hopefully also, because that is another barrier to the scale you need to have to make HA worth it. (like turning on one lamp with the internet is cool and all but until everything is automated what’s the point)

    1. The two things that drove computers into homes were:
      1) Porn/Interactive entertainiment
      2) Job pressure – aided at first by lax anti-piracy measures.

      I’m pretty sure MS figured every work copy of Excel and Word stolen and used on a home computer was a win, displacing Lotus and WordPerfect.

      There’s no similar advantage to home automation. It’s not really fun and it’s not job advancement.

      I just keep getting back to the little story Ray Bradbury wrote about an automated house.

  16. Wow, lot of angry comments. Sadly I agree with parts of a lot of them. While the cloud isn’t inherently bad the reasons various companies are providing cloud service is. Pretty much you can forget about privacy and question of who owns what is laughable if it didn’t make me want to cry.

    Of all the comments so far, I think these are the most important for the future of HA:

    1) Do I need to pull it out if I want to sell my home? A couple of $K worth of HA devices vs the sale of my $100+K home. I’m not going to hold up a sale for those devices.
    2) Does the user need tech support when the devices fail? My wife worries about this
    3) Will it work if the vendor pulls the plug? The communications Co (ISPs, Telcos, Utilities, whatever) stop services usually every few years. Would I want to spend more money to migrate or toss this stuff out?
    4) Can I get replacements locally? The internet is great but when I can’t get the parts or I can’t get the same parts quickly I’m stuck. Almost isn’t good enough (Lowe’s, Home Depot, are you listening? Didn’t think so).

    In the long run, Smarthings, Wink, etc, aren’t the answer. The vendor will shut the service down or change it in some way to make it inconvenient or costly.

    I’m not sure how to build an HA company like you would Red Hat. Also just because you start out with do no evil, doesn’t mean that some other company won’t come along, buy you out and then turn all your dbs into a resalable asset.

    I’ll post responses to the others in their threads. Now lets see if we can get a few more ideas to fix this thing.

  17. End to end encryption needs to be a major part of any system. The cloud is a necessary evil to make connectivity easy. But the cloud software shouldn’t do any of the actual processing. It should just be a relay for encrypted data.

    All devices should simply be paired over a trusted connection(wired or bluetooth) then allowed to join your device swarm via wifi/the internet. How the devices are connected and the the such shouldn’t matter. They all just connect to a cloud server and exchange encrypted messages. Kind of like an IRC server, except all messages are encrypted and only paired devices have the key. Keys should be long and randomly generated.

    Common behaviors should be easy to apply. Custom ones should also be easy to define. The design should be totally open ended. It should be easy to program a light to come on between 3PM and 4:23PM on Wednesdays where the date is a prime number and zebra are on the hackaday front page and there is no motion in my bathroom. It should also check to make sure there are no fish in Jack’s pond.

    I don’t think a central hub is necessary. Even the cheapest 32bit microcontrollers have more than enough processing power to run most automation task. A light switch module could be the master for all lighting in a house. First bound is master, second bound is backup that shadows everything the first does. Initial device can be a phone, tablet or PC but once configured the devices in the swarm should continue to function without the device being on/connected. Other control devices(tables, PC’s, etc…) should be easy to add through a pairing process.

    Each device needs to present its capabilities to the swarm. It should be totally opened ended with just a few standard properties. Datatypes shouldn’t have arbitrary limits. Functions like fade should be presented.

    Time should be synchronized across devices. So something like a fade can be scheduled across a number of devices. All events should be scheduled. So turning on lights should happen like 100ms from now so that they all come on at the same time to allow for network delay. This time delay should be adaptive to allow for longer travel time between the clould relay on bad internet connections or make things super responsive on fast connections. How long could be determined as part of the time sync process.

    So many little ideas to make this all work great.

  18. Mysensors/Domoticz FTW. Commercial systems are continuing to take the piss with price points, although they are getting pretty awesome (livolo, fibaro etc). So yeah, technology for the techies or silly money folk only at this stage.

  19. If I want to control stuff around the house I just yell out a command,
    and one of the kids takes care of it.

    I expect an automation system to do the same, except with less cheeky talking back at me.

    I have tasked the kids with replacing themselves, if they can automate one of their duties they don’t have to do it again, in the mean time I am teaching them everything I can to ensure they are able to succeed in doing so.

    This will be mostly Linux with Python and C on the back-ends and JavaScript on the front-ends. There may be a GPU or two in the mix for AI, particularly sound and vision processing or recognition, this will replace the “cloud” that others rely on.

  20. Being a device (https://flair.co) maker right now leaves me in an interesting spot. I hear some say they care a ton about radio standards, no cloud etc but then simultaniously want endless software enabled integrations and features. My feeling is that you are spot on that software is really the hang up. Radio standards will continue to be a giant war for nothing since they don’t dictate interactions, just behind the scenes routing. A great example is the myriad of ways our systems might connect to say Nest. Our smart vents currently route through our puck and then go to the cloud. While we can and will host and API on our Puck to skip the cloud dependency, half (or more) of the value of what we have built is really in the cloud software that helps it play nice with nest/smartthings etc. But even going through the cloud is confusing. If you have nest + flair + smartthings, the graph of connections starts to grow and who should be doing what when is complex. I have unfortunately lost most faith that there will be some large and consistent software solution to solve this stuff and it will for a long time continue to be a mess. A somepoint there will maybe be some sort of experience bot that you can give all your devices to and it can configure an ideal experience against all these apis but its going to take a while. Exciting times but also frustratingly complex ones.

  21. instead of the central controller telling the endpoint how to communicate, and what it should do; wouldnt it make more sense for it to bet the other way around? This way as new versions of a switch come out it can do more things.

    So you connect your central hub up to your house, and it sits there not doing a whole lot.
    You bring in your first IoT control device. What is it? The hub doesnt know, but the device does, and it knows what its capable of.

    Push the pair button on your central hub, and the pair button on your IoT widget. The widget tells the hub “Hi, Im a switch. I have 1 toggle switch and 1 dimmer. The toggle accepts 1 or 0 and the dimmer takes 0 – 255”
    Now take the anthropomorphism out of it and you have the light switch sending an XML file to the control hub.
    This tells the hub the identifier, the interfaces and the acceptable values for those interfaces.
    The hub doesnt need to know what that switch does, shouldnt care.
    This allows the hub to do its job better, collect input from the user (or sensors) and send values to control units.

    the other thing this can allow is for users to customize their interface on the hub if using a touchscreen.
    “I want to control this dodad” says the user
    “Ok, well it only accepts 2 values, so you can use a slide switch, a toggle switch, or a pushbutton graphic for the interface” replys the hub

    thats it.

    Hub just needs to know the address of the widget, how many interfaces it has and what values those interfaces accept.
    Hell if all the equipment used that it wouldnt matter who bought what from who, it could just work, like it should.
    If my light sockets are GE they should be able to take any lightbulb, not just GE bulbs, or be activated with GE switches.

    I wish I were better at embeded devices and protocols so I could just sit down, bang this out and give it to the “home automation” companies so they could all use it ands just get around to getting me a smart home that folds my socks for me.

  22. MQTT is the answer!

    All hardware devices ( sensors/actuators ) should talk MQTT over whatever transport is applicable to them. This could be
    Wifi ( talk direct ) or any other radios via gateways.
    Controllers then just communicate to the MQTT bus. This allows you to have multiple controllers and choose what is made available to any “cloud” services.

    1. @BG, I like SmartThings but it has it’s own set of problems. Not a whole lot runs locally so the loss of access means much of it stops. Also their Smart App system sounds good but they’re overwhelmed. I have it running with an MQTT interface and I’m happy with that (for the moment) but adding new devices with capabilities outside what they support is annoying (if I need a numeric value, I use the temperature capability, but what about a string?). At least with the MQTT I can integrate it with my existing software.

    1. I have little love for Java based applications (a bias). The enterprise ones especially. Load up the application and find out it has dependencies up the wazzo. Need this library and that library then this one too. Most annoying! Misterhouse has this problem too but not to such a severe extent. My friend tried to load OpenHAB on a Pi and quickly ran into that (he has no background with Java applications), he also ran into that with Misterhouse but I know MH rather well and loaded it quickly (we only needed to add 2 statements to the ini file and add one library via CPAN). Of course both are guilty of lousy documentation, this is where the real problem starts.

      BTW, Misterhouse runs at about 500K (RAM) when loaded with the MQTT interface (a minimal setup). Does anyone know what OpenHAB runs?

  23. Personally, I dont think the software is that big a deal. There are some existing expensive solutions, like commercial building control or SCADA packages. There are also existing domestic solutions, like Homeseer, or even open source projects. They all have their pro’s and cons but are generally extensible with plugins to suit whatever hardware.

    The bigger issue I have is the number of home devices that are really not designed to have a computer interface:
    Split System air conditioners – have front facing IR but that means a transmitter cable snaking around the outside.
    Ducted aircon zone controller – I had to hack an arduino to simulate button presses
    Mains power meter – has an IRDA port but is proprietary and locked down. Had to had add an external LED pulse counter.

    Most of the time a simple RS232 interface would be enough, Ethernet would be even better.

  24. “Look to the PC industry. You can run the same program on a Dell, Acer, Asus, or Toshiba laptop.”

    the PC was an accident, IBM tried to defend their IP and lost. No other company has been dumb enough to make the same mistake again. So we are locked into waring camps. The ARM64 server platform spec is the closest I’ve seen to something like the PC happening again.
    Hardware companies are notorious for being bad at software.

    I would like to propose looking into server management for IoT management, particularly the new Redfish spec. In particular, the use of RESTful APIs, JSON as an interchange format, and the schema system would seem like a good place to start for IoT devices.
    The radio tech is its own issue, maybe SDR can help there.
    Putting the two together could be interesting, running HTTP over some lower layers that aren’t even close to Ethernet sounds like a potential challenge. But I think the looking into server management might provide some inspiration for the software end of things.

  25. I would recomend Domoticz! Think it is the most complete and user friendly HA.
    Pretty easy to hook up everything that speaks 433mhz, z-wave, html, and more….
    Took me 1 year to find a good solution, tried every f***** ha software on the planet! But Domoticz help my life, they even have a good app aswell.

    peace

  26. https://www.mysensors.org/controller/ is a list of all the glue. I personally use domoticz for software, it runs on a pc/pi or nas. It. Uses Blockly or for more complex, lua scripts.
    I can turn my lights on when im away and at a random time, close my blinds and turn the sprinklers on when it hasnt rained for a few days. It also controls my av receiver and send push notifications. Domoticz with mysensors is definetly a good cheap way to go.

  27. Well the issue here is also to differentiate between stuff that should be automated and stuff that should be automated and smart/accessible over the web.

    LIGHTING
    For light simple IR motion detectors would be best in my opinion.
    You need the light to switch on when it’s getting dark.
    You need the light to switch on only when somebody is there.
    You need the llight to switch on and off automatically.
    IR motion detectors can do this with settings for distance, lightness (=lux) and time.

    motion detection lighting on doors of the house and indoors is the smart way at home for 99% people.
    even if you want to check with an IP-camera or something if you switched off the oven you wouldn’t need to switch on the lights in the room because (with the oven in view of the camera) you would be able to see light from controls or the oven itself in normal view and in night view anyway.

    FRIDGE
    would be nice to have a fridge which tells me what I have stored, were it is stored and when it goes bad.
    would be even better if it creates a list of items to re-buy and lets me add to the list, when I take stuff out.
    most stores have software like that.

    Would you need this to be accessible from outside of your home, too?
    Yeah maybe it would be nice to look up the grocery list or what’s stored in the fridge on your way home from work…

    BATH
    Do you really need to have your bathtub filled with water from your smartfone on your way home from work?
    It doesn’t really take long for a bathtub to be filled…
    I would argue here that it would be more than enough to be able to save some settings for amount and warmth of the water.
    letting water in should be manual – stopping water at a certain point to prevent it from overflowing should be automated.

    COOKING
    well you can put rice in a rice cooker and prepare the amount of water needed.
    Here again I would say it’s sufficient smart if it ends the program automatically when the rice is done.
    You can switch the device on, while you “wait” for the bathtub to get filled with water…

    similar devices will cook meat, vegetables etc and have it done in like 1hour after you manually switched the devices on and let them do what they do. I’m not sure if one really needs such devices to be any smarter than they are now. until they can’t prepare meals all on their own (from taking it out of the fridge, washing, peeling…, cooking) they are just not smart enough to make it necessary for someone to let them start remotely via smartphone or whatever.

  28. To me, most home automation looks like a solution looking for a problem. While sometimes a solution looking for a problem can be entertaining in itself, this is not a big reason why I should spend my problem-finding time with setting up some “smart” colored light bulbs instead of some other project like using an Arduino to score a homemade skiball machine and post the results to a web server.

    What home automation really needs is a some sort of “got to have it” application – something that’s not just, “Hey, that looks cool,” but something that’s useful enough to actually spend serious money on buying the hardware it requires. I could see a discrete device of some sort being useful, like a fridge that I can check its inventory from my smart phone when I’m at the grocery store. But I don’t see a real rationale for tying devices in my home together. Wiring a fridge so that it can talk to a toaster is a lot easier than figuring out what they could possibly have to say to each other. “What did the toaster say to the fridge?” seems like you should answer it with a punch line rather than a data layer.

    1. Most of the devices are ‘this is cool, look at what I can do’. Many times, something that’s a test bed to prove and idea. The internet connected eqq tray was one such example. Of course it is an example of a radio device in a frig. It might be useful if someone needed to keep medicine in the fridge and needed to keep track of medicine. So that they used to oldest first and reordered before it became critical. Sorry I couldn’t come up with anything better.

      And what you’ve described above is an inventory management system with sensors (or something that can sense when things are added or removed). That can be useful as there are changes in the season when my usage patterns change and I start to find that I end up with bread that is getting a bit stale (just an example). That would be useful as I can’t alway remember what I need when I’m at the store.

  29. I think home automation is strongly related to voice recognition technologies (nobody will replace the AC remote with a tablet, but everybody will want to get rid of it).

    Unfortunately, until some breakthrough in voice processing happens, we’re stuck with two solutions: Amazon Alexa & friends (this way requires cloud connections and adds some privacy nightmares, but because of the huge install-base and collected dataset, does a good job of transforming the audio stream to text strings) and DIY standalone solutions like CMU Sphinx (which is open, but doesn’t work as well because of the limited dataset – if you speak English with a foreign accent, you pretty much have to train the software yourself, by providing lots of speech samples).

    Another nice thing Alexa does is transform from the natural language to function calls: its AI maps “what is the weather in London?” to “getWeather( ‘London’ )” – even with a very limited set of possible called functions, I don’t even know how to approach this problem, as I’m not an AI specialist.

    IMO, as soon as this kind of voice-recognition and natural language processing gets usable without needing a huge training set, open home automation applications will take off.

  30. There’s a whole slew of factors here, and a bunch of them are pretty important. Fail on one, and you’re cutting the population that will consider adopting it.

    Cost- For a truly connected home, you want as many of these simple gizmos through out the house as possible. Cost adds up quickly, and is one of the biggest barriers to adoption.

    Complexity- Ties directly to cost, but also user experience. At some basic level, a switch needs to just be a switch. Someone should be able to walk in to my living room and dim the lights without reaching for their phone or consulting a manual. A light switch doesn’t need Android, or linux. Hell no. A smart light switch needs a consistent physical interface, and the ability to interact with the home, at large. It needs to be able to convey the current state, maybe a couple of memory parameters (min/max power settings), and to change those when directed.

    Reliability- This one is simple: We expect the light switch to work. But consider how the light switch is being told to change states (see interoperability, infrastructure, and user interface).

    Interoperability- For the sake of all that is good, just do it. Closed systems aren’t going to work in this environment. The arguments are legion against it, and the only reason to keep it closed is to trap buyers into a system. STOP IT! Make your protocols open and easy to use.

    Power- All of this “Smart Stuff” is either quietly sipping some power, or useless when it is turned all the way off (until someone manually turns it back on). Can we accept that minimal power draw? How low can you go?

    Infrastructure/Backbone- Here’s the tricky part. How do you get all of this to talk to each other? Powerline communication has apparently gotten better (I’m not buying it, but YMMV). WiFi? Personally, I’m a big fan of WiFi because I live in a single family home that is separated from the neighbors. I control that infrastructure, and it isn’t encroached on. My circumstances would change dramatically if I lived in a four hundred unit apartment building, each with it’s own wireless router. Something else? Be careful, don’t stomp on the interoperability issue above.

    User Interface- This is frequently the Achilles’ heel, but can actually be solved by embracing some of the above items. Don’t like the Brand X interface? Adopt Company Q’s software instead. Since you’re using open protocols, and you’ve kept the complexity of your device down, others can come behind you and implement different features. Hell, here is the big selling point for many on this board: The end users themselves will have the capability to tweak their system to their heart’s content.

    Everything is pretty much there, it just needs to come together. WiFi chips are around the $1 level, in bulk, from certain overseas providers. Even with the cost doubled (reliability and sustainability), it’s not a bad deal.

    Getting all the parts together, that’s the trick.

  31. I have been on a DIY Home Automation journey for over 10 years now, learning, refining, improving the DIY hardware and especially the DIY software to a point that the software is functionally equivalent to the popular systems mentioned here and also incorporating a number of unique approaches & functionality. It has been a fun & educational exercise using my house as a testbed, initially starting with everything built from first principles (eg. DIY RS485 multi-drop protocol between smart nodes, even speech recognition to fit in a 2K PIC using BASIC along with a cooperative multitasking framework supporting network, LCD and IO). Now I try to keep everything as open as possible.

    It is the software that has maintained my interest in HA and agree with this article that software is where the big gap is, and also the opportunity as software is a blank canvas with so many possibilities to create. My vision for a home automation solution is that it must be standards based using modern technologies, based on a local hub (cloud isn’t fast enough or reliable enough although cloud services can augment local features), front end that is visually pleasing, extensible by the end user and dynamic, available on any device (including voice and video channels). An integration layer that is simple, scalable, easy to write and add new device drivers. An automation engine that is event driven, where historical data is just as easy to use as current data and being truly smart by layering sophisticated logic according to current or historic state (not just ‘if this then that’).

    Years back when first looking into HA I wanted to use a package like homeseer but didn’t like the idea of investing my time to learn and get locked into proprietary solutions (eg. scripting languages unique to the package) where you are dependent on the evolution of the product compared to modern technology platforms like .NET, Node.JS and HTML5. With these platforms a lot of the services needed for a HA system are built in and you have so much more flexibility and an almost infinite ecosystem to leverage. Take a layered services approach where the you start with low level services (including those inherited from the technology platform like websockets) as the basis to build richer automation specific services (eg. event management service) so the features/functionality can evolve over time.

    I use Node.JS for the device integration layer which has been a godsend – the ease of writing in JavaScript & its async nature along with the huge number of NPM packages (think libraries for those who know C) available goes a long way to making it easier to write device drivers. Driver support is critical but it really isn’t that hard if you concentrate on the logic of interfacing with the device in the driver and use the automation framework to do everything else. A lot of devices use a simple protocol to control them (eg. REST commands or serial strings) and most of the time you are dealing with sensors (ingesting their data) rather than actuators (controlling the device) so you end up with most driver code reading their input and reformatting to the message format the automation engine uses – quite simple. For a new device driver I start with a template that exposes to the driver an API to interface with the automation engine and most drivers are a couple of extra lines of Node.JS code especially if you have a NPM package available to help (like the serial module). The automation framework provides a service to read and manage a settings file for the driver so you can describe the driver semantics in a text editable settings file in a standard format which describes the device attributes (eg. minimum & maximum values, local state store, IO channel definition).

    Using open standards and platforms has proven to be a major advantage – when I decided to add MQTT as the publish subscribe protocol for my sensor platform, it literally took a couple of hours to add MQTT support to the hub driver framework as there were NPM modules that had all the MQTT functionality available (both high and low level) as open source and in use by others so I know it has most kinks ironed out. In the microchip sensor framework I’ve developed (in C – see my blog on hackaday.io) to talk to the hub over TCP/IP this took several days of work just to implement basic MQTT functionality and was quite difficult to debug, which really highlighted to me the advantages of modern development platforms like Node.JS versus old school C/C++.

    However relying on high level open platforms like HTML and Node still have downsides. For example, when implementing mobile functionality into my UI framework (which was only about 10 hours work due to the portability of HTML cross-platform), I had to spend another 2 hours working out why icons weren’t showing up on the mobile browser. As I was using Microsoft Azure as the mobile gateway, it worked out that certain mime types served from Express (Node’s web server) were being intercepted by Azure and HTTP headers were being updated. If I had full control of the platform this wouldn’t have been a problem. So you do have to work within the quirks of these platforms but open standards/platforms are still a big benefit. Effectively your are leveraging the open platform as part of the system implementation.

    Likewise with HTML5/JavaScript there are many advantages to be had. I have built a widget based interface where HTML5 widgets can be dragged from a toolbox onto a design surface, scaled and manipulated with a mouse so that the UI can be created in the same way you create a powerpoint slide. These automation widgets are generic HTML5/JS with minimal boilerplate code so are very easy to make & extend, and consume or source events managed by the automation engine on the server using pub/sub. This means the UI is accessible across multiple platforms including mobile, the end user can design the layout without programming, and for anyone with even basic web design/development skills can easily add more widgets.

    The third piece of this puzzle is the bit in the middle, the automation engine which is event driven using a standard topic based message format shared by the Node.JS device driver plugins and the HTML5 browser communicating over websockets. This is written in .NET and will be ported to .NET core so it can run on Linux and Windows (once .NET core matures a bit more). I chose .NET as it has better error management and multithreaded performance compared to NodeJS and it also manages the data and state store. One of the features I’ve added is virtual device drivers that have worked out to be very powerful and I haven’t seen implemented elsewhere. These look to the system like a real device but are created by transforming the data from existing devices into higher level abstractions. For example, I have 3 phase power to the house and sensors to monitor all 3 phases. I don’t really care about the individual phase power consumption but I do want to know the total power consumption. So I configure a virtual driver to be the sum of all three phases and each time the power of a phase changes, the total consumption virtual device automatically changes and I can utlise the events from this driver the same way as real devices (eg. for history graphs, real time power meter widget). Going further with this concept – I also have solar on the roof so I can create another virtual driver that uses total power events from the total power virtual driver and subtracts the solar power generated so I know total power drawn or fed into the grid. And the utility company will pay me 2x the peak tariff if I feed power back into the grid, and using another virtual driver I can calculate in real time the savings I am getting back from the utility co, or do history graphs, create alerts on maximum power use and so on. All this through configuration not hard coding – i.e. an end user can set this up.

    If anyone is interested here is an example of one of the UI dashboard screens (all entities on this screen are widgets able to be manipulated size, position, scale, attributes with a mouse, nothing hard coded): http://1drv.ms/1GgB1hY
    Here is a screenshot of the UI design surface: https://1drv.ms/i/s!ApUB68SilQqFgttNXXuXJl7C5nc00g
    An example of a configuration screen for a virtual driver: https://1drv.ms/i/s!ApUB68SilQqFgttP9HIWD9yMtSMbOw

    Sorry if this post is a bit rambling – as Ernest Hemingway said I am sorry to write such a long letter but I didn’t have time to write a shorter one…. Hopefully it outlines some of my ideas about what it takes to build rich software home automation systems.

    Anyway I’m thinking of doing a more comprehensive write up of my system for the hackaday entry except that I don’t have 4 project logs so won’t qualify.

    1. Have you any plans to open-source it?
      Ad the automation engine…I actually had all the front-end to back-end glue (DB access, MQTT handling, web interface, logging, rule engine,..) written in .NET but then I switched to OpenHAB which has most of these things built-in and offers more. OpenHAB can “normalize” messages from devices (either your own like esp8266, arduinos,..or commercial ones) so you can use the data from those devices in the same way in rules. Rules can be written in XTend, Jython (kinda Python) or Javascript. I opted for Javascript. OpenHAB has many other features like REST-API built in, web interface, DB persistence, voice interface etc. A kind of virtual device could be created with rules too, have multiple mqtt topics/messages as inputs to the rule and fire another mqtt message if any of those inputs change. For now I am using OpenHAB as a rule engine only. I don’t really like it’s web interface so I am writing my own, using MQTT broker with websockets on the server side and Paho javascript client on the client side. That should give me the best perfomance since you’re basically sending mqtt messages right from the client to the mqtt broker (via websockets). So the slider on a smartphone will dim the light almost in real-time (btw. that’s something OpenHAB can’t do at the moment). I might use OpenHAB’s REST-API as a gateway to historical data stored in DB and to internet data (like weather) in the future. This is my second rewrite of the project, HW and SW wise and this new one is in it’s infancy at the moment, lack of time for the project does not help either :) .
      I must say I like your widgets and the editor. That’s what I’ve been thinking of as well to do for myself and that’s why I asked if you’re thinking of open-sourcing it. I will most likely code my own breed of widgets (I am using knockout.js for example) but your code might get me pass some hurdles for sure :)

      1. Yes, I am thinking of open sourcing it. I have lots still to do (update to Javascript ES6 when standards like web components are implemented by major browsers, use vuejs to manage the front end for the database, port the engine to .NET core & implement the API more consistently) and if I open source it others can help me improve it as well as share their UI widgets and device drivers. Its on GitHub now if you want to take a look but I don’t have install instructions yet. https://github.com/deandob (along with my PoE sensor platform that I have a hackaday.io project log on). I do want to launch it as an alternative to homeseer, CQC and openHAB once I tidy it up, as I do think it offers enough differentiation to other solutions (like the flexible HTML5 UI, transformation engine, the only NodeJS open source HA platform) that others will be interested. Getting the time to do it is the problem at the moment.

        I did look at OpenHAB initially but didn’t like the Java implementation or the front end. Like OpenHAB I also have implemented a REST interface, MQTT, websockets, DB persistence and Echo voice interface, my point is that adding all these features is relatively easy if building upon open platforms like NodeJS. Also all the widgets work real time, so moving a slider to dim a light will dim the light (there is a slight delay of 50mS or so).

        The front end has been built so it is very easy for a non programmer to create a UI and my wife and kids mark up their own screens to how they want to see their dashboard (each device can create its own UI or share with other devices). As you can see in the weather dashboard I posted a link to it integrates several data sources – weather sensor data, current forecast and radar from the Meteorology Bureau, temperature history as well as day/month/year highs/lows (transformation engine calculates these real-time). The weather dashboard is a passive screen just displaying data, other screens mix data and control (eg. the lighting dashboard screen has a 3D house layout with light widgets for each light location that lights up/down/dim in real time when the actual light switches are pressed, the user can touch the light to turn it on/off or touch + delay to dim, button to turn off all house lights, dial to show total number of lights on).

        Say you wanted to add a stock ticker widget to show your favourite stock price real time in a dashboard screen. Add a device driver that pulls the stock price from Yahoo and post it to the event engine in a standard topic format (takes about 20 lines of JavaScript using NodeJS HTTP + 10 lines of boilerplate code to interface with the engine). Any text widget can now subscribe to this topic and get the real-time stock price, the timeline graph widget can draw the stock history that the user scroll through the history or zoom in/out of the data, you can build a new scrolling ticker widget using standard HTML & JS (+ a few lines of boilerplate to interface with the front end), the transformation engine can track the days highs and lows, the triggers in the automation engine send you a SMS alert if the stock price goes over a certain range and the query function can be used to check what days of the previous week had the biggest price swings. All very easy to add without much coding, the possibilities are endless.

        It is more than an home automation system, it is a house portal. Back to the generic question for this article, there needs to be a killer application to make HA compelling to the masses. I don’t think there is a single killer app but I do think that a combination of smaller useful features (examples like the weather portal, stock ticker, open/closing front gates remotely, security, mobile access, receiving a SMS when someone presses the front bell if I’m out the back and can’t hear it) coming together in a rich and user extensible front end does make a compelling story.

  32. Back in the 1980s, my family had an X10 Powerhouse setup that was controlled through our Macintosh 512k, and the interface software on the Mac was pretty good. Basically, you draw a floorplan of the house, and– if memory serves –you create objects that represent all your devices, and they basically show up in the floorplan like desktop icons. Simple and it worked like a charm. And you could make the floorplan interface as pretty and accurate as you wanted, within the constraints of the 1-bit color graphics on the Macintosh.

    You could also set up macros and timers, and virtual devices (like you could have devices A1, A3-5, and A9 all grouped into a single virtual device assigned to A15, allowing you to use just a single button on the physical control panel to switch them all on/off.)

    This sort of interface is simple to work with, probably simple to design, and caters to just about any level of tech savvy and a wide range of aesthetic desires. (Some people may want a simple and accurate floorplan view, some may want a stylized isometric view, some might be fine with just having device icons grouped by room and no floorplan etc.)

  33. Okay, sorry I’m late to the game. I’ve had a very long week.

    Personal Information Technology Automation/Smart Home Information Technology (I hope I don’t need to spell that out for you … ;-) ) doesn’t need a software champion, it needs a team of champions for open standards for smart homes. This is too big for one person, it’s an eco-system. Smart Homes/Home Automation (HA) is about a lot more than timers and remote control. Those are just subsets of the category, in fact things having to do with the home is a subset (sorry I don’t have a better name for HA). Get information, make a decision, act on it (asynchronously).

    Cloud services are a huge problem, once you release control of your data whose data is it? Commercial services don’t really have a financial interest in too much security. They want your data for resale. That doesn’t mean I don’t see a use for the cloud, it is just I haven’t figured out how to place my trust in them. On the issue of trust when I do have data pass through a cloud service (like a public MQTT server) I want my data sent with encryption and with a signature.

    What I see in an HA suite is some kind of bus in the middle of the software suite (@DaveW mentioned this in this thread and the previous one). Something that is standard and light weight. So microcontrollers can communicate with the rest of the system. @DaveW has been using CoAP and MQTT. I really like MQTT. The next issue is the remote processors. I think most 8 bit microcontrollers don’t have the resources to handle the security, communications and work load needs of the remote device. In my opinion, it really needs to be 32 bit and a bit more in the way of RAM in these devices. If you’re going to make it easy for consumers to add these devices then dynamic protocols will be required (DHCP, security certificates, encryption, etc). Having dynamic protocols can be a huge security hole, so a locally run server with a local db is needed to increase the level of trust. And, no I haven’t fully thought out the security issues and what I have figured out has given me headaches. So

    * microcontrollers in the sensors and control devices. I prefer 32 bit microcontrollers with all it’s resources built in (nearly single chip). The central server doesn’t have this requirement. (Arduinos – okay, PIC32, ARM (like the Teensy), the ESP8266, etc)
    * Core buss protocol (CoAP, MQTT, etc) to allow different vendors to share to resources. I’m using MQTT which also allows easy manipulation of polled data to be turned into event data.
    * Local Central server for the user. This doesn’t need to eliminate cloud services but it does keep things running when the ‘Internet is down’. I’m using a ton of scripts, Misterhouse, SmartThings and HomeSeer 3.
    * rules engine, so users can have if/then/else programming. (built into Misterhouse, SmartThings and HomeSeer 3 but none of these are something my wife could use)
    * Machine Learning or Artificial Intelligence (optional). I’m beginning to play with MyCroft. I know what I want it to do, not sure how I’ll get there.
    * Presentation interfaces. I really want a nice interactive floorplan interface when a quick look tells me a lot about various things. Something that can be shown on expensive tablets. I’d create a simpler interface for the smaller screen of a smart phone though the floorplan could also work there (zoom and scroll). Voice is nice but there are plenty of places where I don’t want voice and a picture can be worth a thousand words.

    I think that the above can be delivered in the form factor of a Raspberry Pi like server (with SSD not SD storage) and Arduino boards (with support for 3rd party protocols like X10, Insteon, UPB, Z-Wave, and ZigBee). In my opinion, we have most of this now but a descent flexible presentation interface is still needed.

  34. Another HomeSeer user here… it is great to get everything controlled under one piece of software. I could go on for days about the cool HSTouch software w/ iPads in the walls, event engine, wall switches with indicators, etc. but I’ll focus on the issues the article points out.

    Cloud services: I try to avoid these at all possible cost. Nothing is more frustrating than a feature that you expect to use everyday being out and having no way to fix it on your own. Also, I do not like the idea of relying on someone else for services and to maintain them. See ‘Hardware’ below for service being removed just a year after installing the products.

    Amazon Alexa: I broke this out separately because Alexa is a great voice control for the house but that’s about it. She is extremely dumb. Basically a voice to text and then the text needs to match exactly what you want. Don’t expect Google intelligence from her. If I could find a substitute that I could run on my own machine I would have all my echo devices out of the house ASAP.

    Hardware: I only purchase hardware that I know can interact with third part devices. This was cemented by the fact that I purchased Nest devices for my house. Google acquired Nest and stopped supporting the ‘Works with Nest’ environment. This was enough to make my devices around the house pretty much dumb to me. Sure I can use the Nest app and the current software, but the whole point of my automation system is to bring everything into a central location. Maybe this was just a small fluke for Google, but I will not purchase any of their smart home device from now on.

    Software: HomeSeer + HSTouch. Its like a full PLC +HMI package for your home. Try it out!

  35. I have been using HomeSeer since version 1. It is the glue that binds the diverse elements of the home into a single interface. Sure it takes some time, and with HS3, you still need to write scripts (they are pretty simple scripts mostly), and you do need plugins for managing the one-wire sensor (for temp, humidity, lux, etc.) network and interface to the Ademco alarm, MyQ for garage doors. Still, with some initial effort, it all gets unified, and all interfaces “talk” to one another via HS. So it’s entirely possible to announce a garage door is opening, so and so just unlocked the door, and have the home re lock it behind you, lights on or off whenever or however based on occupancy or time or both or to have the blinds operate Somfy blinds via zwave and all house lighting All without needing a zillion apps or ITTTT nonsense, best of all, Amazon Echos are getting pretty good at providing voice interface and with that some other integration like to Logitech Harmony remotes. Using their diskless Hometroller line with their Z-net Z-Wave interface, I control a subset of more than 96 receptacles, outlets, light switches, dry contact devices, thermostats out of the total population for more than 400 devices. I started with just a few switches and plugs-in modules back with version 1 (x-10) back in those days and grew it over time. That is the right approach today for anyone new, start simple until you master the basics and then build it. It just is not that hard if you tackle it one step at a time. And about the need for scripts, I relay on a handful that extends the capability of standard Homeseer event processing. Still, there is a plugin that can significantly extend the HS event system that would eliminate the need for many of the scripts. I prefer to write the scripts. If there is a negative to HS, its that there isn’t a viable dealer community so far as I know and that one aspect they could improve upon. Lastly, with the advent of smart speakers (Amazon Echo in my case), the human interface is complete – not perfect, but more than good enough and it comes with a bonus to integrate a few other bits like Logitech’s Harmony remotes with Echos, and that interface works well too. Ps. i’m disabled – paraplegic and must use a wheelchair and home automation is a tremendous benefit.

Leave a Reply to Neil CherryCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.