Room Lighting 2.4.0.145 - Any way of forcing activation and deactivation of RL rule?

[mattias]

Ever since Room Lighting was first introduced, I've been trying different configurations to try to force an activation of the RL rule, trying to override a "limit activation" condition, at the same time as getting the rule to also properly activate the devices it's supposed to automate. The same with turning off the RL rule again, trying to get it to turn off against a "limit turning off" condition and at the same time still controlling the devices to automate "properly".

Please note that the limiting conditions I'm trying to override below are examples only, not necessarily the actual ones I'm trying to override as they change from room to room. I'm just looking to see if there is a general way of overriding any limiting conditions there are in any RL rule and still get the rule to activate or turn off as if those limiting conditions weren't applying.

An example of my scenario is the below RL rule:

Light A can be turned on and off with a physical light switch (a Pico button in this case). Lights B and C have no physical switch and would normally be turned on and off only by the RL rule.
The Pico is configured to turn light A on and off directly, bypassing the RL rule, because my philosophy is that a human should be able to override the automation any time by physically pressing a light switch, no matter what any limiting conditions in the rule say. And this is where my issue comes in. So, these are the means to activate:

The limiting condition in this example is illuminance. As it is right now in the screenshot, the rule wouldn't activate when any of the means to activate occur since it is too bright in the room.
The human can in this case turn on Light A by using the Pico in the room, but the rule will not activate because of the room being too bright. This means that neither lights B or C will turn on and it also means that the light will not be turned off by the rule using the means to turn off. The light will have to be manually turned off using the Pico again.
So what I'm wondering is, is there any way of having this scenario occur, but the press of the Pico (or something else) will override the limiting condition and activate the rule as if there hadn't been any limiting conditions?

The same goes for turning off the lights. Means to turn off look like this:

During normal use, the rule would turn off all lights either a minute after the motion sensor reports inactive or 10 minutes have elapsed since the last activation event occurred. But, I don't want the lights to be turned off while the motion sensor is active.

My scenario here is that as the human turns off the lights using the Pico again. In this case the rule does deactivate because of the use of Light A as a switch to determine all lights are off, however, it doesn't turn off lights B and C.

Same as for the activation of the rule, is it possible to have the Pico (or something else) override the limiting condition and deactivate the rule as if there hadn't been any limiting conditions?

[JB10]

I generally separate my manual control rules/room lighting instances from my sensors. In your listed scenario, I would have two different Room Lighting instances. The first would only be activated via the motion sensor with the Lux limit. The second instance would handle button presses on the Pico.

[mattias]

@JB10 Nice! Thanks for that. Never thought of that. I’ll so some tinkering with that to see how it works

One might think that having two separate RL instances for the same room might be messy, but trust me, if it solves the problem I’m trying to solve it is a lot less messy than what I currently have in place trying to work around it (several different RM rules and virtual devices per RL)

[JB10]

The other way to consider is modifying your example and adding a Rule Machine rule to go with it. I would leave the Means to Activate alone.

For the Means to Turn Off, I would get rid of the last Activation event time and the limit of the motion sensor being active. Instead, I would change the motion inactive and stays to 10 minutes (basically covering the last activation). I would also add Light A/B/C switch off as a Means to Off as well. Finally, I would add the option of “turn off even if partially off” as this is key to making it all work. Basically, Room Lighting will always send an Off command in either the motion goes inactive or one of the switches turns off.

Then, I would a Rule Machine Rule. If Light A turns on, turn on Lights B and C. Use a required Expression of the Lux being equal to or greater than the limit in the Room Lighting. This way, all three lights will turn on with the Pico but only if the lux is above the amount (i.e working around the limit in Room Lighting).

What all the above does is allow you to work around the lux limit preventing motion active from turning on the lights but still giving manual control. If someone manually turns on the lights and triggers the motion sensor in the room, Room Lighting will turn off all the lights by either pressing the pico or the motion sensor going inactive and staying.

[mattias]

I agree, and that is basically what I am currently doing with my current RL instances. As I mentioned in the OP, this is just an example rule, my real world ones are much more varied. For example, I’ve got motion sensors, but need to cover events where the sensor isn’t activated, hence a requirement for the elapsed time to have something turn off the rule.

I think if RL would have had an option of “means to activate/turn off that ignores limiting conditions” that would have worked well for me, but having thought about your suggestion of 2 RL instances I think that will fit the bill as well. I probably won’t have time to test in the next few days but I’m optimistic

[danabw]

@mattias

One might think that having two separate RL instances for the same room might be messy,

The HE co-founder, who developed Rule Machine, RL, Basic Rules, etc., strongly recommends using multiple simpler rules to accomplish automations, rather than creating one large, more complex rule. So @JB10's suggestions and your actions quite nicely follow his guidance.

[JB10]

I think it would be helpful if you posted a real world example that is not working the way you want rather than the hypothetical. This would allow the community to better help.

[mattias]

Haha. No disrespect but I’m afraid my RL rules are so complicated that I’m the only one who can understand what it is I’m trying to get out of them and trying to explain them would be very hard. The example I’ve provided is quite representative of my issue as a whole though and I am happy with the advice I’ve received. I certainly subscribe to @bravenel’s KISS model when it comes to other automations, but for some reason I haven’t applied that model to RL. I was probably too fixated on solving all my room lighting needs in only one instance of the rule.
I will take a step back and look at my needs and then probably use two instances of RL per room instead. I’m optimistic that doing that can get rid of my companion RM rules and potentially some virtual devices as well.
Thanks @JB10 for pointing out how you use RL in these situations and thanks @danabw for reminding me of KISS