This update did ultimately fix both of my problems
I can now set led colors as before with the HE driver, the withdrawn one and the new one
I now see push 1&2 and double tap 1&2 with the HE driver. I see all the various push events I expect (double, triple and quad tap) with @bertabcd1234 driver.
It seemed like it did not work at first, but I rebooted and hit configure on the devices and that seems to have done the magic for me.
Thank you for these fixes, this round of “Rob automates the house” all kicked off with me trying to expand the double tap to start the kiddos nap playlist and turn on the white noise to accommodate a 3 tap for kid number 2 during my paternity leave. He’s 10 months today, but I’ve finally done the thing I’ve set out to do. On the way, I’ve swapped from smart things to hubitat, re-layed out my whole zwave network and added about 15 devices and automations.
Huh. I've rebooted 2x and hit configure, but I still see the same error when using the control on the device screen:
errorjava.lang.NumberFormatException: For input string: "magenta" (setStatusLED)
dev:182020-11-25 11:00:16.629 pm debugled:magenta color:5 blink:on
dev:182020-11-25 10:59:56.410 pm
Like @rgkaufman I had to reboot and click Configure in the Device page. Once I did, I can successfully change the statusLED from the Device page but am unable to set the statusLED via a Rule. I tried with string "2,1,1" and "2,Red,1". @bcopeland Is the string format correct?
Ah, I see. With the HE driver I do see what you are describing. Both the codahq driver and the bertabcd1234 driver use a number and not a string for that value. The codahq driver does the status leds right at the moment, the bertabcd1234 driver appears to turn the whole thing white no matter what you put in or which led you target. All of them do the buttons now in my testing. That makes the codahq driver the complete one at the moment. I know you can get a copy of it from GitHub (that’s where I got it) but it’s not clear to me what the etiquette is for someone taking over maintenance or linking directly to a copy.
@rgkaufman... My selections are slightly different than yours (I'm using the HomeSeer WD-200 Dimmer driver from HE).
When I was running v2.2.3, my options where like yours but now in v2.2.4 it appears it only shows the colors without numbers but not sure if that has anything to do with the problem. I tried both in my rule and both failed (as you can see from the log in my previous post)
I don't have one of these and just wrote that one trying to help someone else who did, but I'm curious to know more about this problem. What values are you using for color? My driver just does the same numerical mapping HomeSeer does: 0=off, 1=red, 2=green, 3=blue, 4=magenta, 5=yellow, 6=cyan, 7=white. I can add a String (versus numeric) alternate to this command so either "Hubitat"-format (color string name) or HomeSeer's raw numeric values would work, but I guess neither would if this won't, so I'm curious where the problem lies.
...if anyone wants to try helping me figure this out, since I don't have one of these devices. Between switching drivers, it might also be a good idea to switch to the plain "Device" driver and run the "Delete All States" command, then do the for-real switch (HomeSeer's driver in paricular saved some things here that ruined LED calculations for both their own and other drivers that used the same state variable name).
That's me! I'd play around more if I had one of these devices. I'd definitely recommend the "delete all states" thing above if you haven't tried it (glaring bug in HomeSeer's orignal driver if you ever used it). But I'm sure Bryan will get Hubitat's sorted out soon enough.
The codahq driver would probably work on the C-7 if you pair without S2 or S0; I'm guessing it's old enough that Hubitat didn't have the built-in Z-Wave secure encapsulation methods available for driver authors yet.
Well, I don't know what refreshed, but both of mine are now working from the Device Menu controls without error. The debug log entry has the correct color/LED number specified, and the switches are lighting up correctly.
Not yet (just installed last week, going slow and letting the mesh settle).
But others reported that their drivers were working under some circumstances, and the debug log clearly showed a bug in the command, so I assume the automated rules will work.
Still trying to decide if I will go rule machine or try and bring Webcore over.
I reverted back to the build in driver.
I used a driver titled "Clean Device" by BoristheCat. It simply clears all state values, deletes any children and clears any scheduled events.
After this I could set the LEDs from the driver but my RM rule does not work yet. I'll have to check if there may be a spelling or capitalization difference in my RM entries.
Using the built in HS-WD200 driver I found I had to modify my setStatusLed to setStatusLED. Not sure which driver I created this rule in but the custom command was wrong for the built in driver.
No not now since I upgraded to the latest hotfix (v2.2.4.148. When I attempt to set any of the statusLED lights, I get the old error of:
2020-11-27 09:12:04.061 pm errorjava.lang.NumberFormatException: For input string: "red" (setStatusLED)
Between switching drivers, it might also be a good idea to switch to the plain "Device" driver and run the "Delete All States" command, then do the for-real switch (HomeSeer's driver in paricular saved some things here that ruined LED calculations for both their own and other drivers that used the same state variable name).
