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

That’s fair as a personal impression, but without explaining why you feel that way, it’s hard to discuss or learn anything from it.

If you’re willing to share where Matter fell short for you (stability, device availability, features, tooling, performance, etc.) and in which scenarios Zigbee or Z-Wave worked better, that would add real value to the discussion.

Different setups and expectations lead to very different experiences.

That’s not entirely true — it very much depends on how the network is designed.

In my setup, all modern non–smart-home devices use 5 GHz (or 6 GHz), while I run a dedicated 2.4 GHz SSID exclusively for smart-home devices. My Thread Border Routers (Apple TV, HomePod) are associated with the same network don’t rely on fixed IP addresses. My Matter-over-Wi-Fi devices, on the other hand, use DHCP reservations.

When I replaced my router a few months ago, I recreated the same SSID and credentials. All devices reconnected automatically — including Matter-over-Wi-Fi devices. Apple Home continued to work even though the IP addresses initially changed with the new router’s DHCP pool. Afterwards, I simply re-applied my IP reservations.

Some router brands make this even easier by allowing you to export and restore the full configuration, but that’s vendor-specific.

Because Thread Border Routers are bound to the SSID rather than fixed IPs, the Thread fabric re-established itself immediately once connectivity was restored.

So while network changes can cause issues in poorly segmented setups, with a clear SSID and IP strategy they’re usually manageable — at least in my experience.

Thread was designed to be fast, resilient, and largely immune to these kinds of network changes, as it operates independently of IP addressing and relies on a self-healing mesh.

Reliability, a complete lack of.

All of them. Except my Zen Zigbee thermostats, they are the only 2 of my 100+ zwave and Zigbee devices that are less than reliable.

I disgree. See the bolded sections. Nothing in your comments speaks to the average user for setting DHCP reservations. Even in the original comment, he rightly noted that there are a not insignificant number of users who fail to set DHCP reservations for a single hubitat device, even though it is explicitly stated in the documentation to do so.

Documentation - Reserved addresses

An average user expects things to magically work because it's electronic and that's how they think it should work (or because it has electrolytes - which home automation systems crave - obscure movie reference IYKYK). They do not mess with making SSIDs identical. They do not make sure specific items have DHCP reservations. In my case, the router I have requires you to connect a device, and then change the reserved IP on an individual basis (not my preference, but I am willing to deal with it for the other features of the router). Because of this, I avoid changing things. Not because I don't have the technical know how - because I just don't want the hassle. Personally, not going to add more complexity to that by adding a bunch of devices that are currently less reliable, carry fewer features than their Z Wave/Zigbee counterparts, and would also add more to any maintenance I might have to do.

I think matter has some great potential. But, I also don't believe it is there yet and I am not really in favor of having a thread radio until it is. I would rather wait until it is a bit more mature so any hardware would be the latest and greatest at that time.

Let me know when you move to a packed place like NYC where the 2.4 GHz band is basically a public dumpster fire and then tell me, with a straight face how Thread is “immune” and “self-healing.”


Thanks for clarifying. I personally haven’t experienced reliability issues with Matter itself.

From my experience, reliability problems often depend less on Matter as a standard and more on how well a hub implements it. In my case, Hubitat’s Matter implementation has not been reliable, which is a factual observation based on real use, not speculation.

It can also depend on the transport and mesh topology (Wi-Fi vs Thread). A single Thread device placed far from a border router may behave unreliably — but that’s equally true for Zigbee or Z-Wave in comparable conditions.

It would be helpful to know whether the reliability issues you saw were tied to the Matter devices themselves, the hub used, or the network layout.

I agree — and that’s exactly my point. In my example, everything worked again simply by configuring the new router with the same SSID and password as the old one. Re-applying DHCP reservations afterward was something I did out of habit and preference, not because it was required for things to function.

For an average user, recreating an SSID and password is usually sufficient. And if that feels uncomfortable, it’s something most ISPs will happily do during installation or support.

More advanced steps like DHCP reservations are optional optimizations. Anyone working with platforms like Hubitat — and with technologies such as Matter, Zigbee, or Z-Wave — will sooner or later either learn these basics or look up how to do them. They’re not strictly necessary to get things running, but they can help with structure and predictability.

Edit:
I haven’t tested this myself, but in theory all Thread Border Routers (Apple TV, HomePod) connected to a new SSID (over DHCP) should rediscover each other and re-establish the Thread fabric automatically. Since Thread operates independently of IP addressing, the fabric itself should survive such a change. That’s the architectural promise behind Thread — though I can’t confirm it from real-world testing.

Fair point — and you’re right to challenge the wording. Immune was too strong.

Thread does not rely on Wi-Fi and forms its own mesh network based on IEEE 802.15.4. It doesn’t need an SSID, DHCP, or a router to function.
However, it does operate in the 2.4 GHz band, which means it still shares spectrum with Wi-Fi (2.4 GHz), Bluetooth, Zigbee, and other sources of interference.

Thread isn’t immune to RF congestion — especially in very dense environments like NYC. What it’s designed to be is more resilient: it can adapt via channel changes, route around poor links, and recover automatically when conditions change. That helps it cope better, but it doesn’t eliminate interference.

In heavily saturated 2.4 GHz environments, no low-power mesh will be perfect. The difference is how gracefully the network degrades and recovers, not whether the problem exists.

So yes — interference still matters. Thread just aims to handle it with less manual intervention than older stacks.

I want to clarify one thing, because some comments seem to interpret my original thread as an attack on Zigbee, Z-Wave, or even as an attempt to convince people to leave Hubitat in favor of my setup. That was never my intention.

I don’t believe it’s possible — or even desirable — to convince users who are satisfied with Hubitat to move away. And there clearly are satisfied users. From the discussions that followed, it became apparent that most contributors who strongly resonated with the initial post were either users who had already left Hubitat and occasionally return to see whether it has evolved in a direction that fits their needs, or users who have mentally moved on but are still evaluating alternatives.

My goal was simply to present one possible solution among many — a setup that works well for me in daily practice — and to help others understand how some of the perceived limitations of the Apple Home app can be addressed, given that the underlying Apple Home framework is more capable than it often appears.

Likewise, I’m not claiming that Matter or Thread are universally “better.” They are relatively new technologies that work very well in my environment, and clearly also for many others. But whether a setup is reliable or not depends on many variables: device quality and implementation, RF conditions, network saturation, hub behavior, and overall architecture. These factors influence stability and reliability across all standards, not just Matter, Zigbee, or Z-Wave.

Because of that, broad claims of “better” or “worse” rarely hold universally. Context matters — and that’s all I was trying to share.

Respectfully, I would appreciate it if you would not take my comments out of context in the future. What I actually said was...

As I mentioned, a properly planned home network upgrade can avoid these types of issues. However, the average home user has no idea of the ramifications of simply changing the WiFi SSID and/or password. Thus, they opt for a fresh new SSID out of desire for change or the thought of improved security. Next thing they know, their WiFi devices are messed up. And, if they end up on a new TCP/IP subnet for their LAN/WiFi network as well, they may have devices with true static IP assignments that will need to be factory reset to just to get them back on the network. This is no different than today, I realize. My point was simply to point out that adding more WiFi-based devices will exacerbate this issue which is very common today, and may cause people to form a negative opinion of Matter devices as a result. It is not a problem with the Matter protocol, but since Matter depends on Ethernet/WiFi, it inherits these problems. Z-Wave and Zigbee have their own sets of issues, but since they are not inherently reliant on WiFi/Ethernet, this is one area where they shine.

Can all of that grief be avoided with proper planning? Yes, as I stated originally. :slight_smile:

P.S. The people that frequent home automation forums every day are not the 'average home users' I am referring to. :wink: They do not understand the inner workings of home network hardware and associated devices. They often incorrectly refer to an ISP outage as "The WiFi is down!" I am not trying to throw shade on anyone, just pointing out that it is a very small percentage of people that truly understand home networking. Thus, truly proper planning usually does not happen when they decide to change ISPs or upgrade their home router after a trip to the local Best Buy.

I agree completely with the above. Unfortunately, most users have no desire to research and learn what it takes to properly plan a network upgrade.

On several occasions, even those who frequent this forum have requested help to access their Hubitat hubs after changing their network topology or equipment. Including some who indicate they are experienced as network admins .....

And my point is that the average user doesn't even know to do that. From playing tech support for family and friends, I can tell you most (average) people turn on a new router and expect it to just work, then get upset when they have to go open a manual (or call someone) to "fix" it.

I never took it as such. Just providing my own feedback as to why matter isn't right for me.

One thing I have seen and learned quickly: "universal" systems that are supposed to make things easier for the "average" user often give up something (usually features and control) because they have to make things "just work" like plug and play.

I will compare this to the roll out of Win98. Matter is on the precipice of something of similar magnitude. Large promises of capabilities that don't always work as smoothly as advertised or intended. The need to control most aspects at the hardware level limit the users capability for control. The same reasons you cannot do as many custom things on an Iphone as you can on an android. (Not saying either are better - Both have their strengths and either can be appropriate to different user groups)

My preference is for the more technical with more ability to customize. Others may not be able to, or even just prefer not to. That doesn't make either option better or worse. They are different and usually one is more right for a specific person than another.

Why is this thread continuing? You stated in the thread title "Why I left". If you are gone, then be gone. Continuing to pick at this suggests you aren't that happy where you went to....

Nope, this was not Hubitat’s fault. The devices (a stack of nano leaf matter bulbs) would stop responding in Apple home, so nothing to do with Hubitat.

And this was despite having 2 HomePod mini’s and an Apple TV, plus an extensive SME grade mesh Wifi system.

Ps, I’m done, and this topic seems past its used by date.

If it is a standard then all implementations are the same. If a company can implement it differently, then is not a standard. :wink: So, which one you think is true?

About standards, they are crucial. But often aren't followed properly (which doesn't mean they don't exist--kinda like speed limits).

I was an email administrator and supported Lotus Notes. There were definitely RFC standards for everything, including calendar invitations.

The big player in the market, Microsoft Exchange/Outlook violated several standards regularly. And that caused numerous problems which required explicit workarounds from Lotus Notes. Standards compliance is a problem widely in technology.

While published standards are extremely valuable, they work best when everyone abides by them. Unfortunately, that's often not the case and, from the end user point of view, it's hard to tell who is wrong (Lotus Notes always got blamed, when 90% of the issues were Microsoft's fault).

Thing is, everything tends to work wonderfully within one vendor's realm. It's when you mix vendors that things fall apart.

I suspect it's similar with many home automation devices. Some do a great job, others don't.

And, sometimes, the only practical solution is to work around the standard-violating implementation from the other side.

I'm pretty sure the HE folks have their hands full working around problems caused by other vendors violating standards. I appreciate their efforts!! :heart:

There is a difference between implementing Matter and implementing Matter and getting a certification.

I’m sorry, but I don’t quite follow your point.

Matter is a well-defined and strict standard. The fact that different platforms achieve different results doesn’t invalidate the standard itself — it highlights differences in implementation quality and programmers capacity.

In practice, on platforms with a mature Matter implementation (Apple Home being one example), the experience is genuinely plug-and-play: scan the QR code, assign a name and a room, and the device works immediately — no driver selection, no capability mapping, no manual initialization - that's what the Matter standard is made for.

Suggesting that Matter isn’t a proper standard because one platform struggles to implement it seems backwards to me. I’m really trying to stay polite here, but I think it’s important to separate the quality of the standard from the quality of Hubitats given implementation.

Critiquing Matter itself for shortcomings that stem from how Hubitat integrates it doesn’t feel fair to the standard — or helpful to the discussion.

The kind of users who expect a new router to “just work” are typically not the same users who build or maintain complex home automation systems, especially platforms like Hubitat Elevation. In most cases, they either have no real smart home at all (aside from a few app-controlled bulbs), or they rely on systems installed and maintained by an electrician or integrator.

Once someone chooses a platform like Hubitat, they’ve already accepted a certain level of technical involvement — whether that’s learning about devices, networks, automations, or troubleshooting. At that point, recreating an SSID or understanding basic network behavior isn’t an unreasonable expectation.

So I don’t see this as an “average user” problem as much as a question of matching the platform to the user’s expectations and willingness to manage complexity.