A few questions before pulling the trigger

[armand]

@erktrek

Consider Sengled bulbs then.. they do not repeat which is a good thing for smart bulbs. Also you do not have to get color changing bulbs to get temperature changes - for certain areas this may save you money and you would still have the ability to go from daylight to warm white.

Be warned that Sengled bulbs do not pair well in groups larger than 3 bulbs. They have unofficial, and spotty support for Hue Hub (if that is being considered), so they don't fully integrate well into the Hue system. And according to @justin.rodko, the performance and reliability of the bulbs in Hubitat is horrible.

Sengled Reliability

I have eight of the basic element white dimmable bulbs and four of the element plus colour bulbs. I have noticed that reliability and responsiveness of these bulbs is terrible with Hubitat. I am not using the sengled hub but directly with hubitat. For basic functions like on/off they are OK, but any time I want to use them in a more complicated rule to flash lights, change colours more than once, capture and restore, etc. I need to have a minimum of a four second delay between actions to make s…

There is a Sengled hub available that drives their bulbs, but it only integrates with Alexa, HomeKit, IFTTT, etc... There is no public API so any support for accessing the hub from Hubitat would be a crapshoot.

I find it absurd that every smart home company wants to make a hub and lock users into just their ecosystem. They would get more sales if their systems were openly available. Hue is still a leader in lighting hubs because they have public APIs that allow for local and/or remote integration. They started off tightly integrated to only their ecosystem and has learned the value of 3rd party integration. I gave high hopes for WiFi based solutions, like Govee, that have public API but are limited in features, to hopefully offer local control.

In my opinion, perhaps the best solution you will find for performance, and capabilities, will come from the new LiFX WiFi support in Hubitat, because of its tight integration with Hubitat now, and the HE developer's commitment to make this the preferred lighting solution.

There are issues with WiFi for smart home though. They require a router in addition to the smart hub. A single WiFi AP has a limit to the number of nodes that can be supported, and a single Ethernet network has a limit. Historically, the limit has been right around 128 devices, but thanks to switches, and MIMO WiFi technologies those limits have grown larger -- though the router may not handle all those WiFi bulbs, so that typically means a 2nd WiFi network for lighting.

For all local access, if I were to build my smart home from scratch all over again, I would do what I have already done, with a few tweaks. I would:

• Use a single brand of smart dimmers with Central Scene support (gen 7 Z-Wave only) to replace every single switch/dimmer in the house. For me, that is Inovelli, because they have the best customer service, and the products are priced right for an elite dimmer. And they have SmartBulb control logic, so as to know how to handle lights that should not be load controlled, or should be load controlled, but dimming should come from the controller, not the dimmer.
• Put all smart bulbs in fixtures that need color temp or color controls. I would use LiFX for my smart bulbs, so I only have Hubitat as my smart home controller.
• Setup a private WiFi mesh (802.11ac or WiFi 6) just for the SmartHome (Hubitat, lights, anything WiFi or ethernet based that integrates to the hubitat)
• Use three (3) Hubitat Elevation hubs all participating in Hubitat Mesh.
  • One for built-in device support. The only job of this hub is to speak to devices.
  • One for 3rd party integrated devices that are not Z-Wave nor Zigbee, like Roku TVs, Govee, Orbit B-Hyve, Hue bridge (integrated or 3rd party). The only job of this hub is to manage and speak to 3rd party integrated devices that HE will control. The reasoning behind this is that the Hubitat is a great hub, but 3rd party apps can cause reliability issues with the primary hub. When 3rd party services go offline, the hub can get hung up waiting for timeouts. I just submitted a bug fix for my Kevo Plus smart lock controller, which would take down my hub when the Kevo service becomes unreachable. This could be internet outage, or password change, or a number of things. You don't want to put your smart home's functionality at risk.
  • And finally, one hub to rule them all, the rules engine hub. This is where you connect Alexa, IFTTT, and other assistive systems for controlling devices and rules processing. This hub manages your home security, and hub modes. By putting Alexa, GoogleHome, IFTTT, SharpTools, etc.. here, you can decouple the physical devices from the logical ones used for rules. What this means is that if a device fails, or an integration breaks, and you have to recreate new devices, on the controller node, you will be able to simply link the virtual device of the mesh to the new physical device that we just added to the other hubs. Now, you never have to re-setup Alexa, or IFTT, or any other service when a device failure occurs resulting in replacing the device. This also means that rules are processed with the interruption other device control processes which may be busy working, which could prevent, or slow rule processing. The hub mesh solution if very fast, and efficient.

You can setup with one hub now, and grow it later. And hubitat is totally capable of being used in a single hub environment, which is how I have run things for years. But this recommendation comes from personal experience and lessons learned, and still being learned to this day, that have impacted the acceptance of a smart home by family members. The last thing you want is to struggle to figure out how to turn on / off a smart light in the middle of the night, during an internet outage, when your hub goes offline because of some random bad code in 3rd party apps.