Home Assistant is an open-source home automation platform running on Python 3
home-assistant.io
home-assistant.io
Besides being able to install it as a Python package on Python 3, you can also install it using our Hass.io OS. Based on ResinOS and powered by Docker, it offers over the air updates and management of your device via the user interface: https://home-assistant.io/hassio/
Edit: glad to see the project on Github is APACHE licensed. Any drawbacks from using the software compiled str8 from Github as opposed to downloading the binary blob from the website?
The published version of Home Assistant is 100% what is on GitHub. Home automation is able to gather very private details of your house. It knows when you're home, what TV shows you watch, when you go to sleep. We keep all this data locally in your house, without the cloud. We want to make sure that anyone can check and influence the code that is distributed. No data should leave your house without your permission.
We still offer the old API on top of asyncio, so we have been able to incrementally transition. By now the core and important components are all fully asyncio. Most integrations are not.
I work with a large-fintech platform which is partially powered by Python. Our old server was based around threads, queues, and socket multiplexing but we are gradually starting new applications in asyncio.
I recently completed a project in aiohttp which has been fantastic. What are your thoughts on aiohttp vs tornado?
Anyway, I suppose most teens who use today, got the word from gangsta rap and their "street hassle" ..
Thanks everyone for your hard work!
>"Control all your devices from a single, mobile-friendly, interface."
I had a cursory look through the github repo and everything just looked like python, nothing UI wise jumped out at me.
Thank you for this awesome software and community!
This still requires Home Assistant to be running somewhere else on the network and uses an ESP8266 instead of a Pi for several reasons, but it might help you out on your use case.
Currently, there is not much feedback available to the API when adding/removing nodes except for viewing the openzwave log files and comparing state lists before and after.
Also, are there any plans to provide hot reloading of config files, instead of having to reset hass? Large zwave networks can take 10mins+ stabilise after a reset.
We already allow reloading the most important pieces of configuration: groups, scripts and automation.
If you want automatic reloading when a file changes, feel free to contribute a watchdog component to Home Assistant so people can hook it up themselves.
Would you be open to pulling in an extra lifx library that's tested and working until such time as lifx discovery can be rewritten?
Are yours just not showing up at all, or are they coming on and off-line?
Were I to ask a specialist disability company to replicate the setup I have at home it would probably cost me 10 times what it already has, and unfortunately that's not hyperbole is it really would cost me that much.
Not only that, but the Discord[1] channel is not full of terrible old greybeards having a go at n00bs for not knowing things. The amount of patient and helpful advice I've had was learning over these past six months how to set it up has been amazing. That seems to be getting rarer and rarer these days among technical online communities, or maybe it's just confirmation bias. Either way they are very nice people. I've even had the developers help me with problems that are specific to me and my disability and probably not to very many other people just because they could.
They deserve serious props for this work, they really do.
@robotsandcake over on Discord
You can use the platform for free (we will also open-source over time), it can run on Raspberry 3 and we added an integration with the amazing Home Assistant: https://home-assistant.io/components/snips
And on your website:
> The First On-Device Voice Platform
Android already has on-device voice recognition. Just try getting in airplane mode and saying "OK Google, play music" or something that does not require being online.
We do a 100% on-device platform, where your data never leaves the platform, and we want to power the next generation of private-by-design smart IoT devices
How many times do we have to do this? Google isn't selling your data to advertisers.
Google is absolutely selling your data to advertisers.
If you mean they won't sell it to them in raw form I guess you're technically correct, and I'd of course agree with you, but I don't think this is the parent posters point.
They aren't being altruistic by not doing this; if they did they wouldn't be able to monetize it anymore.
Am I misunderstanding something here or are you just being pedantic?
It's the same reason I'm an iPhone user. I'd rather deal with a company whose business model is to sell me overpriced hardware rather than to "sell my data to advertisers"
Here on HN, we know the specifics, but FOX viewers don't (for the most part).
EDIT: clarified that I am using homeassistant to talk to the lightify hub.
Or really one as good as or better than those in the echo dot would be amazing, because that is what my baseline is right now.
What portion of it is currently open source?
This is a blog post on how to create your own custom assistants https://medium.com/snips-ai/build-a-weather-assistant-with-s...
One tip is to use GPLv3, which would force the users of your code, who would put the software on their hardware, to make it possible for their users to reflash the devices. For everyone who doesn't want to allow that you could offer a commercial license.
This way of open sourcing works quite well for example for the Qt Company, they sell commercial licenses to automobile companies which don't want people to reflash their in vehicle infotainment systems for some reason, so they pay a per device commercial license. The Qt Company takes the money and pays developers to keep on working on the free software version of Qt which is GPLv3.
Kind of win win for everyone, small users who play with the sofware on their raspberry pi get the source code and big companies with their own propriatary hardware would pay licenses.
Roomba makes sense to me. Sweeping is hard and takes a significant amount of time. Flipping a switch is not hard and takes no time at all.
1 - outside lights - various lights which light our home's pathway or areas we prefer to have lit at night come on automatically at sundown and turn off at sun-up.
2 - scenes; with HA, we can click one button - a switch with scene control in our case - and have the lights in the room go to a specific set point, receiver come on, select sonos, and tune in to a particular station - an activity which would conventionally require several manual steps with various input devices.
3 - notifications; with HA, I get notifications when the front door or garage doors are opened/closed.
There are several things I plan to implement:
1 - using presence detection and adjusting temps/lights/etc based upon that
2 - fan control; we are heavy users of ceiling fans, and integrating them into home automation would be a significant upgrade. Haven't found a replacement for our Minka controllers which supports zwave (or anything else).
All of this has been possible for years - usually with single vendor solutions which are very costly; HA integrates nearly all automation platforms into a single system allowing each platform's features to work together relatively seamlessly. It's a moving target, but has become very stable/reliable with recent releases.
More importantly, I didn't buy a Kuna for lights on and off with the sun, nor a Nest for presence detection, so I still don't see these functions as killer apps for HA.
A simple sunset/sunrise detector can be had from a cheap photo-resistor. 30 minutes prior to sunset sounds like it needs at least a micro controller with a real time clock and a lookup table with sunset times
One of the "killer apps" for HA is connecting different silo'd smart devices.
I finally gave up and now it's just on (or off) 24/7...
I'm considering giving it another try but I'm not to keen on investing in another tech only to see it fail as miserably as first gen z-wave
Is there no good standard that works over electric lines? Seems it could be so much more reliable and cheap. And every single device already has the wires.
Powerline Ethernet is sketchy with some wiring configurations but you'd think that these minimal bandwidths could be handled in nearly all wiring setups.
Is there any standard that isnt mesh based? Hub and spoke with lots of power like wifi seems much smarter.
Seems like complete idiocy to use a fragile low power mesh network for something that a) has to have 99.9999 reliability (like lights) and also has unlimited power (2kW+ available at each node!!) like lights.
The reason I went with zwave was because of the need to work behind an existing switch. For sockets it would have been much easier with 433-plugs.
I think the problem is that the switch itself is too weak in signal, and sits built into the wall. The z-stick doesn't reliably switch it even if I have it inches from the switch.
(Seriously, I use a nanoleaf aurora to make a nice sunrise to wake up to, and it also acts as a clock and part of it lights up red if any of my servers are down. I'm pretty excited about open HA.)
Can I control a Hue light bulb with some basic bash scripting and a cron job? Can I do it without calling out to some Internet based web service?
curl --request PUT --data '{"on":true}' http://<local bridge ip address>/api/<your api key>/lights/<light id>/state
One thing I noticed from your command: No authentication. Looks like any software on any device on the LAN can control the light. Is that really true?
To answer your other question, the bridge can be accessible via the online “meethue” portal for things like easy remote access but I think this is optional.
EDIT: oh, and it’ll generate internet traffic for firmware updates I suppose!
You just curl to your hub and everything...works.
That is exactly what he's doing.
How lazy I am once in bed.
Again, I am not trying to flame you, just telling you how I use it and giving you my reason for using the software.
Have a nice day! :-)
Light dimming alone is a huge improvement but the ability to start a movie or go to sleep without needing to get up to turn off the light is really great. Believe me I was just as skeptical as many people here.
All the other options I tried before the (admittedly more expensive) hue bulb were either clunky/big or unreliable.
However, when the light switches aren't well placed it is nice to add a layer of software abstraction between the switch and the light to be able to rearrange existing switches in your home without having to pull new wiring. So you can essentially just keep what you are already doing but make the existing, mature UI even more suited to your needs even if you're skeptical of all of the rest of it.
I'm currently running OpenHAB and it's rock solid (I have one with >2 years uptime on a BananaPI). If I want to extend it, I usually write Python scripts that either use OpenHAB HTTP API or send MQTT messages, so I've not yet felt the need to write Java code. While I'm proficient with Java, I'd have to set up a development environment.
But the OpenHAB scripting language - while very powerful - has a very steep learning curve. It's hard to work with if you don't use it all the time and you end up having to google everything single thing you want to do.
The Home Assistant community appears to be more active (about 2x) and the barrier for entry is much lower.
So, it was an easy choice for me. I also really like home assistants philosphy on library code- there is basically no device or tech specific code in Hass, their rule is to only use third party libraries with a wrapper around them. This greatly reduced the scope of the task for developing the internals of a home automation system
Finally, there is now a system in place in has where you can pretty easily write straight python code for scripts, instead of using a yaml config
I would go so far as to say Home Assistant is literally the best open source community out there today. Very active, lots of folks happy to help users with issues, and lots of devs happy to help newer devs through the PR process.
They do have strict code standards, but it's hard to argue that's a bad thing.
Home Assistant has certainly gotten a lot more particular about new code as the project has grown, but I still feel they do a great job of helping new users along.
Bummer you had such a negative experience...
As I mentioned later I have had PRs accepted but overall I find maintainership to be a real mixed bag. Better run open source projects do not have this inconsistency.
https://github.com/home-assistant/home-assistant/pull/9270 The second one was based on an observed defect in the UI. The defect is still there but apparently this is flippantly a “feature” now.
Disagreements about implementation aside this is not the response I’ve gotten from better maintained projects.
We are all volunteers and the last thing we want is to start argueing with every person on the internet. The maintainers would burn out pretty quickly. And that means that if we are looking at 20 PRs a night, we will make mistakes and judge too quickly. Can we look at less PRs and spent more time on each PR? Sure, then people get pissed that it takes too long to get feedback on their PRs. There is no winning for us here and so each maintainer will have to find their balance.
For 9272, Pascal has offered the correct solution: a service switch. Every platform could be sharing code with other platforms given enough configuration parameters. We have made the decision that that is not in our best interest as it means that growing one platform now has to be made compatible with all the other configuration options and it becomes a mess. So create a new platform if your change is changing the core of a platform (like removing the template from a template switch). Your comments after the PR got closed got probably missed.
For 9270, you rebased after the discussion took place and I don't remember if the code was different before. The current change looks fine for me. You've removed your clone so I can't re-open the PR for you, but feel free to open a new PR with those changes and tag me in the PR message.
Backend is Python 3 with asyncio. Source: https://github.com/home-assistant/home-assistant - License: Apache 2
Frontend is a PWA powered by Polymer 2 Source: https://github.com/home-assistant/home-assistant-polymer - License: Apache 2 - Demo: https://home-assistant.io/demo/
They all have built-in scripting, but it's pretty common to send events to mqtt and use some external tools for scripting. In ended up using node-red, because it looked interesting and was really easy to get going.
After a while it seemed like the only reason for using any of those 3 systems was the device support, and since I was just using z-wave, for which there is a nice node-red library, I decided to do it all on my own. It only took a couple of week nights before I had most of the things I needed.
It did feel kinda silly to do drag and drop programming, and I did en up using the function node a whole lot, but in the end I stuck with it because it allowed me to show the family what it does and how it works.
OTA updates have been seamless, but the out-of-box still requires some conf file editing, which may be a turn off for some. It did automatically discover AppleTV, Roku, and Hue (easy pairing).
For integrating "homebrew" sensors I was able to roll MySensors[0] platform with parts lying around in drawers to get house-wide temperature monitoring with a few lines of yaml.
Looking forward to further refinements to the platform!!
A big question is how this fails. It needs to fail into some safe condition. Raspberry Pi machines have a full Linux and no stall timer, so they can end up crashed or hung. If this thing turns devices on and is relied on to turn them off, that's a problem.
https://home-assistant.io/components/rpi_gpio/
Home Assistant is indeed an "aggregator" for a lot of different home automation devices. Personally, I find it very useful to have my Nest, my ZWave devices, various ESP8266 "things" (garage door controller, temp/humidity sensors, my doorbell, etc), along with my Chromecasts, and the home/away status of my wife and I all rolled into one state machine (plus a lot of "general" information... the time, sunrise/sunset timing, current weather in my area, traffic conditions, etc).
Having all that information in one place means those various components can be controlled intelligently, based on all the available information, rather than just the small island each of them would be on their own.
A Pi is totally optional, BTW. You can run HA on pretty much anything that runs Python3.
> A Pi is totally optional, BTW. You can run HA on pretty much anything that runs Python3.
> Home Assistant supports sensors and switches using GPIO pins (if you're running on a Pi, obviously)
> Home Assistant is indeed an "aggregator" for a lot of different home automation devices.
> Having all that information in one place means those various components can be controlled intelligently, based on all the available information, rather than just the small island each of them would be on their own.
(btw, hass means 'hate' in German)
One of the primary deployment platforms is the Raspberry Pi, so it is very well supported. I believe this would do exactly what you want:
I use a version of this: https://www.stavros.io/posts/wifi-enabled-rgb-led-strip-cont...
It integrates nicely with HA via MQTT.
Thank you a lot, this really helps.
http://www.vmwareinfo.com/2017/07/visualizing-smart-home-usi...
But my plan for the next free weekend is to look into Node-RED and a fully MQTT based system. I feel like that's the way to mix and match different frontends, automations, components etc.
https://aeotec.com/z-wave-usb-stick
See this documentation for more info please:
https://home-assistant.io/docs/z-wave/
And this for the specific controllers officially supported:
https://home-assistant.io/docs/z-wave/controllers/
If you're a new user, hass.io is going to be the most approachable way to get hass up and running while making it easy to install all of the add-ons and configure things securely + upgrade easily. The docs for zwave on hass.io are pretty straightforward as well
https://home-assistant.io/hassio/zwave/
And if you want to learn more about what hass.io does ontop of normal home assistant, please visit this page:
https://home-assistant.io/hassio/
I hope this helps answer your question.
I went and spent the money on HomeSeer and it has been so much better. Tons of great plugins that just work like MQ for the garage, IFTTT, etc. Has schedules, adhoc scripting integeration so you can run your own shell scripts on events, multi-event groups, a decent UI, logging and strong device support.
Its strangely written in VB but from a device support standpoint has been extremely solid and finding any device i throw at it quite easily.
Shoutout for data and API integration layer for Home IoT.
Last time I looked into this there was an uninvuative (for a newbie) config file that required a server restart to see changes. Not exactly the easiest way to learn as it was a very slow feedback loop.
(Automations have been able to be reloaded without restarting for a while now by calling the automation/reload service)
[edit: added word "service" at the end]