I think @bravenel might be able to help w/understanding whether this is expected or not, and if it's expected, why.
2 Likes
The app doesn't present options you can't use. It knows what your system has and doesn't have.
3 Likes
I think the question was more about the "on if already on" functionality.
2 Likes
@bravenel...above is the issue he's actually concerned about. 
2 Likes
That was answered correctly above. You use that option to cause the lights to come on from motion even if one is already on.
2 Likes
Bravenel, Can you answer this please? Is there any merit or possible side effects like events, to turning on an already on light? If so, then I would argue that the option be used for that purpose, and if not, the description should better imply that if ANY of the lights are on, you need that option to turn on the rest. Thx, Dave
The subtlety here is that people didn't like the idea of 'on' commands being sent every time motion becomes active, when the app has already turned on the lights. The thought being that sends commands into the mesh, uses resources, etc. So, the app keeps track of whether the lights are on or not, and doesn't send 'on' commands if the lights are on. This in turn raised the prospect of what to do if only some of them were on. Which gave rise to this option. People have presented use cases for both: I want to be able to turn on a light and not have motion turn the rest on, or in your case, I want to be able to turn on a light but have motion turn the rest on. It gets complex quickly. One person's bug is another person's feature.
Personally, I don't use these options because I never use light switches any more in the rooms where I have motion lighting.
1 Like
Why not then just turn on the ones that are not already on, and if that "do turn on" option is set, then turn them all on even if already on?
With the option the way it is, you don't turn any more on if any are on, or you turn them all on even if any are already on. My suggestion you would only turn on the ones that were not already on, but with the option, you could also turn on already on ones again, That give you the most flexibility.
No, not really. Generally speaking it is harmless and meaningless to "turn on" a light that is already on. In fact, the hub is smart enough not to send events that don't change the state of a device. But sending a command is not quite the same as sending an event, and a command is sent, so the driver runs, generates an event, which the hub then drops because it isn't a state change.
Frankly, people were freaked out because of what they saw in the logs. OMG, it's sending 'on' every time motion goes active -- horror of horrors! In reality, none of this really matters. It was easier to calm people down by suppressing these commands than to convince them it wasn't a problem. There's a tricky balance going on between peoples perceptions and reality. I've used Motion Lighting for about 5 years now. For the first half of that period, or more, it sent the 'on' commands every time motion went active. No problem. I knew it wasn't a problem, so never bothered with the 'noise' of busy logs. Hubitat users don't have the same perch I do to understand these things the same way. It's a different ball game when there are thousands of people using an app, with thousands of different perspectives and needs.
Sure, we could add a test to only send a command to a light that doesn't have the right setting. It's more than a bit tedious to do that, and the consequence of sending a redundant command is basically nothing. So why bother? The reasons not to are twofold: (1) app complexity, and (2) app efficiency. Both argue against addressing this, imo.
3 Likes
Ok, understood. I suggest then making in more clear in the dialog that the option needs to be used to turn on the rest if ANY are already on. Marked @neoturbo's original answer as the solution. Thx!
Not sure what else it could mean? If all of the lights were on, why would you need an option to turn them on?
Note to documentation crew....
3 Likes
The way my programmer self understood it was 1) of course all of the requested lights would be turned on that were not already on even if any were already on and 2) the "do turn on if already on" meant additionally that if any were on, turn them on again so as to trigger any events associated with turning something on.
Ah, but you hadn't learned yet that the platform doesn't work this way.
I'd be more than happy to rework wordings of things like this. The app is already tortured enough with phrases such as "Additional switches to turn off when turned off". Perhaps this one should be "Do turn on all even if any already on".
3 Likes
Kind of what I'm saying, why would you want an option to turn on all the lights if they were already on? I was assuming all the lights would end up on even if some were already on, and the option meant turn them on anyway, even if already on.
That would be more clear
1 Like
Could we have an "optimisation off" option so that motion lighting is more reliable? It seems the app isn't keeping track reliably and I'm constantly seeing "info Not turning on, already on" messages when the switch is clearly not on. If I send a command to the device it always works afterwards but after a few days the app again thinks the device is on when it isn't.
Sounds like the switch is not updating it's status. If this is a ZWave non-plus switch you may need to add polling for it, otherwise you may need to look at strengthening your mesh.
1 Like
My z-wave mesh consists of only powered switches and repeaters and no sensors. Only seeing motion lighting has this problem as @bravenel states it tries to remember the state independently of the platform. Dashboard reports the correct state and rule machine does not have a problem.
