C7 Specs β€” is the faster CPU or More RAM?

I have been waiting for a faster system. Has the C7 been upgraded in RAM or CPU speed? If so, I will buy the C7, but if not, I will keep waiting. The original is already too slow using mostly built-in apps, and extensive and frequent tuning. And the performance issues seem to only affect Some apps like Rule Machine.

I believe the only change was the z-wave radio. The latest firmware has made a huge improvement in performance for my hubs.


If your having speed issues I'd take a look for ghost nodes with a secondary controller like a uzb-7 and PC controller v5. I'm at around .075 response time on the c7


My response times are also very good. I can’t imagine that a faster processor or more memory would make a difference. The zigbee and zwave networks are probably the bottleneck at this point.


I've seen people split up their networks across a couple hubs to increase throughput. I haven't found a need to but I guess some people with crazy setups it helps.

IIRC, Hubitat staff have essentially confirmed this in prior threads.

1 Like

I'm seeing 0.192 maximum time and 0.098 as a minimum time in a 24hr period using Device watchdog to measure turning a virtual switch on and off.
How quick do you want it??? :wink:

I've found having multiple hubs help with extending the range, reducing latency by reducing hops and bottlenecks (ZB & ZW protocols are sequential in nature) and isolate issues (one hub gets flaky the other still operates fine, reboot one without affecting the other etc).

But usually for most set ups that's just "splitting hairs" on performance - the gain may or may not be worth it depending upon your situation.

1 Like

Which seems consistent with what they have said previously re: hub cpu/ram not being a bottleneck?


Yes that's what I figure too. However it's always a good idea to practice safe "RM-ing" i.e. using the lighter weight rule apps if you can, minimize use of logging/reporting, custom apps/drivers if possible etc. The usual stuff...

I read that as rimming, which is a bit of a worry :astonished:


You have just opened a window to your mind. :grinning:
I'm not sure I want to look through it.


I agree, you definitely don't :rofl:


Well as an American we are very much used to that these days... All depends on your "taste" of course :rofl:

(gahhhh.... I've gone too far haven't I?)


Ha ha, yeah, just a snatch.


There are two things that can be looked at.

The health of the zwave mesh is one of them. Ensure you have no ghost nodes, having all zwave plus devices helps big time, understanding the routing and other things will help with that side of performance. Unfortunately it requires understanding the zwave details and most don't care to dig deep into it. They just want it to work which i understand.

On the hub side though, its a pretty powerful box, but no matter how much power you have you can still hit limits if you push it. They are looking into the performance issues with the hub itself. If you have devices that report too much information too frequently that could cause issues with db sizes and performance. A quick thing you can do is look at the size of your backups and that would be a good indication of bloat I guess. Mine use to be 30 meg and are down to 3 now. But even at 30meg I didn't have issues. If your at 100meg that might be an indication. I dont know the exact number but its just another thing to look at.

The good news is that they are investigating it and digging deep.

I’ll be happy when stuff happens .5 sec before I think about it, but not if I really didn’t want it to happen.


The problem is not how fast the hub can see a state change, it is how long it takes for the rules to perform on said action.

I have a Bond to control my ceiling fans. The HE is linked directly to the bond.
I have zwave switch.
When zWave switch turns to on, I turn on the fan.
When zwave switch turn to off, I turn off the fan.

From HE, I press On or Off on the Bond fan, and it responds in near real time
From the switch I turn it on or off, and the HE changes state on the interface in near real time

My rule says when state changes, if state is on, turn on fan else turn off fan.

This rule takes from 0.5 to 3 seconds to execute. So, my wife turns on the fan switch and nothing happens, she turns it on again, and again, now a couple seconds later it starts cycling on and off.

This is not a zwave timing issue. This is a processing performance issue.

That is not right. My rules run nearly instantly. Maybe .5 at worst.

Button device? Or from the actual zwave switch?

It is sort of confusing what device is causing the delays?

State of what?

Maybe put your rule up here so we can see if there is something weird or that could be improved?

I fixed the typos

1 Like