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.
My C8 has been rock solid. I had issues at first due to a bad migration (partly impatience, partly now clearly communicated how the migration should have been done). Once I got that ironed out and my meshes rebuilt (which really needed to happen anyway) I have had Zero issues.
I lost track keeping with this thread so pardon my excuses.
So faster reboot time....on the Pro
Any other "noticeable" differences / improvements between the 2 models ?
I am on the fence getting the C8 Pro
I currently have C8
Thankyou in advance
Faster CPU, more memory. Former is noticable. Latter may be important, if you run a combination of stuff that likes to munch memory. Better to fix memory problems, but having a ton of it may be enough "fix" in some cases.
I'd say if you aren't having any significant issues and don't need/want a second hub to split up your devices, wait for the C9. Being on the bleeding edge is more fun, the C8-Pro is very nice, but just another version of the C8.
C8-Pro shaves off around 50-100ms on motion-sensor based lighting turning on. That alone is worth it if you use a lot of motion sensor lighting.
Download the Hubitat app
