I was just looking at the logging that is collected for my hub and this caught my attention.
Simply put I have a simple setup in RL that turns on/off some under cabinent lights based on motion if it is between sunset and sunrise. It seems to work well, but this logging doesn't make sense.
Here is the image of the is setup in RL. It is pretty straight forward.
This is pulled over from my syslog output, but it is the same as what is found on the hub. What is confusing and concerning to me is that it looks like even though the activation is blocked by needing it to be between Sunset and Sunrise this logging shows some activity during the day when activation is prevented. I wouldn't be surprised to see a message from the sensor tha triggers it to save it is active, and then the message saying that activation was prevented. What is concerning is you can also see a bunch of messages about "Turn off Event" and then Already turned off. These are also confusing as they don't follow the timing setup for the turn off configuration.
This makes me wonder if something isn't being stopped when the activation is blocked. Could this be creating allot of stuff in the backend that is being held up.
From what I can see from your setup, this is expected. Your "Activation" is restricted. Your "Turn Off" is not. These actions are configured independently--a restriction on one does not affect the other.
This is working fine for you because they were never considered not turned off when any of your "Means to Turn Off Lights" happened (here, when motion remained inactive for 10 minutes); as such, you don't need to change anything if that either is never something that happens for you or is still an outcome you want even if you "manually" activated the lights during that time (or they happened to still be on--probably an outcome you want, but RL does let you choose otherwise if you don't).
Thanks for the answer. I guess that makes sense it just seems strange to turn off by motion when that method to activate was blocked. I will see about updating the RL instance to see if it makes sense to setup the deactivate limit.
Seems resource wasteful a little bit. That was my concern.
It would really be the same either way--it's going to wake up in response to the motion event (or really any activation or turn off methods) then decide whether to do something based on your configuration, or at least I don't think it's intricate enough to mess with device/event subscriptions (most apps don't, rules with required expressions being one exception). This would not be one of my concerns.
In this case, maybe, but consider other setups where you may have more than one means to activate or turn off selected. This lets you be specific about exactly how you want the automation to work rather than an "all or nothing" approach that applies indiscriminately to the entire automation like some simpler apps may do.
I'd probably leave your setup as is unless you want to deal with manually turning the lights off after sunset (or finding some other way to automate this) should they happen to still be on then.
