FAQ: How does one check if a zwave device is in active or passive mode

Some devices like the CT-1xx thermostats have the ability to be configured in active repeater or passive beaming/listener mode.

I’m trying to figure out if there’s a tool or a place in the IDE one can use to see what mode the the z-wave device is currently operating in (really to look to see/debug if a device is changing modes after a power failure or battery failure).

@tyler @slagle @unixbeast any suggestions?

Or even get a list of devices currently in repeater mode

We don’t have this kind of tooling at the moment. There are hopes to have something someday but there are more pressing ZigBee and Z-Wave improvements that are taking priority.

Okay any tricks one can use to query a device or see some signature etc? tagging @duncan also

Are you sure this isn’t just an issue of being battery powered (passive) or mains powered (repeater)?

That would be standard Z wave and I believe that’s how the CT 100 works. If you use the C wire, it is paired as a repeater.

Technically only partially correct. According to the documentation adding the C wire isn’t enough, the device must have the C wire connected WHILE associating / pairing with the hub. If during the pairing process it doesn’t have the C-Wire it will revert to passive mode. However the device itself doesn’t indicate anywhere whether it’s in active or passive mode.

Recently I had a power failure and the battery on the thermostat was dead. So now I’m wondering when it came back online did it switch to passive mode?
Consequently also if the switches to battery mode after being paired with C wire connected does it switch to passive mode and conversely when it goes back to mains does it switch back to active mode.

so see this I’m trying to figure out if one can query the device, or look at something in the ST ecosystem to figure it out.

That’s because the device is defined by the network as being either a passive device or a repeater at the time of pairing. I’m not aware of any way to change it after pairing.

So if it’s on mains power at the time of pairing, it will be identified as a repeater. ( I have updated my post above to clarify the process.)

If you’re just asking in general, not for the specific device, because I rely on text to speech these days I can’t read the code examples for SmartThings, but if there’s a way to issue a 0x41 command (get node information) then the device should tell you whether it’s a repeater or not. You probably have to parse the response, there’s a lot of data packed into it.

1 Like

So I tried issuing the NodeInfo command using

zwave.zwaveCmdClassV1.requestNodeInfo().format()

I got no response from the thermostat. Any ideas?

I haven’t checked this, but in theory if the device is a repeater, the new Raw Description format will start with zw:L for listening, otherwise zw:F for FLiRS (beamable).

1 Like

What’s the difference between

zw:F and zw:Fs

The lowercase ‘s’ means it’s securely included.

http://docs.smartthings.com/en/latest/device-type-developers-guide/definition-metadata.html#z-wave-raw-description

2 Likes

I wanted to do this from code.

After some failed attempts at getting a nodeInfo report:

cmds << zwave.zwaveCmdClassV1.requestNodeInfo()

… which doesn’t return anything.

I managed to get the info from device.rawDescription (which now seems to be working again (?))

switch (device.rawDescription.tokenize(" ")[0].tokenize(":")[1]) {
	case "L":
    	log.debug "Device is listening, not secure"
        break
	case "Ls":
    	log.debug "Device is listening, and secure"
        break
	case "S":
    	log.debug "Device is sleepy, not secure"
        break
	case "Ss":
    	log.debug "Device is sleepy, and secure"
        break
	case "F":
    	log.debug "Device is beamable, not secure"
        break
	case "Fs":
    	log.debug "Device is beamable, and secure"
        break
	default:
    	log.debug "Unknown (probably old-style fingerprint)."
}

Or:

private isListening() {
    return device.rawDescription.contains("zw:L")
}

However, this method only works for devices that have been joined after the new fingerprint format was introduced. :expressionless:

1 Like

Curious how do you want to use this information in the device handler? I can think of a few uses for hybrid devices which support multiple modes to change the interaction methodology but how would you want to use it?

TL:DR: some devices vary their behaviours (and their NIFs / Fingerprints) depending if they are power or not when they are included into the network. This affects batteryReports, wakeUpNotifications, and the function of association groups. I want one DTH to work regardless of which mode the device is in.

2 Likes