@jebowers I used a method I found on the Hubitat forums to pair my bulbs with no security on a C7. If you start the inclusion timer and turn the bulb on for 3-4 seconds, then off for 2-3, then back on for 3-4, then off for 2-3 and repeat until the device starts to initialize it should pair the bulb but fail the security handshake. Worked for all 3 of mine, it may take a few times to get the timings right but it was pretty easy for me.
@EricM_Inovelli I’m having the same problem. LZW42 dimming speed is fast when controlled directly from the hub, but is very slow when controlled by the dimmer via direct association. In my case, if I start with the dimmer at 100% and hold down to dim to about 10%, it takes the bulbs another ~3-4 secs after I release the dimmer to reach that level. I currently have this setup on Smartthings and Hubitat C7 (I’m mid transition to C7) and behaviour is identical on both hubs. Bulb and dimmer firmware are both the latest (2.30 & 1.48).
Is there any possibility of a dimmer firmware update that allows the bulb speed to match the dimmer when using direct association?
This part seems a little off to me. Are you only controlling one bulb or multiple? What is the distance between the dimmer and bulb(s)?
I’m controlling two bulbs. One is about 5 feet from the switch and the other is about 12 feet.
On/off commands from the switch are nearly instantaneous, it’s just dimming speed that is very slow via association.
Ok so I seem to have solved my dimming speed problem. I was playing around with the associations (I had them setup for group 2, 3 & 4) and group 3 was the problem. After deleting it, the bulb dimming speed tracks perfectly now when holding the dimmer. I had setup group 3 initially so I could set the dimmer via Alexa, but I figured out another work around for that. Out of curiosity, do you know why the bulbs respond slower with group 3?
Glad you figured it out. I don’t know why it would be slower with group 3 unless there was an old device node id in that group that it was trying to send to. Other than that I am not sure.
@EricM_Inovelli Is there any way to set an association default level/color/temp when these are paired with a switch? Basically be able to set it so anytime I press up on the switch it turns the lights to 2700K and 100% no matter the previous state of the bulb.
You can’t do it with associations, but you could use a scene to accomplish that if the up button is pressed. Something like “If button 1 is pushed then set the bulb to 2700K @ 100%”.
Had a feeling that was the case. Thanks for the reply!
Curious if any progress has been made here. S2 added would still be preferred so we can use the switches at S2 and associations to the bulbs.
@Eric_Inovelli I think having S2 added to this bulb and the further refining of SmartBulb Mode everyone is talking about on the switches makes it an incredible combo.
Hey great question and we just talked about this last night with @JasonL_Inovelli.
Basically, it’s going to boil down to whether or not we have enough space on the bulb to add an option for no security. We’ve confirmed it isn’t possible to make an S2 version of the bulb due to the millions of color combinations and extra room S2 takes up.
So, the options are:
- Bulb = Two inclusion methods: S0, & No Security
- Switch = Three inclusion methods: S2, S0, & No Security
My homework is to figure out what we need to refine on the switch to make room for the various inclusion methods. I’ll be doing that today!
Honestly if S0 is the best we are going to get, than I see no benefit of working towards adding no security.
Dont the bulbs already support no security? I never added a security key, and all my devices were successfully set up without security.
Well, we have to do this for SmartThings as the platform doesn’t allow you to choose your security (or no security) method and we need it to match security levels to be able to associate.
In other words, if you pair the bulb to ST, it will automatically pair as S0. Then when you pair a light switch, it will either pair as S2 or non-secure (if it fails the S2 pair).
So, you’re stuck with a switch that is either S2 or Non-Secure mixed with an S0 bulb (as non-secure can’t be selected).
Hopefully that makes sense?
Yeah, sorry, I should’ve been more clear – there is only one way to include the bulb currently and I believe (@EricM_Inovelli can correct me if I’m wrong) it defaults to S0 and then if it fails, it pairs as non-secure.
What we’re trying to accomplish now is to allow various methods of inclusion.
- Turn on/off 5x = S0
- Turn on/off 5x + rub your tummy = No Inclusion
Something like that lol
This feels off. I had association set on ST before moving, I am 100% sure of it (bought over the association into HA and now can see it). I never scanned in any codes or anything and just skipped any codes when setting up the switch. I believe they were both no security.
When did you do this? This used to be the case, but then something changed: [HOW-TO] Using the Z-Wave Association Tool in SmartThings - #114 by LA_MATT.T
I see. This was 2019, so a way long time ago. Makes sense!
Yes it changed sometime in early Dec last year. I setup a dimmer and two bulbs both with S0 and had no issues, everything worked. Tried same thing again in Dec with a different dimmer and bulbs and pairing the dimmer as S0 was impossible, it kept pairing as S2 failed.
This was my motivation to switch over to Hubitat so you can select your security level.
And I agree it would be great to have an option to add the bulbs with no security. I have them setup that way now with Hubitat but it was a real pain to get them added, you have to disconnect power every few seconds during inclusion so that it fails S0 and pairs unsecured (found this trick on the Hubitat forum). Advantage of non-secure vs. S0 is the bulbs respond much quicker. There was a small but noticeable delay when I turned them on via association with S0, and each bulb didn’t turn on at the exact same time. With no security they turn on instantaneously and at the exact same time. If you’re OCD like me it makes a big difference!!
Yep, this is correct. One possibility is to get the bulb to fail S0 inclusion by moving it far away from the hub. This isn’t very reliable though and can be hard to accomplish.