Thank goodness we're not at an earlier version number. Imagine the fun if you told the TSA agent your suitcase was full of C-4?
All of my zigbee devices work just fine on my C8, and have since day 1. Never dropped off, always work fine.
I get that you, and others, are having problems (which sucks) but it definitely isn't a universal truth that everyone does...
Yup, I thought I was rock solid until some ZigBee end devices disconnected. Repeaters do not have the issue, but end devices, like sensors or non-repeater bulbs, really fight you to get them back on the network if they were migrated and then drop off for any reason.
I gave up on two Sengled end device bulbs that apparently will never connect again, though I still have two of the same bulbs working fine that were migrated from the C7. Those bulbs still connect to the C-7 just fine, but the C-8 will not let them back on.
Not true for the 60 Zigbee end devices I have
That is interesting. As a quick test, I pulled out an old Sengled RGBW bulb out of my drawer. I was able to pair it with my C8 hub without any issues. I will say that almost all of my Zigbee repeaters are old Lowes Iris 3210-L Outlets. These are Zigbee HA1.2 devices, not Zigbee 3.0. And, my Sengled bulb that I used for testing is one of their older bulbs, from when they first released their color Zigbee bulbs. (These days, I am using a Philips Hue bridge with genuine Philips Hue bulbs. Not because the Sengled bulbs were an issue - but because I wanted the additional functionality that Hue offers.)
Are your two 'problem' Sengled bulbs updated to the latest firmware available? Just a guess as to something that might help them behave better.
Have you been able to pair any other Sengled bulbs to your C8 after the migration? Or is the problem just specific to the two bulbs?
I migrated from a C7 to a C8 early last year. My Zigbee network was rock solid on my C8 hub. Over this past weekend, I migrated from the C8 to a new C8 Pro. Everything went smoothly and I have not had any Zigbee issues thus far. I do avoid Aqara Zigbee devices, due to their propensity to fall off the network. Most of my Zigbee devices are all old Lowes Iris v2 devices, made by Centralite. They have been very solid for many years now.
These are the soft-white Sengled Bulbs with a candelabra base. Apparently they are one of the few Sengled bulbs that only act as end devices and do not repeat, no they are not in the same category as other Sengled bulbs.
This was all hashed out in another thread if interested:
Just an FYI - None of the Sengled Zigbee bulbs act as repeaters. They are all Zigbee End Devices. (Unless Sengled has recently changed their design on new bulb devices.)
From the Sengled Website FAQ
But do you have any mains powered Zigbee 3.0 devices?
Because I suspect there is an issue with the way the C8's SOC handles the pairing of 1.2 devices in an environment with 3.0 repeaters. Which would explain why some people do not have any issues, since it may be very device dependent. So if all you have is legacy devices, there may be no issues. Now throw in some 3.0 mains powered devices and even that may be very device dependent on if an arises or not.
Also on top of the C8 having external antennas, which may be more prone to interference due to the increased sensitivity.
When I first migrated, 3 sensors and my thermostats refused to come across, but I manually unpaired and then paired them, and they’ve be perfect ever since.
I’d suggest that you have a badly behaving device that needs to be removed and manually added.
I just have another datapoint. I have a C-8 with 103 zigbee devices. It's a combination of zigbee 3.0 and zigbee 1.2. The most active repeaters are all Zigbee 3.0, including 3 Sonoff zigbee 3.0 dongle S repeaters and 3 Samsung Zigbee 3.0 plugs. I also have GE zigbee 1.2 in-wall dimmers and switches, Hue plugs, and Sylvania plugs. I have 7 Hue motion sensors, around 20 Iris V2 motion sensors and contact sensors, Linkind contact sensors and leak detectors, Samsung Leak detectors and contact sensors, Sonoff contact sensors, Hue 4 button dimmers, 20 or so Lightify dimmers, 3 Tuya valves, and a LeakSmart water shutoff. Nothing has dropped since moving to the C-8 almost a year ago.
Base on my experience with the product I would say more CPU would help with inrush or recovery from problematic wireless networks. I've experienced significant delays on the zwave network and I've asked for a "faster" version to help with some of the issues. Fingers crossed the pro version helps eleveate some of the problems.
While not the perfect release cycle, I do believe HE is using the same general iterative cycle that apple uses to create iphones. They're trying to improve on their product as fast as they can and they need to pay the bills someone for all that effort. They have only 2 revenue streams by selling hardware or subscriptions for remote access and full backups. Given smart home automation isn't a huge market that can't be a lot of profit in the business to support the growth. I'm happy they keep pushing forward. The faster CPUs I'm hoping solve some my inrush zwave network issues. We'll see on that front.
Great news for EU users!
C-8 PRO price in EU dropped 10€ ... getting there. Still hoping that some sale in US gets here too.
The problem is that I don't NEED a C-8 PRO, but I WANT one .. why life is so hard?
PS Ultrasmart.pl should be tipping me for advertising their store
I REALLY don't see how moving from a 1.5GHz A53 to a 2GHz A55 CPU will make a single bit of difference for Z-wave. Z-wave is 100kbps. Even assuming it was being handled purely in CPU (which it's not) we're talking about a wireless network that pushes bits at 0.006% the total capacity of a single thread of four on the C8. Having it go from being 0.006% of the CPU total to like 0.004% isn't going to matter.
Your Z-wave issues are mesh related. Get a few more repeaters. If you have power monitoring stuff, get rid of it/turn if off (if that's an option).
But I just don't see the extra CPU power making even the slightest bit of difference here. Z-wave is just so much slower than even the C8 CPU it's basically nothing. Plus the Z-wave radio handles most of the 100kbps anyway, so it's even less than 0.006% of the CPU being used.
A faster CPU handles inrush conditions better then a slower CPU. You can't always detect inrush conditions through CPU monitors do to sample rate of the CPU log. THe CPU speeds you've mentioned above, do you have sample rates. In my setup of 150+ devices, mostly z-wave I've had very large delays at the time of a switch event. For example, I want to turn off all the lights on a floor to go to bed. Sometimes that takes seconds, sometimes it could talk up to 30 seconds to complete that task. When complex relationships are involved say between a z-wave device, Lutron, and Samung Smarthings device, things have worked very well then hard delay. I've been able to work the supermajority of the issues out over time, and that's why I've stayed with Hubitat over moving to other products were I would be starting with a new set of issues, but in my expereince faster CPUs always make for better user experience which can smooth over some of these issues. If you have no issues at this time, then in your case, you may have no reason to move forward to a faster system.
Definitely a problem with a Z-Wave/Zigbee network(s).
Talking about CPU speed vs. slow Z networks. Think about street with traffic lights. Since Z networks are very slow CPU wiill see traffic lights mainly in red. Now does it matter how fast you can drive from one cross section to another? Even if you drive with the speed of light you always will be waiting long time for the green traffic light window.
I think you're all thinking it was done on purpose rather than the team just doing some clever marketing and spinning the standard manufacturing process . We understand that since the 1st pre built hub C5 the processor and ram have not changed that was a while ago. I would not be surprised if the older chips were becoming obsolete or more expensive than a updated newer one. It could have just been a round of rationalization?
It's not impossible the zwave / zigbee network itself could be blame but what Im saying is a bit different and based on my 25+ years of experience building large hardware systems. I've found code is always buggy. Debugging time is limited and throwing faster CPUs at almost any problem gives developers of larger systems more runway to work with. Also note, we don't get much in the terms event driven logs, or time series data in Hubitat design so we're both making personal experience judgment calls with limited data. I do believe faster CPUs are always a good thing for all product lines.