Mixing automations with manual device control

Hi,

As subject... I need some advice on how to think when mixing the two... I always end up with something broken, one way or the other (rule wise).

Optimal scenario would be automations (which I believe I have the way I need it for now), that in a good way could handle disruptions due to manual control of lights and gear.

If for example I have a scene where one of the lamps are off. I decide to turn that on manually. Essentially, what I seek is a way to temporarily exclude that lamp from any automation, until turned off where it again would be part of the automagic...

If not part of any framework, I guess one needs to be created to allow this. Just wondering if anyone has done this, and if so, how.

Thanks

Good timing, i just solved this issue myself. The easy solution in short is to use dimmers and set your automation routines to never take the light up past 90%. The rule example below will see the dimmer in the bathroom if taken to 100% (manually) will hold at that level until 30 minutes of no motion. It sets a local boolean true if the dimmer goes >90% that then overrides the other automation actions.

1 Like

Well, thanks. I am looking for an approach where the device(s) are just disregarded (thus not susceptible to any automation normally affecting it).

One would need to temporarily filter out any commands sent to that particular device as long as under "manual control"...

For example using virtual switches or variables to indicate that certain device(s) are under "manual control" and should happily be disregarded until that switch is turned off again. As if they were disconnected more or less I guess... Custom driver maybe? :thinking:

Now that is a cool idea, a command to disable / enable a device ad hoc in a rule would be awesome! Such as in the device list, you 'check the box' next to devices you want to disable. This could be handy as heck in so many ways! Another example; during a time period disable a motion sensor in an area then back on again during the time you want to monitor motion. You can certainly ignore the sensor in RM but it still has to process the rule from the device trigger. If the device is disabled the rule wont fire making the rule more efficient in terms of CPU time. Cool idea! that has tons of application for enabling and temporarily disabling automation on a device to force it to manual only for a bulb, dimmer, switch or ignore motion and contact sensors as needed.

2 Likes

My automations for any particular switch (done in Node-RED) will not run if that switch is turned on manually (msg.payload.type = physical).

3 Likes

Thanks, maybe we talk about the same thing? I am talking of individual devices, not entire rules/automations. I want the automations/rules to continue to run for everything else, until I decide to "give back" the device I had overruled manually

1 Like

I think so. Let me describe an automation and a manual override to you.

Automation:
I have motion lighting in my kitchen with overhead lighting and wall sconces being turned on based on either of two motion sensors being active. The lighting goes off when the motion sensors are both inactive for 3 minutes.

Manual override:
The way my override works is this - if I turn either the overhead lighting or the wall sconces on manually, the motion sensors are ignored - meaning that particular light (overhead or sconce) stays on regardless of motion sensor status.

Return to automation:
Automation is restored after I manually turn that light back off.

I use this logic in all my lighting automations. But all my light switches indicate a distinction between physical and digital operation. Physical being manual.

3 Likes

It actually sounds like it, agreed. :slight_smile: Next thing to figure is how to do this in HE... I don't run NR, nor do I want another setup to keep track of

1 Like

Well, rule machine does support physical switch and physical dimmer as triggers. So the logic that I do in Node-RED can be reproduced in RM using a combination of two rules.

For example:

Rule-1:
Motion-based lighting rule

Rule-2:
Physical switch on -> pause Rule-1
Physical switch off -> resume Rule-1

3 Likes

Thanks! You have given me a lot to think through and some great ideas on how to improve my setup! :+1:

It will take some planning for sure, but seems plausible to do!

1 Like

It should be possible. Not that this is particularly difficult, but it would have been even easier if physical switch/dimmer were available as conditions. In that event, everything could have been maintained in a single rule.

In specific scenarios like your motion example no. But if for any random light to respond in the same way would probably probe a challenge...

As we now can land on Mars, so guess handling a "smart" light should be a piece of cake... :wink: (kidding) As I see it, a workaround can be created like you suggested for certain scenarios, but what would really be needed for this to work is low-level support for filtering devices that meet certain criteria/has some parameters set. Ie, if I "mark" one particular device, it should be omitted in every automation/rule it is part of - until the reservation is returned...

I will play around with this but don't think that any logic in a rule will inhibit a certain device when for example a scene is run... which is what I am really after... :slight_smile:

Not sure I understand without an example of an automation along with the desired manual override.

Example:
A scene Z include lights A, B & C

(this is the part that don't exist yet and I'm asking support for)
In a rule or by using a dedicated physical switch or button, I "exclude" light "B". This causing scene Z whenever it next runs, to only affect lights A & C, eliminating the need for a specific scene for every circumstance.

If you can do your scene using RM instead of the Groups/Scenes app, then this is very much doable.

What can't RM do... :open_mouth:

I can create rules that do what a scene does, but is there any fancy RM tricks for it, or it means basically to go all in with RM, leaving the scenes app all together?

But, how is this then communicated to other rules etc?

1 Like

I get what you're asking, but I'm the wrong person to answer it because I don't use RM.

2 Likes

I ended up creating a series of variables which I test to see if I should perform the automation. Usually use them to disable motion sensor events - I test for "physical" like you do and have a timer that sets them back off after a specified time.

Maybe @jjackson can look at RM Global variables to see if that would help.

https://docs.hubitat.com/index.php?title=Rule-4.0#Global_Variables

Have a rule that simply tests for the desired physical event and sets a global variable "DisableX" (true or false maybe) then in automations test for global variable = true to bypass.. or something like that. Have another rule that sets "DisableX" back to false after a period of time.

edit: it's been a while since I've used RM too so ymmv and there may be better ways of doing this.

2 Likes

Very clever idea! still would dig it if it was a simple enable / disable at the device level in RM. Simple and fewer moving parts would be a plus. Thank you for the concept using GV's (very familiar and used heavily for global control thresholds as an example), really clever.

2 Likes

Could you share an example of the flow logic for this? I would like to incorporate something like this into one of my lighting automations.