I have noticed an issue when I try to use Start and Stop level change with a zigbee bulb connected directly to the hub. There is no ramp rate selection like there is for a hueBridgeBulb so the change happens so quickly it's almost impossible to actually adjust the level of the bulb. The change happens so fast that it's impossible to stop where you want to.
Also, with the Sengled bulb, using start dimming and stop control, I'm actually able to go to zero percent but the bulb doesn't change status to off. It would be helpful if while dimming the bulb stopped at the lowest logical dimming level rather than going all the way down to zero. When I issue a setLevel command of zero, it does turn off the bulb. Is this an error in the way it's handling start dimming?
I believe the startLevelChange is simply issuing a special ZigBee command, built into the ZigBee specification. So, I am not sure that Hubitat has much control over the ramp rate, unless it is something that can be configured in the bulb via a ZigBee configuration command. @mike.maxwell would probably know best.
I use Pico remotes to start and stop level change. Since the Picos are so responsive, I get pretty decent control over my Zigbee bulbs. I have the Picos configured to behave exactly the same as my GE/Jasco Z-wave dimmer switches using @stephack’s awesome Advanced Button Controller (ABC) App.
I remember reading somewhere that the ramp rate can be changed in the zigbee protocol but not with the zwave protocol. These are definitley questions for Mike.
Yes, but a hueBridgeBulb on Hubitat doesn't use ZigBee on the Hubitat side--it goes over your LAN through the Hue bridge. I don't know the specifics of how Hubitat's implemtnation works, but it's likely simulating "start level change" and "stop level change" by sending repeated brightness/level commands to the bulbs or group (unless Hue has added something to their API that supports this since the last time I checked).
Mike will probably have an answer on whether bulbs let you configure this or if there's anything the driver can do, but if not, you may be able to simulate the behavior you want via another method (multiple presses to step up/down by a specified amount with each press is, of course, one way you can cheat in the meantime if you're not set on the press-and-hold behavior).
Mike discussed this in the past. HE actually uses a zigbee command that is part of the protocol. That's why the dimming is smooth. Doing this through repeated level commands always leads to a jittery fade which is not optimal.
That's not the way it issues the command to Hue Bulbs though. I found this out the hard way. I am not using a genuine Hue Hub but a DIY version using an RPi Zero that also supports WiFi lights. So, they show up in HE as Hue Bulbs. Works really well....except for the start changing level. I took the logs from the hue emulator and sent them to the developer and he said that is exactly what HE is doing. Sending a bunch of level change commands all in a row. That's why it isn't working right for me. The weirdest part....the light dim perfectly, and at the assigned rate. They just show up as being off while they are changing. That one is just too weird. But that's an entirely different problem.
Certainly not for Hue bulbs that are accessed from Hubitat via HTTP(S), though? (Unless, again, Hue exposed or Hubitat reverse-engineered a new/undocumented API.)
To be clear, I'm talking about the setup where the Hue Bridge is added to Hubitat and the setup is effectively a LAN device from Hubitat's perspective.
The reason it's done differently with Hue bulbs in HE is because it is being controlled via the hub. As far as HE is concerned the hue bulbs are not zigbee at all. It is a lan integration using the HUE api. Lan api commands are sent and not zigbee commands. For zigbee bulbs attached directly to the hub, zigbee commands are issued and they support the changeLevel commands.
Yes...but the hue hub can be instructed to issue the start changing and stop changing command. In fact, the guy who does DIYHue was just adding support for that as it just reached the regular hue hub rather recently i guess.
Oh, I know...I just think it's funny that I'm having problems with two different lights for exactly the opposite reason. I mean, you'd think 50% of them would work, right? Even a broken clock is right twice a day. LMAO
Just bringing this thread back because I have started to buy some hue bulbs to replaces some of my other bulbs since with the newer Bluetooth ones it has the restore previous state feature (LOVE IT) and I know that the older ones were updated to do it but since I prefer to have the bulbs directly connected to my hubitat and i can still update the firmware as well as set the restore previous state feature via Bluetooth command all while not disconnecting it from hubitat.
Now the issue I have noticed is the Start level change command does not work at all now, when you click the option in the hubitat web UI it simply does nothing at all but the stop level change does seem to work (if you set level and change the duration to 10 seconds then click stop level change it does).
Is this something that others have seen issues with and hoping that it can be fixed as i was hoping to use it with the Dimmer Button Controller and this app uses that function.
I know this is a little bit of a different issue, but do you have any other Zigbee devices (motion sensors, smart plugs, etc.) connected to Hubitat? If so, Zigbee bulbs in general can be problematic here, but Hue in particular are one of the worst offenders. The issue is that they are bad repeaters for non-bulbs and may cause hard-to-troubleshoot problems, including dropped messages on your Zigbee network. This is summarized in Hubitat's Zigbee tips doc, but you can also find lots of forum posts about this (and similar bulbs that are also problematic, with other common offenders being Cree, GE Link, and at least first-gen Sylvania).
Again, that's another issue, but I'm just trying to help you avoid problems in the future (or now) if this is the case for you. The Hue Bridge integration is nice for that reason (though it doesn't support Change Level on groups; I wrote a custom integration that does for this and a few other reasons). It avoids this by keeping Hue on a separate network, thus keeping your Hubitat Zigbee devices happy. There are few advantages to directly pairing, IMHO, with one of the only being that you don't have to wait for the poll/refresh for changes made outside of Hubitat to be reflected inside Hubitat. I've otherwise had problems with them failing to respond on the first try to commands or bulbs as part of a group (even with Zigbee group messaging enabled) not all responding. I went back to the Bridge after trying the sometimes-recommended dedicated second-Hubitat-solution to this problem.
Back to your question: back when I did have directly-paired bulbs, I didn't notice this problem. However, I'm not sure I had any current/BT-gen bulbs at that time. Do you know if this is only a problem for the new generation for you, or if the older ones also experience it? I should also note that even though it did work, there was behavior I didn't like where I liked the Bridge bulb behavior better: startLevelChange(up) turned on lights that weren't already on, whereas the Bridge ignored this for bulbs that weren't on (individually or as part of a group). Additionally, if you didn't interrupt a startLevelChange(down) soon enough, the bulb would turn totally off instead of stopping at the lowest "on" level. Again, I know, tangential to the issue, but worth noting.
I am using other Zigbee devices and I did read that there could potentially be issues but I figured I would try it out and see how it works for me, I have been running the new bulbs for about a week and have not had any problems with my motion, contact sensors, humidity sensors, and Samsung buttons. So far the bulbs are all responding normally (aside from the level change issue) and I have not seen any issues with my sensors at all. I do have a Hue Bridge that i could put in place if issues crop up but as of now all seems good.
I unfortunately do not have any old gen bulbs to test this with, the other bulbs that I have (mostly EcoSmart Home Depot) do seem to have that same behavior for the down level change and but do not have the up level change issue. This issue is not a deal breaker or something that would force me over to the hue bridge but am hoping that this is something that could be fixed if it is fixable in a future update. I just am fairly new to the community and do not really know how I would go about reporting this as an issue or who I would report it to.
I am also seeing devices go through my hue bulbs without issue via the Parent child parameters page
Both of these devices seem to be going through a bulb that is a Hue bulb and they are working flawlessly, unless of course i am misinterpreting this info ..... which is possible, very possible.
I did submit a ticket back in June under request number 17475 but other than the normal response of it has been forwarded off to our engineering team I have not heard anything.
On another note related to above I have yet to have any issues with my Zigbee bulbs and having them on the same mesh as all my other sensors, plugs, and buttons. Everything seems to be working great together and I have yet to see any of the issues that have been discussed here and in the Hubitat documentation related to connectivity and reliability, obviously other than the issue with level change but that seems like a driver issue not a Zigbee mesh issue.
Like Robert said previously, I have the non bt hue color bulbs. I had them briefly on Hubitat, but they performed poorly compared with my Sylvania and Sengled color bulbs, so back to the Hue bridge they went. The start level change commands didn’t seem to be an issue. I’m pretty sure I would have noticed that since I use that with all of my dimmers and have never had a problem with it not working. I guess it might be something specific to the new bulb. Have you tried checking to see if the bulbs had a firmware update? I assume that you’re using the generic zigbee rgbw driver?
The bulbs are completely updated using BT from my phone and have all the newest features that hue offered including power loss recovery state, and is using the generic bulb driver (non rgbw version) but have tried other drivers to see if others would work and most didn't even work with the bulb itself. They must have made some changes to the hue hardware because I have had none of the described issues with any of the bulbs, or any of my other 60+ total ZigBee devices at all.
The Hue Bridge integration is nice for that reason (though it doesn't support 
