The driver is hueBridgeBulbRGBW. The Hue hub says the bulb is an LCT014. I'm on the latest firmware on the Hue and Hubitat hubs
I can confirm. The switch changes to off as soon as the transition begins. It also happens when starting the level change up. So, if it had something to do with the transition time, it would not affect the level increasing to 100%. But when I begin adjusting the light up, it immediately shuts off in HE.
@patrick I noticed that there wasn't a fix in the latest release for this issue. Any idea if this is going to be addressed?
It happens on both raise and lower with my cree bulbs through Hue hub.
FWIW, I just tried this on the latest firmware and the problem described happens to me. In case it wasn't clear, here are the steps I used to reproduce, and it seems to be the same as what the other poster(s) described:
- Start with a hueBridgeBulb* that is turned on (I'm testing on a hueBridgeBulbCT, but I see the above has an RGBW with the same issue). In my case, the bulb is on at 100%, and the driver is correctly reporting it as such. To be extra clear, this is a "first-party" Hue bulb used on Hubitat via the v2 Hue Bridge.
- Click "startLevelChange" with either "up" or "down" selected (doesn't seem to matter for me).
- Note how under "Current states," the "switch" attribute immediately beings reporting as "off," even though the bulb itself is still on. Clicking "stopLevelChange" does not seem to change anything, even if you hit it before the bulb has actually dimmed all the way down. In fact, even if you do let it go all the way down, the actual bulb will remain on.
- Note that after a bit, the "switch" attribute will again correctly report as "on" without any action on your part. I would say that "a bit" is the refresh interval, but manually clicking "Refresh" does not have this effect for me.
And actually, step 2 can be replaced with "stopLevelChange"--even if the bulb is not currently changing level, clicking this also immediately turns the switch state to "off" (in Hubitat, not in Hue) for me despite there not actually being any changes to the light itself.
And since it was mentioned above, this seems to happen for me regardless of what "transition time" I choose in the driver. This is also happening on both of my Hubitat hubs and with lots of different Hue bulbs I tried. The Virtual Dimmer and similar drivers do not appear to support the start/stop-level-change commands, so I am unable to test with other devices that also implement these commands.
That being said, since it seems to self-correct, I don't actually see this being much of a problem for most people. I noticed this while working on revisions to my Dimmer Button Controller app, however--it only executes level changes on bulbs that are on when the level change is performed, so if a "start" or "stop" was recently performed, dimming in my app doesn't work properly until Hubitat shows the correct state again.
Thank you for confirming!!! This is a really huge problem if you have other lights that turn off when the one you are controlling turns off, which I do.
So, @patrick, you said you do not see this with your Hue bulbs, correct? What do we need to provide you with so that you can see what we are seeing? Obviously this needs to be addressed at some point.
Yeah, I noticed it when working on a change to my DImmer Button Controller app I mentioned above. I've been doing a lot of testing and can definitely say that the problem is an "always" problem for me and not a "sometimes" problem with pretty much any of my Hue Bridge bulbs on both of my (Hubitat) hubs.
Since I want to use button presses and releases to issue a "start" and "stop" level change command, respectively (optionally, as an alternative to simple steps up/down with a press) but only change bulbs that are on at that moment, this pretty much prevents that from working (at least in the "up" direction; there's no harm in dimming a bulb that's already truly off, so I just send the command to all bulbs in that case anyway--but then Hubitat thinks they are all off for a bit, and the "up" commands that check for the switch state being on first don't work since it doesn't think they are on).
@mike.maxwell, @patrick I'm still seeing this problem. The startLevelChange causes the bulb's switch status to change to "off". stopLevelChange doesn't make any changes to the bulb status. The bulb status evidently refreshes on the next poll. It would be nice if startLevelChange would periodically update the status as well as stopLevelChange rather than waiting for a polling refresh.
Hubitat FW 2.0.7.126
Hue Bridge Integration set to 1 minute polling
Hue Bridge 2nd Gen
Hue RGBW bulb LCT014, hubitat driver: hueBridgeBulbRGBW
Turn bulb on and set level to 100
Current States
- colorMode : CT
- colorTemperature : 2732
- hue : 13
- level : 100
- saturation : 55
- switch : on
StartLevelChange "down"
Current States
- colorMode : CT
- colorTemperature : 2732
- hue : 13
- level : 100
- saturation : 55
- switch : off
StopLevelChange
Current States
- colorMode : CT
- colorTemperature : 2732
- hue : 13
- level : 100
- saturation : 55
- switch : off
wait a minute or so for polling to occur
Current States
- colorMode : CT
- colorTemperature : 2732
- hue : 13
- level : 74
- saturation : 55
- switch : on
I just got my Hue hub recently, and have migrated my CT Bulbs over to it, and a few of Hue's CT bulbs, and one Hue color bulb.
I am having what I think is a similar issue. When I hold a button on my button controller, I initiate a start raising or start lowering (depending on which button is held) and on release I issue a stop changing.
Neither the start raising nor start lowering seem to do anything. I can seeing in my button device, that the held event is triggered just fine. And if I just execute just the on/off (button push event) the on/off events work fine. I can manually set the dimmer level, and that works fine too (in HE).
Is this what you are seeing? How did you work around the issue?
so, I just found that the start/stop level change do work on hue, but not on hueGroups (zones and rooms). Do we know what the reason for this would be? It seems that if I so much as include the hueGroup, this will not work.
This was discussed a while back with Mike.
changeLevel issues a zigbee command that controls the bulbs...it is not a software driven command but a zigbee protocol command and not all devices support it.
At the time he said that he didn't believe the hue api supported the changeLevel functionality in groups so it was not included in the drivers. Not sure if that still applies today.
I just checked, the set state of lights and groups both support the same bri_inc and transitiontime. Maybe this can be added, or maybe there is another reason it is not used. Hopefully more of the capabilities can be added.
The problem with using this command for a group device is that all of the lights might not change at the same rate or begin changing at the same time. Since Hubttat is not issuing the commands directly to the devices, the hue hub is, there is no way to guarantee that they will all be at the same level when you let go of the button. If you were using a hue dimmer connected directly to a bunch of hue bulbs, they would all change the same because the dimmer is communicating directly to the lights, through TouchLink, rather than the hub doing it.
Are you sure about this? I have two dimmer bulbs in a group on Hue. I have a Hue Dimmer in that room. When I issue an on/off/brighten/dim event on the Hue Dimmer (attached to hue) the whole room is controlled not just the lights in the group. As I understand it, a Hue Room and a Hue Zone are both just Zigbee Groups. So when the dimmer is issuing a raise/lower event, the hue group receives that, and issues the event to the zigbee group. Is this understand wrong?
As i said....if the dimmer is paired directly to a bunch of lights. You can use the hue dimmer wihtout the hub at all to control a bunch of bulbs. I've never tried to connect it to a hue group. But if that is true that the Hue bridge is able to accept the command through the API for group devices, then it could be added.
I ran a test through clip. If set transitiontime to 50 (increments of 100ms) and I set bri_inc to 254 (the api range is 0-255). it slowly brightens all bulbs in the group equally (I tested with a hue zone to confirm this is not limited to rooms). I then issued a bri_inc=0 to stop, and they all stopped.
If I set the bulbs in the group at different brightness intervals, then when the room brightness is changed, the bulbs all increase/decrease in scaled units so as to not change the scene, just to brighten or dim it.
So, this is very much a workable solution.
I don't know how Hubitat implements startLevelChange (and stopLevelChange) with a Hue Bridge bulb, but...
EDIT: They appear to use bri_inc: 254 or bri_inc: -254 to start increasing or decreasing the brightness with a 3-second transition time, then bri_inc: 0 to stop wherever it happens to be. (This is what I discovered by temporarily setting up a diyHue installation to see what Hubitat sends.)
As armand notes, this is something possible for both Hue bulbs (/lights in the Hue API) and groups (/groups in the Hue API). I'm not sure why Hubitat would have implemented this feature on only one of the two, but it would certainly be possible to do it on both.
Scenes are a bit higher on my Hubitat/Hue wishlist, but this would be nice to see too. 
EDIT: I've released my CoCoHue integration that supports startLevelChange and stopLevelChange on both bulbs and groups and can also integrate scenes into Hubitat as button/switch devices.
I understand this could be problematic, but what I am stating is that the whether you set a hue bulb to a value, or the hue group to a value, the work on the HE hub is the same, and the solution on the HE hub is the same. Hue deals with this all the time, and the bridge handles this quite nicely, which is exactly why the lighting effects work so well. I am not saying anyone is wrong, I am stating that it should be possible, and it seems like a superficial limitation on HE. Other systems, like Vera do this without issue.
The scenes not appearing in HE is exactly why I am working on my own Hue Bridge Integration app. We need the scenes exposed to HE. Since Hue scenes are a child of a Hue Room or Hue Zone (collectively, hueGroup), it would make sense to create all the group's scenes as child devices to the hueGroup device. And this is what I am currently working on, except that it requires that I re-invent the whole Hue Integration components (at least at the group level) to get this in place.
Using HE Scenes with hue bulbs just is not feasible, because HE issues every command in sequence, and the effect is a process of all the lights taking turns to change to their desired state, where when the same scene is programmed into Hue, they transition seamlessly as one to the new state.
1 Like
This only makes sense when all of your lighting is through a hue bridge. Otherwise it makes more sense to build your lighting scenes in HE.
