Why I left Hubitat – a neutral reflection from a long-time user

💬 Lounge
1

Why I left Hubitat – a neutral reflection from a long-time user

I have been a Hubitat user for several years and genuinely wanted the platform to succeed.

From a technical standpoint, Hubitat has an extremely solid core: local execution, powerful automation capabilities, and a level of control that mass-market systems rarely offer. That strong foundation is exactly why I chose Hubitat and why I stayed with it for so long.

For years, I hoped that this foundation would grow into something truly usable and sustainable for European users. Unfortunately, that expectation was never fulfilled.

Dashboards: a missed opportunity at the HTML level

The Legacy Dashboard, while visually outdated, had one important advantage: it was flexible.

With enough effort, it was possible to build clean and functional dashboards. I personally invested a significant amount of time doing so. However, most of this effort went into compensating for a fundamental issue:

the lack of semantic HTML and meaningful CSS classes.

If dashboard tiles had exposed clear, stable classes (for example something like tile_hvac_fan_section), many common customization needs could have been solved instantly:

  • Power users could have customized dashboards reliably with simple CSS.
  • Beginners could have benefited from a basic property editor to show or hide sections without touching CSS.

From a technical perspective, adding clear semantic classes would likely have required far less effort than developing an entirely new dashboard system, while providing immediate value to a broad range of users.

Instead, the Easy Dashboard was introduced:

  • less flexible
  • based on fixed assumptions about device capabilities
  • and marketed as “modern” despite offering fewer real customization options

For experienced users, this felt like a step away from extensibility rather than progress.

TRVs and the European perspective

For European users, TRVs are a core part of everyday home automation.

Native TRV support never truly arrived on Hubitat. For a long time, I assumed this would be addressed with Matter, especially since TRVs are part of the Matter specification.

Instead, Matter support appeared in the form of specific drivers for a small number of individual Matter thermostats, rather than a generalized, capability-based abstraction that would naturally include TRVs.

This approach felt inconsistent with the goals of Matter and left an important gap for European users.

Matter, Thread, and strategic decisions

Matter was designed to abstract devices by capability, not by brand or model. Implementing it in a device-specific way undermines that goal and increases long-term complexity.

Similarly, releasing the C-8 Pro without an integrated Thread radio—after Thread and Matter were already well established—felt like a strategic misalignment rather than a technical limitation.

Automation: powerful but difficult to maintain

Rule Machine remains one of Hubitat’s strongest components in terms of raw capability. Its power is undeniable. However, its user experience makes long-term maintenance unnecessarily difficult.

In practice, modifying complex rules often felt harder than rebuilding them from scratch. While the user interface has received visual updates, the underlying interaction model remains challenging.

The alternative graphical rule engine, while visually modern, does not scale well for non-trivial automation logic.

Why I moved on

Over time, I realized that I was spending more energy making the platform usable than actually benefiting from its power.

I have now moved to simpler, more lightweight systems such as Apple HomeKit and Philips Hue. Technically, they are far less powerful. However, they provide:

  • consistent device modeling
  • predictable behavior
  • a polished, coherent user interface
  • and a level of usability that makes daily interaction effortless

Ironically, these mass-market systems now cover almost everything I actually need.

This was not an easy decision. I generally prefer to support smaller, enthusiast-driven companies rather than large ecosystems. But usability, clarity, and long-term maintainability matter—especially for systems used every day.

Closing thoughts

Hubitat did not fall short because it lacked potential.

It struggled because several architectural and strategic decisions repeatedly worked against usability, extensibility, and the realities of non-US markets—despite having an excellent technical core.

I still believe the ideas behind Hubitat are strong. I simply reached a point where I needed a system that works with me, not against me.

10 Likes
2

Just curious, but what do you use now for complex automation?

3

Did you use Ai to generate your post?

1 Like
4

Migrating to Homekit and Hue cannot have been that straightforward for you....It appears to have started in late 2024

1 Like
5

I use Philips Hue for all lighting in my house, and Apple HomeKit for everything else. In the end, it really depends on what you consider “complex.”

At first, I assumed that most of my more complex automations would not be possible with HomeKit. That assumption was only partially correct. Today, my automations do almost everything they did before—sometimes slightly less complex, but still more than sufficient for everyday use.

One of the biggest mistakes beginners make is trying to build complex automations using only the Apple Home app. The Home app is designed for simplicity and intentionally exposes only a small fraction of the power of the underlying HomeKit framework.

Using tools like Controller for HomeKit, Apple Shortcuts, and AppleScript, and combining them thoughtfully, makes it possible to create very sophisticated automation logic within HomeKit.

3 Likes
6

I'd say don't take the bait on this thread. I read some of the posters previous threads. They have a certain personality. That they come back and try to roll around in it just seems very self important rather than constructive. Its at least the second time with the same type thread.

Best of luck. Off you go. Focus on your new life in 2026 and forget about Hubitat.

3 Likes
7

Could you give us a tl;dr version of how this is different from your last thread on a seemingly similar topic from a year ago?

4 Likes
8

Yes and no. I’m not a native English speaker, nor do I have an academic background in English. I usually write my texts in German or French and use AI to translate and refine them only into correct English.

This approach helps avoid misunderstandings caused by false friends—for example, “eventually” in English means “in the end”, while in German it often implies “maybe.”
While AI helps with the language, the ideas, opinions, and content are entirely my own.

7 Likes
9

So you will eventually let go of Hubitat?

No censor.

10

That’s correct — the transition started in late 2024, and it wasn’t something I did overnight.
I ran both systems in parallel for quite some time, gradually migrating devices and automations step by step.

A major factor in the timeline was hardware availability and cost. I had to replace most Z-Wave and Zigbee devices with Matter-compatible devices, which required real investment. Toward the end of 2024, many Matter devices were announced but only became available in 2025.

Because of that, financial considerations and device availability had a much bigger impact on the migration speed than technical complexity.

This parallel, long-term setup allowed me to compare both approaches in real-world use, not just theoretically. The decision to fully move to HomeKit and Hue was based on that experience, not on a short-term test.

Edit: I still use Hubitat for smoke detectors and a few relays. Smoke detectors with Matter support do exist now, but they are currently around $100, so I’ll likely migrate those to HomeKit gradually over the coming months or year. Philips does not offer true relays, but there are some Friends of Hue alternatives, which are also relatively expensive. That said, with Matter devices the cost is somewhat easier to justify, as they can be migrated to any Matter-enabled ecosystem in the future.

3 Likes
11

I understand the sentiment, but I’m not trying to provoke anything.
I still own and keep my Hubitat hub, and I genuinely hope that some of this feedback contributes to positive changes over time.

I’ve moved parts of my setup to HomeKit and Hue because it works better for me today, but I haven’t “burned bridges.” If Hubitat were to implement Matter in a more complete, capability-based way, returning would be straightforward without major hardware changes.

My intention isn’t to dwell on the past, but to share a perspective that comes from long-term use and continued interest in where the platform could go.

6 Likes
12

Not necessarily.
I still keep Hubitat and I’m genuinely interested in where the platform goes.
Right now, HomeKit and Hue fit my needs better, but if Hubitat implements Matter in a more complete, capability-based way, coming back would be easy without major hardware changes.

4 Likes
13

The earlier thread was based on short-term evaluation and experimentation.
This post reflects long-term, real-world experience after running different systems in parallel and making concrete migration decisions.

No offense intended — this is simply a more mature and considered assessment, not an experimental one.

9 Likes
14

I agree. The development of the Legacy Dashboard has become stagnant since Easy Dashboards were introduced and I don't like the lack of flexibility of Easy Dashboards. I understand that the lack of flexibility is often hand-in-hand with Easy. For example, my dashboards for home theater and TVs are button devices with 20 plus buttons. The button tile on the Easy Dashboard is worthless for that use.

This stagnation has finally led to increased investment in Home Assistant's dashboards. :frowning_face:

12 Likes
15

I invested a significant amount of time in CSS styling. The core problem was simply that Hubitat did not generate HTML with clear, semantic classes.

As a result, I often had to rely on selectors like div > div div div, and even then it was sometimes impossible to reliably target the correct element. This made customization fragile, hard to maintain, and highly sensitive to internal layout changes.

The solution would have been straightforward for Hubitat and easy to implement: generate HTML with meaningful classes, for example <div class="tile_hvac_fan"> instead of a generic <div>.

Once clear classes exist, customization becomes simple and robust. A single rule like .tile_hvac_fan { display: none; } would immediately solve many real-world use cases, both for power users and for simpler configuration tools.
Here an example of my efforts:

image
image1032×1026 65.5 KB

13 Likes
16

Agree on the dashboards, as per my post from early '24.

5 Likes
17

It’s the long version of the platform is good but the UI lets it down.

9 Likes
18

Not quite. The UI is certainly part of the problem, but it’s not the whole story.

The other major issues are the lack of proper TRV support, the absence of a capability-based Matter implementation, and the missing Thread radio.

If Matter had been implemented according to the standard’s capability model, the lack of classic TRV support would have been much easier to accept. In that case, Matter could have closed the gap naturally.

1 Like
19

That hasn’t been my experience.

A number of my suggestions and requests — some of them supported by other users — were acknowledged but ultimately ignored in terms of actual implementation.

Large global players like Apple or Philips don’t act on individual feedback either, but they do tend to adopt industry standards such as Thread and Matter quickly and efficiently. Apple has stopped developing new HomeKit-specific drivers (not support) and is now fully focused on Matter and Thread, while Philips has aligned its new Pro Bridge entirely around Matter and even offers Hue luminaires with native Matter and Thread support.

That gap between listening, standard adoption, and actual execution is what led to my criticism.

1 Like
20

Note: The Matter standard has significant potential for Hubitat if it is ever implemented in full compliance with the specification. According to the standard, Matter devices can be shared across multiple controllers. This would allow me to keep all Matter devices exactly where they are and simply share them with Hubitat.

In such a setup, Rule Machine could take over parts of the more complex automation logic and make use of variables (which are still missing in HomeKit). Even though my current setup works well without this, such an approach would clearly be a “solution on steroids.”

Variables and virtual devices are currently still missing in HomeKit. While I have found ways to work around these limitations, cheap ESP32-C6 and ESP32-H2 development kits offer interesting, largely code-free alternatives that I plan to experiment with next.

Many current Matter devices are already based on these chips. Espressif provides tooling that allows multiple Matter devices—such as switches or dimmers—to be defined on a single board and communicated over Thread. Devices like these could effectively be used as virtual devices, or even as simple variables, for example dimmer values ranging from 0 to 100.

Edit: Home Assistant (as simple as the Green) can already do this.
An additional advantage is that I retain Apple Home’s own controller-level failover. With multiple Apple controllers (two Apple TVs, two HomePods, one HomePod mini, with more to come), HomeKit itself has built-in redundancy. If one controller fails or is offline, another seamlessly takes over. For simplicity of maintenance I still prefer Hubitat but only once Matter is fully implemented.

3 Likes