The driver is the Lutron Pico driver. I can't "open it".
The startLevelChange() is part of the changeLevel capability. This applies to a switch or bulb driver. The Lutron pico is a button device.
You would need to verify that the driver for the switch/bulb you want to control supports the new changeLevel capability (capability.changeLevel). At this point I believe this would only apply to the built in Generic Zwave and Generic Zigbee drivers.
1 Like
Oh, right. I'm confusing the driver for the light with the driver for the Pico. 
The lights are Hue, so I still don't have access to the driver, at least in any standard way. Since I have them going through the Hue hub, can they be changed to "Generic"? Or am I stuck for the time being until the Hue driver gets updated?
I spoke with @mike.maxwell about Hue bulbs and they are not supported..yet anyway :(.
The reason the smooth dimming works so well is because it is being executed using zwave and zigbee commands that are natively supported by the hardware (instead of the usual software trickery).
I hope the brilliant minds at HE can think up a way to make other devices support this....but it may take a while. Some things are better done the right way or not at all.
Can the Hue bulbs be connected directly to Hubitat? I've read they can be connected directly to ST, but also read they're a bitch to connect back on the Hue hub. Not sure I'd want to do that, but is it an option?
Precisely why I have never tried this. Not worth the trouble in my opinion.
I highly recommend using the hue bridge vs pairing the bulbs directly. Hue uses ZLL not ZHA for bulbs and limits the channels. I put all my zigbbe bulbs on hue bridge and everything else ZigBee on Hubitat.
1 Like
in HE they can be directly connected, and when excluded properly. they can rejoin the hue bridge without issue, that's been my experience anyway.
When I initially developed the zigbee RGB drivers I paired all the hue devices that I owned, wrote the drivers, excluded them from HE, then paired them with hue again, I don't recall any issues doing this.
Bulbs that can pair with Hue, I leave paired to the hue bridge, partially to advantage the hue group support, which issues zigbee group commands (ie no popcorn), but also zigbee bulbs in general don't have a great track record in my book functioning as routers. YRMV of course.
I've not investigated adding changeLevel to the hue integration, and given that changeLevel implements low level zwave and zigbee commands it might not even be possible to support it via the hue integration, same for Lutron dimmers.
If I'm best off by leaving the Hue bulbs attached through the Hue hub... I really want the hold-to-dim functionality. It's the intuitive use for a dimmer button.
The only thing I can think is to "fix webcores button code" (per @mike.maxwell), which aside from almost certainly being beyond my abilities, still wouldn't produce a smooth effect.
Does that leave any options for smooth hold-to-dim?
fixing buttons in webcore isn't going to help smooth dim your hue bulbs using an HE button controller.
I have a Osram Lightfy zigbee RGBW light strip that I wanted to pair with my HUE bridge but I couldn't figure out how to get it to discover. It paired immediately directly to Hubitat. Have you had any experience getting one to pair with HUE bridge?
I have not, but I have heard that depending on age, getting the lightify hub and pairing it to them and doing a firmware update might make them work with Hue. Just going off 3rd party information, not anything I have personally done. My bulbs are Hue, GE Link and Cree that are all working on Hue Bridge.
1 Like
I've tried this, no success, doubt they work.
1 Like
Why do the Pico devices show multiple buttons being pushed or held? For instance:
Current States`
- held : 3
- pushed : 4
- released : 4`
I see the number represents the button number, but if that is the "current state", is that maybe what WebCoRe is picking up on?
If I could use WebCoRe, then with the "released" functionality, then "held" could initiate a "fade", and relase could exit the piston. It's a moot point with WebCoRe not working right, but how do we know it's WebCoRe and not the Pico driver?
Fixing /enhancing webCoRE is not a trivial task. There is a ton of code there...
My advice would be for you to look at @stephack’s Advanced Button Controller application which he updated yesterday to support the new Pico remote’s released events. It works amazingly well with directly connected bulbs.
So, I would think you could start with it and hack it to attempt to implement some sort of stair-step dimming for your Hue connected bulbs. I doubt it will work well, as sending repeated commands in rapid succession is likely to cause isssues.
1 Like
That won't help me unless I were to get any bulbs that connect directly.
That's what I have for individual button pushes. I can improve on it a bit, but essentially it increases/decreases by a 1/3rd, with a minimum of 1.
Did not know about groups. Very cool. No more popcorn. At least that's something accomplished today.
This just shows the last button that was pushed/held/released. WebCore would use "events" and not "states" to execute actions so this is not likely the issue with webcore.
A while back I took a look at the button sections of Core to see if I could assist. I can tell you that getting this to work with hubitat is not a trivial task as there are multiple sections that would need to be edited in very specific ways....ST and HE have different button implementations. If you are set on using core, you should reach out on that thread to see if any of the gurus over there are willing to dive in.
Even if I knew what to look for what needed to be "fixed", I wouldn't even try. I have no illusions of being able to do that.
I'll post to the WebCoRe thread, and hope, because I really want the progressive dimming, and really do not want to directly connect all my Hue bulbs.
Same here ...webcore is a monster. But there are folks over there that are doing great things with it. It could hurt to put in a "feature request". 
