I had an issue including it the first time, that’s where ID 55 went, lol. Found out (after excluding/re-including) that the problem was just a dead battery. So far, it has been performing well on the C7.
1 Like
I hope it works out better for you than it did for me
1 Like
Excluded both the Zooz and Inovelli devices (56 & 63). Did not have an effect on the orphans. But now the Zooz will not join (S0 device), the inovelli will not join in S2(joined successfully unsecure), and both schlage door locks will not join the network(one is S0 and the other S2)...So it seems that devices can't join securely to the C7. I restored to last night's radio and regained some functionality by "replacing" the nodes in zwave details. I ended up excluding them again...Zooz and Inovelli were in a partially initialized state. Zooz reported motion and tamper but not much else. Inovelli would respond to commands but not report it's state unless polled.
It sucks, but I am at the point where a zwave radio reset and start from scratch is on order...
Ouch... that does suck. I have never had to reset the Z-wave like that and I've messed with/up a lot of hubs from the C-4 through C-7 . I wonder if there is some other device that is causing this issue. I have had that happen and it caused some interesting problems like forcing my Zigbee mesh offline. [edit: I might be misremembering this incident]. I had trouble with pairings when the C-7 first came out but powering the hub down and waiting usually resolved the issues.
Agreed, but that is nearing the end of my zwave devices...only 3 devices left, but they were added after the issue initially presented, so likely not them...but I may try re-joining them this weekend and see what happens.
I am waiting to hear back from engineering to see what they say, before doing anything rash... If it’s just a database issue then resetting solves it...but if it’s a hardware/low level issue then I’d be shooting myself in the foot, lol.
1 Like
The other thing to do is disable all apps and custom devices temporarily. Maybe it's some sort of funky resource issue. Did you look at the app/dev stats?
I should have looked for all these threads in the community showing how much this C7 hub sucks. I've been struggling for nearly 10 days now trying to have a working mesh network, with more than 40 devices, replacing most of my old Z-wave devices with new Z-wave plus devices, nothing makes this work. All devices (yes, you read well, all of them) fail 10 minutes after a fresh reboot. No ghost devices / orphans (don't get me wrong, they happen all the time, every other device I pair gets / generates a ghost/orphan device).
And nobody in the staff seems to realize and their "ambassadors" are just like propagandists who will imply that HE customers are too dumb to use their product properly. I'm that close to getting a hammer and destroy this device and post a footage of this on Youtube, maybe it'll cover the cost of this brick they sold me. Oh, and btw, no answer from the Customer service, I guess they took a vacation.
1 Like
Well, it does happen to be a 3 day holiday here now. Maybe they are on a vacation?
Indeed, it is a long weekend here in the US... 
I'm just super frustrated, mad, wacko, nuts... lol
Wondering... Could this be a power supply issue? My hub is connected to a long usb power extension (10 feet or so, maybe 15) and I see that the power supply is only 1Amp... I just connected it to a 2A power supply because the length of the usb extension probably generates some power loss. That would explain pretty much the loss of all devices connections at once a couple minutes after reboot.
Is that the power supply the came with? I thought 2 amp was required.
Can you move the power supply closer to the hub? With a long cable you could have a Voltage drop. Increasing the available current doesn't compensate for voltage drop.
1 Like
True but usually intensity can compensate since what matters for many devices is the total power supply… but haven’t thought of the fact that radio throughput can be voltage sensitive. I’ll look into this.
Thank you.
Update: Not the issue. I'm slowly reversing back to my old C5... So far not ONE of the issues I had from the very start with the C7... No ghost device every step of the way, no problem associating any device. My hub is faulty,clearly.
I just gave up trying to make my C7 Z-wave work... Put everything back to my C5 and in less than a day got everything to work smoothly. As long as Hubitat staff doesn't follow up on this, I'll continue to believe they sold me a faulty device, at the best and, at the worst, that they put a product on the market without having tested it correctly or, even wose, they knew the SKD was terrible but had no choice but to still put this one on the market because they were out of C5 already.
I’m on my second C-7. Very similar problems. I had a stable mesh on Micasa Verde, then Smartthings G2 for ~10 years. No problems. My upgrade from ST was due to preference, not performance, but HE has just not worked.
I’ve upgraded many devices now to z-wave plus, even the $200 lock to get out of S0 encryption (never an issue before), installed to Aeotec extenders within a triangle of 10’ of the hub and 2 extenders, still can’t get the paired lock to repeatedly, reliably respond to lock commands. I’ve removed all ghost nodes with a stick (another purchase).
First level troubleshooting refeered my issues to engineering, but never heard back. Got some feedback from the forums that maybe Homebridge was “flooding the network” with automated off commands (never an issue with ST) so I created groups and Webcore rules that stagger commands.
Result, still only about 50/50 success in having my automations and commands execute. Especially on the Schlage lock.
I’ve got hundreds of dollars and over a hundred hours into making HE work successfully, but have hit a wall and feel like I’m at a dead end. So frustrating.
PS: I should add (without hard data), that I feel it's the Silicon Labs 700 series Z-Wave Chip. I see the hub sending commands to the z-wave radio, I get the UI of Hubitat, see the promise in the box, it's just that last mile of executing z-wave commands...
2 Likes
I too think that there is a problem with either the 700 series chipset, or the SDK released form Silicon Labs for this chip. Hopefully it's the latter, and performance can be corrected with a firmware update.
I was having performance issues with Z-Wave. One or two devices would always work, but when I tried to have automation with more than two devices, I would get inconsistent results. I sent my data so support, but never got a response back.
Outbound messaged seemed to get "clogged", but inbound messages always made it through.
The solution for me was to put the Z-wave devices into groups (using the built-in Groups and Scenes app) and use the automation logic on the group versus multiple single devices. This helped drastically, but occasionally, I would have switches not switch.
To make things stable (and they have been since I have done this), I enabled the "metering" function of the group with a 75 ms delay. According to the documentation, this inserts a delay between multiple z-wave commands going through the radio. One would think that there would be flow control already in the device...but this is what made things work for me.
I have been monitoring BOTH my Z-wave mesh details and automation performance daily for the past month...and things have been stable for me since doing this.
Well, the current platform is using a fairly old SDK version. Although looking through the release notes of every SDK version, I don't see anything that would make me think this is "fixed" in a newer version.
That said, I'm sure at some point Hubitat will upgrade SDK versions - they have to in order to support Zwave LR, for instance.
Maybe when they do, some of these quirks will magically go away, even though there isn't anything in the release notes to make me think they will. We all know not everything makes it to the release notes... 
3 Likes
I've had the same thoughts, that at some point an SDK will be released that works the kinks out.
@ksgnow2010 Thanks for the heads up on metering. I hadn't explored that as I thought it was more about power reporting and I'm doing everything I can do to keep traffic on the mesh down.
One other thing I've found that seems to help with my lock being intermittant.
I use webcore for many of my automations, and I'm testing, but believe it to be more reliable if I "refresh" the lock, add a wait command (5 seconds), then execute a lock function.
The refresh shouldn't be needed, but it seems to "wake things up" and make it so the lock command actually goes through.
I have more testing to do, but in testing the automation 10x, it worked 100% whereas without the refresh, wait, change state I was running ~50% success rate with no other traffic on the network at the time.
More testing to do! We'll see... I don't need speed in most of my automations, I need to trust that they do what they're supposed to do.
Thanks everyone,
Jonathan
1 Like
Thanks! I wasn't aware of that. I'll give it a try!
1 Like
