SBM (param 52) is a dimmer option. You should disable local protection (probably remote too). You associated the switch to the bulbs with group 2?
Hey @misterk71 – building on what @stu1811 said, unfortunately, we weren’t able to get the official, “Smart Bulb Mode” integrated into our On/Off switches due to what the manufacturer said is a space issue (our dimmer switch has two MCU’s whereas the On/Off only has one).
But to disable local protection, you can do it a couple of ways:
- Via the switch itself = tap the config button 8x fairly quickly (the LED bar should blink red) – make sure the switch is on prior to doing this
- Via the UI in Hubitat using the Inovelli driver (there will be a section that says, “Disable Local Control” or something like that)
As stu mentioned, you may want to disable remote control too so you don’t inadvertently turn off the switch remotely – this can only be done via the UI in Hubitat.
Once you have local protection (and remote if you want) enabled, you can follow these directions: https://support.inovelli.com/portal/en/kb/articles/how-to-use-the-z-wave-association-tool-hubitat
One caveat is that both the bulb and switch need to be on the same security level (ie: S0 or non-secure). If you need help here, let me know – I can explain further 
1 Like
@stu1811 Yes, the association is to group 2.
@Eric_Inovelli I have the bulbs associated and local control turned off. Easy peasy, that one. What I cannot do (with local control turned off) is turn off the bulb at the switch now. That’s where I’m confused
Are the bulbs and switch all included with no encryption or S0?
As the man said “Well, there’s your problem…”
Switch and bulb are both S2. So, I need to exclude them and re-add with S0? The bulbs joined with the S2 level without me doing anything, but I’m sure I can figure out adding them without security. Or just use a Red dimmer.
Yeah figured this may be the case lol.
So, the bulb actually doesn’t have S2 built into it – I have seen that Hubitat shows S2 = Yes sometimes, but idk why it is.
What I would recommend for best performance is no-security.
To do that, you’ll have to make sure your bulb is on firmware 2.31 (if you purchased it and the bulb says, “Inovelli” on it, then you’re good – if it says, “Ilumin” on it, then you will need to upgrade – let me know and I can show you how too).
Assuming you have 2.31, when you include either device, I think a security popup will show up that asks what level you want – uncheck all levels and the bulb should pair without security. If there isn’t a popup that shows up, then you’ll have to do it the manual way.
I know this is a SmartThings tutorial, but it will show you the cadence of how to pair the bulb: Non-Secure Inclusion (Pairing) | Inovelli RGBW Smart Bulb | SmartThings - YouTube (start at the 22 second mark).
Hope this helps?
No joy.
I excluded and removed the bulbs and the switch. Re-including the bulbs and then viewing them through Z-Wave details shows them to be in S0 state. This happens whether or not I do it from the Hubitat or from the bulb manually. The switch can be added with security None (if you skip the DSK step) or S2. The pop up you’re thinking of hasn’t been a thing for a couple of firmware releases, though I don’t know if that’s a Hubitat firmware issue or a device handler issue. Regardless, it doesn’t happen.
This is way more effort than I’m willing to put in. I’ll reuse the switch somewhere else and just put in the dimmer that I was planning on using in another room. If that doesn’t solve it, I’ll just go back to the dumb switch with a kid-proof cover and return the bulbs in favor of the Nanoleaf Essentials that I had prior to this installation.
Thanks for your help @Eric_Inovelli and @stu1811.
Alright, sorry for the frustration. I’ll mess around with it when I’m home tonight and write up a tutorial. I’ve been slowly adding to the knowledge-base and have been dealing primarily with associations, so I’m happy to play around with it to save you some time :).
Hopefully it’s a simple fix!
No worries! Thanks again
1 Like
After some further reflection, research, and retrying…
S2=128 actually means S0. S2=131 indicates S2. The bulbs are definitely going in as S0. That could be the cause of the confusion, but I’m no electrical engineer!
It’s the Hubitat. The C7 defaults to adding with the highest security protocol available to both the hub and the device, so it’s never going to bother throwing up a selection.
All that said, I got it working on the Red Switch after playing around with the dimmer and running into the exact same problem. I did the “turn it on and off three times” during the inclusion of each bulb and got it to include with no security. I’m not happy about that security being off, but it at least works. The association of the bulbs to the switch worked on the first try and is super responsive.
Once again, thanks for the help, and the quality products!
*EDIT - Ya know, I used to get a pop-up from this hub when adding devices, so I cannot definitively say it’s the Hubitat that’s being obstinate. Do the handlers control the inclusion dialog? Is there some way to tell the switch to default to S0 instead of S2?
1 Like
Not exactly, but probably close enough for most cases. 
In the event you care: it’s actually an 8-bit field where the “first” (highest) bit represents S0 (10000000 in binary = 128 in decimal) and the the last three bits represent S2 Access Control, S2 Authenticated, and S2 Authenticated, respectively. I assume the bits in between are reserved for future expansion. So, you’ll get different decimal values out of the resulting binary values/bits. If you only have exactly one grant, you’ll get something like:
| Class/Bit #: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | = Decimal: |
|---|---|---|---|---|---|---|---|---|---|
| None | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| S2 Unauth | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
| S2 Auth | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 2 |
| S2 AccCtl | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 4 |
| S0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 128 |
But if you have multiple grants–like the dimmers that will probably do S2 Authenticated plus everything “below” that by default–then you can end up with other values. For example, two possibilities:
| Class/Bit #: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | = Decimal: |
|---|---|---|---|---|---|---|---|---|---|
| Auth+Unath | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 3 |
| S0+Auth+Unauth | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 131 |
So, that’s how you get 131. Theoretically, that should work with Association to the S0 bulbs since both the dimmer and bulb have S0 in common, but some people have reported issues when everything doesn’t match (I can’t attest to either outcome or the other; just repeating what people have said and what should work). And my recommendation would be to skip security on the bulbs entirely since they only support S0 for reasons you’ve probably already discovered, so I guess this doesn’t really apply in that case…just some history.
No, that is handled at the hub level. A couple hub firmware versions ago, they removed the choices in the S2 popup (possibly because people were getting confused about what grants to check or not). Now you can either “Confirm” or “Skip,” where “Confirm” will use the default grants (and prompt for the DSK if necessary) and “Skip” should avoid security entirely.
However, this popup would have never — and still won’t — appear for S0-only devices where the device requests S0 during pairing. This is a limitation of the “official” Silicon Labs Z-Wave 700 SDK that Hubitat is using. Devices can work around this by providing a different pairing process for S0 vs. non-S0, which Inovelli recently added to their bulbs, but it does require some precision, and a secondary controller is still probably the easiest way to avoid this. (The other option for the vendor would be to add S2, avoiding this entirely, and now required for newly certified devices.)
With an S2-capable device like the LZW31(-SN), you used to be able to un-select any or all S2 grants and use only S0 if you really preferred that (assuming the device itself still supports S0; I’m not sure if the spec requires this). But that’s probably the worst of all possible ideas, since S0 can be pretty chatty on your network, and unless you really want it, it would be better to just go non-secure.
1 Like
Dude! Thanks for the education! Any day where you learn something can’t be a total loss
@misterk71 – this is awesome news. I know I sound like a dork, but I literally did a, “hell yeah” with my fist bc I was excited you figured it out lol.
Nice work
EDIT: Forgot to give a shoutout to @BertABCD1234 – man, I don’t know how you are such a wealth of knowledge, but I swear every time I read something of yours, be it here or over in the hubitat community, you always teach me something haha!
I am wanting to add my bulbs unsecured, but they keep joining in S0. Could you please give more info on the 3 on/off during pairing that adds them unsecured. I don’t see that info anywhere. Thanks!
Sure! You’ll need to update your bulb firmware, and you can see both that and the pairing instructions in this thread:
An alternative method, which will work with any bulb firmware version, is to use a secondary controller to join instead of Hubitat.
Thank you! Im Hubitat but it appears to be the same. I just got my bulbs from Inovelli so im on new firmware. When i control 5 bulbs at one time, the chatter from the S0 logging darn near creashes my Zwave.
Yeah, they only call out SmartThings in the release notes, but the change should help anyone on a 700-series controller that uses the official Silicon Lana 700-series Z-Wave SDK (and I believe Hubitat was the first such hub). Some people have still found it difficult to do that exact pairing sequence, so I’d double-check when you’re done.
I’m not sure if or when they started shipping bulbs with newer firmware, so you might want to verify that too if you haven’t (not doubting you; I just don’t know).
Good luck!
1 Like
Here is a video of me putting the bulbs into non-secure pairing mode.
That is where all the inventory went!