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. (Just will still take some work.)
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.
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... )
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.
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.... 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).
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.
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.)
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?
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.
(Just will still take some work.)
)
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).
(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.)
