I find HE usually adequate in my pursuit of home automation. But in those cases in which HE does not have support for a particular device I want to use but HE does I have the following question:
If HE does not support a particular device and HA does can HA use the Zwave/Zigbee radios of HA? It is my understanding that the two way bridge between HA and HE relies on the other side having the ability to obtain results and just handing over what it has obtained. If HE does not support that device at all does HA still communicate with that device by using HE's radios? I guess another way to ask the question is if I buy a Raspberry Pi should I purchase a Green (No radios) or a Yellow (Has radios) Raspberry with the understanding that I already have radio's in my C8?
I have one more question: Is my guess correct that if I implement HA with a Windows virtual environment the performance will be significantly reduced with respect to a Raspberry? If the answer is yes then is Raspberry the best hardware platform or for about the same money can I do better?
If I’m reading your post correctly, you will want Yellow so you can attach to HA the devices not supported by HE. You would then share them with HE using the community app HADB (Home Assistant Device Bridge).
I use HA but not for zwave/zigbee. I use HA for ESPhome, NUT, and ibeacon.
Before adding HA, you might want to ask the HE community about the specific zwave/zigbee devices that you think are unsupported by HE. There are a ton of community drivers and some very helpful folks on this forum.
To add to @ireallyhopethisworks 's comment, I would also suggest offering some more specific use cases you have in mind, if in fact you have any. This will help people not only provide some more targeted advice with regards to HA use, but also any alternative options that may be available.
In terms of the HE <-> HA integrations, these are not so much about one platform using the others radio directly, they allow devices generally to be shared between the platforms, whether they are Z-type or not. That said, there can be limitations, so it would pay to check up on the types of devices you want to share and the attributes of these devices you care about. This is another reason why sharing any potential devices would also help.
Thanks for the feedback. I would like to attempt to make a more clearer reason of my asking the questions above. I am very interested in the HA environment and will purchase what is necessary to provide me with that playground. What I primarily wanted to know is if I bought a Raspberry Green can I use the Hubitat for zwave/zigbee radios instead of a USB stick that supplies that functionality. If I am told that the Hubitat cannot be used in that way I would probably just by the Yellow instead. If I get responses that indicated I get a Yellow (or some other SBC) would I have to worry about my C8 radios conflicting with the other radios? In addition, I would love to know if some SBC (or whatever) would be better than a Raspberry for about the same cost.
I should have also added that I support making use of additional platforms (like but not limited to HA) to broaden the options available to a smart home.
If you are generally interested in broadening your Z-type compatibility, my suggestion would be to purchase a HA system that allows you to at least include the relevant Z-type sticks, whether they be included now or able to be added later. Without knowing the type of devices you may want to include, either via Home Assistant or HE, it is hard to advise you on whether you should include Z-sticks in your HA setup or could rely on HE's capabilities as there are some devices that are better / only able to be supported via HA or other platforms and/or supported via HE.
If the decision about which HA option centres around Z-sticks, I would choose one that can be expanded in the future.
I would say this is a hard "No", HA will not be able to literally see or access the HE radios. With the right software and config they can share a degree of awareness of each other's attached items, like having virtual devices.
As previously suggested, it is worth looking at the specifics of a device that doesn't seem like it'd work on HE, there might be a way you didn't anticipate with the help of the community and 3rd party drivers etc. That said, sometimes HE may truly not be able to get a given thing to work, where HA might ... in that case, whatever HA hardware you use will have to have its own way to support the device's connection type, so yeah, probably additional ZB dongles or what have you.
I’m still having a little trouble conceptualizing what the OP is looking to do, but I think this is an important point to reinforce.
Hubitat and Home Assistant can’t share z-wave or zigbee radios. They can only share virtual representations of the devices directly paired to each hub’s respective z-radio.
Perhaps another way to view the answer to this is.... it depends.... One reason many people look to broaden their setup to include HA is that there are some devices supported on the HA platform when directly paired to the radios of the HA system, compared to when attempting to pair the same devices to HE radios.
And to take @marktheknife 's point one step further.... pairing a device to a Z-type radio on a HA/HE system is not seen as expanding the Z-type mesh on the alternate system, but rather, providing to the alternative system a virtual representation of the device.
So in order to have the option to use either system that best supports a new device type requires a radio in both systems, i.e. you would want a radio available in your HA setup if you want to be able to leverage the ability to pair Z-type devices with HA that are not supported by HE.
I use HA as an addition to HE for certain wifi or cloud devices that either don’t have an HE alternative, or would possibly hog resources on HE. I have a couple rules on HA, but definitely would not like to attempt making more rules on HA. It is not exactly a user friendly experience. Devices mirrored to HE from HA are indistinguishable as far as responsiveness goes from native HE devices. I just formatted an old windows pc with Ubuntu and installed HA. 16GB RAM 500GB SSD and an I7 that was collecting dust. It was essentially free and much more powerful than a rpi.
Do you have any experience using a virtual environment in Windows and hosting Ubuntu with it to run HA? I am wondering if RPI is so slow that I would be better off performance wise just using my Intel I9 11900K.
HA is not very resource intensive. I run it on a pi4/4GB and processor utilization averages about 3% while RAM utilization is around 30%. I went the pi route because it is drop dead simple.
An SSD instead of an SD card can be a good idea. The SD will die more quickly than an SSD.
I added HA to my setup but not because I had a problems with Zigbee/ZWave devices pairing directly to HE. The main reason for adding HA was to bring in Bluetooth devices and to get rid ftom could based integration. I started with RPi but very quickly switched to Odroid because RPi with SD card was extremely slow.
No. I thought about doing that, but it seems like there were additional headaches that Windows brought to the table (?dns and mdns).
You can use the Home Assistant OS (Hass os) instead of Ubuntu, but I chose Ubuntu so I would have more flexibility, since I have so much more bandwidth than I need for HA. I also run Homebridge, pihole, and an NTP server on it now and the cpu usage sits at 1% with ~4GB of ram in use.
I purchased a Govee RGBIC LED Strip (H617C that needs a Bluetooth interface) recently and that got me thinking of HA. I then did a little research and found out that this particular strip was not supported in HA! But HA is still something that I will pursue to tinker around with.
It is actually pretty easy. Just get a supported Hypervisor up and running on Windows, and then download the appropriate VM image from the HA site. The problem with this typically is that passing USB devices (like Zigbee and Z-Wave radio sticks) can be problematic. Also, MS Windows loves to install patches and then reboot itself. This can cause undesired downtime events. It can all be worked through and solved, but it does become a nuisance.
I started my use of HA in exactly this way. I soon realized that a Raspberry Pi, booting off of a SSD (not an SD card), was much, much simpler to maintain, and much more reliable.
Over years I experimented with many different LED Strips and controllers. As of today nothing is better than COB style LED Strips. If I don't need Color I am using 24V COB 2700K Strips controlled by plain low voltage Zigbee Controllers (in few cases I am using regular Dimmers with dimmable transformers). However if I need Colors I am using COB Addressable Strips (24V or 5V) controlled by Pixelblaze. These are a bit DIY projects but the result is outstanding. And sure, there is a very nice HE Driver for the Pixelblaze. Pixelblaze is a WiFi ESP32 based controller but the HE integration is 100% local.
I believe what I bought was considered COB but when I programmed white light I could see the Red, Blue, and Green depending on the surface it was bouncing off of. I had a strip on the bottom of my TV table and the "white" light bouncing off the smooth porcelain floor was RGB! The same strip on the back of the TV Table was actually pretty good because the textured walls combined the RGB lots better. I should have just got a white strip... live and learn.
