Inspired by this thread and this post in particular, I have created an app that (I think) easily allows button devices to be configured to control bulbs, switches, and dimmers. This app allows you to:
choose a button device (I wrote this with 5-button Picos with the "fast Pico" driver in mind and expanded it to work with the "held" events from the Osram/Lightify dimmer and later the "double tapped" events from other devices, but any button device should work)
choose one or more bulbs/dimmers or groups to control
choose an action for each button press: turn on (any or all selected bulbs), dim up or down, turn on scene, activate Hue Bridge scene (CoCoHue required), turn off last used scene, turn off (specific) scene, or turn off (all bulbs)
dim can either "step up"/"step down" or (if button device supports "released" events and bulbs support the start- and stopLevelChange commands) continuously dim while pressing or holding the button
for dimming, only bulbs that are currently on will be changed (emulating Hue Dimmer)
for "on"-type actions, multiple pushes (default of 5) of the button are (optionally) tracked to allow you to cycle through different manual settings (with "Turn on" selected) or scenes (with "Turn on scene" or "Activate Hue Bridge scene" selected); the count resets to press 1 after 15 seconds or after an "off"-type button is pressed. This, again, emulates Hue Dimmer behavior.
Turning on and off is nothing you can't do with existing apps (e.g., Button Controller or Advanced Button Controller), but since they do much more than lights, it takes more time to set them up (and the default "transition time" was too high for me--mine defaults to 100ms but can be changed from 0-3s). I also found it annoying to need to select the same lights for each action when I want all actions to affect the same ones. The "multi-press" feature and "don't dim/brighten bulbs that aren't already on" features are also not easily possible with existing solutions.
Link to GitHub repo is below. This is a parent/child app, so add the code for both (parent first), then install an instance of the parent, which you can use to create child apps.
Or for manual installation with raw code, use these links:
NOTE: If upgrading to 3.x from 1.x/2.x (and you care to keep 1.x/2.x child apps), see the notes in the readme on GitHub or post 86 below (but basically, add the 3.x child as a new app, update the parent, and keep your 1.x/2.x child app code as-is; the 3.x child is an entirely new app, as was 2.x from 1.x).
Alternative installation method: Dimmer Button Controller 3 can also be installed from Hubitat Package Manager. Choose Install > From a Repository > Utility or look by author "Robert Morris" (bertabcd1234) or namespace "RMoRobert".
I've tested this mostly with the "manual" input settings (e.g., "Turn on" and then manually specified brightness, color temperature, etc. settings), but I've added support for turning on (and off) scenes due to anticipated requests for that. I've also used the new Hue Bridge scene feature (via my CoCoHue integration) a lot. Hopefully it's as useful to others as I'm finding it for myself!
Here's a screenshot of how I have one set up using a CoCoHue group and scenes with a 5-button Pico, though you could do something similar with "regular" bulbs and scenes (or manual settings) too:
Some additional notes--I'll update this post as I make changes to the app with other announcements, etc. I have a wishlist that includes:
Dimming up/down for "press"/"release"-capable devices (like a Pico with the fast driver) and bulbs/dimmers that support the "start" and "stop" level-change commands (as Hue over the Bridge now appears to and many directly connected bulbs have for a bit)--then these can be a "press to start dimming, release to stop dimming" button. Right now, pressing just steps the level up/down by the specified amount (default is 10%). ) (added v1.5)
Ability to auto-fill sensible default values for specific button devices--e.g., for a 5-button Pico, you'll probably want:
button 1: turn on (or turn on scene)
button 2: brighten
button 3: turn on (or turn on scene)--like an extra "on" button that gives you even more scenes/settings to cycle through--or whatever you want!
[app:2027](http://10.0.0.53/logs#app2027)2018-12-28 09:58:19.051 am [error](http://10.0.0.53/installedapp/configure/2027)java.lang.IllegalArgumentException: Must specify a non-null value for the 'to' index in a Range on line 52 (pageMain)
What button device are you using? I'm guessing it doesn't report the number of buttons. If there's a way to specify that in the driver details/edit page for your device, I'd do that. I think all the stock Hubitat drivers do this automatically, except maybe for the Picos where it doesn't have a way to automatically differentiate.
If you're using a custom driver, you'll need to make sure the driver sets the numberOfButtons value in the updated method. If it's some sort of button device where this isn't specified for some reason, I could probably add in a spot in the app to specify, and I'll update the code to at least handle the situation where this value is unset more gracefully. (EDIT: As of v1.6, I've done this and it will now assume one button if the device doesn't report. You'll need to fix the device to use more, but this will prevent errors.)
Thanks for the report, and I hope something above helps!
I'm assuming you read the rest of my post and made sure the number of buttons was set? Here's what I mean--go to the "Devices" page, find and click the name of your device, then on that page find and set this value appropriately, depending on the actual Pico you're using:
It should work if that is set. If not, I see your username is tagged with "Developer," so I'd try writing a small app that takes your Pico device and calls.currentValue('numberOfButtons') on it to see what it returns. I suspect it will return null or error out. This shouldn't happen if that value is set in the device preferences (maybe change it to something else then change it back?) unless there's a Hubitat bug somewhere.
(EDIT: You don't actually need to do that. Just see the post from stephack [of Advanced Button Controller fame] below. )
These 2 features interest me. I have never used the Hue dimmer so I don't totally understand the multi press function but it sounds like it would open up a lot more control options for each button. I'll have to fire your app up to test and maybe add something similar to ABC as well.
Regardless, this sounds like an awesome app for light configs. The list of community apps is growing fast. We need a @JDRoberts to help catalog them all before it gets out of hand.
Yeah...There was an issue where the driver wasn't sending the numberOfbutton events during the install. I believe they fixed it since but it wouldn't be there if you installed the device before the fix. I manually went in to all my picos and did a Save back then to force the sendEvent.
I think you have something similar in ABC, the "cycle between scenes with button press"-type feature. However, I haven't used it so I can't say for sure, and I suspect there's no equivalent to the "timeout" that the Hue Dimmer switch has where it will "reset" back to the first scene after so long without pressing the "On" button (the one that you can configure to either just turn on your lights, set a scene, or rotate between 5 scenes) or after pressing the "Off" button. (I actually don't use Hubitat scenes much, either because they're new and I'm not used to them, it causes a proliferation of devices, or I just like manually specifying the desired settings--which is really what I wrote this app to do and just added support for Hubitat's "native" scenes under the assumption others do use them.)
The "don't dim/brighten lights that aren't currently on" feature is the main one (besides needing to choose the same lights in every action in other apps instead of just once for the whole child app) that made me want to write a custom app. I might be unusual in the way I use my Hue lights in that in many cases I have several in one room but not all are necessarily on. I think the Hue Dimmer works by essentially dimming/brightening the last scene (or it might be smart enough to know what bulbs are currently in use regardless of how they were turned on; I haven't tested that). Otherwise, I get lights turning on that I don't want on.
I've updated the child app (raw code link here, or see above) to version 1.5. The biggest change is that the app now supports a new option you'll see when the "Dim" or "Brighten" action is selected for a button press: "Start dimming when button pressed, stop dimming when button is released."
Just as it sounds, this requires a button that supports "press" and "release" events, which includes a Pico using the Fast Pico driver (the app will check for this and not show this option if yours doesn't). It also requires bulbs/dimmers that support the startLevelChange and stopLevelChange commands (the app does not check for this at the moment). With this option checked, a button press will send a "start level change" command, and a button release will send a "stop level change" command. This is an alternative to using a simple press to step the level up/down by a set amount, which you can still do without this option. (EDIT: Later updates add support for a "held" event to do a startLevelChange and a release to do a stopLevelChange.)
Unfortunately for those with Hue Bridge bulbs used in Hubitat, there appears to be an issue with the "startLevelChange" and "stopLevelChange" commands in my testing. Specifically, either one immediately will change the bulb to "off" in Hubitat even though the bulb itself actually remains on. Because my dimming functions only work if the bulb is on (that's part of the reason I wrote this app), this may cause problems for some people. (EDIT: Later testing reveals that the startLevelChange and stopLevelChange commands still work even if Hubitat thinks the bulb has an incorrect switch state, so if you only use this style of dimming, you shouldn't be affected--only if you mix the two types of dimming, i.e., continuous and step up/down, and don't want long enough betweeen using them.)
This thread has more details on the problem I mentioned in the previous paragraph: Hue lights Start Level Change. However, as of the last post in that thread, staff did not seem able to replicate this problem. There may be renewed interest in the problem since more of us are noticing it now. If anyone uses Hue Bridge bulbs on Hubitat and wants to test, feel free.
PS - I also changed my mind about "held" functionality. I have a Osram/Lightify two-button dimmer device, and I'll need to make use of "held" to get that device to work as intended--where I think most people would want to use a "press up" for on-type actions, a "hold up" for "start level change," and a "release up" for a "stop level change" (if dimming is configured this way; otherwise, just a step up on hold and nothing on release), then something similar but reversed for the bottom button with "off" being my recommendation for a press and some dimming actions for hold and (again optionally) release. Coming soon (EDIT: now released!).
Support for button "held" events! Now you can use an Osram/Lightify Dimmer with this app (the reason I added this feature), and it should also work with the Minimote or "regular" Pico driver, but I still think the "Fast Pico" driver works better here
note that, as before, "released" events are supported as part of the "dim while held" functions (so you can start a level change with a press or hold and stop it when released; your button must support these events and your dimmer/bulbs these commands)
there is no "doubleTapped" support, nor do I have a use for it, but I could add it it someone wants it (again, my first use for this was the Pico remote emulating a Hue dimmer, so you can press it twice or more to cycle through scenes/settings without needing the device itself to support multiple taps)
"dim while held" function no longer checks if bulbs are on before starting level changes because no bulbs in my testing respond to startLevelChange if they are not already on, so this was unnecessary (let me know if anyone has bulbs or dimmers that prove me wrong)
this also avoids effects of the "Hue bug" I mentioned above where a level change command immediately changes the switch state as reported by the driver to "off" even though the bulb itself remains on (bulbs the driver incorrectly thinks is off still correctly respond to the continuous dimming commands)
note that the step up/step down style of dimming does still check, and all dimming functions should work as before (in the event you mix and match this dimming with the continuous/"dim while held" dimming, this may still be a problem of the "Hue bug" affects you)
Nope, I think it's a problem with my code, and it could be me just not understanding how scene devices in Hubitat work. Thanks for catching this! The short answer is that around line 400 in the code, there's a command sc.push(), which should work if you change it to sc.on().
If anyone knows why, I'd appreciate some insight. I thought either one should work. The device appears to expose both, and it works if I click it in the device's "Edit" page in the UI, but only "on" works if I use it in my code. The effect should be the same unless you care about not tracking the on/off state of the scene device itself (e.g., I think some people with dashboards do).
I'll try to address this in the next update, either changing it to "on" or figuring out why "push" doesn't work. In the meantime, if you feel comfortable, hopefully anyone with this problem can try the minor change themselves. I mostly use it for manual "scene" creation myself and confess that I didn't do much testing with Hubitat scenes.
Thanks for the pointer. I don't know enough to say why sc.push() would fail and sc.on() would work but am happy changing it as I don't care about the state for this use case. I'll give it a shot later when I'm back home.
I'm curious what you mean that you're using it for manual creation?
I use the "Turn on" option, not the "Turn on scene" option. The "Turn on" option lets me manually (that's what I meant) specify level, color temperature, and/or hue and saturation, rather than choosing a "real" Hubitat scene to activate. I guess I shouldn't have said "creation" since they don't make scenes that are accessible outside the app, but the effect within the app is the same--just manually specifying the "scene" settings you want.
This was in no way inspired by me trying to use the Hue app to make scenes and having to just guess where the heck 4000K was on a visual color-temperature slider...