Thanks for that. I’ll start toying with it again
I knew it wasn’t DBC related. But did kinda figure you might have an answer.
Regards.
Mac
I was setting up a pico remote with 10 button presses and got an error with button 3’s 10th iteration (colour bulb, each press is a different one). Any ideas?
2020-10-10 20:34:29.778 errorgroovy.lang.MissingMethodException: No signature of method: java.lang.String.right() is applicable for argument types: (java.lang.Integer) values: [1] Possible solutions: with(groovy.lang.Closure), length(), print(java.lang.Object), print(java.io.PrintWriter), getAt(int), getAt(int) on line 170 (pageButtonConfig)
Thanks for the report! (It was an error converting "10" to "10th" for purposes of displaying the number of button actions it takes to get to that particular configuration.) I've fixed this in...
Version 2.1.2: Minor bugfix for display of action numbers >=9. Available on GitHub (see first post) or Hubitat Package Manager.
1 Like
Ah! Good to hear it was a quick fix!
I have converted quite a few lights to bulbs controlled by buttons (hue Pico Remotes) instead of switches and I really adore how your app works! It is absolutely awesome! Makes the light super easy and intuitive to control!
Thanks! Sounds like exactly what I wrote it for! 
(I use it with a few other devices, but Picos are what I had in mind, and I missed both the behavior of Hue Dimmers on Hue as well as not having to specify the lights for every single button/event.)
1 Like
Hey! I was hoping for some assistance.
I have a IKEA Tradfri Smart Plug that is not visible to the "Select lights to turn on and dim" dropdown, but it is visible in the "Select lights to turn off" dropdown. I suspect this is because I cannot dim a plug, but I would still like to be able to map it to a button (simply). Is there something I can do to add it here? Or perhaps this is a feature request?
Thanks, and keep up the good work
A workaround would be to create a group and put the switch in the group. Group capabilities don’t change based on the actual abilities of devices in the group, so you should be able to select a. group that includes the switch in the app.
Otherwise, I would just use either the built-in button controller or Advanced Button Controller.
I don't support selecting switch-only devices in the "main" list because the actions are capable of doing things like "Set Level" that the device needs to support, though if you don't use those actions, it won't really matter (and I suppose I have bulb-y commands for color/CT too and don't check that specifically, but I didn't want to be that restrictive). If you really wanted to, you could change "capability.switchLevel" on line 83 to "capability.switch", but if you update the app in the future, you'll have re-do the same change at an appropriate spot.
I might ask what the use is for a switch-only device with app like this. My intent was to allow Hue-Dimmer-style functionality, e.g., multiple presses to cycle through different scenes (or color/CT as specified without a "real" scene, etc.) and easy up/down dimming for the same devices with other buttons on the device. This works well for Lutron Picos, Eria Remotes, Hue Dimmers, and similar as the button device and smart dimmers, smart bulbs, and similar as the lights. If you just want a single button press to turn on or off a switch, I might recommend one of the above simpler apps instead since I'm not sure you'd really get any use out of these features, but maybe I'm missing a possible use case.
Hey! Thanks you both for the reply. I probably should have mentioned that I am very new to HE.
@EdMcW, the group suggestion was great, but I have actually set up the built-in button controller as suggested. Just as simple! Thanks very much.
@bertabcd1234 as for my use case, there is nothing special. I have a lamp plugged into it, so in my head it is a "light", but I understand the reason not to include it. I have a Hue Dimmer, and it was super simple to configure, so I wanted it for my lamp. Before Ed mentioned the other options, I used rules to tie these together.
I think I'm good now, and thank you both for the help.
2 Likes
I was trying to read the whole thread and I may have missed this, will this work for fan control? I have an Inovelli Fan and light switch and would love to set this up to change the speed fans and lights on and off. I have this working on some smart bulbs to turn on and off and dim, but I haven't seen the ability to select fan speeds.
There is no "native" support for fans, but if your fan driver implements the "Set Level" command, then you should be able to use it in the same way as a dimmer. Some drivers do this since it makes them more compatible with a wider variety of apps (and I'm not sure Hubitat's fan capabilities were as clearly defined in the early days), but some don't, likely trying to be "pure" fan drivers with only the "Set Speed" command, so your luck may vary. There are certainly ways you could achieve the same ends with a rule if needed, or likely even Button Controller (if it supports cycling speeds; can't remember off the top of my head).
Just discovered this thread.
I have a house full of Fibaro dimmers - which allow you to use a secondary physical switch (I use retractive switches) as a button for triggering other stuff - in my case for controlling other Fibaro dimmers.
Until now, I've been using RuleMachine to process the button presses.
This app certainly saves the pain of writing lots of IF-THEN-ELSE blocks - or needing multiple rules.
But sadly the Fibaro dimmers dont appear to support the dim until released option.
Thats a shame, but its still better than what I had before this app.
Great app, glad somebody had the presence of mind to think of it.
Glad you like the app! This feature requires the button device to send "released" events. I'm not familiar with the Fibaro, but if it doesn't have this capability, then that explains why it doesn't work. If it does but still doesn't, I can look into any possible problems. On the light/dimmer side, you also need to have devices with the "Start Level Change" and "Stop Level Change" commands, since that's how this feature works.
@bertabcd1234, I noticed today that if the light is off, using a button that is configured to dim up doesn’t do anything:
Would it be a lot of work to add a toggle or a drop down option to turn on the light at its lowest level if it was off before it start dimming up?
I have these buttons using your app all over the place and find them especially useful where I have smart lights. This extra piece of functionality would make them act the same as with Lutron dimmers and would be very useful!
Thanks for all your great work!
Since you have the "dim until release" option selected, this sends the startLevelChange() command to your devices. Some drivers/devices respond differently here. Hue bulbs, for example, are unaffected if off, whereas many directly-paired Zigbee bulbs (not sure if this is still true for the Advanced drivers or if they changed the Generic behavior in 2.2.5), it will turn them on of not. So, it's really not the app doing anything special here, but what you see will depend on your device. It might be nice if there were an option on devices to control this. 
But since that isn't what you asked (and it's largely outside of our control), it would probably be possible, as long as your bulbs accurately report on/off states. For Hue Bridge bulbs, polling (so real states vs. Hubitat states) would come into play here--it may not always work as expected. Or if they're CoCoHue bulbs, I might be able to do something on the driver side...still trying to figure out how to incorporate some more features into those drivers.
1 Like
Most of my bulbs are Phillips Hue and connected through Hue Bridge. Are you saying that Hubitat needs to poll the Hue Bridge? I didn’t realize that!
Yep! The Hue API doesn't have a way to "push" changes to third-party integrations in realtime (HomeKit is a special exception; I mean their open HTTP API that most people use, including Hubitat's built-in integration and mine).
So, polling it is: CoCoHue requests device states every so often, according to your configured polling interval (by default 1 minute in my app and theirs), and adjust device states if anything doesn't match. However, both Hubitat's and my apps try to be smart about this: any device changes initiated from Hubitat should be reflected immediately on the Hubitat device if the command was successfully sent to the Bridge (so if you only control your devices form Hubitat, almost everything should be instant). If you include both groups and lights that belong to that group, some states may still take until the next sync to be accurate (though CoCoHue has options for if/how to propagate these changes), and if you use scenes, it pretty much will take until the next poll for activations to be accurately reflected (it isn't impossible to retrieve the states the scene is supposed to set, but it's either fetching that pretty much every time--it could change, of course, after creation--or fetching the device states during the next poll, and I'm not sure there's a good reason to do the former over the latter).
Anyway, this won't necessarily be a problem, but if you hit an unfortunate time when Hubitat thinks the lights are off but Hue has them on, it could be. It wouldn't be impossible to put a setLevel(1) or on() command (probably the former?) option before startLevelChange(up) in this app, but maybe it would be more appropriate as a driver preference for behavior on this command? 
1 Like
I installed this app (combined with cocohue) and I'm impressive with the results. My pico remote does works exaclty (and smooth) as a Hue dimmer. Great work.
A question regarding additional lights:
I have a lamp on a Zigbee outlet.
The outlet shows under "Additional lights to turn off with 'Off' actions."
But it does not show under "Select lights to turn on/off and dim with below actions."
Is this by design? Wouldn't it make sense to have the oulet showing under both options?
