I'm still figuring out Home Assistant. I love that it has a real ecosystem and that it seems to have a decent HTTP/WebSocket API (that I just started playing with).
Some things I don't love:
* A lot of the integrations seem half-baked or to not quite fit the generic Lovelace cards. I think to some extent this is an inherent problem in supporting a lot of devices that have crappy, non-standardized APIs. Example: if I bump up the low temp on my Venstar thermostat on the Home Assistant dashboard, Home Assistant will immediately set it back. If I dig through logs, I see the thermostat complained that in auto mode (heating or cooling as needed), the low set point and the high set point have to be (at least) six degrees apart. When I adjust the thermostat through its own touch screen, the high set point automatically raises to meet that constraint. Home Assistant should do the same. I've been meaning to look into fixing it myself, but there seem to be weird things like this on every integration.
* You need multiple automation rules to do almost anything. I think it's common to want the state of one thing to match another (for example, garage door open => sticky notification on my phone, person in driveway after sunset within last 5 minutes or switch on => driveway light on). You need a rule in their YAML DSL to for the off->on transition and another for the on->off. It'd be nice to set a rule that defines a level rather than an edge and have it internally do the transformation. It'd also be nice to define the actions of a notification's buttons inline, rather than as a separate automation.
* The companion Android app's notifications seem to be flaky. At least, they're sometimes slow. I think they can be delivered out of order and possibly are lossy, which aggravates the problem with not having something that just sets the state reliably. I assume it's pretty hopeless to have it reliably be in the right state if your phone was off when a notification was supposed to be delivered or Home Assistant was down on state transition or the like.
* Some things seem to be only checked at startup, so my house has race conditions after power outages. For example, if Home Assistant starts up more quickly than my Yamaha AV receiver (+ network switch + DHCP server), I can't control my home theater setup until I restart Home Assistant.
> ... for the off->on transition and another for the on->off. It'd be nice to set a rule that defines a level rather than an edge and have it internally do the transformation
The "solution" I found was to poll, and use "choose", and sometimes some helper switches for state, to do what is needed. But, I think at any reasonable level of complexity, you're better off using one of the three python components: the one built into Home Assistant, pyscript, or AppDaemon.
Thanks for that. I just tried out pyscript. I found it a lot more pleasant to write automation in a real programming language. It also more or less addresses my complaint about needing multiple rules. In the tutorial, [1] the motion_light_rear example addresses this via sleeping + task.unique. It's not the approach I imagined, but it's aimed at the same problem.
> The project group was launched and introduced by Amazon, Apple, Google, Comcast and the Zigbee Alliance, now Connectivity Standards Alliance (CSA).
I'm having a real hard time believing that anything user-beneficial will come of this, unless you're willing to sell out your smarthome and privacy to big tech.
Another way to look at this - maybe this is a way to give a pressure relief valve for all the privacy conscious so they stop harassing them so much for the 90% of consumer case that doesn’t care?
I think people are also very unhappy with latency. The only way to get low latency is to keep things local, and for devices to work together, directly. But, people still want remote access.
> I'm having a real hard time believing that anything user-beneficial will come of this, unless you're willing to sell out your smarthome and privacy to big tech.
At this level, the way data is handled is vendor agnostic.
I see Matter as more akin to USB, or indeed, the internet, as the idea is that devices are supposed to be able to communicate via IP, not just by ZigBee.
> my house has race conditions after power outages
I'd be inclined to find something with an SNMP counter that counts up either "seconds since boot" or "megabits of traffic passed" or whatever else and have a script that runs shortly after the RPi boots to reboot the Pi if that counter if below some threshold.
Running this from the pi will query the uptime on my router in milliseconds:
snmpwalk -v 2c -On -c public 192.168.2.1 .1.3.6.1.2.1.25.1.1.0
You could have a startup script on the Pi do something like "wait until you get a valid reading of this uptime and if that reading is less than 180000 [3 minutes], then sleep for N minutes [long enough to not double/triple reboot on a power outage] and reboot the RPi (or restart HA)"
If HomeAssistant needs to be recycled after every router reboot (not just on a power dump), have that script run in a cron job looking for an uptime less than some threshold and rebooting the Pi.
It might feel inelegant or even "gross", but I look at it as just reliably automating the fix and therefore better than what you're doing manually already.
I also hate that you have to install it as an OS or VM to be fully featured.
If you use the docker version it is crippled with no "supervisor" mode.
Also every now and then a light or switch will go greyed out in HA, their official apps still work, and I have to restart HA to be able to use it in HA again. Pretty annoying when you get home after a long day, soaked in rain, fumbling in the dark to turn on lights and now you have to fumble more to restart the damn server before you can use your lights.
It seems fine that this isn't available in docker, since you can do all of this via docker and your host's configuration system. It would be nice to have a GUI for it, but if you need a GUI then you probably aren't running HA via docker, you used their image.
Same here. Running on a pi 3 with nodered, both in docker containers. Works perfectly and reliably with hundreds of entities, numerous automations, etc. Just make sure you have an official pi ac adapter and boot off an SSD drive not SD card otherwise you will have problems.
I'm running HACS in the container release right now, it's worked for a long time. So long as you have your HA configuration folder as a volume etc it will preserve across restarts/upgrades.
I'd go as far as to argue the (officially supported!) container release is the best way to get a production quality install of HA - containers are a great way to package and release complex web apps like HA. Mines automatically updates itself every time new container image released, has done so with no intervention from me for over a year. With the container lifecycle/config, you don't really need Supervisor mode either.
To say it is crippled is nonsense, it is literally one of the two officially recommended install paths:
HACS works in a container, or is there specific functionality of it that doesn't work? I've been using it inside a Docker HA container on a Pi without issue.
Some things I don't love:
* A lot of the integrations seem half-baked or to not quite fit the generic Lovelace cards. I think to some extent this is an inherent problem in supporting a lot of devices that have crappy, non-standardized APIs. Example: if I bump up the low temp on my Venstar thermostat on the Home Assistant dashboard, Home Assistant will immediately set it back. If I dig through logs, I see the thermostat complained that in auto mode (heating or cooling as needed), the low set point and the high set point have to be (at least) six degrees apart. When I adjust the thermostat through its own touch screen, the high set point automatically raises to meet that constraint. Home Assistant should do the same. I've been meaning to look into fixing it myself, but there seem to be weird things like this on every integration.
* You need multiple automation rules to do almost anything. I think it's common to want the state of one thing to match another (for example, garage door open => sticky notification on my phone, person in driveway after sunset within last 5 minutes or switch on => driveway light on). You need a rule in their YAML DSL to for the off->on transition and another for the on->off. It'd be nice to set a rule that defines a level rather than an edge and have it internally do the transformation. It'd also be nice to define the actions of a notification's buttons inline, rather than as a separate automation.
* The companion Android app's notifications seem to be flaky. At least, they're sometimes slow. I think they can be delivered out of order and possibly are lossy, which aggravates the problem with not having something that just sets the state reliably. I assume it's pretty hopeless to have it reliably be in the right state if your phone was off when a notification was supposed to be delivered or Home Assistant was down on state transition or the like.
* Some things seem to be only checked at startup, so my house has race conditions after power outages. For example, if Home Assistant starts up more quickly than my Yamaha AV receiver (+ network switch + DHCP server), I can't control my home theater setup until I restart Home Assistant.