I may implement buttons differently in the future (use holdable, releasable, etc.) but for now this is how they work. All button events are pushable buttons. It acts like it has 12 pushable buttons.
Button Mappings:
ACTION BUTTON# BUTTON ACTION
Double-Tap Up 1 pushed
Double-Tap Down 2 pushed
Triple-Tap Up 3 pushed
Triple-Tap Down 4 pushed
Hold Up 5 pushed
Hold Down 6 pushed
Single-Tap Up 7 pushed
Single-Tap Down 8 pushed
4 taps up 9 pushed
4 taps down 10 pushed
5 taps up 11 pushed
5 taps down 12 pushed
Trying it out. Not much time this morning but maybe I will get to try some this weekend. In any case it will only be the basics as ours is mounted without any actual light to control yet, but that still leaves all the status LEDs and button presses.
Dimming levels are reported correctly from switch pressing and when set on device page.
Setting initial status LED when load off works.
Setting default status LEDs color works.
Individual Status LED control does not seem to work. Neither individual LEDs or all, tried a couple colors, with and without blinking. None of them happened when the Set Status LED button is pressed.
This seems to be working for me. I found a bug where I was only flashing 4 of the 7 LEDs if I chose to blink them though. That's fixed and in github already.
Would you mind sharing the MSR from the device details section? Also, perhaps a screenshot of the set status LED parameters you are sending?
Also, if you wouldn't mind turning on all the logging options in the driver and then performing the action and sending a screenshot of that. If you're uncomfortable sharing logs then redact what you need or we'll cross that bridge if we can't figure it out from the first two requests.
I am getting the same issue as @snell is. If I try to set a status led from the device details page, i get the following error:
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:05:48.896 pm [error](http://192.168.86.5/device/edit/994)java.util.IllegalFormatConversionException: x != java.math.BigDecimal on line 476 (setStatusLed)
If I try using a custom command from RM, I get the following errors:
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:07:09.741 pm [error](http://192.168.86.5/device/edit/994)groovy.lang.MissingMethodException: No signature of method: user_driver_codahq_hubitat_HS_WD200__Dimmer_1090.setStatusLed() is applicable for argument types: (java.lang.Integer, java.lang.Integer) values: [7, 1] Possible solutions: setStatusLed(java.lang.Object, java.lang.Object, java.lang.Object) (setStatusLed)
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:07:09.664 pm [error](http://192.168.86.5/device/edit/994)groovy.lang.MissingMethodException: No signature of method: user_driver_codahq_hubitat_HS_WD200__Dimmer_1090.setStatusLed() is applicable for argument types: (java.lang.Integer) values: [7] Possible solutions: setStatusLed(java.lang.Object, java.lang.Object, java.lang.Object) (setStatusLed)
Oh. Now that's fun. Are you leaving the blink parameter off somehow? I marked it required so the UI shouldn't let you do that BUT.... RM and other ways of calling commands might.
Oh, RM definitely is leaving it off. It's a bug but it's fixed in the current beta built. RM was evaluating parameter's existence based on "if (parameter)" or something similar.
if (0) is false but it should be true so I think bruce changed it to if (param != null)
*edit: Adding the .toInteger() can't hurt anything. I'll put it in the driver to make things more safe. I don't need it in my firmware version but now that I think about it I'm not sure why. Most parameters are passed as BigIntegers. Maybe it's a UI thing depending on what browser is calling the command.
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:05:48.896 pm [error](http://192.168.86.5/device/edit/994)java.util.IllegalFormatConversionException: x != java.math.BigDecimal on line 476 (setStatusLed)
I had a custom driver similar to yours and I had to make the parameters String because Number was evaluating a 0 as a non-number. Supposedly that was fixed a while back (maybe not).
Then I had to convert the string to an integer within the method to keep from getting an error.
Weird thing is that it successfully changes the indicator light, but throws the error.
I was referring to HE (hub) firmware. That error happens before the command goes to the dimmer firmware so it's not a HomeSeer issue. It has to be a difference in platform firmwares.
Can you check that changed I just pushed to github? I'm assuming your line 476 was still 476 from github.
Annoyingly the RAW URL content refreshes after the commit happens. If you jam ctrl + f5 it will eventually come through. I can see it was changed though by looking at the non-raw version and the commit messages/log. I guess that's the drawback of relying on the import URL for real-time changes. Do you use the import function? Love it.
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:49:01.318 pm [error](http://192.168.86.5/device/edit/994)java.util.IllegalFormatConversionException: x != java.math.BigDecimal on line 476 (setStatusLed)
Also noticed this after I updated the driver. Never noticed it before:
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:45:54.670 pm [warn](http://192.168.86.5/device/edit/994)Parse returned null for command null
[dev:994](http://192.168.86.5/logs#dev994)2019-06-07 01:45:54.186 pm [warn](http://192.168.86.5/device/edit/994)Parse returned null for command null
Okay, I think I know why it's working for me but not for anybody else. State saves variable data types so if my driver and another driver is storing data to the same state variable it will keep the data type from the previous driver.
I think to fix this I'll add some cleanup to my driver. What driver were you using prior to this? I'll install it or switch to it, do some monkeying around and then switch back to mine and catch all the problems.
Built-in HomeSeer WD200 Dimmer driver. A while back I used a ported version that another user had created. I'll try and find it as I have not used it in quite some time.
