Zwave - non-existent devices in cluser?

I am starting to have have problems with one of my zwave plus contact sensors and decided to try to see what devices it is clustered with in an attempt to understand if it is a range issue.

When I go into zwave details (C-5 hub) and look at the device it shows 12 devices as "in" the cluster. I started to look each of these up on the same page and found:

  • three are GE Jasco switches (furthest possible switches it could have picked)
  • three are battery powered devices
  • six are non-existent devices

"in: 0x5E, 0x86, 0x72, 0x5A, 0x73, 0x80, 0x71, 0x30, 0x85, 0x59, 0x84, 0x70, out:"

Are the six non-existent devices a "problem" that I should be concerned with? I was thinking I would have more actual devices in the cluster to help with routing.

My setup (as it relates to ZWave):

  • C5 hub
  • 66 GE Jasco Zwave in-wall switches (combination of dimmers, on/off, fan, zwave and zwave plus -- probably more than half are zwave plus)
  • 17 contact sensors (Mostly go-control)

Thanks!

You misunderstand what inClusters and outClusters are. They indicate the zwave command classes supported by the device. And not other devices it is “connected” to.

So all your zwave+ contact sensors of the same brand and model will have the same inClusters.

3 Likes

Have a look at this thread, lots of good info:

1 Like

@aaiyar - Thank you, I was hoping I was missing something basic!

@Ranchitat - Thank you. I have a Gen5 Z-Stick and the Simplicity Studio, I will dig into it some more with the info you sent.

Thanks guys!

1 Like

You might find this reference useful.

1 Like

@garrett What about the simple diags.... Replace battery in the contact sensor? (Never rely on battery reporting, it lies)

1 Like

@rlithgow1

Sorry it took me until now to acknowledge this suggestion. I didn't have any new batteries of this type so I had to get some. I installed yesterday afternoon and it's not any different. I'm still missing 95%+ of the events. I also added a plug in zwave plus repeater two days ago as close as I could between my other always powered devices and this sensor.

I'm thinking of buying a different zwave plus sensor to try it. I wish Go Control still had sensors, the non plus ones of theirs have worked so well for me over the years.

Run a z-wave repair after doing this. The trouble with the C-5 is that the z-wave stack doesn't show the path by which a given device is communicating with the controller (hub). Also, typically, once devices pick a route, they don't change that route very easily. The odds of picking a better route rise somewhat after running a z-wave repair.

With the C-7, since the path/route is known, it is possible to unpowered specific repeaters along that route and then force the device to use a different route by running a node-specific z-wave repair.

1 Like

I forgot to mention I did run a repair a few hours after adding the repeater. Timeline basically was Friday afternoon add repeater, Friday evening zwave repair, Saturday afternoon replaced the battery in the sensor with a battery just purchased.

I can certainly try another zwave repair, or do you think it might be worth excluding the sensor and re-adding it while it is in its current location in hopes of it hitting the devices that will be closest to it?

I keep debating upgrading from the C-5 to a C-7, maybe I should use this communication path visibility as an excuse or reason to actually buy it.

Yes.

1 Like

Funny...when I first came to Hubitat I was briefly confused by that as well. :slight_smile:

1 Like

It can take weeks, literally, for new repeaters to pick up devices, even if you do a repair. So don't expect that your contact sensor will immediately jump onto one of the new (or existing) repeaters. The Z-Wave repair should help urge things along, but still is a "watch and wait" game. Excluding and re-adding the device after you add the repeater may help you "get lucky" but I've had "the best" (from a location perspective) repeaters consistently ignored by my devices, frustrating, but does happen.

1 Like