Zwave.parse question / error

So I am working on porting over the Qubino RGBW controller device handler from ST. I am getting a weird error I don't understand.

Can anyone shed some light why I am getting that error from the zwave.parse command? Am I just missing something simple (happens a lot), or is it a platform issue?

I am getting a zwave message description like:

zw device: 49, command: 3304, payload: 00 57

In my def parse(String description) event, when I do this:

def cmd = zwave.parse(description)

I get this error:

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'short'. Try 'java.lang.Short' instead on line 717 (parse)

What version of switch color does that device support?
Just off hand without specifying the command class version we will attempt to parse it with version 3, which probably is expecting more payload bytes...

1 Like

You know that the built-in Fibaro RGBW (beta) driver works with the Qubino RGBW, right?

It throws 3 errors (a red, a blue, a green) but they are harmless, apparently.

1 Like

@csteele You are right. The fibaro driver works OK. No scene support, no 4 switch modes, a few errors, etc. I played with it all afternoon. That is my fallback.

@mike.maxwell That's probably it. I figured it was something silly I missed. I think the device supports V2. I'll play with it some more.

You can pull the class versions using the basic zwave tool...

I just did that, it is v2.

Specifying V2 cleared the error. Can't believe I missed that. :frowning:

2 Likes

@JasonJoelOld Any updates on the Qubino RGBW driver you were working on? I'm debating porting the ST driver as well but figured I check in to see your progress. Thanks in advance for your time and help.

My qubino device died after only 10 days... So I never finished it.

That's a shame! I installed 2 a month ago and they're going strong. Any final words of wisdom before I embark on my attempt?

@JasonJoelOld

Where do you make the change to specify V2? I have the Qubino and have that same error in the logs.

You specify command class versions in the zwave.parse command. Here is an example from one of my thermostat drivers. The numbers after the colon for the command class is the version:

def map = createEvent(zwaveEvent(zwave.parse(description, [0x20:1, 0x31:5, 0x40:3, 0x42:2, 0x43:2, 0x44:4, 0x45:2, 0x59:2, 0x5A:1, 0x5E:2, 0x70:1, 0x72:2, 0x73:1, 0x7A:3, 0x85:2, 0x86:2, 0x98:1])))

If you want a quick list of what most of the command classes are:
http://wiki.micasaverde.com/index.php/ZWave_Command_Classes

There is also a zwave command list in the SmartThings documentation.

Assuming you are getting the error on zwave command 33, you would need something like 0x33:2 in your zwave.parse.

I just get this error:

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'short'. Try 'java.lang.Short' instead on line 785 (parse)

You said in an earlier comment:

Specifying V2 cleared the error. Can't believe I missed that.

Just need to know where you did that.

I tried this on line 785:

def cmd = zwave.parse(description, [0x7A:2, 0x25:2, 0x59:1, 0x85:2, 0x70:1, 0x33:2, 0x33:2, 0x26:2, 0x73:1, 0x5A:1, 0x72:2, 0x86:2, 0x5E:2])

But now I get a bunch of new errors

What was in the zwave.parse line before you changed anything? I would first try to just add the 0x33:2 and change nothing else...

Also, if there is no color v2 code section, you will need to make one. An easy way to do that is often to edit that section of the existing code changing the version number.

Every time you change the command class version being used, you need to have a zwave handler for that specific version. Look through your existing driver and you will see what I mean - most/all of the zwave handlers have version numbers in them.

And, also, the zwave.parse is almost always at the BEGINNING if the driver, right after header and parameters. And there should always already be one in an existing driver. So you comment that you put it on like 785 is very troublesome.

@JasonJoel

Are you not the same @JasonJoelOld that replied earlier in the thread? Just wondering, as that Jason said he changed something to solve the issue and I am wondering what was changed.

I am / that is me.

I don't remember what I changed as my device died a week later so I never ended up using it. But based on what I wrote above, I would assume I put 0x33:2 in the zwave.parse, then changed the subsequent code for those classes to be V2... Easy to tell if you need to do the 2nd part, as if you only do 0x33:2 and don't have the right handlers below it will spit out an error with the name of the handler it was trying to find in the code... :wink:

I'll look and see if I kept the driver I was working on around or not. If I did I'll be happy to share it.