Uniquely out of date as of today, actually: https://home-assistant.io/blog/2017/07/25/introducing-hassio...

tldr; Home-Assistant, the system mentioned in the parent article, now maintains their own OS variant for the RPi that they recommend you install directly.

You don't have to, of course. You can still install Home-Assistant yourself on whatever distribution you choose.

If this is the sort of thing that interests you, and you happen to be looking for a job somewhere +/-3 hours from GMT, drop me an email. We're looking for good engineers at Neos to work on our connected home security system (we're also looking for people interested in building backend software for insurance, but that's somewhat less sexy).

We've got a Raspberry Pi based hub which sits in customer's homes communicating with z-wave devices, the software on there is currently proprietary but if you do buy a policy drop me a line saying you're from Hacker News and I'll turn on access to the MQTT broker running on the hub so you can play with integrating other things ;)

Hey, cool! I've been tinkering together something custom using a VeraPlus [http://getvera.com/controllers/veraplus/] and a raspberry pi for the last couple of years. It stopped working a few months ago, and sadly I replaced my whole vera controller before realizing the problem was that the wall wart had degraded and was no longer supplying enough voltage. D'oh!

The Vera doesn't have wifi (well, it does, but it can't join a network!!!), but a regular old raspi can act like a wireless bridge, offering wireless access to the vera, and a sound card, and also a linux environment to run my custom rails frontend. Add in some location reporting via Tasker, and I have an announcement sound whenever an outside door is opened, and I have motion and light sensors that record video and upload it to my personal website, and it's all controlled intelligently based on when my wife or I are at home. I'm pretty proud of it.

Home assistant works beautifully with the Vera.

It's how I have it setup right now, and it was a great way to slowly move away from the Vera (at least as the UI).

I've been running Home Assistant (the software in the blog post) for a little over a year now. (started out on a raspberry pi, upgraded to an Intel NUC recently for more power, and to do more non-home-automation related things on it)

It's by far one of the most well-managed community-driven open source projects i've ever used.

All of the "components" are just small-ish python programs that contain mostly "glue" code, and they are required to use 3rd party libraries to actually implement the real work. This spreads the workload out across many repos in terms of breaking changes and help, and makes it much easier to contribute back to (you aren't contributing to a massive monolithic repo, you are contributing to a small 200 line python library with 20 stars on github, much less pressure!).

Because of this architecture layout, anything that has a python library that can be consitered part of "home automation" most likely has it implemented already. In my setup alone I have:

* chromecasts

* 2 different smart TV brands

* many zwave switches (run through a vera, not using zwave directly)

* many zwave door/window sensors

* multiple ip cameras

* a wifi thermostat

* a few IR controllers for "dumb" IR devices

* phone/device tracking (which keeps all the data stored locally)

* usps/ups/fedex package tracking and delivery notifications

* network speed monitoring

* have-i-been-pwned monitoring and notifications

* weather

* a 3d printer's completion percentage

* a google home

* an amazon echo

* ups runtime monitoring

* multiple esp8266 based sensors and switches for various hacked together things

* and more that i'm probably forgetting

And all of it is processed locally (when possible), stored locally (in a postgresql database), secured via TLS, available on any browser anywhere, and on a server I maintain and manage (with the help of some automations I created in hass itself). And speaking of automations, it's python, so they are basically unlimited. I have an automation that will notify me on my phone if it will start raining at my phone's current location before I can get home, and only while on my motorcycle.

It's not perfect (it's pre-1.0 software, so there are still semi-frequent breaking changes, and configuration is mostly manual still via yaml files), but it's been a such an amazing experience.

Home Assistant is the reason why I love IoT.

I like the architecture of HA as well, but is there a way to use the HA level interface but making it program driven, as opposed to config-driven?

I know python...I don't know all of the config variables for the yaml language they encourage you to write

That's what the AppDaemon project is about - https://home-assistant.io/docs/ecosystem/appdaemon/ - it let's you do the automation rules inside code instead of inside yaml. You'll still need/want yaml for basic device connections and grouping, but doing complex automations can be done easier in AppDaemon.

They recently introduced "straight python" components i believe, so you can just write in that.

Additionally there are multiple apis you can use to interface other than the front end at https://home-assistant.io/developers/api/

Also the HA front end just calls those backend apis, so if you "emulated" those you could use it as a drop in for some other backend (in theory)

Thanks, I'll check that out!

Just curious on how you use Esp8266 based sensors and switches . Can you list some of your best use cases ?

Sure!

One of them is hooked up to a button on a humidifier in my house. I pulled it apart, and just solidered it to one of the buttons and just have the esp8266 respond to some lan rest commands. Using Hass I hook that up to the nest's indoor humidity sensor and it auto turns on when needed. Then I grabbed a small load sensor and hooked it up to the ESP8266 to every hour or so send the load value back to Hass for the water tank in the humidifier.

So now I also get notifications when I need to fill the water reservoir!

Most of them are little things though. One is solidered to the light in my oven that shows if it's on or not, and it can notify us if we leave the oven on, another uses a very hacky (literally 2 paperclips!) Short sensor to say when I open a drawer next to my desk. If I haven't opened it by 9:30 and work is on my calendar, it will notify my phone reminding me to take my medicine!

Once you have the major components setup in something like Hass, and you've worked through the headache of setting up the esp8266s, it becomes really quick, and there are so many uses for them.

My next idea is to put a load sensor in the center post of my chair and notify me if I've been sitting for too long (and maybe of the sensor is accurate enough, maybe weigh me every day? I'm like 90% sire it won't be though...)

Thanks , I was just thinking the load sensor one today in my office to lock my computer when I get out of chair and set slack to offline status as I always forget to do that . You should really start a blog or do a write up in hackster.io . Also looks like they announced hass.io to auto update and manage home assistant a breeze

I've been thinking how much I hate Iris and would love to replace it with something else, and I've also been wanting to play with a Pi

It's amazing how awful the state of home automation is on the commercial side right now

I think Z-wave has been or is in the process of being superseded by just using Wi-Fi. I do not recommend investing in Z-wave gear.

Unless you know something I don't, I think you're completely incorrect on both counts. Z-Wave isn't going anywhere, just a few years ago the Z-Wave alliance published Z-Wave+ and more and more consumer devices have been coming to market. They're all over Home Depot (among other large retailers) and backed by very large brands [0]. All major hubs support it, and z-wave offers many specific technical and security advantages over WiFi with respect to automation.

Z-wave has a much smaller threat surface area and requires no internet. In fact, it requires no central controller at all, as you can have controllers in every room for scene automation. The internet connected hubs bring a lot of shiny features to the table, but they're completely unnecessary for local automation. Even better, communication forwarding is part of the design so you can have a controller hundreds of meters away from the thing you want controlled and as long as there are a couple of devices on the mesh between them it will work. We've seen how great WiFi repeaters are... plus WiFi on battery is basically a deal breaker, whereas you can have z-wave devices last two years on some AA batteries.

Z-Wave and Zigbee are both so much better than WiFi at automation that I can't even fathom why someone would suggest the opposite.

[0] https://en.m.wikipedia.org/wiki/Z-Wave

I wouldn't say that it is getting replaced with wifi. But z-wave is definitely getting replaced by Zigbee, 6LoWPAN and Thread. (all of which aren't compatible with z-wave's proprietary hardware.) Also the entrance of the long awaited Bluetooth mesh, will have interesting effects on the market.

If market forces play out logically, Z-wave should lose out to any of: Zigbee, Thread, Bluetooth mesh, or 802.11ah (HaLow).

Z-wave is a proprietary protocol. Only 1 company has the IP & monopoly on manufacturing Z-wave chips... By contrast, any of these other techs are open and have multiple implementations available from multiple manufacturers.

History has not been kind to proprietary networking protocols, and it's winning at scale rarely about just technical advantages. I know they have opened up more in the past year or two, but it may be too late.

I refine my comment to capture BTLE as one of the protocols going forward, in addition to wifi.

I'll grant you BTLE and/or something more open ascending over Z-Wave or Zigbee, but I've got to imagine that's years out. If I was picking something for the next 5 years I'd still pick Z-Wave over the WiFi IoT horror show.

Also, there is a lot of inertia in the home automation space. Hue is all Zigbee, and is one of the biggest off the shelf IoT platforms right now. The door lock space is mostly z-wave. Friends that I have that have a mix of these things are more and more putting their energy into z-wave as it's far more reliable than wifi, having the advantages of the mesh network, and living in a non crowded spectrum.

Is there any concern that Z-Wave and Zigbee could/will be reduced to nothing more than a tinkerers platform after both Apple and Google grab more of the market (both of which appear to be building systems backed by Wi-Fi and Bluetooth)?

I don't know if Apple is going to go anywhere with Homekit as it sounds (third hand reports) like it's more expensive to get products HomeKit ready over just using other protocols, or paying a license to Z-Wave or Zigbee.

That being said, some combination of BT/LE/Mesh + WiFi and/or some other networking protocol would probably win very quickly if it wasn't encumbered with large licensing costs.

Fair enough, but it does appear Apple is committed to HomeKit; this marks the third year in a row they've made major strides and improvements, with this year being the biggest in terms of licensing and implementation.

In some cases using WiFi makes sense, for example if you've got a mains powered device such as a camera, smart plug, or similar. However z-wave really comes into its own with remote battery powered devices - a properly configured motion sensor for example will easily last two years on a single 3.3v lithium battery. That's despite waking up every few hours to report its presence, and probably transmitting the presence of motion, temperature changes, light levels, and other data points far more frequently.

Not Wifi, but definitely should be BLE. ZWave is notoriously insecure, the available chips are extremely buggy, and the licensing requirements very expensive. I used to work on ZWave products and now work on BLE devices. BLE has been far more pleasant of an experience. And Bluetooth is getting mesh networking soon!

Z-wave plus at its core is fine, the protocol is pretty well designed for home automation, and at least the chips I've used have been fine. Sadly the ecosystem is a bit of a shitshow. Everything will work to some degree, but you'll probably end up spending an hour or two reverse engineering exactly how any given device communicates what its seeing, and what configuration is needed to avoid draining the batteries within a month or two.

I'm cautiously optimistic for Bluetooth Mesh giving z-wave a run for its money but its still very early days.

Z Wave+ addresses many of the security concerns of Z Wave (the licensing costs remain, obviously).

A lot of z-wave+ devices do not implement that security portion and it's a pain to set up on top of it.

Z-wave's biggest short coming in my opinion is how easy it is to overload the network. Turning off 40 lights at once has half of the operations drop off due to the network getting overloaded and just dropping commands. If you have a few devices reporting their power usage, the network becomes quickly overloaded and you get the same command dropping crap in even simple operations like 'turn on light 2 when light 1 turns on and vice versa'.

I have a condo with z-wave everything right now, but after seeing how much of a mess all IoT home automation crap is, I'm going to sit and wait until we have something that works properly that doesn't cost $60-$100 per light switch or require maintaining something complicated.

----

IMO we should have a dual network solution. Something like wifi for plug in devices which also act as repeater networks for the battery powered BLE sensors and such.

I use Insteon. About 100 devices. Plugs, light switches, HVAC, leak sensors, motion sensors, cameras. Their support sucks when you have to deal with them and the programming of this then that is nowhere to be found. On the other hand I have had to deal with support twice and after pulling their heads from the ass they fixed the issues. Otherwise it pretty much just works and works as scale. These guys started with the X10 stuff in the 80s and are not going anywhere. So if you want something that will just work it is the best bet. They have a hub with HomeKit integration but I am not using it as they do not support some of the older door sensors with it yet.

Insteon sends packets concurrently via both radio and the power line. Devices also act as repeaters: there can be up to 4 hops to reach the destination. In theory this makes it one of the most reliable networking tech.

But it's dated (from the 1990s), there is zero encryption/authentication, and devices are kinda expensive.

It's not the lack of a dual link part, but the easy network bandwidth congestion part thats the problem with z-wave.

I used to use insteon in a small test build out, but got frustrated with their bad software support. You have to use a ~$300 hub with a $80 PLM modem before you can get something half decent. And Insteon devices having a reputation of breaking after a couple of years due to using cheap capacitors and such put me off from using it any further.

Absolutely agree. I have a z-wave alarm, and often times the automation rule will turn the alarm off, but will leave the strobe on. Sometimes lights will no turn on (or off). Sometimes some door sensors will report to be open when they are not.... it is a complete mess.

it's the ecosystem, you can find zwave switches, plugs, everywhere, there is no wifi switch I can find.

Esp8266 based wifi switches can be had quite cheap (sonoff is one of the brands)

looks perfect for my needs, is there any REST API documentation?

Dunno, but you can flash any esp8266 firmware onto it and roll your own API (or other smarts)

I mean write my own script to turn on/off the switch such as using wget or libcurl

Yeah, you could flash a simple Arduino sketch with such an API, and use that, assuming you can't access the in built API

tplink and belkin wemo both make WiFi switches and plugs.

IIRC the Belkin Wemo plug runs a full-blown Linux OS. Disgustingly over-engineered! Complex software & hardware means less reliability.

A remotely controlled plug should be running tens of kB of firmware, at most, and that includes crypto libraries. It shouldn't be running the megabytes of code that an embedded Linux OS represents.

Yuck.