I tried adding ST via the community app but there seems to be a major OAuth token issue that made the app unusable (I’m recalling reading about this a few weeks back), so the ST community app appears abandoned at the moment unless I misunderstood the issue completely.
Which CentraLite devices do you have? You might also be able to migrate some devices to other bridges, like I mentioned
Note that you can add any generic Zigbee light, plug, switch or dimmer to the Hue Bridge. It doesn’t have to be a Hue device
I don’t know, but if I had to guess, then no, that’s not possible.
No, that’s not possible. However, you can add multiple Hue bridges to a system, which means that you can add all generic lights, dimmers, plugs and switches to one or more Hue bridges, and add them to Homey via Hue
According to your AI analysis, the network is full so you’ll have to remove some devices and the easiest devices to move are the switches and lights (because you can move them to the Hue bridge). I’m not sure how this will affect your network, but you’ll have to move some devices. Have you considered the eWeLink, Third Reality and Tuya hubs for the devices I mentioned?
I see that CentraLite device 4 “Salon Veilleuse” is not used by other devices, so I think you can safely move it to the Hue bridge. CentraLite device 5 “Cam SW Salon” also appears to be unused. Same for “Light Strip Cuisine” (the Ledvance device) and “IKEA Strip Bibliotheque” (the eWeLink plug). These are all safe to remove from Homey and add to the Hue bridge.
Actually, no, haven’t considered it because I tought Homey could become “the main home hub” for all my different devices, like I was doing on my Smartthings Hub v2 before I migrated to Homey a few weeks back. I am trying to find which devices I could replace with a similar Zwave or some other tech like Matter of Wifi devices to reduce the “Zigbee load”, I have already my sight on replacing the 3x Zigbee LUMI Leak sensors because I have a Switchbot Hub v3 that has cheap (20$) leak sensors with built in alarms. I tried checking also IKEA last sunday but they were out of stock of many Matter devices, so yeah, even with the best intentions it’s not as easy to manage this on a budget. I already ditched/replaced a few unsupported devices when I migrated from ST to SHS namely some Fortrezz Zwave water leak detectors which don’t seem supported and other Centralite (1st gen) motion detectors.
Do not use those. Matter is such an unstable and unreliable standard. It’s in experimental phase, and there are many issues reported here on the forum regarding Matter devices
Tuya, ThirdReality and eWeLink are more “bridges” that bridge a communication protocol (in this case ZigBee) to Homey. So Homey is still the central controller (and you can run all automation in Flows), the bridges simply bridge a protocol to network/internet
Have you tried moving the devices I mentioned to the Hue Bridge?
I looked up the LEDVANCE LED Strip light and it doesn’t appear on this list here (which seems fairly comprehensive for HUE Hub compatibility) https://iconnecthue.com/supported-devices/
I looked up Tuya bridges, but it looks like a very large “ecosystem” with tons of Tuya compatible bridges made by tons of companies, I’m really not convinced the average Tuya generic Zigbee bridge is any better than the Homey Bridge I already have. Maybe you have a model you recommend ?
As for ThirdReality bridge, I had a bad experience with 4 of their Zigbee Gen 2 smart plug which I couldn’t even make work with Homey bridge for some reason, maybe with their bridge it would work better ? Is it the bridge you recommend from them ? Smart Hub Gen2 Plus – ThirdReality
As for Matter+Thread devices so far I’m just dipping my toe, I had to enable IPV6 on my router, servers and wifi first and I’m using the IKEA Dirigera Hub with them so far, but it’s just a few buttons and sensors, I will try the switches soon too, keeping mind it’s fairly new and probably unstable.
As long as it uses generic ZigBee clusters, which I think would be the case here since other LEDVANCE devices work with Hue as well, it should be compatible with the Hue bridge.
Note that Tuya bridges only work with Tuya devices, so the only one you can connect is the MOES device and other Tuya-based devices. Any Tuya-compatible bridge with ZigBee or “MultiMode” (Bluetooth Mesh and ZigBee) should work with those.
I also have their smart plug and Hub Gen2+, it works great in Homey with my ThirdReality Hub app. Energy values get updated every 10 seconds as well, and power state is almost realtime.
If you have any other ThirdReality devices that aren’t yet supported by my app, you can report it here.
Just saw a new SHS version 13.2.1 that hopefully improves Zigbee stability, I just installed it, will report how it performs over time here compared to 13.2.0
After 24 hours the Gemini AI analysis reports the following issues in the Homey log files:
The analysis of the server log reveals specific issues with the Zigbee network, including device timeouts and controller memory warnings.
Problematic Zigbee Devices:
-
f0:d1:b8:00:00:00:90:ab: This device failed to respond to “get node capabilities” requests. The controller experienced repeated
Timeout (5000ms): 1410 (type: areq)errors, ultimately reporting an inability to ping the device entirely. -
00:12:4b:00:22:42:67:1b: This device experienced timeouts when the system attempted to request its network address. This resulted in a
Timeout (4500ms): 1408 (type: areq)error, indicating a failed network address refresh attempt.
Underlying Network Problems:
-
Controller Memory Leak Warning: The
ZStackControllergenerated aMaxListenersExceededWarning. The log explicitly flags a “Possible EventEmitter memory leak detected” because 11areqlisteners were added, exceeding the configured limit of 10. Controller-level memory issues can severely degrade mesh routing and cause the network to drop requests. -
Device Unreachability and Timeouts: The timeout errors (codes 1410 and 1408) point to devices that have either dropped off the mesh network or are suffering from broken routing paths. When the coordinator repeatedly fails to ping nodes or refresh addresses, the resulting retry operations further congest the network traffic.
Here is the breakdown of the error frequencies and their percentages across your network. There were 142 total recorded occurrences of network address request timeouts.
| Device MAC Address | Error Count | Percentage of Total Errors |
|---|---|---|
00:0d:6f:00:02:f7:97:13 |
~56 | 39.44% |
00:0d:6f:00:03:29:2d:51 |
~31 | 21.83% |
00:0d:6f:00:03:1c:44:de |
~29 | 20.42% |
| Other/Miscellaneous Devices | ~26 | 18.31% |
The vast majority of the network failures are originating from just three devices. However, as noted by the memory leak warnings and the hardware limitations of the CC2530 coordinator, these high error rates are a symptom of the controller’s inability to process the requests, rather than a defect in the end devices themselves.
The 13.2.0 errors with “problematic devices” was way longer before the upgrade if you compare, so it seems 13.2.1 manages the ZigBee network more efficiently, will post again in the next few days to report on stability under 13.2.1, here are the errors under the previous version (for comparison):
Problematic Zigbee Devices (by MAC Address)
The following devices are repeatedly throwing errors, failing to respond to route discoveries, or timing out.
-
00:0d:6f:00:02:f7:97:13(nwkAddr: 28571) - Frequently timing out, throwingZMemError, and marked unreachable during OTA checks. -
00:0d:6f:00:03:1c:44:de(nwkAddr: 23681) - ThrowingZMemErrorand timing out on network address requests. -
00:0d:6f:00:03:1c:3b:66(nwkAddr: 28451) - CausingZMemErroron frame sends and failing to be reached. -
00:0d:6f:00:03:29:2d:51(nwkAddr: 43545) - Continuously failing network address refresh attempts withTimeout (4500ms): 1408. -
00:0d:6f:00:04:05:52:e1(nwkAddr: 63109) - Throwing theInvalid Response (status: ZNwkTableFull)error and timing out. -
00:0d:6f:00:03:28:a5:4e- ThrowingZNPSyncRequestErrorand failing OTA awake checks. -
b4:0e:06:0f:ff:e2:6f:df(nwkAddr: 41851) - Failing OTA awake checks (Could not reach device. Is it powered on?). -
00:12:4b:00:22:42:67:1b(nwkAddr: 49275) - Timing out during network address requests. -
00:0d:6f:00:05:7d:0d:37(nwkAddr: 57307) - Unreachable and failing awake checks. -
00:0d:6f:00:05:5b:6a:ee- Failing awake checks.
Have you already tried moving those devices to your Hue Bridge? The lighting devices and switches at least
The Centralite 4257050-RZHAC switches seem to run ZHA profile instead of the ZLL profile needed by the HUE hub, so they don’t appear compatible. I have only one light on the Homey Hub, all my HUE lights are already on the HUE Hub.
4 days later I can report the Zigbee failed again last night, I rebooted the SHS and it dodn’t help and then the Homey Bridge which resumed operating after that, so 13.2.1 is NOT a fix for Zigbee network reliability, as mentioned by other (and by Gemini AI) the bridge seems completely underpowered/unreliable by its limited chipset.
