Problems with "not turning on, already on"

I have had repeated issues with Motion Lighting failing to turn on lights when triggered, returning the log entry "not turning on, already on." This occurs in different rules, and seemingly randomly. Notably, it occurs when (a) the lights are not already on, and (b) even if "do turn on if already on" is checked. In other words, there seem to be two points of failure.

I've read various threads about this. It has been said that also checking "don't turn off if already on" causes conflicts, so I have avoided that.

Here is an example. Perhaps someone can point me to an error I've made.

log

I see that you have a scene to turn on. Does the scene (device) say that it’s on? I haven’t had great luck with using just scenes in ML, instead I have the group set up as a switch to turn on, followed by the scene. This is my upstairs hallway ML setup using Hue scenes that I imported and used in HE scenes. The scenes often say they are on when they are not, thus the addition of the group as a switch


BTW, It works perfect this way and I never notice any odd transitions due to this configuration.

The scene is off, from everything I can see. FWIW, I've had the same issue with rules that only directly control lights. And not that it's likely to make any difference, but this scene is only two lights (both of which show as off).

That’s strange. It seems like it should be working. Maybe a database corruption? Have you tried doing a soft reset and restore? Or just recreating the ML rule?

1 Like

In the past, I have deleted and recreated rules with this issue, which works. However, after having done this 5 or 6 times with various rules, it's not a great long-term solution.

And BTW, I just tried a reboot and it didn't work.

Try doing a backup to your PC, then do a soft reset and then restore your backup. This will get rid of any database corruption that may be causing your problems.
https://docs.hubitat.com/index.php?title=Soft_Reset
I have quite a few ML rules and they always work as expected.
ps. I also have my hubs on a backup power supply so they are never shut down abruptly, and only shut down when I shut them down from my Dashboard shortcut.

1 Like

Remove the option."not turning on if.already.on" at worst an.extra no-op.on.will.be.sent

1 Like

He doesn’t have that enabled; only do turn on even if any already on.

1 Like

Thanks for the input. To summarize the past few hours, (a) the rule worked properly, then (b) it failed again with "not turning on, already on," then (c) it worked again, then (d) it failed again. I didn't knowingly make any change to it during this time.

So, I did the soft reset and...it still failed, saying "not turning on, already on."

At this point, I deleted and recreated the rule, so it's working--for now, until it (or another motion lighting rule) develops the same behavior. At least that's been my experience.

Have you tried removing the virtual office sensor from the equation to try isolate what is causing the behavior?

@awagsii: No, I haven't. That virtual sensor is an Amazon Echo that can sense presence (a recently added capability for Echos devices). It trips a virtual switch in Hubitat, which then sets the virtual motion sensor to active.

If the issue recurs, I'll try removing the virtual motion sensor. However, I've had another motion rule in another room--which had only one [non-virtual] trigger, and which didn't use a scene--develop the same "not turning on, already on" behavior. That was a couple of months ago, and it's been OK since deleting and recreating the rule.

Well, the "not turning on, already on" issue just happened with another rule. A difference here is that the "already on" state is shown as true, even though I specifically confirmed that all lights are off before triggering the motion sensor. Still, I have "do turn on if already on" checked, so that shouldn't matter.

As a side issue, either I don't understand what "do turn on even if any already on" means, or the setting doesn't work right.

If I trigger motion to turn on several lights, then manually turn off one of them and retrigger motion, I expect the turned-off light to turn back on with that setting specified. But it doesn't; I get "not turning on, already on" log entry.

On the other hand, if I start with everything off and turn on one of the lights manually, then trigger motion, it works as expected--i.e., the lights turn on.

I think the issue here is that the "delay off" period hadn't expired in the first example, but had in the second. But is that how it's supposed to work?

That has been my experience.
Have you turned off lights manually when ML doesn’t turn them back on? If that’s the case, you probably just need to specify what you are using to turn them on/off in the ML rule (switch, button controller, voice assistant, etc).

I've been wondering what that "switches to turn off lights" setting does, particularly if you're specifying a switch that would normally turn off the lights. (I did see a post suggesting it was good practice to specify that anyway, although I'm not sure exactly why.)

I often turn off lights with a "turn off all lights" voice command, so I can specify the Hubitat "all lights" switch in that setting.

EDIT: I guess conceptually, telling Hubitat that the off switch turns off a light would let it know the rule is completed if a light is turned off manually, rather than having the timeout timer continue. That could account for some of my issues with "not turning on, already on," if Hubitat didn't correctly track the status.

It doesn't explain the issue that started this thread, though, as Hubitat reflected that the lights were off, but still didn't turn them on.

1 Like

What was the state of the "Pause Master" switch when this stopped working? If that switch (virtual switch?) was on, then this ML rule wouldn't activate as you have it set in "Options for Activate, Disable...."

Maybe temporarily remove that Pause Master from both sections and see if it works?

@neonturbo: The pause switch was off. I rarely use it.

That failure seems to have been a one-time event. I'll chalk it up to Hubitat not "knowing" that the lights were off, perhaps because I had done it manually.

1 Like

I found alot of the motion lighting options really confusing as well. Most didn't do what I thought they should at all. But on the upside once I had it all debugged they have been rock solid.

2 Likes

OK, I've figured out why some of my problems were occurring, and why they appeared to be intermittent. I don't know if this is a bug or a feature of "do turn on all even if any already on," but I can see how it works.

Two scenarios, with two lights (A and B), and a rule which says on motion turn on A and B, and do turn on all even if already on:

  1. I manually turn on A, then trigger motion. B turns on, as expected.

  2. A is turned on by a rule, then I trigger motion. B does not turn on.

So, "do turn on if already on" only applies to lights that were turned on manually, not to lights turned on by a rule. Is this the intended functionality? I haven't seen this documented anywhere. I would certainly prefer that the behavior were the same, no matter how light A was turned on.

Hmm, that seems odd. It almost sounds like it is detecting physical but not digital events. What brand and model switches are these?

@bravenel ???