Inovelli dimmer and smart bulb control - slow

I’m new to all this, so apologies for dumb questions.

I have some Sylvania Smart+ recessed cans on their own circuit (constant power to the lights) and a new Inovelli Red dimmer (also constant power to the dimmer…nothing connected to the load side). I added the DTH’s per Inovelli’s instructions and then added a smart lighting automation for the lights to follow the switch. Everything works, but there is a palpable delay (sometimes several seconds).

Also, the lights don’t all turn on/off at EXACTLY the same time, which is a little annoying. If I mess with the lights via a lighting group in the ST app, they are perfectly in sync.


Do you have the automation setup with smart lighting using the mirror function?

Yes, the Sylvania lights are set to mirror the Inovelli. The setup “works” in that it does exactly what it should do, except there is a noticable delay (press the Inovelli switch, wait a second or two usually, then lights react).

1 Like

Hey @Aegwyn11 – yes, this is, “normal” in that unfortunately the device handler used processes in the cloud (vs local). So, depending on the cloud connection, there may be a delay.

Tagging @Eric_Inovelli

Thanks for the response.

Is there any way to make it local (other than waiting for the Inovelli to be certified as WWST)? Side question - any clue when that might happen?

Also, any ideas how to make the lights function better as a group? On/off sync with the smart lighting automation is close, but not perfect. On/off sync using lighting groups from the ST app is PERFECT, but I don’t see how to tie a lighting group to automations.

The lighting groups within the ST app are backed by protocol specific device groups, in this case a single Zigbee device group which serve the specific purpose of getting all the devices to act as in-sync as possible :slight_smile: This is actually a very new feature to the platform so we are working to get it to be a full first-class citizen in all aspects of the ecosystem, one of which is being able to have automatons trigger a device group. I don’t have at timeline for you, but it is coming!


@Aegwyn11 are you using any of the advanced features of the Inovelli switch such as multi tap? if not, you should be able to switch it to the generic z-wave switch (or dimmer) handler and have it run local. You could always test this temporarily to see if it works faster.

1 Like

Yeah, this is a great question and one that I wish I had better news about. So, there is no local device handler that I know of that allows Z-Wave Scene Control (which is what I’m guessing you are using – ie: used Smart Lighting and Button Control). If there is, I’d love to know about it too :slight_smile:

As for the WWST Certification, unfortunately, even when they do get certified, ST is not certifying it with our device handler. Instead it will be certified to work with the Generic Z-Wave handler. This was disappointing to us, however, I do see their rationale. Basically, with the new app, ST wants to make it easy to pair things for beginners and once you’re WWST Certified, your logo shows up and it’s easy to start the pairing process. A group of manufacturers all share the same generic handler, but our, “fingerprints” (ie: the manufacturer number, model number, etc) are what determines what brand shows up during the inclusion process.

In other words, it will say, “Inovelli Z-Wave Switch” or something when the switch is paired and use the Generic handler.

The pros to this method is that people who are newer and may not have the experience of installing a handler (or just don’t need the advanced features) have an easy time and aren’t overwhelmed by all the options available.

The cons to this method is that in order to get all the advanced features, you still have to install the device handler and unfortunately custom handlers all process in the cloud (although hopefully this changes soon – I’m honestly not sure).

So, the net of it is, at this time, if you are using a Z-Wave switch with a non-Z-Wave bulb, there’s really no way to control smart bulbs outside the cloud on SmartThings.

If you do have a Z-Wave bulb, you can actually use a tool that @erocm1231 created called a, “Z-Wave Association Tool” which you can find on our GitHub. Once associated together, the switch and bulb do not need a Hub to talk to one another, but rather talk directly via Z-Wave.

Hopefully this clears some things up!


I tried changing the device type to generic zwave dimmer switch and saw basically the same operation…the switch dims to off, there’s a delay for the cloud, and then the lights act.

So based on what @Eric_Inovelli is saying, there’s NO zwave switch (not even the ones that are certified WWST) that can control Zigbee smart lights without going to the cloud?

At this point it seems like my best bet is to set the dim time on the switch to 0. I lose dimming functionality at the switch, but can still do it from my phone I guess. Just means that for me in this application, a dimmer switch is the same as an on/off switch.

Device type “z-wave switch generic” runs local, as does “z-wave dimmer switch generic”.

Can you provide a link to the zwave association smart app? Is it similar to zwave tweaker?

The lights will need to run local also, so the switch alone will not make a difference.

Aren’t my lights already running local? They’re Sylvania 73742 recessed lights, listed as WWST. When I turn them on or off from the app, they react basically instantly with no discernable delay.

So with the switch using the generic z-wave DTH (that is also supposed to be local), why do I get the delay?

Would I be better off spending the extra money for a Zigbee dimmer like this: GE 45857GE Zigbee Smart Dimmer In-Wall Lighting Control, Neutral Wire Required Works Directly with Alexa Plus, Echo Show (2nd Gen), White & Light Almond

BTW, side note, the version of the 73742 that comes in Osram packaging sucks! I received and installed the last of the lights for that room yesterday and one of them was in the Osram packaging (the other 8 were in Sylvania packaging). In IDE, the Sylvania packaged ones show with a manufacturer of LEDVANCE while the Osram one shows OSRAM. The Osram one never turns fully off, just to a very dim blue (I saw others reported that issue with the 73742). The Sylvania/LEDVANCE ones turn OFF. Also, I was having some issues with the Osram one not responding as reliably/consistently as the Sylvania ones. Updating the firmware didn’t help the dim blue issue…not sure about the reliability issues. Annoying that a different piece of hardware is shipped with the same model number.

Yeah certainly!

There are two of them that have to be installed. I’m not entirely sure how close they relate to Z-Wave Tweaker, but would be curious to know!

I don’t believe so, but curious to hear what everyone else has to say. There will still be some sort of delay as the Z-Wave signal has to be sent to the Hub, interpreted, and then a ZigBee signal will have to be sent to the bulbs, but if both handlers are local, then it shouldn’t be that bad of a delay.

Also curious, how’s your internet speeds? Nathan, who works here, has issues with ST processing speeds due to living in the country and not having fast internet, but again, I’m not sure how that relates to local processing. Just wanted to throw it out there.

I definitely experience the exact same behavior as you with my non-Z-Wave lights (heck, even some of my Z-Wave ones that aren’t associated do the same thing) in my basement. I have a single-tap up on a switch which sends a scene to turn on all basement lights (as they’re not connected to the same circuit) and most days it’s about a 1-2 second delay (enough time for me to make it down the stairs) and then other days it can honestly be like 5-10 seconds which is super annoying.

So, I completely understand the frustration and hope that one day this gets sorted out at the Hub level as well.

Regardless of the route you take (ZigBee switch w/ZigBee bulb or continue down the Z-Wave/ZigBee path) I wish you the best and know that I’m over here living the same scenario at my house lol.

We live in BFE, but got fiber about 6 months ago. As such, speeds are great and consistent (single digit pings to stuff relatively close like Netflix servers).

I’ll play with the generic handler for the switch a bit more today and report back later. I did change the ramp rate to 0 and that helps a lot, as is seems the mirror smart lighting automation doesn’t happen in real time, it only happens in the lights after the action on the switch is fully complete (which is obnoxious).

Maybe if/when I do non-recessed can lights, it might be better for me to do zwave lights. We’ll see.

1 Like

Have you checked the ide to make sure all the associated devices and the automation itself are running local when doing your testing?

Showing my newbieness…how do I do that?

Duh that was a dumb question. It’s obvious if I just look a little.

So I got it all working locally. It seemed like in order to get the Smart Lighting automation to run locally, I had to first change the switch to a zwave dimmer generic, and then create/delete a new automation using the lights and switch. After that, the original automation updated to run local. Before I did the create/delete step, the automation was still showing cloud (maybe I just didn’t wait long enough? :man_shrugging:).

That said, it doesn’t seem to make a huge difference running local vs. cloud, but it’s also the middle of the day. The biggest improvement was setting the switch’s ramp time to 0. I’ll have to tinker with it more tonight when there’s more traffic on the interwebs. Then I need to decide is scenes from the switch is worth having it lean on the cloud or not.


Let me know if you make any more improvements. I am in the same boat as you and already purchased 24 of the Lightify recessed can lights for the house.

My fallback plan is to set up some “scenes” at different dim levels (e.g. 2x up for 100%, 2x down for 75%, 3x down for 50%, etc.) to control dimming at the switch, and then just have fine-dimming and color control done through Alexa.

I am also considering looking into Hubitat in place of Smartthings, but my frustrations haven’t gotten to that point yet.

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.