The only issues I've seen with the c4's is not being able to write to the internal storage (that kind of memory has finite writes)
So, Matter or Z-Wave Long Range? 
TL;DR: C-8/C-8 Pro can't be expected to operate reliably with pre- Zigbee 3.0 devices unless stack is configured to always accept ZHA well known link key on Trust Center rejoins. The spec doesn't permit this behavior for certfied devices but the typical legacy Iris V2-era (non Zigbee 3.0) devices rely on it.
The Zigbee 3.0 security model is not fully compatible with pre -Zigbee 3.0 device rejoin behavior; random drop-offs can be expected with such devices 'working as designed' when non-Zigbee 3.0 devices attempt to rejoin and obtain current network key by using HA 1.2's well known link key. Complaints about drop-off behavior with post-C-7 hubs are common in forums are rooted in differences between legacy device's rejoin behavior and the Zigbee 3.0 security model.
I'd like an option for C-8 or C-8 Pro hubs to ship configured with 'Zigbee Home Security' model (per SiLabs is an option) instead of using the Zigbee 3.0 Security model. Granted, CSA won't certify devices using "ZHA style security" but who cares.. HE hubs aren't certified anyway.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Since buying my C-8 a in March 2023 I've never put it to productive use, aside from running a handful of devices to experiment now and then. Why? lack of confidence it would operate reliably as my old hub with my existing mix of legacy Zigbee Pro ZHA and Zigbee 3.0 devices.
The reason: C-8/C-8 Pro use the Zigbee 3.0 security model and will only use the HA well known Link key briefly, on initial device joins (but not during Trust Center rejoins) to transport the network key... Zigbee 3.0 brought security enhancements; changes in how the key exchange and updates get handled... and related issues merging legacy Zigbee with 3.0 Zigbee devices.
True that CSA will no longer certify devices using "ZHA style security" but who cares.. HE hubs aren't certified Zigbee 3.0 anyway. But they ARE (evidently) expected to operate with legacy devices as reliably as Zigbee 3.0 devices (as evidenced by the inclusion of Iris V2 sensors on HE's compatibility list). For many, this has not been the case with random device drop-offs never being completely eliminated. Many resort to putting 'problematic' legacy devices on older hubs.
At the core of the issue (for devices that do not support install codes) is use of the 'well known' default ZHA link key used to encrypt the initial network key exchange when a device joins the network. Pre 3.0 devices can't handle updates to the Trust Center Link key; this has implications for subsequent rejoins (and results in drop-offs if the rejoin fails). Zigbee devices are expected to tolerate disconnects and rejoins or the experience will be flaky.
This SiLab's article explains some of the issues:
Zigbee 3.0 Device Interoperability with Legacy ZigBee Devices
In a nutshel (from the linkded article, emphasis added; italics are my additions):
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Care must be taken when implementing the default link key within Zigbee 3.0 networks. Some options include:
Using the default link key as the primary link key within the network. This solves any HA interoperability issues, but with the concerns of wide open security. This is during transport of the network key
Using the default link key as a transient link key (a link key with a timeout after which it will no longer work). This allows HA devices to join a network for a small window, minimizing security vulnerabilities, but it can cause problem if a legacy device associated using the default link key detaches from the network, it won't be able to rejoin using an unsecured rejoin. Ths is the oft-reported 'joins but then quickly drops off the mesh' scenario
The article continues summarizing the actual problem: prior toZigee 3.0 not all devices were capable of updating their link keys:
There is also the question of legacy devices if they can update their link key.
Ultimately interoperability does raise issues with the security that must be explored and carefully considered before deciding on the path to take within a Zigbee 3.0 application.
7 Likes
I just have a C7 for old devices, 8 don't think HE should be held back with old technologies. Zigbee 3.0 has been around for years so I don't think they should support less secure devices on new hubs.
The iris old original devices are also not supported on the C8 only up to the C7 BTW
My C8 only has good zigbee 3.0 devices on which is my biggest network. Then my old LL and HA 1.2 devices work perfectly on my C7 no issues and with HE it makes it easy to do that.
Old devices working better on old hubs and new devices work better on new hubs. Why would you want to break that.
The issue is that the new C-8 hubs do not pair and stay connected with some new Zigbee 3.0 devices.
The same devices work without any problems with all other popular Zigbee hubs.
3 Likes
Are they zigbee 3.0 devices that are not fully "zigbee 3.0"?
I'm fully on board with the devices should be fixed not constant work around and bodges in the hub.
Obviously if there is a issue with the hub that intern needs to be fixed.
We have done a lot of work to implement 3.0 correctly and securely on our products with no exceptions. It's security first and for most when you have to sell commercially and domestically all over the world.
1 Like
I don't know. The fact is that SmartThings, Homey, HomeAssistant (both ZHA and Z2M), etc... do not have problems with these.
2 Likes
All of those are purely domestic right? Where are hubitat has a commercial arm? That could be the reason.
And as you said ZHA. Not 3.0.
By 'ZHA' I mean the HomeAssistant built-in / native Zigbee interface. Zigbee2MQTT is an alternative add-on.
The problem is definitely in the Silicon Labs EFR32 chipset libraries/stack used in the HE C-8 hubs.
ZHA, Z2M, Sonoff had the same connectivity issues with this chip, but they were patched long time ago.
4 Likes
I know that Mike is working on the issue with SiLabs but you know SiLabs, they're slow AF regardless of how many complaints come in.
3 Likes
How would providing options to the customer as @Tony described hold HE back?
Break what, concretely ?
2 Likes
I don'tdisagree with you, however I think the positioning of the 3.0 hubs should be made clear. They will not reconnect reliably with legacy devices for reasons that were documented years ao and should be well understood by HE's developers-- if not at the time of the C-8 release then certainly when 'device connecting then dropping from the mesh' issues began to manifest themselves. This is exactly what the application notes predict will happen when a legacy device fails to update its link key (or disconnects for other reasons from the mesh) and tries to reconnect with no success.
It didn't help matters that migration
obscured the problem by transferring the existing platform's security keys, delaying onset of the reconnect issues until I reconnection was actually required...
Again, these are not teething issues related to new technology because the technology isn't new, as you pointed out; when it comes to its application as a product suited for use with previouslycompatible legacy devices-- which it is intended to seamlesslyto migrate from a fully working, reliable installation--it is being misapplied.
Rather than ignoring the actualreason for the issues that many users have trying to get devices to stay connected, fostering the assumption that it is due totechnology quirks that are being worked out-- although that may indeed hold true for issues with some Zigbee 3.0 devices not working properly eiher--I think HE would uld do better by their customers to reposition the 3.0 hubs as '3 .0 compatible only' as long as the hubs only support only the Zigbee 3.0 security model.
Should HE wish to broaden their customer base to include support for the legacy Zigbee residential security model, that is their option;it's doable (just not certifiable but again who cares) on the 3.0 capable platforms and should support 3.0 devices as well as HE's pre-C8 latforms do...
7 Likes
I totally agree with @Tony.
How many times did you have security issues with your Zigbee network? I mean, for sure an issue could be exploitable, but it's probably so complex to do so that it's easier for thieves to just hammer down your door, break a window, or wait for you to open the door if getting into your house is what they want.
I also don't care about security certification, I'd rather have a rock solid Zigbee mesh any day (even with not so compliant devices). We are not automating hospitals or cars.
But now, just adding something to the discussion. I have a problem with C8 Pro that apparently hasn't been reported. Maybe the root cause is the same, I don't deeply understand Zigbee like some other folks here.
For 3 months I had zero problem with my Zigbee devices after migrating from a C7.
Then the problems started, just by coincidence, after an update that had nothing to do with Zigbee. I later found that the trigger was the restart after the update, not the update itself.
I have 32 XBee 3 devices, mains powered repeaters. I didn't add them to improve my Zigbee mesh, which already had 60 repeaters and only 4 battery devices. I use the XBees with sensors.
After the restart, my devices would simply not respond to commands. Not a single one of them. Long story short, at some point I connected an extra XBee to XCTU to scan the Zigbee network to help me finding the problem. To my surprise, the scan failed with an error, in 3 years using a C7 the scan had never failed! I tried again, failed, restarted XCTU, nothing. Tried every available option on Hubitat to get back a working Zigbee mesh, to no avail.
Today I decided to turn off all XBees, which is a laborious task. Then I started the hub again, with just 6 Zigbee devices and they finally started reacting to commands. I've powered all other devices except the XBees and they all worked. I then powered on some XBees, and everything is working.
It seems that sometimes a routing issue is triggered if the XBees are not the last ones to connect to the mesh. And it makes the whole mesh useless.
XBee 3s are certified Zigbee 3.0 devices. Of course a firmware update after the certification could make them non-compliant, but again I had zero issues with them for 3 years while using a C7, and they are were probably the best repeaters I have had.
I have now a few thousands of dollars in XBees/Sensors/Power Supplies that I simply can't trust to use with a C8 Pro.
