I haven’t seen much about this issue on the forum, but there’s a known issue with V2 where the “set dim level” commands often simply do not work. Several weeks ago, support said a fix was imminent, but now who knows what’s going on or when the fix will go in.
I’ve since discovered that the issue is NOT limited to just in the Smart Lighting app. The issue seems to only be a problem when trying to have a light come on at a certain percentage when triggered by a motion sensor. The same problem happens if I set up a routine. Let’s say I have a routine that turns on the bathroom light at 25%. If I manually run that routine, everything works correctly and the light dims to 25% as it should. Let’s say I add a “run this routine automatically” rule to go every day at 10:00PM. This also works correctly. Now let’s say I add a “run this routine automatically” rule to run when motion is detected by a sensor. The light still turns on, but it does not get set to 25%. It just turns the light on to whatver % it was on before, which essentially means the hub did not send the correct command to set the level. Seems crazy that the trigger for initiating the action would make a difference, but that’s what we’re dealing with.
**Update (1/6/2015): here’s a better workaround for this problem:
Create a virtual switch if you don’t already have one you can play with
Create or edit a SmartLighting rule
Set the light to come on at a desired dim % when the virtual switch is turned on
Test that this actually works correctly and that it sets the light to the correct level. You may need to hit the virtual switch more than once before the light comes on.
Edit (not delete/recreate) the SmartLighting rule to come on via motion instead of the virtual switch. It should still work after this AND set the light to the correct %. Yay!
This is much cleaner and still keeps everything local by staying within the SmartLighting app.
Old workaround: So here’s the fun part: I did figure out one insane workaround. You can set up a routine that sets the light to the desired percentage. Then create a virtual switch. Then create a Smart Lighting automation that turns that virtual switch on whenever a certain motion sensor is triggered. Finally, set up an instance of the “Switch activates home phrase” smartapp so that the virtual switch triggers that first routine. This actually works.
Motion -> Smart Lighting -> Virtual Switch -> Switch activates home phrase -> Routine -> Turn on light at correct %
Obviously, it’s super clunky as you need a routine/virtual switch/SAHP smartapp instance for every rule, but it does work. I’m planning on setting it up for the lights I most care about having dimming levels set in certain ways.
It’s 12/23/15 and the issue is still unresolved!! “Motion -> bright lights” is perhaps one of THE MOST COMMONPLACE automatons you would want to create, and ST gets it wrong.
It’s definitely the case that trying to have a Smart Lighting rule on a zwave dimmer (GE) that is triggered by a motion sensor (SmartThings) to turn on at a specific level ignores the level setting. The workaround using the virtual-switch described above works (thanks brbeaird!), but what the hell.
I totally agree. This workaround also has the disadvantage of spamming the app with a message every time motion is detected because it’s routine-based.
Right, which is the most baffling part to me. Why would the command sent from the cloud be able to set a dim level but not one sent locally? I figured all the cloud did was basically tell the hub to then send the command to the light. I would expect when running locally, the hub just skips the cloud part and sends the command to the light. Why would the origination of the command change the communication that actually hits the light switch? I’m sure it’s more complicated than that, but it just seems weird that it’s taken this long for them figure out how to replicate whatever the cloud-origin command does to make the local smartapp behave the same way.
Because Smart Lighting runs locally on hub V2. That means it’s in firmware, and bug fixes are slow to be incorporated. I don’t know how often they are updating the firmware, but not frequently enough because this bug has been there for months. The whole design for local execution is dumb, IMO. But, it is what it is. Rule Machine does not run locally, and I push out bug fixes daily as needed.
A much better workaround has been discovered by @mobious . Here are the steps for that:
Create a virtual switch if you don’t already have one you can play with
Create or edit a SmartLighting rule
Set the light to come on at a desired dim % when the virtual switch is turned on
Test that this actually works correctly and that it sets the light to the correct level. You may need to hit the virtual switch more than once before the light comes on.
Edit (not delete/recreate) the SmartLighting rule to come on via motion instead of the virtual switch. It should still work after this AND set the light to the correct %. Yay!
This is much cleaner and still keeps everything local by staying within the SmartLighting app.
Once again I’m reviving an old topic. I tried to use Smart Lighting with the motion sensor to set up a night light. Indeed, it does not set the level correctly… but more problematically, it does not turn off the lights when motion stops. In fact, the switch in the program to do that does not even stay flipped on! And perhaps related, I cannot edit the names of these routines. That switch also isn’t working.