[RELEASE] Dimmer Button Controller (configure Pico to emulate Hue Dimmer or any button device to easily control lights)

Ya, seems the off properly sets the light to off in the bridge, but the on is not. Once the poll completes the light is updated to on and everything is rock solid form then on.

Just wondering: are you mixing bulbs and groups in DBC, or is your group device the only one you're using? I just tried a CoCoHue Group device, and both the Off and On actions immediately changed the state in Hubitat.

If you're mixing bulbs and groups, there are options in both devices for whether you want to "sync" group changes to bulbs (on by default) or bulb changes to group (off by default), so that could explain why all devices are not accurate until the next poll/sync. Otherwise, if you can figure otu some pattern I don't see as to when this happens or doesn't, I can look into it more.

I pulled in all bulbs and groups from hue. But to date I have only been using groups in the actions.

That’s what is odd about this , the pattern here is so simple and happens every time. With the Pico turn off a group, turn on a group. Press dim as many times as you want, nothing happens. After the first poll dim works and rock solid.

I wonder what’s difference about our setups!

Interesting, I was able to do that with a group without problem. All of these events on the group were caused by a Pico with DBC and no Hue refresh in between:

Something in the environment is different I think.

Greetings, all! I've released a beta of version 2.0. Unfortunately, I made some significant under-the-hood changes, so 1.x apps will not be able to be automatically upgraded to 2.0, but you can still run them both side-by-side (just update the parent app and add the 2.0 child app as a new app; do not overwrite the 1.x child app code with the 2.0 child app code). The upgrade process is explained in more detail in the readme on the DBC GitHub. For any new users, you can just add the parent and child apps as normal.

Most of the changes right now are under the hood, so there aren't a ton of visibly new features. However, the new codebase should give me the ability to more easily add things in the future, and I already have a few ideas :slight_smile: (mostly for CoCoHue users but nothing will change if you don't use those features). New things you might notice:

  • new "Set for all" option for "On" action--use same level, CT, or color settings for all selected bulbs instead of specifying for each, if desired
  • former "Toggle" action moved to new option under "On" action; this gives you the ability to still do something else with subsequent actions on that same button
  • improved clarity on wording:
    • tried to eliminate the word "press" wherever possible in favor of the real action name (in case anyone wants to support multiple possible actions on a double tap, for example--now supported)
    • "dim while held" option renamed to "dim until release" so as to be more generic and make it easier to understand on devices like a Fast Pico where the sequence of events would be "pressed" and then "released" (as opposed to Pico where it would be "held" and then "released"). As before, you only want to choose this option for events that will be followed by a "release."
  • UI cleanup and improvements, notably:
    • when configuring manual level/CT/color settings for "Turn on" actions, the settings now get saved only when you push the "Save Presses" button (instead of every time you change a setting, forcing the whole page to re-load and slowing down the input process); I recommend clicking/tapping this button every time you finish configuring all settings for that particular push (this will force evaluation of whether you've completed all the required information and can add actions for an additional push)

If you notice any problems, let me know! (And again, do not import the 2.x child over the 1.x child. Update the parent app, then add 2.0 as a new app if you're a new user. :slight_smile: )

I've released version 2.0 (final) with minor changes and fixes from the beta. Everything above still applies--notably, existing 1.x users will want to read the upgrade instructions carefully to update only the parent app and install the 2.0 child as a new app, keeping the 1.x child app. You can use both side-by-side, but 1.x child apps are not directly upgradeable to 2.x child apps due to major under-the-hood changes.

I've also added Hubitat Package Manager as an installation mechanism now (would only recommend this for new 2.x users or 1.x users after you've upgraded manually).

Minor update: I've released version 2.1 with a change that allows you to use a group device to replace individual bulb devices for actions that the group device would support (e.g., "Off" or "Turn on...and set to..." when all bulbs are set to the same setting), which may improve performance if you're able to do so. This is hidden under "Advanced" for what I'd consider a good reason (you need to be sure that the group device contains the same devices as the indivudal ones you've selected elsewhere, and unless you rely on the startLevelChange() command that the "dim until released" option provides, you could probably just use the group device in the first place; for CoCoHue users, for example, this should not be needed).

As before, existing 1.x users will want to read the notes above (see first post, updated) before upgrading to anything in the 2.x series. Existing 2.x users can upgrade with no special considerations.

Now can you make a version that does exactly this but for (Serena) shades/shade groups? I cannot get the built in button controller to do raise and lower while holding 2/4 no matter what I do!

a two click configure would be amazing. Prepopulate the "default" (on/up/fav/down/off)

  1. What Remote
  2. What Light/Shade

Done

Do Serena shades support the "Start Level Change" and "Stop Level Change" commands? If not, you won't be able to use the "dim until released"-type options becsuse that is what DBC uses underneath. I think in 2.0 this option should actually be hidden if art least one device doesn't support it and you'll get a warning in the UI if all don't, but I only tried this with actual dimmers and don't know how most shades work here in terms of what commands would produce the desired effect (usually they're similar).

I actually was working on a blinds-oriented version of this, but I'm not sure it would solve the above problem because I don't know what the cause is for you (feel free to share your setup). But I do have a "problem" where battery-powered blinds take at least a few seconds to change and report their new status back to the hub, so a button to adjust the level/position by, say, -10%, won't do much good if it just reads the current level from the device and calculates a difference; instead I'm planning on "remembering" recent changes and calculating the new level from that (but also subscribing to changes from the device so the app will know for sure after it really does report back).

Something like this is on my to-do list too, but it's not quite that easy. Notably, this only makes sense for a few button devices, like a 5-button Pico or Hue Dimmer where all buttons are labeled and most people woups probably want the same thing on most buttons. If you're using, say, the Osram 4-button device or a Remotec ten-billion button thingie, all hope is lost. Second, it depends on the lights you're actually controlling. For example, not all support "Start Level Change"/"Stop Level Change," so, for example, button 2 on a 5-button Fast Pico would have to be configured differently in these two cases.

All are able to be worked around: guess by the driver what the button device is, only support this feature for a known subset of devices where this makes sense, modify assigned actions depending on the capabilities of lights/dimmers that are selected, and ultimately still allow customization by the user (just fill out what may be sensible defaults). Part of the reason I mostly rewrite 2.0 is to make this a bit easier for me to implement. I'm glad it's not such a crazy idea. :slight_smile: (Just will still take some work.)

Thanks for the feedback!

They don’t seem to understand those commands. The up and down (hold) that the come with from lutron works great but nothing I do in HE seems to for for that. The shades are all plugged in so battery isn’t an issue.

If it is possible, @bravenel would know for sure. Bruce uses Lutron personally, and probably wrote much of Hubitat’s Lutron integration.

Bruce, is there an analogous method to control Serena shades from Hubitat? Like the way one can use a Hubitat connected Pico to adjust a Lutron dimmer via startLevelChange and stopLevelChange commands?

UPDATE: It appears the Lutron Shade driver does support a startPositionChange and stopPositionChange pair of commands. @jared.zimmerman, have you tried using these two commands tied to the “pushed” and “released” events of a Pico?

Hmm, maybe the Lutron drivers are "pure" and only implement the Window Shade capabilities instead of the Switch Level (i.e,. dimmer) capabilities. I'll probably modify my hypothetical "Blinds Button Controller" to use position instead of level and setPosition instead of setLevel, or at least provide that as an option, though a lot of drivers I've seen implement both synonymously (presumably because many apps are written for dimmers and far fewer for specifically shades).

That being said, I don't see startPositionChange() as a command for any capability on the official list, just startLevelChange() for the "ChangeLevel" capability. Presumably these were made with an analogous, potentially hypothetical "ChangePosition" capability in mind? (Maybe it already exists and isn't documented?) This would again make sense for "pure" drivers that only want to be blinds/shades and not pretend to be dimmers for the sake of wider compatibility with apps (which I imagine voice assistants, should both they and their integrations ever operate an an ideal world where so many things didn't have to pretend to be switches/dimmers and risk getting interpreted as lights, would like a lot better...).

If you add a virtual device, and specify the Lutron Shade driver, you will see that it implements much more than the standard Window Shade capability. Assuming the start and stop position change commands work with Serena, then there should be a way to issue these custom commands via Rule Machine’s custom actions using a ButtonDevice Trigger.

This is my current setup here, the full open and full close work, but that's it.

So, the first question is why not simply directly pair the Pico remote to the Serena shade, bypassing Hubitat altogether? It will respond much quicker and more reliably (assuming this is possible, as I do not have Serena shades... :wink: )

Seems like it is possible to directly control Serena Shades via a Pico Remote

I can do that, I was just trying to have everything at least visible and controllable in Hubitat, but at this point that seems like more trouble than its work for the shades+pico

Actually, you'd probably be disappointed with the performance. I know users who have tried the PICO->LutronHub->Hubitat->LutronHub->LutronDimmer have not had great success due to the fact that the LutronHub's telnet interface gets a little bogged down by all of the traffic. The direct Pico to LutronDimmer works perfectly.

1 Like

Continuing the discussion from Advanced Button Controller (ABC) concerning what color values mean for users of DBC (or really any app):

For hue and saturation, if you haven't figured it out yet, here are some things that might help:

  • Hubitat will report RGBW capable bulbs as being in one of two modes, RGB (color) or CT (color temperature, i.e., shades of white)
  • CT is a different model from the RGB (HSL) model, and there is no easy conversion between the two. To determine the relevant attributes that contribute to the current appearance of the light:
    • look at the "colorTemperature" attribute in Hubitat when in "colorMode: CT"
    • look at the "hue" and "saturation" attributes when in "colorMode: RGB"
  • The "level" attribute is just the brightness of the bulb/strip and is applicable to both.

As to what these attributes mean:

For RGB mode...

  • Hubitat's hue model goes 0-100 with both extremes being red
    • this is a scaled version of the standard 0-360° color wheel (so divide by 3.6 to get a Hubitat value; some devices also have a "use high-resolution hue" option, which does allow 0-360, though not all apps will necessary play well with those values)
    • device manufacturers do not have to "standardize" hue values, so a specific value on one brand/model might look different on another (e.g., Philips Hue vs. Sengled)
  • Saturation (0-100%) is basically the intensity of the color, so 100 will give you the reddest red (if your hue is near 0 or 100), bluest blue, etc.
    • note: some bulbs have specific weaknesses here, e.g., early Hue bulbs were widely reported to have weak/unsaturated greens and blues, but 100% would still get you the best they could do)
  • The "level" component of the color corresponds to the dimming/brightness value--Hubitat's color picker is a bit odd here because lower values become closer to black, which is probably the best approximation you can do but it really just means the light won't be as bright
  • All three of these parameters can be set individually ("Set Hue," etc.) or as part of a color ("Set Color"); the resulting effect should be the same, though if you're using app or rule and want them all to get set at the same time, "Set Color" is likely to be faster (but trying them individually is often easier for testing--or if you really do only want to change one value)

For CT mode...

  • This is standard color temperature in Kelvin. The lower the number, the "warmer" (oranger) the light appears, and the higher the number, the "cooler" (bluer) it appears.
  • Each bulb has a different range here, but something like 2000-something to 6000-something is a pretty common gamut. Casual Googling suggests Osram goes 2700-6500,
    • 2700 is about the standard warm white people are used to from incandescents
    • 4000 or even 5000 is what some people might associate with fluorescent office-type lighting

I wonder if something like this shouldn't go in an FAQ somewhere.... :thinking: It's not really DBC-specific, but unlike BC and some other apps, I don't provide pre-selected colors in a drop-down or anything (though with how much bulbs vary, I'm not sure if that is worth it).

2 Likes