Would you zigbee if doing over?
I have just a few, plugs and presence sensors, and they are a joy to join.
every version of 2.2.4 ive tried has delays on turning on lights.. i am think whatever they changed my mesh is too big..
1 Like
ya but replacing all light switches to zigbee would be a royal pain not to mention expensive.. and there are some zigbee devices that are not avail. like sensors to go into my freezers , and dry relays are hard to find etc. But yes other than the couple of lightify bulbs that kept dropping off the mesh that i replaced with hue bulbs, zigbee has been effortless.
1 Like
FWIW interface responsiveness has been outstanding for me on 2.2.4, but device responsiveness has been noticeably slower than 2.2.3 (but still OK enough for me - maybe 1-2s slower on 'round trip' logic like mirroring a device on/off status).
Since I do my logic in node-red it could be Maker API has slowed down or the device reporting itself has. I don't have time to figure out which right now. Everything else on the node-red side is as fast as ever, so I don't think the issue lies over there.
1 Like
I would say it's the same for me as well - but still seems responsive enough. My Aeotec dual nano is still awful though - get 7-9 seconds of delay but I always did even pre-C7 (the pico mounted next to it is MUCH faster!).
I have faster automation response on 2.2.4.153 (and thankfully haven't had any new issues). Device page response has always been fast, so no change there.
I do have a broken motion automation that won't run as it always thinks the switch was turned off manually, even though it wasn't.
Other than that I'm pretty good right now. I have one device (iBlinds) that kept falling off my mesh and bringing it down priort to .153. So far it's holding on...hoping the improved efficiency of Z-Wave in .153 (as Bryan described it) will help it to stay connected and keep it from trying crazy routes like it did previously.
1 Like
Why would pulling repeaters enable you to bootstrap back to working, and why did you think to try that?
Just trying to figure out:
(1) what is different about my C-7’s setup that lets my installation work fine on 2.2.4.153, and
(2) an intelligent way for me to proceed if a similar thing happens to me on a future update.
Mine is a fairly simple setup, almost all lights on Hue hub and Lutron Pro hub, less than 20 Z-Wave devices (all plus except for one), and 6 of the devices are Ring V2 repeaters.
1 Like
The Iris 3210-L2's were the only suspect devices I had on my mesh. Removing them was a first step troubleshooting step. Given the large number of devices on my z-wave mesh, coverage is not an issue. Loading .153 after removing the repeaters also let me upgrade without issue. Guess we'll see how it goes from here.
1 Like
So you were using the Z-Wave part of those plugs - I have tried to stay away from doing that - it always seemed so hit or miss. The Zigbee side has been good though.
I ripped both the zigbee and zwave 3210's out. I've never had any issues with the zigbee side but decided to pull them all for the time being.
2 Likes
Same here, I don't have a ton of them (maybe four or five) but I'm only using them for Zigbee repeating.
BTW, 2.2.4.153 has a new URL to reset (wrong -> firmware <- wrong) z-wave stack to the version used by 2.2.4.148 and prior:
/hub/advanced/installZipgateway714
And another one to download 2.2.3 if it's gone from the hub after several 2.2.4 updates:
/hub/advanced/download223
I hope nobody ever needs these... but they're there just in case.
3 Likes
WHAT firmware? I don't remember seeing that there was a firmware update in the release notes? Or did I miss it?
(See below, no mention of any firmware updates)
Release 2.2.4.153 Available
This hot fix includes:
App Features
- Rule-4.0: Set Boolean variable to another variable.
- Thermostat Controller: Added optional restrictions.
- SharpTools: added documentation and video links.
Platform Changes
- C7: Z-Wave single node repair now works in the new repair GUI.
- C7: Changed Z-Wave startup order to prevent busy messages.
- Hub mesh: advertise available devices in pings. WARNING: not fully compatible with earlier hub mesh versions. You must run 2.2.4.153 on both hubs in the mesh or devices will be disabled and will not update.
- Hub mesh: store all remote device state, attributes, and data in local database.
- Hub core: revised memory settings.
Bug Fixes
- C7: Z-Wave stability and performance improvements.
- C7: Bug fixes for Z-Wave Repair.
- Mode Manager: Fixed earlier/later of two times bug for daily settings.
- HSM and HSM Custom Rule: Fix alert set lights to level.
- Motion and Mode Lighting Apps: Fixed import list for exported rules.
- AppUI: Adjust min width for 24 time input on desktop view.
- SharpTools: fixed issue with devices not unsubscribing properly.
Did you mean that that URL is used to set the database to the version used by the prior versions of firmware? I'm a little confused.
Ok, I probably used a wrong word for it. It's the Z-wave stack. It's just another piece of software running on the hub, nothing in that update gets flashed into a chip or anything like that.
Yup. More super secret changes that aren't listed anywhere, just like the magic platform changes.
eye roll
Yes, that is sarcasm, but it is annoying. I'll get over it - your company, your rules, your decision on what to list in release notes.
Z-wave stack should rolls back when a version gets rolled back. But it is a separate executable. If something goes wrong and it doesn't, there's a way to force it to a clean previous version without doing anything more extreme. We can't anticipate all potential issues, but we can provide a plan B once we see someone running into them.
3 Likes
Just to clarify do we think there is a bug with .153 ? I'm on a c5
Got it. Thanks.
