Not off to a good start

correct

To elaborate -

For a zwave device: Go to the device detail page for the device (click on the device in the Devices page on the hub), scroll down near the bottom and look for "inClusters". If the 1st one is 0x5E it is zwave plus - it it isn't, it isn't.

2 Likes

Most excellent t information!!!

Using this, I've got 8 (out of 63) Z-Wave devices that are not Z-Wave plus. Is it worth upgrading them? Like the OP here, I've had lots of problems with the dependability of scenes and groups so I'm always looking for anything that will make my network more dependable.

No right or wrong answer there. In my OPINION, yes it is worth replacing them, and here's why:

The main PROs for replacing them:

  1. Automatic status updates from device to hub without polling the device manually/periodically
  2. Up to 2.5X faster ZWAVE message data rates (40kb max vs 100 kb max). This applies both to the new device AND for any other zwave plus devices that happen to be routing through the older non-plus device (if any are)
  3. More resilient mesh in that devices can send out Explorer Frames if they can't communicate to the hub, and re-route their messages based on that info (alleviates most of the need to do manual zwave repairs)
  4. Sometimes new/more/better features you didn't have before (default ON brightness settings, programmable LEDs, multifunction devices like Motion Dimmers/Switches, etc).

The main CONs for replacing them:

  1. Cost
  2. Should verify that the new device can do what your old one did (almost never an issue though)
1 Like

Would setting up groups and turning those off rather than the devices directly help with reliability?

Welcome to Hubitat and the community here. I read this thread and found numerous similarities to my recent experience. I migrated from Vera many MANY years ago. At that time I migrated from Vera to a Hubitat C-3 (ancient now) hub. Recently (a few months ago), I migrated from C-3 to C-7. At that time I rebuilt my mesh which is the only way in that migration case. Following threads on this forum I had a painless process. But then I started seeing the "never completes" or "forgotten devices" phenomenon when calling scenes. What was even more baffling is that adjusting individual devices from their device pages, dashboards, or apps (rules mostly) would be perfectly smooth and instant. But scenes? Failed nearly every time but it would be only one device out of a 20 and often different devices that were missed.

Nothing seemed to fix it and I did try "everything." Now I have a perfectly performing system and ZWave events seem to be instant and simultaneous. I had to rebuild my ZWave network one more time but this time without any security. No S0 nor any S2 in any of its forms. I did this at first as an experiment because it was the only difference between my C-3 network (which worked perfectly) and my C-7 network (which was disappointing). If you have a majority S2 included devices I suggest you try this. It is not a permanent solution for me as I would like the security one day when I can use it. Certainly if I had any locks or other devices for which I would want security then I would include them with S2. But for dimmers? Switches? I gave up so that I could return to smooth operation.

Previously my experience has been that groups make it worse. I see in the latest release there's an option for a delay in groups. I assume this is a delay between commands to the devices in the group. I'm anxious to play with this and see if it helps. Fingers crossed!

I've tried to do that but found that some devices (e.g. Aeotec recessed door sensors) just won't revert out of S2 no matter how many factory resets or power-restarts I do. VERY frustrating.

Anyone else had this problem?

No, and Iā€™ve got 4. Are you doing classic inclusion when you re-include? Make sure you donā€™t have a SmartStart QR scanned in to your app.

Much thanks to the welcome, very glad to be here! I did see a similar post as well (I think maybe the same thread as @nclark mentioned with the ZSE40 4-in-1 sensor?) - and thought this very well may be something to smooth things out. I hesitated for 2 reasons: #1 I just added all these devices and it would be super annoying lol and #2 I leaned hard into Hubitat because from what I've heard compared to Vera, everything actually works. Including advanced configuration features that very well might be lost if I include without the security... not sure here, perhaps some smarter than I can weigh in. It would be pretty disappointing to think that getting the newest and best hub and the newest and best switches using perfect drivers (almost everything was generic in my Vera) and alas, same thing - unreliable performance and/or limited features.

I have never heard of, or experienced, a loss of configuration features when pairing without security. Don't think you would lose any features if you pair without security. But like you said, perhaps someone smarter than me could clarify this statement.

There was a time, from at least August 2020 until mid December 2020, when Ring Alarm Extender Gen 2 didnā€™t seem to report power source change events (mains to battery) unless paired S2. Something seemed to change about mid -December, perhaps one of the Hubitat firmware updates, that fixed that. Nothing changed on the Ring Extenders, so it must have been a firmware update.

1 Like

If you do classic inclusion and uncheck all the boxes, yes. It takes a bit of practice to do the inclusion dance, though. I have 6.

1 Like

So I have continued digging. Some updates:

  1. Excluded the Zooz 4-in-1
  2. Re-created my coming/going based on Life360 presence. Essentially I have presence dictate mode based on time of day (mode mgr) and then have RM that activates scene based on mode. (day, day vacant, evening, evening vacant, etc.)
  3. Run several repairs and removed a random ghost node that shows up here or there,
  4. Tested presence coming/going many times. Day arrival is minimal (<10 device actions) and Day Departure is pretty complete (basically everything gets a command to turns off) and I'm noticing these debug messages in the logs for departure on some of the Inovelli fan/light combo switches.

Any ideas on what to try next? Side note, I've emailed support and apparently that's not monitored... :-1:

This is received by support if you received a ticket number. You are asking a question that to me looks like a device issue. Hubitat support does often help wherever and whenever they can, but do not "support" devices. Never have, despite them often lending a hand with what are really device issues, not an issue with the hub itself.

What is device 152? Click on it and look in the list at the top of your logs please.

It's one of the Inovelli Fan/Light switches (LZW36). I removed all 4 from the scenes to see if they were tripping up the others, but scenes continue to not complete.

And understood regarding the support - but my email to support was about multiple devices not receiving commands during scene activations and then zwave was becoming unresponsive to other devices and only option to get working was a full power cycle (reboot didn't fix either)

I have two of these and don't have that error. Have you updated its firmware? Current is v1.36

Also is this the built-in driver or the Inovelli driver?
Have you also tried excluding and re-including it without security (you'll want to do that anyway for the firmware update if it needs it).

I have found these seem to sometimes need a power cycle by pulling the air gap switch at the bottom before Exclusion or Inclusion will work properly. Don't use SmartStart with them. Join via discover devices and when the security window pops up on screen, uncheck everything.

I have only ever included things through what I think folks are referring to as classic. Coming from Vera, it was painful and slow and restarted after every device. Classic inclusion here is light years ahead ha.

But I'm quoting what you said about the security bc yes these default to at least one class of security and most of the zooz switches did as well. And you're about the 3rd mention of security being a possible cause. Is there any reason to ever include them in available security classes? Is that just so someone can't hack into my network from my front yard? lol :crazy_face:

If this is really suspected as cause... I might as well factory reset everything and start over which freaking blows for so many devices.

I'm not suggesting it's the cause. Just looking at what I have on two switches that don't give the error, and that's one difference. Really I would just never put security on a light switch if I don't have to. S2 is much much better than S0, but none is always going to be better for a light. What's the risk in not have a light securely joined? I can think of none.

You didn't mention if your LZW36 firmware is up to date. This would be the other reason you'll want to join it without security. The firmware update is excruciatingly slow with security enable. I'm talking an hour for 5% progress is what I saw when I tried it on both switches. But with no security, each updated completely in an hour.

Apologies, you're right. I have never actually updated firmware on any zwave device (it wasn't possible in Vera and I'm only 2-3 weeks in with my C7. I can try updating but will need to look up how to even start. If I get results like you mention, I'll just exclude them all and re-include. This one specific device that was throwing these errors consistently is actually within 5-10 ft so might be quicker than usual. I'll report back, thanks for the suggestion!