Are there people who over the years experimented with those 3 leading platforms. Advantage of HA and Hubitat is that those 2 keep all data locally and can operate fully when Internet is down and Smartthings can do this partly (the basic flows).
But how do those 3 platforms compare in terms of:
Stability / no unexpected system crashes.
User interface for creating logic flows and the App interface via smartphone.
interoperability with Zigbee devices of different makes.
How rock solid is for instance the up-time of the HA platform and the Smartthings (cloud-based) services?
As someone who’s used all three, I’ve stuck with Home Assistant the longest.
Home Assistant in and of itself has been VERY stable. However, because you provide the hardware needed to run it, that can affect said stability. Run it on a Pi3B+ with an SD card and chances are you’ll have problems as the SD wears out. But, run it on a Pi4 with SSD/USB? Completely different experience. Run it on an Intel NUC with 16gb of RAM and a 500GB SSD, it’ll stay stable for years probably. But, there’s a caveat to this (and this applies to Hubitat as well); Introduce crappy code and you’re in for a rough experience. On Hubitat, all it took was one badly written device handler to bring down the hub. On Home Assistant, it’s a lot more resilient, but still entirely possible to kill it with a bad integration.
IMHO, Hubitat wins when it comes to making automations and rules in a graphical way. Home Assistant does have a built-in editor, but it still has its quirks and there is a bit of a learning curve there. However, one can use NodeRed for automations which is 100% better (again, IMHO) for most automation management in Home Assistant.
As for the mobile experience, Home Assisant provides a mobile client for both Android and iOS and they display the same dashboard that you would get through a browser (it’s all Lovelace). The real treat is the sensors support in the mobile apps; Battery levels, activities, network info, etc.
This is another section where it depends on the hardware you provide. I use the ZHA stack with a Nortek Zigbee/Z-Wave stick and have zero problems with devices. The great thing Home Assistant has over both Hubitat and SmartThings is that you can choose to use different Zigbee/ZWave adapters. deConz is one of the most popular (paired with the Conbee2 stick).
If by “HA Platform”, you are referring to NabuCasa, I can only recall one instance over the past year where NC went down and that was about 4 minutes. As for SmartThings, that really depends on how often they go down.
This is my uptime monitor for my NabuCasa instance:
Your choice of hardware, and what else you do on that hardware, will influence this. On my Pi3 I had one unplanned outage, due to a dead SD card. On my 7+ year old laptop… none.
I’ve seen people have things fail when they’ve added custom components (not part of stock HA). Otherwise outside of beta releases things tend to be pretty stable.
Upgrading to the latest stable version is the time with greatest risk. My approach is to not be an early adopter, I don’t rush to install the second a release is out. I always wait at least 24 hours to see if there’s significant issues - which these days are rather rare.
If you’re looking for some slick drag-n-drop UI, not so much. Automations (logic flows) are YAML - text based. You can build them in the UI, but if you try to do so without understanding the underlying logic things are painful.
Fortunately as has been mentioned there’s Node Red for the visual experience, or AppDaemon if you’d rather write them in Python. Oh, and NetDaemon if you want to use .NET.
I don’t really use the web UI much, but it works fine.
Take your choice of Zigbee integrations Built in you’ve got ZHA, or you can use either deCONZ or Zigbee2MQTT, or Zigbee2Tasmota, or …
All of the options work, they’re just different with slightly different device support (most document what they support) and adapter support.
I only use the cloud service for Google Assistant, everything else goes direct so I have no reliance on the cloud.
That said, it’s pretty good. I don’t have stats, but outages are rare. There was one recently that lasted a few days of intermittent issues, but that’s the exception.
Bottomline, could we conclude that a HA set-up on a Rasp Pi 3+ is nowadays a past station since it is vulnerable for crashes caused by the SD card?
Rasp 4, should be more reliable if you boot only from the SD and have anything else on a connected SSD?
Is that sep-up really worth it, since a Rasp Pi 4 + decent case + heat sink + SD card + SSD comes in the same cost range as a decent NUC (with i3) or a second hand decent laptop as platform for HA?
About NodeRed, can that be installed directly on a Rasp 4?
Yeah, as @Tinkerer said, if you can do better than the Pi3B+, go for it. If not, you could run HA on it with a decent SSD and still get good performance and reliability. The main crux is really the SD card; Some people have good results with them, others, not so much (me being in the latter category). Plus, the Pi3B+ is getting a bit long in the tooth, so the Pi4 (or better) is always going to be the better choice.
There are three Zigbee options with Home Assistant (regardless of how you install it). These are:
deCONZ is relatively stable and mature with its own UI (and Discord server). It can run in an add-on, in a Docker container, or natively. Only the ConBee range of sticks and RaspBee GPIO boards are support. Known working devices are documented, and how to request support for a new device is documented too (you can’t add unsupported devices yourself).
zha is actively developed as part of Home Assistant Core, using the zigpy stack, the UI also being part of Home Assistant. The EmberZNet based sticks are recommended, but there are other options. There is no list of supported devices, as any standards compliant device should work. Devices that require extra support are listed, and adding unsupported devices is documented (you can’t add unsupported devices yourself).
Zigbee2MQTT is very actively developed and can run in an add-on, in a Docker container, and natively, with no native UI. It uses MQTT for control and configuration, but there are third party UIs. It supports mostly TI based sticks, with the Zig-Ah-Zig-Ah! and Slaesh’s sticks being recommended. The known working devices are well documented (which usually includes how to pair them so you don’t have to find the manual), and adding unsupported devices is also documented.
It’s down to whether you want it tightly integrated with HA (use zha) or not (use Zigbee2MQTT IMO).
Btw, I get more and more the idea that staying away from the assembly of the HW platform (config HW & build, VM, Docker, which make&model of the zigbee/z-wave USB dongle, etc) is perhaps the way to go.
Why would I spend time, trying, testing and (driver) bug fixing a certain underlying HW and OS platform for HA in combination with certain zigbee, z-wave and/or wifi adapters?
Would it be more simple to use a Hubitat (with the built-in zigbee radio) and connect it via IFTTT for instance with a Smartthings if you would also like to use devices which operate with z-wave or Wifi? And if you have 433 Mhz devices you could interface between Hubitat or Smartthings with a Broadlink Pro (which has the 433 Mhz radio and also IR for instance).
Probably Homebridge can also act as the middleman to for instance the Homekit App.
I used Hubitat from when they first released up until mid-last year. The memory issues killed it for me. The lock ups, the fumbling around with Rules Manager, etc all caused me more stress because I wasn’t sure my home automation was going to consistently work. I absolutely respect Mike and Bruce (and I still miss Patrick) and the majority of the HE community, but I couldn’t stand to be locked into a hub that I couldn’t even figure out what was going on internally with it. I had been using HA for a couple of years as a sort of bridge between HE, ST and MQTT and it was OK, but it wasn’t until I went full in on HA that I realized just how bad the prebuilt hubs truly are. No way to see if the ethernet port was being throttled, couldn’t see if the new driver I just downloaded was coded badly enough to cause the CPU to throttle, etc. I literally couldn’t stand it anymore.
With that said, you have an incorrect assumption about HA: You can download a prebuilt image, copy it to a drive (HDD, SDD, thumbdrive, SD card, etc) and boot up either NUC or Pi and not have to ever touch the underlying OS; Virtually the same thing that the prebuilt hubs give you without all the hassle or locking you into some design decision that may or may not work for you. Or, you can go the mid-route; Docker image on your own OS. Or, you can go the hardcore route (python venv with your own OS).
The bottom line is that the choice is up to you on how you want to run and build your system.
A device like Hubitat Elevation provides convenience. It is far more of a consumer-friendly product than Home Assistant which, in its current form, is for hobbyists and tinkerers.
The trade-off is that you can’t replace or modify any of the supplied hardware unless you upgrade to an entirely new model. You can’t increase memory, storage, ports, CPU, or its wireless radios; it’s an appliance.
Home Assistant is a better fit for hobbyists who enjoy the process of assembling their own hardware and learning about the technologies that “create the magic”. Someone who purchases Hubitat Elevation is probably less interested in how the thing works (let alone assemble it) and exclusively focused on what it can do for them. There’s no right or wrong answer, simply a choice between what you want to derive from the experience.
EDIT
While composing my reply, I was unaware of code-in-progress’s latest post. I just noticed this comment that happens to reinforce my observation about who is best served by Home Assistant:
IFTTT just increased the prices that vendors pay them to provide connections to their service earlier this year. Enough that Tuya had actually dropped IFTTT support because their monthly pricing was too high. eWeLink went and created a “pro” plan ($10/monthly) to provide access to IFTTT to cover the costs that they pay IFTTT. Before July 2020, most businesses paid ~$600/annually (with a mandatory annual contract) to use IFTTT’s services. IFTTT turned around and raised that fee to over $2000/annually with additional fees based upon usage. Supposedly that applied to all three plans they offered to vendors.
There’s really no other way to put it than IFTTT is double dipping between hardware vendors and the consumers.
You’ll only have problems if you try to use some obscure piece of hardware, or pick a method that’s beyond your skills, and even then that’s only likely to be an install time issue.
If you stick with standard hardware and Home Assistant OS or Container, the odds of you having to troubleshoot OS or core hardware problems are exceedingly low.
I’ve been running “hardcore” (pip install) for 4 years, the only things that have come up with that have been:
The SD card failing - so I had to use my backup to recover, downtime was a little over 5 minutes, most of which was HA starting (because back then it took about 5 or 6 minutes to start my setup).
Having to manually install a new Python version - which is only a problem with that one install method. If I used the other methods it’d be handled for me.
I have had to troubleshoot adding Zigbee and Z-Wave devices, but those parts aren’t special to HA. You’d have that with any solution.
OK, great to read that all works well at your end and practically with no down-time over the years.
May I ask which hardware components you are using for the HA set-up and which Zigbee / Z-wave dongles?
Built in you’ve got ZHA, or you can use either deCONZ or Zigbee2MQTT, or Zigbee2Tasmota, or …
