This app is really meant to be used with dimmable devices, i.e., ones that support commands like "setLevel." Apparently, for that option, I let you choose plain switches instead. The dimming actions, of course will fail (and would regardless of where they're selected if they could be selected in the first option as well). I'm not sure if there's a good way around this, but the first input could be modified to include all switches if you really wanted to. 
I got it. The way you did it does make sense: the option that says "and/off and dim" is listing dimmable devices, the one that says "on/off" is listing all types of switches.
But when you say it will fail, do you mean throw an error of some sort?
Isn't it possible to test if the device support dimming before trying to set its level (to avoid an error)?
This way both options could have dimmers and switches but on one of them, on/off commands goes to everything but dimming commands only to those where it is supported.
This is just me thinking out loud here. Your app is amazing and it doesn't make sense to add anything that is going to "break" it 
It's possible to check that the capability (SwitchLevel) claims it's implemented or that the setLevel() command exists, but it does seem a bit odd to constantly do that in an app called Dimmer Button Controller. 
But yes, the alternative is just sending the command, and if it doesn't exist, the platform will log an error.
I do understand why I did it the way I did before now: that second option lets you choose additional devices to turn off. They do not need to support dimming. The "main" option is for devices where the app may need to set level, dim/brighten, or turn on/off, so it needs the full set of capabilities. It's not impossible to do it another way, but aside from the above, you'd have to deal with what happens if you issue a "Set Level" to that device besides just trying to avoid an error (e.g., should it turn on?). That's honestly a bit more than I might be willing to modify the app to do, but you're welcome to do so on your own if you want! Replacing "capability.switchLevel" with "capability.switch" on the affected line would at least let you choose those devices, but the rest of the behavior is up to you.
SetLevel(1) would be the one that most closely mimics the Lutron, as long as it only applies to when the light is off...
Thanks for the background on how the API works! Always something to learn! 
It does explain some odd (out of sync) behaviours I have occasionally seen.
Yep, it kind of does
My rational is the same behind the option "Additional lights to turn off with 'Off' actions", which I'm guessing is:
if i'm turning off all the (dimmable) lights in the room, there is probably something else I want to turn off
Among the same lines:
If i'm turning on all the (dimmable) lights in the room, there is maybe something else that I want to turn on
From an UX perspective, maybe instead of adding switches to the first option which would also require you to to test for the dimmer capability, you could add a new option and change the labels a little bit.
Options:
- Select lights to turn on/off and dim with below actions.
- Additional lights to turn off with 'Off' actions.
Could become:
- Select lights to turn on/off and dim with below actions.
- Additional switches to turn on with 'On' actions.
- Additional switches to turn off with 'Off' actions.
I think that would be a good thing to add.
But, I'm a software engineer myself and I know how it is with the whole feedback thing. Sometimes they are great and some times they are ... let's just say not according to the products vision.
I never done anything for HE elevation before and also never did anything in Groovy but I will look around and see if/how I can contribute.
Thanks again, great app.
I went ahead and did it based on the concept from my previous post.
Turns out to be very useful in rooms where I have some decor that should be turned on with the hue scene (like a lava lamp for example 
).
Hi,
I installed your app today. The setup finally seemed to go ok after the third try but the buttons aren't doing anything and I don't see any button presses in the logs.
The log does shows this however:
2021-04-02 10:08:53.810 pm warndescription logging is: true
dev:62021-04-02 10:08:53.808 pm infoupdated...
dev:62021-04-02 10:02:48.495 pm errorgroovy.lang.MissingMethodException: No signature of method: lutronDimmer.updateTelnetInfo() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl, java.util.LinkedHashMap$Entry) values: [lutron_telnet_7, lutID1=2] Possible solutions: updateTelnetInfo(java.lang.String, java.lang.String) (updateTelnetInfo)
dev:62021-04-02 09:58:10.796 pm errorgroovy.lang.MissingMethodException: No signature of method: lutronDimmer.updateTelnetInfo() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl, java.util.LinkedHashMap$Entry) values: [lutron_telnet_7, lutID1=2] Possible solutions: updateTelnetInfo(java.lang.String, java.lang.String) (updateTelnetInfo)
dev:62021-04-02 09:58:10.675 pm warninstalled...
I don't know groovy but exceptions usually keep the code from working as expected.
Is that the cause of my problem or is there something else that I have done incorrectly?
Thanks,
Dan Essin
The only errors I see are for device 6, which is not Dimmer Button Controller because DBC is an app and not a device. If you go to http://hubitat.local/device/edit/6, substituting your hub's IP address for hubitat.local if necessary, you should see the offending device. Maybe it's a Pico? I'm not sure how to solve that problem, but if you're on 2.2.6, toggling the new "use telnet direct" option on or off (staff are now recommending it on, but the only option used to be basically off--the option is new) may help.
It's working now. I deleted my first attempt and started over with different settings and that works. First try was probably just "learning curve"
Thanks
The conrinuing saga.
I just added my second pico. I tried to configure it identical to the first but I think I messed up somewhere. I've added it to the button controller. The first time I got options for all 5 buttons. The second time I got options for only one button. I'm including the screenshots. I am totally baffeled.
Pico 1
Pico 1
Pico 2
Pico 2
I hope that you tell me what I did wrong and how to fix it.
Thanks
The DBC setup looks fine, but I think something is wrong with your Pico-4 device. You should see things under "Current States," which notably lacks a "pushed" attribute for the last button number you pushed (plus one or more other attributes as a result of events you'd get depending on your driver).
This would be an issue with your Lutron setup outside the scope of this app, but the first thing I'd check if you're not sure where to start is that the ID you provided in the Lutron integration app on Hubitat matches the device (Pico) ID from your Lutron integration report. If you have Caséta, you should also be able to simulate a button press from the Lutron mobile app, which if all works as expected would suggest a problem with the Pico itself (e.g., could it be out of range? dead battery?) since that would mean the ID matches and the Hubitat integration is working for this device.
It was registering presses on all 5 buttons so I deleted it and added it back as a puch/hold instead of a dimmer and it gave me all 5 buttons. Anyway your app is cool and for me it is essential. I would never have been able to recreate my wink setup without it!
Thanks
Oh yeah, if you've got a Pico, you want either a "Pico" or "Fast Pico" ("p" or "q" if you're using manual setup, or the appropriate options if you're using the wizard), not a dimmer, which is for the in-wall/powered dimmers. Glad you got it figured out!
Attempted this using 2 Rule Sets on RM with a Aqara 2 Button Wireless Switch. One Rule Set for button controls - left button to increase the SceneCounter and right button to decrease the Scene Counter, and pressing both buttons toggle (ON/OFF) a full Daylight scene. Another Rule Set to turn on Scene based on SceneCounter. Also set SceneCounter "0" as OFF.
Rule Set 1
Rule Set 2
Note: The Scene settings are using Hue Scenes via CoCoHue integartion
Thanks for this app, much easier to use than other ones, but...
I notice the "Toggle" switch only appears if I pick multiple bulbs. If I pick only one bulb then the Toggle action does not appear:
versus
Parent 2.0.2 according to app code.
Thanks for the report! I see where I misplaced a bracket/if and caused this oddity. I've fixed in in child app version 2.1.3, which I've just uploaded to GitHub. HPM should get these changes (via the "raw" files on GitHub) soon. The only update is in the child app, though I also took this time to update the parent app to add the documentation/help link should anyone try that (but no functional changes there, so no need to update if you're doing it manually).
1 Like
Perfect! Updated and working. Thanks muchly.
I've just released an update to the app (both parent and child are affected), Dimmer Button Controller version 3.0. First, to upgrade:
- if you're using Hubitat Package Manager, I suspect everything should take care of itself (updating the parent app; downloading the v3 child app as a new requirement; and leaving v2, now optional, as is); or,
- if you installed manually, then:
- overwrite the parent app (named "Dimmer Button Controller") with the new parent app code
- keep the existing v2 child app code as-is (named "Dimmer Button Controller (Child App) 2") -- do NOT overwrite the v2 child app code with the v3 child app code
- add the v3 child app code as a new app
(There are actually lots of similarities between v2 and v3, so unlike the v1 upgrade, it won't mess up everything if you do accidentally overwrite the code, but you'll have to re-do some of your settings, so I just wouldn't. You can keep v3 and any number of older-version child apps installed without any problem. If you ever move all child apps to v3, you can remove the older child app code if you want.)
Now, for the new features in v3:
- Ability to mix "on (to specific settings)," "activate scene," and "activate CoCoHue scene" actions in the same button event. For example:
- New "Presets" feature to automatically fill in some settings. Access it below the button action configuration:
I'd consider this feature sort of experimental and I have a few predefined that I found useful for me:
I've been asked by a tester to consider allowing user-defined presets, but there is some difficulty entailed with that, at least compared to the current implementation (which, among other assumptions, necessitates the "Apply same level and color settings to all lights" options, though you can turn it off and configure individual lights as desired after applying a preset if you want; they are just initial settings and won't be overwritten unless you apply another preset). - Ability to use new (Hubitat 2.2.6) three-parameter
setColorTemperature()command, which may work better if your devices support it. Many do not right now (test it on their device page first), and the "old" behavior is enabled by default:
I've tested v3 a bit myself, but let me know if you notice any problems! And, of course, you are free to keep using v2 if it meets your needs (though I'm more likely to troubleshoot v3).
1 Like
hi bert, firstly thanks for your work on this app, i use on it and its great.
i upgraded from v2 to v3 using hpm and there were no errors, but none of my configured buttons changed from v2 to v3. (in the parent app config page they show as child v2).
is that expected?
is the intent that users need to recreate every button config from scratch after upgrading?
Yes, that is the expected behavior. In general, I increment the major version number only when there are breaking changes (such that existing installed app instances cannot necessarily be directly upgraded; this is simiar to what has been done with many built-in Hubitat apps, like Rule Machine, too).
Anything you create as new can be v3.0 (as long as you aren't creating new instances of a previous/deprecated child version, which it will still let you do). But there is no reason to unless you need the new features, as all versions can coexist without problem.
1 Like
