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.
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.
I'm not being hostile. I just don't agree with you. Is that not allowed?
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.
But that is only possible if you have all of your lights connected to a Hue bridge. Otherwise, it is pointless to have a scene defined twice.
I agree with you that there is a problem with the way that Hubitat has implemented the start level change and stopLevelChange commands with regards to Hue, but if you look at the commands coming out of the hub, it is more related to the commands that they are sending. When the startLevelChange("down") is sent, Hubitat is requesting a briinc of -254. That is what is turning the switch off immediately. I have talked this over with the folks that developed and maintain DIYHue, the biggest Hue Emulation platform out there.
But the reason that the switch states of your lights is not updating is due to the fact that you do not have the polling turned on for you bridge. If you did, Hubitat would eventually poll your Hue bridge and then get the correct switch and level settings for the lights.
The refresh is flawed. The other integrations for hue, like the vera, don’t have this problem. They are rather seem less actually. But, if we ignore these other systems, we can fix the capture state by establishing a a hook into the refresh. The refresh function can have an attribute or state that gets set when the refresh is initialtied and then when the async call back if the refresh is completed. Then in the rules, a capture state operation could be as simple as device refresh then wait for event. But, for this to work, they need to support a per group or per device refresh, which I do support in my implementation, but they do not. As for syncing, the focus on accurate syncing is misplaced. The current process is broken. So it makes zero sense to leave it completely broken when it can be a lot better. I would rather my room or zine can change state in synchronization with each other while the other devices change state at different times more than having them all be controlled one at a time. And this is what drove me to create my own integration.
The problem is that I cannot create a “scene” controlling app that integrates with the current one, but they can modify the current one. As stated previously, you can programmatically create scenes in hue, and update them from Hubitat. So, it would be trivial to create a hue zone with a hue name (say, HubitatScene-xyz) that has all the lights that are defined by the he scene selected lights and rooms. Then create a scene in the zone with some arbitrary name, say HubitatMamagedScene). The beauty of this solution is not only does this allow seem less control and manipulation of the scene it also allows for checking if the scene is on, because with the zones are can get the state of all the member devices when asking for state from the api.
No, you have to refresh the bridge...not the individual lights. That's not my point at all.
Exactly part of why it is flawed. Refreshing the hub means downloading the entire hub configuration for all the groups, lights, scenes, hub configurations — everything. Then this has to be Parsed from JSON to a java map that groovy can understand (part of the slurped) and then almost all of that data will is thrown out just so you can update a few devices or groups. And all the scene data and all the device data not imported is discarded. A full hub refresh on a large hue system can take about 0.5 seconds or more. And the refresh command is a blocking command that initiates a non-blocking async call to the hue http api service which then returns the results to a result handler that is not part of the refresh command, because it is async. That refresh result then has no idea that you just need to capture changes or just need to capture the state of a single device. This gets problematic if you are not able to fully control hue by just the unit at System, or is the hue has some integrations of its own that that change the state. So now, you want to capture state, but you can never be accurate, just mostly right, because the hue system refresh is so heavy of an operation in He that you cannot check every 5 seconds or less without causing performance issues. And again, the system is now doing 100% of the work to update 1% of the devices.
This is wrong. It is fine for a once a minute or once every 5 minute interval thing. But when you just want to capture the real state of a bulb, you should be able to make that call which takes a few milliseconds, and if the refresh system could identify when the refresh has completed, then all that wasted work goes away, and we limit the chatter to only updating the specific light or group that we are interested in, and making it possible to now fire a capture state event immediately after a refresh event of just that one device has occurred.
It is not that he’s to understand, yet I feel like I am being pegged as the bad guy or the forum idiot because I am proposing a simple change that makes things better and that actually works right.
#1 you're not even listening to me....i was agreeing with you about the level change issue. So, take YES for an answer.
#2. You're just wrong because Hubitat has to update all of the light states every few seconds to catch any changes made outside of HE. Otherwise they wouldn't be picked up in HE.
What would be better here? Since bri ranges from 1-254, I suppose a bri_inc of -254 would bring a light at full brightness all the way down to 254-254 = 0, which Hue doesn't support and whose behavior I'm not sure is defined, but doing this on my official Bridge has always just made it as low as possible, presumably 1 (but definitely not off); I'm not sure how diyHue handles that. Are you thinking -253 (which would, at full brightness, be 254-253 = 1, a defined value), or more generally a maximum absolute value of the current brightness level minus one? Or am I missing something bigger?
I'd appreciate any input here, having worked on a custom Bridge integration (more on that below). Currently, I'm doing everything the way Hubitat does in the interest of making it as much of a drop-in replacement as possible, except for slight differences in Group behavior and extensions to features or addition of missing features, the reason I started it in the first place.
I also wrote my own Hue Bridge integration and contemplated whether to implement refresh() on individual bulb/groups or just for the Bridge device that would get everything. I may do it on individual bulbs/groups some day, but for now, I did it the same way Hubitat does--the Bridge for everything. My reasoning is that I have it doing an async HTTP call out to the Bridge anyway, so it does that, wakes up for the response, and parses some data there. Hue is limited to 50-ish lights and I'm not sure how many groups, and my guess is that parsing this data shouldn't take much longer than doing it for just one or two bulbs since I'm again guessing that the bulk of the time and work is spent doing the HTTP call and callback, not processing the response. I could be wrong. I don't really have good profiling tools in Hubitat to see for sure. I'm certainly open to changing this sooner if anyone finds a significant difference, and I might do it at some point anyway, but I'm guessing the behavior with doing more than a couple bulbs or groups at the same time would actually be worse (especially with rate limiting on the Bridge over HTTP). Again, totally open to data that may suggest a significant difference.
I also wasn't sure how to handle scenes. If you get just one scene from the Bridge, you can view the associated lights and their settings. However, that isn't retrieved if you just retrieve all scenes, and if you only retrieve it when the scene is first brought into Hubitat, there's no guarantee the user didn't change it later via another app--so "polling" of some kind would be required to make sure that information is still accurate. My integration doesn't handle updating light or group states at all after activating a scene, with my suggestion being that the user poll if needed. I may add in an option to automatically get the information for the associated scene (and lights/groups), but I think I'm more likely to just add in an option (or suggest to the user) that they refresh the Bridge for everything. Again, I'm not sure there'd be a significant performance difference and am open to ideas here.
I handle scenes as child devices of the group. The scene is a momentary switch device. Groups and lights support a refresh, which is a subset of the device refresh. By default, group and light refresh is disabled, but can be enabled and a custom interval defined. The hub device also has a refresh, and refresh intervals. All device refreshes are performed by the parent integration app. As such, if a hub refresh is performed, all child device refresh schedules are reset. If any child device refresh is performed the scheduled readership (if one is pending) is reset. The idea is that I never prohibit a manual refresh but any refresh resets the clock for the next refresh.
I do not, at this time, try to integrate my hue scenes with the other scene controller apps, as it would be easier to write a new one from scratch, so instead, I just trigger the scene from the he scene. It works beautifully now. I need to implement the whole gamut of light types still, and implement some more fine tuning before I release it. Once released, I will consider the scene controller app of my own, but I really think leveraging the built in one is the best choice as it will allow the Zigbee grouping to work well.
