Yup, that was it. The drop down was set to 5 already, but I went ahead and clicked save and lo and behold, numberOfButtons state showed up.
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.
2 Likes
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. 
All,
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!).
Thanks! Now I can use the minimotes and iris key fobs!
New update! Child app has been updated to version 1.6 (no changes to parent). GitHub link in first post, or raw code for child here: https://raw.githubusercontent.com/RMoRobert/Hubitat/master/apps/DimmerButtonController/DimmerButtonController.groovy
Changes include:
- 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)
Let me know if anyone notices any problems!
I'm trying to use this with a Pico to activate a scene and am not having any luck. I can't see anything wrong with my setup so am hoping someone spots something obvious.
Here's the controller. test pico is a fast pico switch if it matters. test1 scene just sets a dimmer to 30% and it works fine when activated directly (or via a switch).
Here are my logs (with debug logging for dimmer button controller enabled) and it's definitely seeing the button press and it looks like it's trying to activate the scene but nothing actually happens.
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...
Ah, that makes sense. My only real reason for wanting a scene is that I want to restore the state of the light on the first press but maybe there's a better way?
What I'd been thinking was a scene that activates on button 1 press 1 and save the scene state when button 5 is pressed. When button 1 was pressed a second time I intended to activate a scene that just sets the light to 100%. This could be done differently if there were another way to save the light state (when button 5 is pressed prior to turning them off) or if there was a way to use a scene (first press) and setting the dimmer (press 2) but I didn't see a way to do either of those without a lot more work (than just using scenes).
Hmm. I think that's almost possible as-is if you just use "Turn on" and don't specify anything else. Unfortunately, it doesn't save which lights were on/off when you press whatever button (say, 5) you have set for "Turn off," so it will turn on all of the select lights back on again--but it will turn them on to whatever they were before, since all it does is send an on(). Maybe I could add a "Turn off and save states" and "Turn on and restore saved states" action? (Incidentally, that's about what I do with my Lights on Motion Plus app, albeit with motion-sensor triggers and not button-device triggers; I was thinking about merging some aspects of the two, however, e.g., allowing a button to restore instead of new motion.)
interesting, I confess I didn't try just sending "turn on". I actually don't have multiple lights (these are recessed lights all behind the same switch) so that's not an issue for me. If I can set it up to "turn on" for press 1 and "set to 100%" for press 2 and "turn on" restores the last state then I think it'll work as I want. I'll give that a shot tonight.
If it works and WAF with any delay (compared to Lutron native connection) is ok then I think I'll be set.
I tried leaving the first press for "turn on" empty (no level) but that just made press 1 do nothing. Here's what it looks like and the logs.
Changing to sc.on() did the trick for the scene but I haven't quite figured out how to store the scene state when button 5 is pushed (since I can't combine two actions; turn off + push another button or switch). Turning off the scenes (including a capture for "scene 1") doesn't seem to work as I'd hoped.
BTW, I think I found a bug on line 422; I think def sc = settings["btn${btnNum}Held_SceneOff"] should read def sc = settings["btn${btnNum}_SceneOff"].
Any thoughts on either getting "on" to work or how to store the scene state?
1 Like
@bertabcd1234 Hi,
how about this (with a hue dimmer in mind):
hold button 1 to shift to blueish, hold button 4 to shift to redish light?
otherwise, it's already great.
You can already (sort of) do that: if the button device supports "held," you'll see it as a configurable action. You'll then just need to set the hue, saturation, and level values to match your desired colors.
However (this is the "sort of"), I don't think you can do that with a Hue Dimmer because I don't think it supports "held" on buttons 1 and 4. This is how the device works, nothing Hubitat or this app can do about it. (But you can check for sure by seeing what events get logged as you try the various buttons. It's common for this type of device to only support "held" or both "push" and "release" on buttons that are intended to be used for dimming: Pico remote, Eria Dimmer, and, I think, this.)
1 Like
You're right. The Hue dimmer doesn't support it on 1 and 4. But it does on 2 and 3. unfortunately it doesn't work with your app. the log says it doesn't support "start level change" and "stop level change". I played yesterday with the build in button controller and there it seams to work.
Something I can do to help solve this issue?
Verify that your dimmers/lights support startLevelChange and stopLevelChange, which you can see by looking at their device page. If those buttons aren't there or you try them and they don't work that is the problem. (That being said, I'm not sure why BC would work and this wouldn't if yu mean the same lights/dimmers. Are you using stock or custom drivers?)
The functionality is given. It works perfectly fine on the device page.
It states clearly when held and released.
I'm using the stock driver (couldn't fine costom drivers for testing).
The same with all 4 of my dimmers.
And also, the built in button controller app supports it. But I need your app for the "swich configuration on multiple button presses" functionality.
@bertabcd1234 In case you have no intention to investigate why the start/stop mechanic on my/the hue dimmer switch/bulb/bridge not works, HE has this function also intigrated. So with a combination of your app and the build in button controller app I can do what the dimmer should do.
(It's an inconvenience but it works)
thanks anyway
