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...
@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.
@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.
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:
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.
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.
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 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...
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.