I know @spalexander68 posted all the general info, but here is what I had earlier today, with screenshots I just took of what I was setting and the log from earlier. My Hubitat itself is version 2.1.0.123, and the WD200+ is 5.9 with MSR 000C-4447-3036.
K, I just posted an update. Two things to note:
- indicatorWhenOff (and all of the indicator methods) are not implemented. You will get errors when you try those. I think I will take them off because these devices do not follow the HE indicator rules. For example, if you turn the dimmer to status LED mode it doesn't show any indicators based on load. It ignores load completely and just shows the status LEDs. If you set it to normal LED mode then it shows the bottom LED on for off AND for lowest level dim. So... I could program around that but at the end of the day I don't want it to act like the HE status indicator because it's cooler than that. At any rate, for now all of those OOB status indicator command associated to the status indicator capability are not implemented.
- Second note is that somehow your guys' HE hubs are passing Strings to those methods. That is either a weird browser caching issue (what browser are you on?), a HE bug that it is not replacing the data types from the old driver (The oob driver used Strings. I'm not.) OR you have an old command in RM that is still passing String data types. Can you help me track down which of those is happening?
I have tested your updated code on Edge and Internet Explorer. Neither of those browsers worked at all.
I cleared the cache in Google Chrome and it through the error. I installed FireFox and tried it and it threw the error as well. So I don't see how a browser caching issue could be the culprit.
While testing, I am not using RM commands at all to set a status LED, just the device details page.
I'm on the latest release version of HE. I'll do some more testing later.
Using Chrome as my browser, "regular" Chrome was used this morning from my desktop. My phone (right now) uses Chrome Canary.
I have no Rules using the WD200+ at this time.
Imported the newest version. I am remote, so I cannot see if the LEDs worked, but the log shows an error. Screenshot attached.
Okay, both of these are very peculiar. I'm going to force the command to only accept BigDecimals because I want to understand if the problem is what is passed into the command or what is happening once the values are in the command. There is an updated version now. I appreciate your flexibility on this and helping to work through the issues.
No worries at all, you are helping us by making this driver so the least I can do is help out when I raise a possible problem.
Imported the new one, saved the device again to make sure it got the latest, set the status LED, and got an error again.
Can I PM you something to try?
Sure.
I'm convinced this is not occurring in the driver.
Any idea what could be happening here? We're seeing an illegalFormatConversionException with variable 'x' but there is no variable x in that line. There is no variable 'x' in the driver. Is this another weird Groovy nuance? What does "zwave.configurationV2.configurationSet" try to do with those parameters once they come in? Does it cast them in a print statement or anything like that?
No nothing like that , a parameter with a size of one is a byte, 8 bits a big int and is 64 bits.
Configuration value is an array of bytes, scaledConfigurationValue takes a big int, use that instead. But none of these params in setStatusLed need to be big ints, nor typed for that matter...
None of the parameters the device supports is larger than 1 byte I don't think. I'm not making them BigInteger but that's how they come in from the UI page so I'm just not casting them or treating them in any way special because when I did testing I could pass the BigIntegers to configurationValue without an exception. Did one of the newer hub firmwares support a cast down from BigInteger if one was passed to configurationValue? I can't reproduce this problem they're seeing.
2.1.1 has a change to scaledconfigurationvalue so it gets treated as a signed value as it should. I don't beleive any changes were made to configurationValue
1 Like
Okay, sounds good. I'm not sure why they are seeing the issue and I'm not. Either way, I think I'll just convert the BigIntegers to int with intValue() and call it a day. Hopefully that should fix anything because at least they're castable as unwrapped ints and whatever is happening underneath I'm guessing is dealing with unwrapped int or byte instead of wrapper classes.
Alright, @snell and @spalexander68. I pushed an update. Let me know if it fixes the issue, please.
1 Like
Appears to have fixed the issue. I'll continue to monitor it. Thanks for your help!
1 Like
Fixed it for me also. The LEDs operate normally now, so I get to play around even more. 
I still can't use a custom action to set the LEDs but I will keep messing with it.
I'll try with RM and let you know how it goes. It works with my fan driver but my fan driver didn't force BigInteger in the method header.
If you don't know or care what that means then try to make your rule's custom action look like this:
Choose int parameter types (they may be called number. i can't remember right now). If it doesn't work then it is likely due to the RM bug that was just fixed recently when passing parameters with the value of 0. If it works when you pass non-zero aka if you tried 5, 1, 1 and it works just know that bug will be fixed very soon with a firmware update.
Nope, it didn't work. I'll wait until the next release.
Thanks again!
1 Like
I tried RM and it's working for me. Are you getting anything in the logs?
