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. 
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.
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.
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?
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.
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,
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.
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.
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.
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.
At this ill be happy just to get back to pre-2.2.3 performance/reliability on my C4.
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.
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:
For REALLY important things:
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 
), take all that nonsense out.
Edited to correct my brain fart, calling out the wrong command.
There is definitely something about the S2 inclusion process. I suspect there are some memory bugs/leaks or something somewhere (due to the way it behaved--it would remember parts of previous attempts that it shouldn't, for example).
I could only do 1-2 S2 device includes between reboots.
However, when I went through and "unchecked" all the security boxes, I could easily do WAY more. And, in general, that went MUCH more smoothly.
What would happen if the device is faulty?
A continuous loop is not good.
Maybe 3 times. I don't know but continuous doesn't seem good to me.
Nice idea though.
Ugh. I need to think better. I meant a "repeat x times loop"
Like this:
Note: these locks are a real pill, so I let the locking attempts run a lot of times.
Most devices would work in 10 or fewer tries.
@bobbles thanks for catching that!!
If multiple events get triggered on the hub for unknown reasons then wouldn't looping through and generating more events possibly exacerbate the situation?
The lock I recommended for my client was the YRD256 with the Zigbee module - which I use at my house. Just paired that 2 days ago and it seems to be working very well so far. It is the only ZB device on that hub at present. I am glad I went that route.
The biggest issue for me right now is the inconsistency. Devices are delayed in their commands/events, pairings partially succeed creating ghosts and preventing further inclusions or fail to pair sometimes but succeed other times. Mesh seems unstable even with a bunch of repeaters everywhere.
The problem I'm having is being able to discern when the trouble is with the hub or a device itself. Until things settle for the hub I'm kinda in a holding pattern with troubleshooting device specific issues unless there is some obvious physical issue.
edit: something odd just happened with the forum on my browser. I thought my post immediately followed yours but all of a sudden there was a bunch of posts that popped up in between. I guess my browser did not refresh properly... seems to be all about the refresh! 
While I'd like to think there are major zwave tweaks coming i am thinking it's not so. Historically when staff have found and fixed an issue anywhere it is promptly posted an announced for "next release" while I have seen some of these i have not seen any saying this zwave thing is better or that is fixed.
So I remain hopeful. Though I am starting down the path of wishful thinking.
Download the Hubitat app
