I notice ML currently performs the delay and sends the off commands regardless of whether it actually turned on or not. In my case for example right now the ML rules don't fire because lux is above the threshold and/or its in the wrong mode, but the logs show the off is being delayed and then the offs are being fired, even though the lights are already off, and weren't even turned on by ML.
I realize it doesn't do any harm to turn off an already off device, but for the sake of optimizing the system as much as possible, it might be better if the ML routing just stopped after figuring out that it won't do anything. Right now it seems to carry on doing the off stuff regardless.
It probably applies to the on also, if we have "dont turn off if already on" and the light was already on, then ML should just exit saying so. instead it will go through all the motions of turning on an already-on light, and then counting the delay and sending the off, only to figure out that "dont turn off if already on" should apply.
Less confusing messages in log, less cpu cycles and less z-wave traffic, all of these must be good things, no?
Motion Lighting keeps track of when it has turned lights on. What I can do is if it thinks the lights are on, not to turn them on, and if it thinks the lights are off, not to turn them off. This could represent a minor change of functionality for a period when it is restricted for whatever reason to not turn them on and they are turned on by some other means. Currently, it would turn them off when motion goes inactive. With this change, it would not turn them off unless it turned them on. This would preserve the desired functionality of turning them off after a mode change from a mode where it turned them on to one where it would not turn them on.
Would love to see that in Rule machine as well. Instead of setting it in the condition. If the light is on then turn off. Resulting in my rules always evaluating to false. Not that I need my rules to evaluate to the correct status if it's better on the hub.
This isn't worth worrying about, and a solution is not generalizable for RM. If you have an automation that says "on these conditions do x", then it sure better do x upon those conditions. Motion Lighting is a different sort of app, where it's supposed to be managing lighting, and knows its intent, if you will. RM is, and should be, blind to intent, and just do what you tell it to do.
Funny how we all have different requirements. Or maybe not.
Personally I want every command to be sent regardless of the state of the device.
Why? I am using some stateless devices so HE may not know the current state of a device. Therefore I need the commands to be sent 'just in case'.
I know webCoRE doesn't send the command if it feels it isn't required. Because of this I disabled 'command optimisation' to ensure commands were sent.
I also did this back in my ST-webCore days, but I did it because I found ST too unreliable with regards to knowing the current status of the dimmers (Lutron Caseta/z-wave). Since HE is communicating via telnet with Lutron and locally with z-wave I don't see the need for sending the commands regardless of device's current state. But as always is the case, "to each their own".
I like the approach of adding it to motion lighting but keeping RM as it is, giving the end user the option to create their equivalent using conditions or restrictions.
Actually. I have rules that could be simplified by having that feature. If the light is already on then only adjust the light that is on. Just would be nice in several use cases for me anyway.
HE will send the command even if the device is in that state already. I have run into this problem with "stateless" devices being switched on when they were supposed to be switched off but were off already (IR controlled devices). The device is off in HE and the command is to turn them off and the command is sent regardless of the current state of the device.
