It seems pretty straightforward.
The Bedroom Sconces are two Hue bulbs. Everything works fine, except when I push button 2 the bulbs turn on to 100%
I saw some other posts about not being able to dim up +20 from 0 but they didn't really offer solutions that fit my exact issue.
Also, I did try start/stop adjusting, and it didn't work. Nothing happened. Maybe the Hue bulbs don't support it?
Something very strange. Trying to do another Button Controller for a Pico in the living room. Very simple, button 1 set temp 3000 level 100, button 5 turn off, Works great.
Then as soon as I add one for button 3 that sets the dimmer (Hue bulbs and a Hue strip) the off button (5) won't work any more. The lights turn off then back on then dim up and down, acting very strangely.
I have used the following app to do essentially what you describe. It might be worthwhile to give it a try:
For the situation that acts very strangely, I suspect that multiple apps or rules are trying to control the same light. From the bottom that same light’s device page, you can see what apps or rules are using it. I would recommend checking this see if you can find the one(s) that are causing issues.
I'm not sure what benefit comes from mimicking the Hue dimmer. Pico is 5 buttons, tell each button what to do. Seems simple.
There are no rules that control these bulbs nor use the Pico. I removed the button controller rule for button 3 and did it in Rule Machine and now the button 3 press works and doesn't interfere with the button 5 press. Bug in Button Controller?
And now I've realized that the "from off, adjust dimmer +20" isn't actually turning it on all the way.
Ohhhh I think I know what it is. I remember reading that turning off a dimmer doesn't set the dimmer to 0. So say I have it dimmed at 50% and turn off. When I do "adjust dimmer +20" it sets it to 70 because even though it was set to off the dimmer level doesn't go to 0.
This is probably what's happening. You can see the "level" attribute value in the device page under "Current States" (whether the switch is on or off) to verify.
I suspect you have not used Hue. 
The Pico does not natively support, say, quintuple taps on the top/"On" button. Nor does the Hue Dimmer when paired to Hubitat. This emulates that ability on Hubitat in software, which is likely what a Hue network also does, and allows you to do things like cycle through different scenes/settings with successive presses of the "on" button...or really whatever you configure, but that's the inspiration.
So I set the "button 5 pressed" action to set the dimmer level to 0 and then turn off. Figured then when I press button 2 to adjust +20 it should work. But it doesn't. The same thing still happens, the lights are set to much more than 20%.
Very odd! 2 things that might help understand what is happening:
Give the ABC (Advanced Button Controller) app a try. I use it with Hue bulbs all of the time with my Pico remotes and it works great. You cannot use a “Hubitat Group” of individual Hue bulbs, if you want the Start/Stop Raising/Lowering feature to work. The method below makes Hue bulbs behave the same as a normal Lutron Dimmer. So, if you have Lutron dimmers already, then these Picos will act the same, which helps family and guests have a consistent physical interface.
Example ABC automation in this post.
This depends on the device and driver, but usually a Set Level to 0 is equivalent to an "Off" and will retain the last known "on" level. A value of 1 would probably work, or perhaps you could adjust the automation that turns things on to always start from a specific level instead if that's what you want.
The way on/off and level work is very strange.
It seems like the state should be level 0 after the rule runs, but it isn't.
All I want is the dimmer up to go 20, 40, 60, 80.
How could I write a rule that says "when button 2 pushed, if switch/dimmer is off then set dimmer to level 20, else adjust dimmer +20?
SUCCESS
Yeah I know the NOT is weird. I need to fix that, however the logic does work correctly. Conditional actions, oh boy!
From what I can tell (I'm actually a programmer btw) the way the Hue bulbs work is "set level 0" is LITERALLY the same as "turn off." So "set level 0" doesn't actually set the level, it executed a "turn off." Time to Tweet Phillips 
Be careful with that Tweet... 
Hubitat's Hue Bridge integration and associcated drivers are more likely to blame. Hubitat's design decision is that setting a dimmer level=0 is the same as calling the off() command. Hubitat wants to preserve the last used dimmer level, so that the next time on() is called, the previous level is restored.
To add to the above, this is the way pretty much any dimmer-type (bulb, etc.) driver on Hubitat works. Levels are generally reported in the range of 1-100 (or 1-99 for many Z-Wave devices--closer to Z-Wave spec). The "Set Level" command may take 0 as a level parameter but is generally equivalent to off()--as you wrote and as I previously did above:
It should be noted that with some drivers, you may at least get to specify an arbitrary transition time with setLevel(0,...), unlike a plain off(). (Actually, there are some oddities with either Hue or the Bridge API here, so I'm not sure I'd recommend it unless you consistently avoid plain on/off commands for this device in favor of "Set Level" for but on and off sides of things--the issue is with remembering the last level on the bulb side--but for most devices...).
On a related note, it should be also noted that, in the absence of pre-staging being enabled (which itself seems to sort of be deprecated in favor of a special command instead), a "Set Level" command will also turn on a device that is off--no explicit on() needed.
Again, this may vary by driver, but that's generally what happens. The takeaway pretty much everywhere, though, is that the switch and level attributes are not related. If you want to test the on/off state, use switch.
I still agree with your point, but if anyone wants to know: this is actually also how Hue's v1 API, which Hubitat's built-in integration uses, works. 
Brightness values can be set from 1-254 (note that 0 is not an option--and they're also in "raw" Zigbee values here that Hubitat scales 1-100, per convention, though that's beside the point). Additionally, the API reports brightness (the bri attribute in the API, which corresponds to brightness/level, as its name suggests) as the last known value when on, with the on/off state being reported via a separate attribute. Here are some relevant parts of the state for one of my currently-off bulbs now (last dimmed to 10% before turning off):
I think this is generally how Zigbee devices work, too; the Hue v1 API is a thin wrapper around this with minimal abstraction from what I can tell. SmartThings also seems to have originated as mostly a Zigbee-oriented platform (given that they still use Zigbee terminology like "clusters" to describe Z-Wave features like "command classes"), and this might have been why they made that choice.
It's all really beside the point, I guess, since a driver can choose to abstract real-world details into whatever presentation on the hub it wants (and why I still agree with your caution). This is just convention for how Hubitat does it--regardless of underlying protocol, as far as any device/driver I can think of goes (and again, it's not the only platform I'm aware that does it this way). Just have to know what to look for! And for this purpose, it's switch.
Then I realized you can also do conditionals in Button Controller. So this is the final solution to make the Pico control the two bedroom sconces like a proper dimmer.
0 is a proxy for off, so set it to 1, then off...
Then my adjust +20 ends up at 21. The conditional rule I posted works much better.
i know this, so you can actually tell the difference between 20 and 21?
My brain knows. OCD
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
