Off-topic rant about security

My experiences as a recent (~6 weeks?) convert from Smartthings:

So I recently migrated ~90 Zwave devices from Smartthings to Hubitat. And then after that, I've been replacing a lot of first-gen Zwave devices with Zwave Plus & S2-capable devices (shout out to Inovelli & their Red Series Dimmers). So I've spent a lot of time fighting with Zwave inclusion/exclusion issues.

When it acts up, I experience:

  • Intermittent behavior wherein Hubitat simply doesn't find the device
  • Intermittent behavior wherein Hubitat includes the device, but never offered me S2 Authenticated options. This requires me to exclude and then re-include (trying again).
  • Intermittent behavior wherein Hubitat is in exclusion mode, but doesn't find the device.

I seem to have the best luck if I first do an exclusion. If Hubitat immediately finds/excludes the device ("Unknown Z-wave device removed"), the inclusion process run immediatley after will find the device about half the time. Of those instances, I'll only get asked about S2 options half of the time. So it usually takes me roughly ~3-5 exclude/include cycles to get an S2 devices hooked up and connected S2 Authenticated.

If Hubitat, after repeated (failed) exclusion attempts, absolutely positively will not find the device I'm trying to exclude, I'll try the shutdown/unplug/re-plug process that I've seen suggested on these community forums. After that process completes, the first exclude/includes almost always goes perfectly. Sometimes I can get 1 more to go smooth before I'm back to the "Try, Try Again(tm)" behavior I outline above.

As I said I've only been a Hubitat user for ~6 weeks. I think I started on build .141, and I've been accepting the new ones as they've come along -- so I think that puts me on build .148 at the moment (Dec 1, 2020). I don't feel like the behavior has changed amongst the 3 or 4 builds. I've had these struggles from the get-go.

If you haven't already, make sure your Inovelli switches have the most recent firmware. I had a black series switch that was pretty much wrecking my Zwave network and since I upgraded the firmware, it seems OK.

Thanks for the suggestion.

I just recently bought the switches, so they all came with the newest version (1.48, I believe?) on them.

(That said, my issue is not just with Inovelli -- having it with contact sensors, Aeotec Trisensors, etc.)

Check your past logs for zwave busy messages. If you see them then do a safe shutdown and pull the power for a minute.

This doesn't address your larger problem, but I do have a suggestion to simplify your ongoing exclusion/inclusion activities a little bit. You might consider joining your devices w/out security - uncheck all boxes in the Security dialog that appears. Many of us (myself included) don't feel the small risks are worth the hassle of finding/ tracking S2 codes per unit, particularly when going through problems like you are.

Totally a personal choice, obviously, but joining w/out security will make things a little easier to mange.

3 Likes

Good call, yes, I always start to get Zwave Network Busy messages when the problem occurs.

There appears to be two ways I can trigger this behavior:

  • Try to include more than 1 or 2 devices (will trigger immediately), or
  • Wait 4-12 hours (haven't figured out the timing yet) and it'll happen on its' own

As I outlined in another thread, what specifically happens is I'm unable to tx Zwave messages from the hub. The hub continues to rx Zwave messages, such as switch presses, motion sensors, contact sensors, etc.

Related: Since the upgrade to 2.2.4.158, I can't seem to include S2 Authenticated devices as such. The pop-up that appears only has S2 Unauthenticated checked, and if I manually check S2 Authenticated I get a complaint about key mismatch (although I was never prompted to input the key).

I'm thinking about putting a reboot on a 6 hour timer or something, but if I have any motion sensors triggered when rebooting they get out of sync until they next detect motion. So then I have lights all over the house on that aren't supposed to be.

-jd

Those messages typically pop up when there is a failed pair but a bunch of stuff can cause it. Weak mesh with a bunch of unack's or whatever.

1 Like

This is selected by the SDK's S2 bootstrapping.. If a device does not support S2 Authenticated, it will not be selected and selecting it would be ill advised.. You can always uncheck things, but adding checks to unsupported security mechanisms will most likely end up in a failed inclusion

2 Likes

Would it be useful, diagnostically, for me to use my Zniffer to capture all Zwave traffic from hub startup until the issue triggers? Would you or anyone here be willing to review it? I confess I know HOW to capture the data, but don't really know how to interpret it per se.

I don't think I have a weak mesh since when the issue isn't occuring I don't have problems with anything Zwave-based, but ...

-jd

Well, it's a little more complex than that.

These are Aeotec Door Sensor 7s. I have 12 of them already deployed, and a handful more waiting to be deployed. The 12 I have already deployed are S2 Authenticated, so the devices are clearly capable of it -- but since the upgrade to the 2.2.4.158 build I can only pair them as S2 Unauthenticated.

I don't really get down into the packets. That's more @bcopeland gig. I would check to see that all your devices have something listed in the clusters column on the settings, zwave details page though.

Maybe.. but if it's not selected.. then this part of the S2 bootstrapping may have failed.. In any case see above..

After all the failed/partial inclusions the other week, I did have a ton of blank/dummy entries in the Zwave device list -- I removed them as failed devices using an Aeotec Zstick Gen 5+ paired up as a secondary controller and they no longer appear in that list.

I'm going to try getting rid of a few devices oddball devices I don't really use (GE Embrighten outlet, Aeotec Smart Sensor 6) because if no one else is having these pains I'm starting to think I must have a device that isn't playing nice. I saw chatter in another thread aobut a specific Zooz device causing issues similar to this. I don't have anything Zooz, but maybe something else is causing a simliar issue. Hoping it's not Aeotec in general, though, because I now have a ton of their Gen 7 door sensors and threw away all the packages. :slight_smile:

Thanks for your insight.

Ok, that adds up. I'll try rolling back a build or two and see if I get the previous behavior. Thanks!

you might also try pairing them with everything unchecked and see if that clears up your error. Seeing as it sounds like a bootstrapping issue on pairing.

This is handled by the SDK and not hub code.. The hub code just presents what the SDK has reported.

An[quote="bcopeland, post:1350, topic:46870"]
This is handled by the SDK and not hub code.. The hub code just presents what the SDK has reported.
[/quote]

Hmm, ok. Maybe it's two bum devices, then. I'll crack open some of the unboxed sensors as see if I get anything different. Thanks again.

1 Like

Our “security experts” may cringe at this :joy:.. But I actually most of the time unselect S2 authenticated out of laziness (no pin needed).. Except of course for ring devices, which are very temperamental when they don’t get the grants they want.

4 Likes

Or w/no security. (OK, I'll stop harping about it.) :wink:

1 Like

I have a ton of Zooz, and the only trouble I've had was with the 4-in-1 sensor paired with S0 security. Do you have any S0-paired devices? My understanding is there's a lot more network chatter/overhead with this particular security scheme...

Edit: ok, not the only trouble... but the 4-in-1s were the only devices that ever hosed my mesh and actually took the whole thing down. My issues with the ZEN30 double switch kept themselves neatly isolated to the switch in question.

1 Like