Anyone else seeing occasional issues with Z-wave on the C-5 since 2.2.3? Since the last few updates, my z-wave mesh will seemingly, slow to a crawl (over a minute for a command to turn on a light will come through). A reboot fixes it, but I'm wondering what might be going on.
The main way I notice is when I tell Alexa to lock a door, the command times out, and the door doesn't lock. During that time, if I try to issue any other z-wave commands, they are significantly delayed.
It's completely correlation and not causation necessarily, but it SEEMS to only happen after one of the 2.2.3 updates and I don't reboot a second time after the update.
Anyone else seeing similar? Thoughts? I'd love to update to a C-7, but I'm waiting for Hub Protect.
My locks were flawless until this last update, now all they do is hang. The lock status doesn't update correctly. These are Schlage BE469 (non-zwave plus) locks, and all 3 suddenly have problems after a year or more of being perfect. It takes my locks literally 2-3 minutes to do a lock or unlock action after clicking on the dashboard. I just tried Alexa, and she timed out with "something went wrong".
I also did notice an occasional issue with some Zwave lights and fans, but nothing like the locks. Weirdly enough, other Zwave lights are so fast I cannot believe it. And these good switches are probably a couple feet from the badly behaving locks, and maybe less than 10 feet from the other switches that give issues.
I think it was the 2.2.3.135 that caused it, as I just noticed this after yesterdays update. I have rebooted multiple times, and I have done a couple zwave repairs with no apparent difference in performance. I didn't try rolling back yet, but that is probably next.
@bcopeland or @gopher.ny did you make any changes that could have affected C5 Zwave and maybe in particular locks?
Just unlocked and locked my Schlage with no issues. I will say I'm good about locking the door when I come in so it's rare that it tries to do anything automated. I'll try to leave it alone on my next few times in and see if it will lock okay based on timeout.
That did not work for me, I did multiple (3-4) reboots with no change. At least not a long term change anyway. It was fine immediately upon reboot, but within a few minutes issues were back.
I think you have been around long enough to see why they are not recommending this lock anymore. I don't think they wanted to pull it from the supported device list.
But I would not read into that they are bricking it, at least not purposely. It worked well up to this point, so I think they broke something (unintentionally) in the 2.2.3.135 update.
lol not implying hubitat doing anything to cause issues. Just worried that with it not being supported it may be less likely to receive serious trouble shooting time. Which as you have stated is understandable given the many issues reported over the years with it.
Then again if it is a wider zwave issues I am sure more users will start chiming in.
I only noticed it because I had to work last night. I left the house, and by the time I got to work I had an alert that the door was unlocked. I always physically lock the locks by pressing the Schlage button, there are no autolock automations. So was almost 100% sure I had locked the door as I heard the motor whirring.
So after I got that alert, I looked, and sure enough it said the door was not locked. I tried to cycle the lock via cloud, and it was hanging. I tried a couple times with no change.
So probably if this is a larger issue, people will know today when they leave or arrive home for work and things bomb out.
And for Bryan or Victor, I tried debug logging this bug on .135, and I got literally nothing. There was no indication at all in the logs that I had even tried to lock/unlock. After the .132 rollback, I get the expected messages in debug logging like Parse, LockOperationReport, door lock was unlocked [digital], and so on.
