Yep as far as I know (to both your questions!) - when pairing with no security the next popup has the full code on it..
EDIT: As far as S2 security goes some devices can be problematic but in my experience the repeaters like Aeotec 7 & Ring work fine.
I generally do NOT pair smart switches with S2 out of habit but this may change with future firmware updates.
Ideally just keeping things at what the device wants SHOULD be the way to go.. but for now, I am playing safe.
Contrary to many, I use S2 for EVERY device that supports S2. Not because I think it is especially "needed", but more because it is the default pairing mode and I know for a fact it is tested in the zwave cert for devices.
Plus, there is basically zero performance penalty for S2 security - so why not?
2 Likes
When I installed 61+ Zooz switches/Dimmers at a client's house last August, HE firmware was a lot less stable than now so ended up pairing everything with no security. Was worried that I might have additional issues and support on my hands. It's been very reliable so far which is kind of amazing to me given the past system quirks.
If I had to do it over now I might consider just going with the defaults because I agree that SHOULD be the correct thing to do. However I think I am going to wait to see how it goes if/when we get an update to the ZW radio firmware...
1 Like
There really isn't anything wrong with doing no security, though, either.
In fact.... The current S2 supporting GE Fan Controllers have to be paired with no security or they lock up (will likely be silently fixed in a future device firmware by Jasco that existing users can't get...). 
So SOMETIMES pairing with S2 is worse due to the newness of some device manufacturers S2 firmware code path.
Good point, on the device end...
1 Like
I would add to this that nearly every version of the SDK from SiLabs has had a lockup.
The watchdog is actually used by the SDK and the things still lockup.
First of all - Thank you all for all yours help, advise, ideas and support.
I learned a lesson about Zwave mesh stability in a hard way but thanks
to all of you right now my ZWave network looks really good.
- All ghost devices are gone;
- No any device included with any security;
The only one which should be included with security - is an
August Door Lock (right now is not included). Since I am not
planning to use it for any automation I will keep him excluded
(it is S2-capable but I will rather will not try to include it).
Somehow my newly added devices mostly to be a repeaters
still not in any route path. However dedicated Aeotec repeater
finally (after 3 weeks but few times I moved him to a different
locations) is a repeater for few devices.
3 Likes
Something strange and unlogical is going on.
It looks like my ZWave mesh is still healthy (did not notice missing event).
But:
- the dedicated Aeotec 7 repeater is not longer in demand;
- of course, few outlets I added just to be a repeaters are not a repeaters;
- Outdoor Light Sensor is functional but lost its routing table:
This one is about 12-15 feet away from the hub and not obstructed.
I think, it reported a direct connection to the hub.
Something is going on but what?
I hope, my ZWave network is not started degradation.
Edit.
Somehow route is restored back.
If you have a C-7, try Tony Fleisher’s (@tony.fleisher’s) excellent Z-Wave Mesh Details app.
This might give you insights into what is happening.
It also installs via Hubitat Package Manager, by Dominick Meglio (@dman2306).
1 Like
The ZWave 700 Series chipsets have very little issues.
I am an EE that is also a programmer.
The issue is that the SDKs from SiLabs on the 700 Series have very many updates every couple months. Some of them are lockouts, some are LWR issues, some are worse and they still have not fixed them.
IF you go to SiLabs and check on the ZWave SDK releases you will see 15 or more in the last year.
Some of the releases.
Every single time a company puts out a "fix" which includes the ZWave SDK update, it costs them money (a pretty good amount considering it wasn't their mistake). Not a very good thing for the companies since they will more than likely not update until very often.
3 Likes
Are the updates to the SDKs something that can be fixed through firmware updates or it that something that requires a hardware fix/replacement.
Considering the competition they are about to encounter from the Connectivity Alliance and Matter, SiLabs better get their act together quickly.
I would guess the answer is fixed via firmware updates - The C-7 already had one radio firmware update with 2.2.3
3 Likes
There were some HW issues but I don't know of one vendor that put out devices with the bad chipset. I believe SiLabs caught that issue before anyone went into production.
There are also differences between the Hub SDK (ZWare or ZIP) and the end device SDK.
They do not always have the same issues.
https://www.silabs.com/documents/public/release-notes/SRN14783-7.16.0.0.pdf
Here is an example of the dates of just SOME of the SDK releases:
7.15.4.0 GA released April 7, 2021
7.15.2.0 Pre-Certified GA released January 27, 2021
7.15.1.0 Pre-Certified GA released December 9, 2020
7.14.3.0 GA released October 14, 2020
7.14.2.0 GA released September 9, 2020
7.14.1.0 GA released July 29, 2020
7.13.9.0 released March 3, 2021
7.13.8.0 released October 28, 2020
7.13.7.0 released August 12, 2020
7.13.6.0 released May 27, 2020
7.13.5.0 released April 29, 2020
7.13.4.0 released April 15, 2020
7.13.3.1 released March 27, 2020
7.13.3.0 released March 20, 2020
7.13.2.0 released February 21, 2020
7.13.1.0 released January 24, 2020
7.13.0.0 released December 13, 2019
Here is just one of those issues:
SWPROT-3888 The workaround for the chip issue RTCC_E205 in the ZGM130s was not 100% safe and could result in end devices missing timer interrupts and lock up.
As you can see some of the issues you may be having with ZWave devices may not always be a Vendor issue. If you are having issues with a device, go to the alliance web page and find its SDK number. Then go to SiLabs website and find the release notes for that SDK.
I wish someone at Hubitat would simply have these issues somewhere in a FAQ.
1 Like
I quick reply to the other part of your response:
SiLabs didn't invent ZWave. They bought out Sigma Designs who had it before them.
Everything involving the 700 Series was all SiLabs and its only been 1-2 yrs with them.
Everything including Long Range is getting better.
SiLabs Zigbee devices have no issues like this.
SiLabs is going to marry Matter, ZWave, Zigbee at some point later this year. They said so in the Matter Conference. Expect some major changes in ZWave over the next 6-8 months.
1 Like
Zniffer is a passive Listener.. you don't join it to a Network. Or in more technical terms, Zniffer exists in Promiscuous mode.
2 Likes
I was very sceptical about hub's Node ID 077.
Today I tried few times to catch a very clear shot(s).
It is I would say 100% repetitive.
All what I did - is simply send sequential On/Off commands to (again problematic)
Node 037. And now I am convinced - the mysterious Node 077 is hub itself.
But why?
And what is more important - is this already a problem or a predecessor for
the potential problem(s) may show up?
Today the communication to this Node 037 is definitely compromised
but so far without any noticeable changes from previous days of stability.
I have had this happen to me - these "ghost routes" seem a lot harder to clear. Mine eventually went away, not sure what I did - maybe re-paired the device that was using it I forget.
