Back for another try

Hi everyone,

I was a Homey user some time ago, then moved to Hubitat after leaving Homey. At that time, my Homey (White Sphere) was unfortunately not very reliable for me, whereas Hubitat proved to be extremely stable. However, Hubitat had its own downsides: the dashboard felt outdated, and support for European devices such as TRVs was missing. I stayed with Hubitat for quite a while because the platform itself has real potential, hoping these gaps would eventually be addressed.

When Matter was announced, Hubitat communicated that it would support it. In practice, however, the current implementation relies mainly on vendor-specific drivers, and important device categories (like TRVs) are still missing. This led me to gradually rethink my setup.

Over time, I transitioned step by step toward Philips Hue and Apple Home. Both systems have been very positive experiences overall. Hue, in particular, is impressive: the built-in logic in the bulbs and the way dynamic scenes work is something I haven’t seen matched elsewhere. Its main limitation for me is the lack of proper backup options, but aside from that, it’s an outstanding system.

Apple Home was more challenging at first — not due to device connectivity or stability, but because automations initially felt very limited (“When this, then that”). It took me some time to discover how powerful it can actually be. By converting automations to scripts and using third-party apps to add additional triggers and conditions, it’s possible to build surprisingly complex and very reliable automations.

One major advantage of Apple Home is its controller handling. In my setup, I have two Apple TVs, two HomePods, and one HomePod mini. Apple Home automatically selects the active controller, and if one goes offline, another takes over seamlessly. From a resilience perspective, this works extremely well.

That said, Apple Home is still less powerful than Hubitat or Homey when it comes to advanced logic and complex flows.

A few years have passed since I last used Homey, and I’m hoping the platform has evolved significantly. I’ve learned a lot from past experiences and now want to avoid dependence on a single hub. With that in mind, I’ve decided to give Homey another try and have ordered a Homey Pro (2026).

I’ve also developed a broader strategy around redundancy and interoperability, which I’ll share next. I’d be very happy to hear your thoughts and feedback.

Looking forward to the discussion!

3 Likes

Good morning @Pascal_Nohl - you posted the following on the Hubitat Community this morning, indicating that users of the Homey forum had commented on your planned setup. So I decided to visit this forum to learn from their opinions.

Unfortunately, it appears that my post is just the second (after yours) in this thread, so the comments must be on another thread in the Homey forum that I am unable to find. Could you please post links to these comments so we may all learn from them?

2 Likes

This is a very professional approach!
Too complex for me at this time but I downloaded the picture for future use…
Thanks !

After your comment, someone replied right here. :grinning_face:

That said, I do find it somewhat amusing that a Hubitat Ambassador follows me over from the Hubitat community into another forum to verify whether feedback exists.

Yes, I received feedback. That’s how forums work. People reply, people comment, people react—sometimes publicly, sometimes indirectly. You don’t seriously expect that every reaction or technical discussion automatically turns into a neatly linkable public thread, do you?

And no, I won’t start providing a list of links to every place where Homey or competing platforms are discussed. Anyone who has spent time in multiple smart-home communities knows very well how feedback circulates and why not every discussion is easily discoverable—or publicly traceable.

So rest assured: the feedback exists, it was technically relevant, and it was sufficient for me to validate my thinking, why else should I order a Homey Pro. To be precise, I was initially looking at the Homey Pro Mini and was advised not to buy the Mini due to its 1 GB memory limitation, which could become a show-stopper for the kind of setup I’m describing. Ah.. I asked the question before creating the final draft, weird ? That’s all there is to it.

Thank you, I appreciate that.

You’re welcome. If you come back to it later, I may have tested this setup under real-world conditions by then and would be happy to share feedback or help you with the setup.

Clarification: Homey Pro failback concept

The Homey Pro failback is only outlined at a very high level in the draft and is apparently not very clear, so here is a more precise explanation.

The idea is to use one Matter switch (SW1)—or for a more robust failback, a second Matter switch (SW2)—on the Apple Thread network. This network is considered fail-safe, as it is supported by multiple cooperating border routers (in my case, five).

For core automations, a basic automation is created in Apple Home (which is more limited in logic capabilities). This automation includes a condition such as:
If SW1 is OFF (or SW2 is OFF), then …

On Homey, a more advanced flow is created, using its more powerful automation engine. This flow includes the complementary condition:
If SW1 is ON (or SW2 is ON), then …

If Homey fails or becomes unavailable, simply changing the state of one switch immediately activates the Apple Home automations. This allows the system to continue operating—possibly in a degraded mode, but still functional—without requiring a backup restore or manual reconfiguration.

The second switch may be overkill, but it adds resilience: if one switch fails or becomes unavailable, the failback mechanism still works (OR condition).

I did not find a reliable way to switch (fail over) automatically between Homey and Apple Home. That would, of course, be the nec plus ultra, but at least this approach allows for a controlled and predictable manual failback.

Edit:
A suggested solution that I got on another forum is to use two shared Matter outlets. Apple Home acts as the watchdog by periodically switching Outlet A ON (e.g. every 60 minutes). Homey has a simple flow triggered by this event and responds by switching Outlet A back OFF. Apple Home checks the state after a defined delay (e.g. 10 minutes). If the outlet is OFF, Homey is considered operational. If it remains ON for multiple consecutive checks, Apple Home assumes Homey is unavailable and activates the fallback by toggling SW1 (and SW2).

Outlet B can optionally be used as a secondary confirmation or future extension, but the core failback logic already works with Outlet A alone.

The Homey Pro arrived !!!
Here are my first considerations—some might be final, others not. I knew the 2026 model would still lack an Ethernet port (who came up with this poor design?), but I didn’t order the expensive official brick. A cheap 8€ one from Amazon does the job just fine. I guess Homey could buy them for 3€ in China, so why not just add it to the package? The puck itself feels high quality and has a pleasant design, though.

The onboarding process was very nice and I felt well-guided. However, soon after, many of my devices showed up as “unreachable” in Apple Home. My immediate suspect was the Homey Thread radio (Interferences). I thought “no problem, I don’t need it,” and tried to turn it off. No luck—there is simply no way to do this. After some research, it seems the Thread radio is bound to the Zigbee radio.

I figured switching channels might solve it, but again, no way to change the channel in the standard settings. I had to use the Developer Tools URL. Even there, you can’t manually select a channel; there’s just a “Reset” button. Click and hope. I had to click it 6 times before it finally jumped from channel 25 to 15. It’s basically a guessing game.

Eventually, the Thread network self-healed while I was out walking the dog, and all devices returned to Apple Home. Still, I really miss a simple toggle to turn Thread or Z-Wave off. Why pollute my house with waves I don’t need?

On the positive side: I connected my Zigbee smoke detectors and exposed them via Matter to Apple Home—that worked perfectly. Adding Matter devices from Apple Home to Homey was also very straightforward and a great example of multi-admin working as it should: I just went to the settings of a device already paired to Apple Home, pushed “Turn on Pairing Mode,” copied the code, and pasted it into Homey. Easy.

But here is the dealbreaker: The Flows. I created some simple Advanced Flows (e.g., button press = light on/off). They worked fine at first, but three hours later, when I wanted to show my wife, nothing happened. The devices were definitely connected (the “Identify” light blinked), and I could control the lights manually in the app, but the flows just wouldn’t trigger. Interestingly, Apple Home reported every button push correctly.

This morning, the flows are working like a charm again. This reminds me of my bad experience four years ago when flows ran more randomly than stable. I’ll check this over the next few days. If they don’t run 100% reliably, the Homey goes back to the sender. It would be a shame because my schema from above works well, but it has to be stable.

Hello everyone,

I’ve been running some tests with Homey for a few days now. I still have about 7 days left in the return window, so things are starting to get a bit tight.

I connected a handful of Zigbee devices and a few Shelly Gen 1 devices over Wi-Fi directly to Homey and then shared them with Apple Home via the Matter bridge. In parallel, I shared almost all of my Matter devices that are paired with Apple Home (with two exceptions) with Homey using Matter multi-admin. Overall, this worked very well and was surprisingly easy to set up.

The two exceptions are probably not Homey’s fault:

  • The first one is a Matter over Wi-Fi device. For multi-admin sharing it apparently needs to be within Homey’s direct Wi-Fi range, but it’s installed further away and embedded in a wall. I decided to leave that one for now.

  • The second one is a Matter-over-Thread relay from SwitchBot. Like their other relays, it’s poorly implemented: it’s not a native Matter device but a device with a built-in Matter bridge. I’ve learned my lesson there — I don’t want to end up with dozens of bridges. That’s not the direction I want to go.

I migrated all my automations from Apple Home to Advanced Flows. Doing that made me realize how complex my Apple Home automations have become over time, simply because Advanced Flows make everything much more visible. Unfortunately, I also realized that beyond the nice visual representation, Advanced Flows don’t add a huge functional advantage for my use case.

I asked myself what I would want to do in the future and how I would implement it in Homey — and then whether the same thing would be possible in Apple Home. In most cases, the functional difference turned out to be rather small. For me, the Homey Pro feels quite expensive mainly for a nicer interface.

So far, I’ve seen a lot of positive things and many aspects I really like. The price would be acceptable for me — but today I had a blackout moment: about half of my devices were suddenly unreachable in Homey, while all of them were still available and controllable in Apple Home. After restarting Homey, all but four devices came back. After a second restart, everything was reachable again. Unfortunately, one heating control flow didn’t run because the end devices were reported as unavailable.

I’ll monitor this very closely over the next few days. I need a home automation system that is reliable above all else. If Homey turns out to be less stable than Apple Home or Hubitat, I will most likely return it before the return period ends — especially since, in my setup, Homey is more of a “nice extra” than a core component.

As a pure Zigbee-to-Matter bridge, Homey is simply too expensive for me. For the same amount of money, I could buy 8–12 Matter-over-Thread devices and replace most of my remaining Zigbee devices entirely.

That’s not how it works, both Homey and the device need to be connected to the same network. Homey will not correct directly over wifi to the device.

1 Like

Thank you for the information. I wrote “apparently” because I found that statement on an internet forum, which said that for Thread there is no issue if the shared device is not physically close to Homey, but for Matter-over-Wi-Fi commissioning the device needs to be within Homey’s direct Wi-Fi reach. :wink:

That said, all my other devices of the exactly same type and manufacturer are successfully shared with Homey and are located on the same floor. The one device that does not work is on another floor. It works perfectly in Apple Home, and Apple’s Border Routers, Homey, and the device are all on the same subnet. The device is also in the same Matter Fabric ass the others.

So from a network perspective, everything looks correct, which is why I found the behavior a bit confusing.

Next days test – review

After a few more days of testing, I still don’t clearly see what Advanced Flows enable that cannot also be achieved in Apple Home, with two notable exceptions that could arguably belong to other categories as well: variables and virtual devices.

In my use case, variables are mainly used for heating setpoints. Compared to Apple Home—where the same value often has to be changed in multiple automations—Homey allows me to simply change a single variable, which is definitely a practical advantage.

I also missed virtual devices in Apple Home. I wanted to use them as a substitute for variables (for example, a virtual dimmer representing a value from 0–100). In that sense, variables and virtual devices are almost interchangeable for my Apple Home use case.

On the other hand, logging is just as complicated in Homey as it is in Apple Home. By contrast, Hubitat offers built-in logging that can be configured to be very powerful and is much easier to work with.

At first glance, Advanced Flows are very appealing. However, the deeper you go, the more you start asking yourself whether they are truly better—or even more readable—than Hubitat’s Rule Machine. My conclusion so far is that Rule Machine is both more powerful and more readable for large and complex automations, while Advanced Flows are better suited and more readable for simple to medium-complex automations.

Another observation is that Matter features are better exposed in Homey than in Apple Home. Many of my devices shared via Multi-Admin expose additional features such as offsets, which can even be modified in Homey but are simply not shown in Apple Home. This led me to realize that some features I don’t see in Apple Home are actually exposed by the device itself, but are just not handled or displayed by Apple Home. I was even able to update the firmware of one device via Homey, something that does not work in Apple Home.

Since my last report, Homey appears to be running stable. If this stability continues, Homey represents an expensive but real added value to my system—and at this point, I do believe it is a plus-value.

I now get this logging :wink:

1 Like

Hi all,

After the disaster with my Thread network caused by an IKEA button (see here: Ikea Matter Dual Button joined to bulb - Potential Risk), I had to completely rebuild my Thread setup by deleting and re-pairing all my Matter devices. I noticed that Homey offers a “Repair” function even for Matter devices — something Apple Home doesn’t provide. I’m not sure how effective it really is, but it’s interesting that it exists at all.

I decided to use this as an opportunity to properly test Homey and paired almost all my devices directly to it. Of course, this broke most of my existing flows, since all device references were gone, so I had to rebuild them manually.

I did run into some range issues in the basement, since my Apple TV there unfortunately doesn’t act as a Thread border router for Homey. Placing two Eve Energy plugs in strategic locations immediately restored good Thread coverage in that area.

I also encountered a few flows that didn’t work as expected at first, but in those cases the problem was on my side — I had selected the wrong flow cards when rebuilding things, and in one case I even missed a connection between cards.

So far everything has been running smoothly. I lost my Apple Home backup (which can apparently become corrupted as well), but now I have everything centralized in Homey: most devices via Matter, plus a few remaining Zigbee and Wi-Fi ones. Even my air cleaner in the bedroom is now controllable through a dedicated Homey app.

Today is the last day I could return Homey. After two weeks of testing, it has been stable, and even the Homey Thread network itself seems solid. So I’ve decided to keep the Homey Pro instead of sending it back.

Hopefully this confidence won’t be disappointed in the future.

1 Like

Murphy’s law, I guess. Just after the return window expired, Homey lost a large part of its Thread-controlled devices. A simple Homey restart immediately brought the entire Thread network back and all devices were reachable again.

At first I thought: OK, once can happen. But the same thing happened again last night. Again, a restart fixed everything instantly.

For me, this clearly shows that Homey is still not a fully reliable system — at least not in its current state. Spending around 400 € on the hub, plus the energy dongle, currently feels like a questionable investment. This reminds me a bit too much of my earlier experiences with Homey several years ago. I really hope this gets fixed soon.

What makes this more frustrating is that, aside from one major incident caused by a problematic IKEA device, my Apple Home setup has been running for over a year without losing contact to a single device.

So what’s the short-term workaround?
Restart Homey every night at 3:00?
When are updates actually pushed to Homey — is there a fixed maintenance window, or could a restart interrupt an update?
If updates are not automatic, how can I clearly see when updates are available and trigger them manually?

Quite a few questions at the moment.

In the mobile app goto More > Settings > Updates.

There you can choose to opt in for automatic updates of your Homey firmware or opt out. You can also manually update your Homey from that screen.

Further, if you want to receive experimental (beta) updates, you need to enable the respective toggle in the Settings section in the Homy Developer Tools:

1 Like

I really love Homey, and I recently published my Fronius GEN24 Local app. I’m also working on a second app and hope it will be certified, even though it sometimes feels like similar functionality is judged very strictly (despite my app having some unique features).

That said, I’m running into a serious reliability issue: parts of my Thread network become unavailable after some time—sometimes after 2–3 days, sometimes in less than a day. Until recently, a reboot fixed it, but that’s obviously not a system I can trust long-term.

I’ve read that this can happen when Thread and Zigbee devices are mixed, since Homey uses a single multi-protocol radio. So I decided to remove all remaining Zigbee devices (five left over from my previous setup) and replace them with Matter over Thread devices.

Important detail: I removed the Zigbee devices by deleting them, but I did not reset the network.

A few hours later, almost all my Matter over Thread devices became unreachable. Rebooting didn’t help. During reboot I also noticed 8 red LED pulses after the white spinning ring, before the rainbow animation started.

I then did a factory reset and restored from a backup. Everything came back fine. After that, I removed the Zigbee devices again.

But today, a large number of devices became unavailable again.

So… what do I need to do to get this stable?

At this point I’m running only:

  • Matter over Thread devices

  • Matter over Wi-Fi devices

  • one Shelly device

Installed apps:
Chronograph, Data Vista, Enhanced Device Widget, Flow Checker, Google Sheets, Open Weather, Philips Air, Philips Hue, Shelly, Sun Events, Text Transformation, VeSync, Virtual Devices, WidgetBoard.

None of these looks suspicious to me, but maybe I’m missing something.

If these disconnections continue, I’ll unfortunately have to consider returning the Homey to Amazon as “not working as advertised.” That would be a real shame, because in terms of features it’s probably the best system I’ve ever used — it’s just not reliable enough right now.

I suppose you are stil using Apple Homekit in parallel with the Homey Pro. Running two Thread networks is troublesome. Not a Homey thing, the whole Matter over thread thing still has some quirks. I am running a Thread network on Homey Pro only (not using Apple Homekit anymore) and Homey’s Thread network has been very stable for me for some time.

I don’t fully agree. I’ve run two Thread networks in parallel for a long time (not Homey-based) without issues. In professional/industrial setups, multiple Thread networks in parallel is also quite common. Thread has not been developed for smart homes but for IoT in industrial spaces.

That said: in my current setup I’m not running two Thread networks anyway. I only have four Matter shutters (relays built into wall switches) that are onboarded to Apple Home over Wi-Fi because they are physically installed as switches. I have no Thread devices in Apple Home at all. All Thread/Matter-over-Thread is on Homey.

Homey behaves strangely in other areas too. For example, I tested a Matter-over-Wi-Fi device far away from an Apple border router but close to a Wi-Fi access point and paired it to Apple Home — worked perfectly.
Then I tried to add the same device to Homey via Multi-Admin — not possible.
So I removed it from Apple Home and tried pairing it directly to Homey. Bluetooth commissioning worked, but the step where the device should connect to the hub failed repeatedly. Only after bringing the device physically close to Homey did it finally succeed.

That’s not how Matter over Wi-Fi is supposed to behave. Wi-Fi reachability should be the deciding factor, not physical distance to the hub after Bluetooth pairing.

It is clearly a Homey thing.

In industrial setups, you should never use Matter and Thread as they are unstable, new/experimental and definitely not ready for those types of setups. I would still recommend wired and more traditional installs in industrial setups.

I don’t agree with the claim that “in industrial setups you should never use Matter and Thread because they are unstable.”

1) My real-world experience: Matter over Thread can be very stable
In my own setup, Matter over Thread under Apple Home has been rock solid. I ran it for over a year without a single Thread device going “not available.” That doesn’t prove it’s perfect everywhere, but it clearly shows the technology can be stable.

2) Thread is used in professional IoT — often independent of Matter
Also, in industrial/professional IoT, Thread can be used without Matter. They’re related but not the same thing:

  • Thread is a low-power IPv6 mesh network.

  • Matter is an application layer that can run over Thread or Wi-Fi.

So saying “Thread/Matter is unstable” as a blanket statement doesn’t match how these technologies are used in practice.

3) The behavior I see doesn’t look like “normal mesh limits”
Yes, any mesh can struggle with distance, lack of routers, or bad placement — that’s true for Zigbee, Thread, Wi-Fi, everything. But that’s not what I’m seeing.

I don’t have occasional weak-signal dropouts. I get devices becoming unavailable in rooms that have multiple routing devices nearby, while other devices in the same room remain fine. That pattern feels more like a radio/stack issue than a simple range/coverage issue.

4) Matter over Wi-Fi is flawless for me — so Matter itself isn’t the problem
All my Matter over Wi-Fi devices are completely stable and never become unavailable. So from my perspective, Matter is not the unstable part here. The instability correlates strongly with Thread on Homey.

5) What I suspect is happening
I don’t know Homey’s implementation details, but based on symptoms, two categories seem plausible:

  • Radio / firmware stability issue (Thread radio gets into a bad state, loses performance, or fails to recover properly)

  • Software/stack issue during network changes (channel changes, router role changes, topology/routing updates) where the recovery doesn’t complete cleanly

I’m happy to run diagnostics or provide logs if there’s a known way to debug Thread health on Homey — but I don’t think it’s fair to conclude “Thread/Matter is unstable” in general when other ecosystems run it reliably.

I’ve never seen Matter or Thread used in any industrial environment, and that’s for a good reason. Matter and Thread are both very unstable in my own (home) environment (most of the time not even working at all). That’s likely related to my firewall rules, which prohibit not only based on the network (IoT) but also block specific networking features for specific client groups.

In corporate and industrial environments, network segmentation is also very common. It’s common to see that clients are completely isolated from each other, which would fully block any local communication or broadcasts. This is why other protocols that don’t require specific network features (IPv6, broadcasts, etc.) like ZigBee, Z-Wave, simple LAN/HTTP communication and cloud communication are used more often in these scenarios.