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
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.
I disagree. If He commands 15 Z-Wave and Zigbee lights to transition to a certain state, and another 10 hue lights in a zone, that is 10 http calls that are reduced to just one http call to the hue, and the end result is still a smoother transition to the final state. I am working on this for a friend that has a lot of hue lights as well as other lights, and it takes way too long to watch all the lights slowly transition one at a time.
It makes sense to leverage the scenes and groups.
One such technique would be to program an heScene in hue for every He scene created/updated, so that HE simply triggers the scene knowing the scene matches HEs scene. Granted, this may require some changes but it is certainly possible. And would make the integration more seamless.
That's controlling a group. My comment was specific to scenes, not groups. If you have a scene created in HE and one in the Hue App and you want to change it, you have to change it two places, rather than one. For scenes, it makes no sense to me to use Hue scenes unless you can do all of your scene control within the Hue environment. Plus, how does Hubiat know if the scene is active or not if it has not idea what the scene settings are. Hubitat knows whether a scene is active by matching the settings of the scene to the current device attributes.
Well, as I stated, the Hue API can be used to create scenes. Hubitat, should be able to program the scenes of HE groups by creating HE specific scenes in Hue to match the He scenes settings. It can determine if a scene is active on the group, by asking the group for the active scene. Or by querying the group’s member lights like it must do now.
Not sure where the hostility is coming from. I simply pointed out that there are short-comings in the HE implementation of Hue that other systems don’t have, and I am working on a solution to address them, since they are not supported natively now.
Scene settings are exposed during every hub refresh. In fact, the scene settings can be retrieved as part of the hub refresh (http://`host`:port api/uid) all scenes refresh (http://`host`:port api/uid/scenes) or specific scene (http://`host`:port/api/uid/scenes/id)
The scene setting can also be assigned using an http-put method. Each scene is owned by a group, and can have multiple bulbs associated.
This is not theory, this is documented in the hue developer documentation.
I actually completed my hue integration app for scenes and groups, and a friend of mine has completed switched over, and Inhave partially switched over. I have not yet implemented support for lights, and I have not yet implemented the ability to program the scenes, as I will need to create a scene controller. But for now, it has made our scene automations seem less, and smooth. When we trigger an HE scene, it turns in the Hue scene device and the the hue lights change state in synchronization, as opposed to the HE native solution which is one at a time...
When I finish making my changes to support lights, I will likely add a capture scene command to the scene device, to set the scene to the current state, this will make it possible to integrate with the built-in He scene controller better.
