Is there a major problem with the new C7 hub?

🛎️ Get Help
1

First, what happened to the updates? Me and others have been waiting over a month for a fix on Siren 6, which does work on the C5. Meanwhile I have no auxiliary chime for my doorbell.

Secondly, this system hangs, A LOT. I thought I had the kinks worked out. 3 full zwave radio resets and I finally had a somewhat stable system until yesterday. Out of nowhere I'm back to random zwave radio hangs and devices taking over 30 seconds to never to respond.

I don't think I'm asking anything special out of this product - turn lights and a few other devices on/off. The amount of man hours I have invested is embarrassing. My question is, is there a problem with the hardware that went out and now they're scrambling behind the scenes to develop a workaround in firmware? Do I have a bad HE C7, RMA time?

2

You really haven’t provided enough facts (firmware level, devices, etc.) for anyone with a similar configuration to suggest steps to try.

I’ve got a C-7 running 2.2.3.148, never hangs, always responds quickly, never reboots. Now, I’ll be the first to admit that the built-in Aeotec Door/Window Series 7 driver has issues, but nothing that prevents the devices from working. I’ve turned in numerous bug reports (support tickets), and have been told that a fix is forthcoming in 2.2.4. No real show-stoppers for me, but I understand that there are some people who are up the creek, so to speak.

I’d prefer to wait for a well-tested, solid release. But that’s just me.

3 Likes
3

It does seem abnormally quiet at the moment
I wonder if Hubitat are awaiting a 700 firmware update.

1 Like
4

No, we aren't waiting for anything from silabs. 2.2.4 is in progress, it's a pretty big release, when we're happy with it we will release it.

20 Likes
5

@mike.maxwell Do you recommend waiting for that release before migrating from C-5 to C-7?

I’ve already purchased my C-7 but I’m hesitant to migrate at this time because of all the z-wave issues I’m reading about.

6

I think this is more a philosophical question.

I have a new C-7 sitting on my desk. I had powered it for 2 - 3 weeks to make sure it didn't go dead, but now its back in the box.

I'm waiting until a few updates into the 2.2.4 release. Normally I would just jump in but I have some other projects keeping me off the streets.

As said above all indications are that 2.2.4 will have some big changes. Now that I'm at the point of moving all my devices over should I start Murphy will have 2.2.4 show up partly through the change over.

So while my C4 is running fine, I'll wait.

1 Like
7

There are major updates about every month. And this has been two. But if you look back at the history, there were some fairly large changes in 2.2.3 bugfix updates even without them being a major release. The last 2.2.3 update was just a touch over a month ago.

These slightly irregular spaced update periods aren't completely unusual. Look at the history going back about a 18 months. :arrow_down:

1 Like
8

I would say sort of. My opinion is that the C7 was rushed a bit due to global supply issues. Add to that the C7 is the first 700 series hub on the market, and there were apparently bugs inherent with that new chipset and firmware.

I think Hubitat has done a great job fixing many of these bugs as quickly as they did and getting the hubs mostly stable. They were turning out hub updates pretty often there for a while. I know some of the staff didn't sleep much doing updates and fixes.

So I think it is good that they are taking time to iron out some persistent bugs, and to make things run smoother. I think everyone is anxious to have this update, it is supposed to fix a whole bunch of issues on all versions of hubs.

In the meantime, maybe post some specifics like logs, and what types of devices you have, and maybe someone will be able to spot why you are having these issues.

4 Likes
9

No need to cutpaste but I posted about all these issues a few times. Mostly the threads either have zero replies or go nowhere. Any I don't think its anyone's fault, I don't think there is an answer at the moment.

I'm a little surprised there isn't more noise about these issues if others are experiencing the same things.

10

I looked through your history, but I wasn't quite sure what issues you had that were ongoing. Maybe give us a quick recap of what you are still having issues with?

1 Like
11

I'm hoping to see some fantastic things come out in 2.2.4 Although for my usage I can do everything I need now. But consider they brought bcopeland onto the team not too long before things went "dark". With the extra very talented manpower a lot of things can result.

I guess we'll have to see.

My guess is at the same time they are addressing them in 2.2.4 and any work on 2.2.3 is diversionary, as long a folks are at least limping through.

1 Like
12

From what @mike.maxwell indicated earlier today, this is exactly correct.

13

The doorbell is being fixed in the next update. I'm not thrilled about waiting so long but it is being addressed.

The reoccurring theme I have is that the hub just gets sleepy, it stops sending out zwave commands. This can be the case for 30 seconds or minutes at a time, or until I trigger a reboot. The zwave log is empty and nothing zwave responds. Incoming Zwave remains working however during these periods, such as motion sensors. They keep on updating status like nothing is wrong.

A for instance would be, I have three outdoor outlets with holiday decorations set to come on at sunset. At least once a week, only 2 out of 3 turn on. My understanding is rudimentary, but if the ON command fails to make its way to an outlet, doesn't it try again, and again, until the device state is correct? Shouldn't this be -kind of- impossible (with working devices that are in range) And not sure where the blame would fall but if it's going to give up trying to turn something on, shouldn't an error go in the log? Again I'm just making assumptions but that's the best of my understanding,

1 Like
14

Not that I am aware of. I don't know the code behind this, so don't take this as gospel. But from my observations things seem to wait some period of time after an command, and if they don't respond, too bad the hub moves on.

I would think this would depend upon the source of the error, and what logging settings you have turned on. This might me a good thing to do if you are having such issues, turn on logging on your rule and the devices and watch for a day or two and see if it is the rule or device acting up.

I have a hunch that you don't have very many Zwave devices, and/or that many are sensors or non-repeating devices. A lack of mesh or bad mesh can do weird things. Could you give a quick summary of devices you have (brand/model) and maybe we can see something unusual.

15

My mesh should be great. I'm counting over 50 zwave devices. More than half of them are mains powered (mostly innovelli switches/dimmers) and a few leviton and jasco/ge outlets. And if thats not enough, FOUR aeotec range extender 7. All this in a pretty small 1500 sq ft home, all the devices pretty well spread out.

1 Like
16

Yep, that should be fine. It is usually the people with 6-8 devices where I would be concerned about that.

I don't think what you are seeing is normal even with the recent firmware issues, so keep looking at things because you may be in the same boat when 2.2.4 hits if it is something like a defective switch or ghost node (you sure you don't have any?) or something like that causing issues.

So I guess my above advice stands. Turn on logging on something like those outdoor lights, and their rule(s) and see what happens.

1 Like
17

Yes, logging for everything is on.

As I mentioned before I had to reset the zwave radio 3 times when I came over from the c5 hub. I added just a few devices every few days, trying to weed out a device not behaving properly. Best I can tell what I'm experiencing isn't tied to any one device in particular, because the hub did this after each reset, with different devices paired each time.

The one thing that did allow me to finally get ALL the devices included was NOT keying in any of the DSK digits. During inclusion when the hub asked for a DSK, I unchecked all the security boxes and did not enter a key. This worked much better than the first few times where I did enter those keys. I'm wondering if these zwave problems have something to do with the added security that comes with the 700 chipset.

18

At this ill be happy just to get back to pre-2.2.3 performance/reliability on my C4.

1 Like
19

I'm seeing problems with multiple events logs from devices that are simply switched on or off and are a few feet away from the hub and direct line of sight. I'm also seeing serious and random delays when trying to trigger things - I expect a Zwave group to popcorn a bit but some switches take seconds longer to respond than ones right next them in the same box. There is some kind of messaging overload that happens (Storm maybe?) - I hope gets addressed in the next update. Also I think the device pairing is wonky - it's improved a bunch but some devices don't want to pair or partially pair and a bunch of network busy messages get generated. Another issue is pairing of certain non-S2 devices via HE - like my Aeotec Recessed door sensor 5 forces the device into S0 mode with no ability to change it. In my case the sensor paired that way did not respond at all just reported 100% battery. The only way to get around this is to pair the device via a secondary controller like a Z-stick and using the Z-Wave PC controller software. My understanding in reading various posts by the staff is that this is per SiLabs spec so is not really HE's fault. It's odd that SiLab's PC Controller sw allows it though. Note: I only paired via a 500 series secondary controller (Z-stick) NOT the new UZB-7 so maybe that's the difference.

2 Likes
20

Dropped commands, multiple log events, status not updated properly. Those issues seem to not be isolated.

And, I am hopeful that the comment about it being a "pretty big release" is a very good sign--meaning that they found some issues and have been working hard to resolve them.

Not to mention that there should be some additional drivers and driver updates for some devices (from what has been said elsewhere).

I was freaking out about my system not working well (all the issues I mentioned in the first sentence) and busting my butt to figure out why and try to fix things.

However, once I realized the issues were apparently "well known", I have mostly been living with it and waiting for the new release.

Having been in IT for a long time--most major software companies address bugs in the scales of weeks to months and new releases are many months to a year or so. The Hubitat folks were working nearly around the clock cranking out releases and fixes for some really serious (as in, locked hubs, devices not pairing, stuff not really working at all) kinds of issues.

Now, it seems we're down to 10-30% of devices sometimes don't respond all the time as expected--which isn't great, but for most automations, it's not a complete show-stopper.

I originally paired all my S2 devices as the default of "S2 Authenticated". I went through a painful exercise of removing/including them as "Unauthenticated". I seem to think it got me for 20-30% failures to 10-20%. A notable improvement, but not a complete solution.

So, in the mean time:

For more important things:

  • Add a "refresh()" prior to the command, wait a few secs, issue the command wait a few secs, do a "refresh()" again, and issue the command a second time.

For REALLY important things:

  • Do them in a "repeat x times" loop--Do a "refresh()" before the loop and wait a few seconds. Then, in the loop (looping, say, every 15 secs); do a "refresh()", delay 5 sec, check to see if it worked and exit if it did, otherwise issue the command. Loop. See this example:

Screenshot_20201024-042942
Screenshot_20201024-0429422048×1926 696 KB

That should help tide you over at the moment.

(And, yes, those are REALLY bogus things to do--not the kind of thing you want to do forever--but, they are modest, albeit ugly, workarounds for the current, hopefully temporary, situation).

So, yeah, once the issues are resolved (fingers crossed for 2.2.4 :crossed_fingers: :crossed_fingers: :crossed_fingers:), take all that nonsense out.

Edited to correct my brain fart, calling out the wrong command.

2 Likes