(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.)
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?
(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"
in_some_function()
{
if (device supports cmd_class 0x70)
{
set_configuration_parameters_my_way();
state.configurable = true
}
else
{
// 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.
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?
device.device.rawDescription
We’ll look at making that more sensible and then documenting it.
I don’t mind a bit of insanity, @duncan. In fact, it makes me feel like I’m at my paying job.
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.)
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).
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.
