Device type dev: how to access zwave node info?

(I’m always terrified in starting threads asking how to do something. I’d just send the question to support@, but they always respond that I should post here. Then the question inevitably gets diverted into theoretical architectural discussions. PLEASE DON’T.)

@Jim (or whoever would know the answer):

In the code for a z-wave device type, how can I access the information displayed as the “raw description” in the ide device information? (this is also the information used for the device fingerprint.)

There doesn’t seem to be anything (documented) for accessing this information from the “SmartDevice” or “device” classes.

My next hope was that I could send the device a 0102 command (request node info) and get a response, but it appears that the device response isn’t being passed to the device type’s “parse()” function: (I didn’t expect all the info from the fingerprint to be in the response, but figured it’d be a start…)

def refresh() {
(new physicalgraph.zwave.commands.zwavecmdclassv1.RequestNodeInfo()).format()
// zwave.zwavecmdclassV1.requestNodeInfo().format() doesn't work
// the above code, tested with log.debug, does format to 0102 as expected

// however, parse() is never called in response...

Eventually, my intention is a dynamic device type that changes behavior based on the device identifier or supported command classes. (Not all “z-wave switches” support Configuration, and therefore there’s no indicator LED.)

Without any long architectural discussions, is there a way to get the z-wave device information I’m seeking?


Gary, if you see this, just flag it/notify me. I’ll try my best :smile:

Never mind, I see ST wrote the fingerprint for zigbee first, then (sort of) mapped zwave into it.

@duncan should know the answer to your question.

p.s. For long term, I’d be really surprised if a " dynamic device type" would work, but that’s for a different discussion.

Edited to put the docs link back in, look at the bottom of that page for what we’re talking about.

(Message I was originally replied to was edited… it referenced the ‘fingerprint’ section of the “building z-wave devices” documentation)

That’s the information I need, but I need it in code, not in the IDE. Using the dynamic z-wave switch example, I might create a device type with a fingerprint of:

fingerprint inClusters:“0x25”

That’s saying: use this device type code for any device that supports a command class of 0x25 (binary switch.)

Then, from within the device type code, I’d like to be able somehow find out if the device ALSO supports command class 0x70 (configuration) and do something additional. However, I don’t want to limit the device type code to ONLY devices that support 0x70.

Using pseudo code:

fingerprint "supports_binary_switch"

    if (device supports cmd_class 0x70)
        state.configurable = true        
        // device doesn't support 0x70, so set a flag
        // so other functions know it's unconfigurable
        state.configurable = false

[quote=“JDRoberts, post:4, topic:11519”]
p.s. For long term, I’d be really surprised if a " dynamic device type" would work, but that’s for a different discussion.
[/quote]Perhaps. I actually don’t expect what I have in mind to work out even today anyway - but in the process of trying to make it work anyway, I’ll learn more than any documentation could ever give me.

1 Like

You used to be able to do device.rawDescription but due to a recent server change to only load the most important device values by default, you have to do

ready for this?


We’ll look at making that more sensible and then documenting it.

1 Like

I don’t mind a bit of insanity, @duncan. In fact, it makes me feel like I’m at my paying job. :wink:

However, it doesn’t seem to work:

results in:

Is there some other “groovy” type way to get the data? (I also tried device.device.rawDescription() in case it was a method, but got a similar “not allowed” type message.)

Thank you

Huh. Sorry about that. I just tried pretty much that same thing before posting, but maybe my device type had some kind of elevated premissions or something. I’ll have to look into it some more and get back to you.

I was able to use RequestNodeInfo() to query a device (a Yale lock). From looking at the documentation on an older version of the lock, it looks like it responds to normal queries before it is associated, but only returns an abbreviated set of capabilities. I’m guessing a little on this part, since my lock is already associated, but it explains why the raw description is much shorter than the result that I get when securely sending the same command. When I run the command in the clear, I get no result (I assume because it’s associated already).

tl;dr. Try sending RequestNodeInfo securely.

@duncan, any update on this?

Thank you

@garyd9, I just tried this in one of my device types:

log.debug device.device.rawDescription

And it worked swimmingly:

3:11:42 PM PDT: debug 0 0 0x4003 0 0 0 3 0x72 0x86 0x98

I’m 99 44/100% sure that my device type has elevated nothing. I’m no expert, and I don’t know if anything has changed since late Feb when you asked about it, but if it’s still not working for you, maybe you’re using it somewhere that ‘device’ isn’t in scope? I called it from within a command method.

It’s quite possible that they’ve changed it. I’ve noticed that many platform changes and/or fixes remain completely undocumented. :frowning:

Looks like this is not working again…

log.debug device.device.rawDescription


10:01:21 AM: error java.lang.SecurityException: Getting properties on class physicalgraph.device.Device_$$_javassist_13 is not allowed @ line 141