Motion Lighting Questions/Observations

[Ryan780]

Don't know whether what I'm seeing is an issue or the way it was intended to work, so I will try and explain what I am seeing and you can tell me.

I have a simple motion lighting app that turns lights on when active and then off 4 minutes after motion goes inactive. The rule also has an overriding switch that will prevent the On or Off functions if the switch is OFF (I know on is the default and I have changed that). The rule works perfectly in the following scenarios:

• If the override switch is on, motion activates the lights and 4 minutes after motion stops they turn off.
• If the override switch is off, motion does not turn them on and if they are manually turned on, motion inactive does not turn them off.
• If override switch is on and motion is detected, lights on and if the override is turned off motion inactive does not turn off the lights.

That is all working perfectly. What I'm seeing that I'm wondering about is the following

1. Override switch=on, motion goes active results in Lights on. (Expected)
2. Override switch turned off.
3. Motion goes inactive.
4. Before the 4 minute timeout, the override switch is turned back on.
5. Lights do not shut off. (Not expected)

This got me curious, so I tested ran through the following scenario:

1. Override switch=on, motion detected results in Lights on. (Expected)
2. Motion goes inactive.
3. Before the 4 minute timeout, the override switch is turned off.
4. Lights turn off. (Not expected)

It would appear that the logic to override the lights turning off after the programmed timeout is evaluated only when the motion goes inactive not when the timeout is reached. Is that correct? And if so, is that the intended behavior?

It seems to me, the logic should instead be evaluated when the timeout is reached, since that is when the action might or might not take place. Is there some other way I should be setting up my motion lighting app? I know that I can have a RM rule to compensate for some of this behavior but before going through that effort I wanted to check if what I was seeing matched up with what was expected.

Also, I am seeing that if a motion lighting rule is set to turn a dimmer to a specific level and that dimmer is at a different level when motion is detected, it does not modify the dimmer's level. However, when the timeout is reached, the lights still turn off. So, I'm wondering if this is expected behavior as well.

Here is a screenshot of the motion lighting app I have:

Also, just wanted to say that the bathroom motion lights were ones that always annoyed me in ST. I think it was a combination of the dimmer, the particular motion sensor I use in there and the fact that the only way to automate it correctly was in webCoRE resulted in the lights taking a good 2-3 seconds to turn on. Always resulted in guests hitting the switch and screwing up the automation. Since I moved to Hubitat, it is literally instintaneous. The only way it could be any faster is if the sensor was also psychic and knew I was coming in before I did. I originally moved my ST webCoRE pistons over to Hubitat so I had something in place while I learned the system. After comparing the two, the native Motion Lighting app works much faster. The webCoRE piston is still a lot faster than it was on ST but nowhere near as fast as the native app (for anyone else deeply invested in webCoRE and moving to Hubitat).

On a side note...the new docs page was very helpful in explaining what some of the options mean, thank you. I'm a native English speaker and upon first reading some of the options in the app sounded like they were written in Swedish, translated to one of those African clicking languages, then to English. But I know how tough it is to summarize a paragraph (or longer) description into two or three words. After reading the explanation in the documentation, they all make total sense. I found myself saying, "well, duh!!!" So, kudos on the documentation, very helpful.

One thing I would suggest for a future release would be a link directly to that page from the app (in a new window). It would just make it easier for new people to know that they exist and to find the right page that much quicker and easier. I had to hunt down the wiki's address then find the right page and I only went to hunt for it because I already knew it was out there. Just another idea to throw into the hopper, I know you get a lot.

[bravenel]

@Ryan780

I am seeing that if a motion lighting rule is set to turn a dimmer to a specific level and that dimmer is at a different level when motion is detected, it does not modify the dimmer's level.

This is not the expected behavior. One thing you could do to investigate is to look at the app details page (click on the circle i on the apps page for this instance). Under App State look for override. If it is true, it stops motion lighting from changing the level, if false, normal operation. This thing is tricky, and I've never been completely satisfied with it. Thanks for your diligence in tracking down the app behavior.

@Ryan780

It seems to me, the logic should instead be evaluated when the timeout is reached, since that is when the action might or might not take place.

I think you are correct, and the app should be changed to behave this way...

@Ryan780

One thing I would suggest for a future release would be a link directly to that page from the app (in a new window).

This is coming soon.

[Ryan780]

@bravenel

This is not the expected behavior.

I didn't think so but I didn't want to presume. Thanks for following up.
Thanks for the tip on the rules detail page, I'll def check that under these two conditions.

[Ryan780]

Okay...so, still having lights turning off on me. Now while motion is active and unchanged. So, how can I tell why an event took place? This is impossible to debug without proper logging. I'm really starting to get very frustrated with this thing. I'm really starting to regret making the switch from ST. Yes, I lost control when the internet went down. But when it was up, things worked. I just came home from a week away on a work trip to none of my lighting automations working when i came in the house. One of my motion lighting apps just reverted to an early state all on its own and another turned the lights off while motion was active the entire time. And there is no log to help me fix this. I really would appreciate someone telling me how I can investigate these situations without any type of log.

[Ryan780]

Here's another perfect example. Why is this motion lighting app listed with OffDisabled True? The overide switch is On (and i have off is the disabled mode). So, Off should be enabled. Yes?

NOTHING WORKS!!!!

[bravenel]

You aren't showing enough information to answer that question. You selected a switch to disable off, called Bedroom Auto. Show the Motion Lighting setup page.

What logs is it that you think you need?

[Ryan780]

I can't tell what app turned the lights off. If I have multiple apps affecting the same device there's no way for me to tell which one made the particular change at that time. At least not that I've seen or been told when I asked this question before.
I don't understand what else you need?
I had to rebuild the rule to get it to work.

[bravenel]

Adding logging to Motion Lighting. Next release...

[Ryan780]

Okay...so here's another one. This one didn't turn on when motion changed to active.

Any idea why this didn't work this time when it's worked a dozen times before?

[Ryan780]

This one also did not work tonight. Also, strangely enough, this one just comes on randomly all the time too. Still can't figure out why.

[Ryan780]

Can someone please tell me why this Motion Lighting App still has a scheduled shutoff while motion for the motion sensor is still active?

[bravenel]

@Ryan780

Can someone please tell me why this Motion Lighting App still has a scheduled shutoff while motion for the motion sensor is still active?

Because it doesn't unschedule those events. Instead what happens is that when the schedule fires it knows to ignore it. It was six-of-one, half-dozen-of-the-other, to use state or unschedule, and it turned out that state was easier. That particular thing will get rescheduled once motion goes inactive again.

[Ryan780]

OMG....i'm really trying to remain calm here but Bruce....i dunno man.....

So, how am i supposed to figure out why this isn't working? I really don't care what it is, i just want to figure out why my motion apps never work consistently. That's it.

[bravenel]

@Ryan780

i just want to figure out why my motion apps never work consistently.

So would I. Total logging for Motion Lighting coming. Not much I can do to help you until that release is available. I'm sorry you are so frustrated.

[Ryan780]

I think I found part of my problem. I have two LED strips, one on top of my desk (uplighting) and one under the hutch of my desk to light my work area. In Night mode, I turn both of these on to different levels. They are Digital LEDs so they are controlled through a Program Called McLighting. To set them, I have to issue an HTTP call. And sending those two http calls was initiated with a virtual switch set to be momentary. And the switch worked fine for turning the lights on and worked in Motion Lighting to turn the lights on. I had it set to turn on switches by mode and in night mode it would turn on this Virtual Switch.

The problem occured when it went to turn the lights off. Because the switch was already off, I think that was screwing with the automation. So, i changed it to a normal virtual switch and now it seems to be working correctly.

I've also turned off my motion lighting setup for my kitchen and gone back to my webCoRE piston. Since i only have like 5 pistons I'm hoping it will work okay. It is just too complicated to try and use Motion Lighting. I'll try and move it over to RM but I have a feeling it's going to take a while. just so you can see, here's the piston with the automation.

[destructure00]

I see 4 RM rules to handle this piston. I'm on my phone right now so it's a PITA to switch back and forth between your screenshot and typing a reply but I'll come back and update with my ideas as soon as I'm in front of a computer.

[Ryan780]

Okay...cause I saw either 4 or 5. But as of right now it is working in webCoRE so I'm going to leave it alone. Timing is as crucial for the kitchen as it is for the Bathroom, which is a much simpler automation.

I seem to find that the people who were having issues with webCoRE might have just been trying to use it for absolutely everything like they did with ST and that just doesn't make sense. I have like 95% of my stuff moved to native HE apps but there are some things that webCoRE just does really well. And it appears to me that if its use is limited to only those automations that require the complexity of webCoRE, it runs just fine. I have like 10 pistons at the moment, most of which handle the HTTP call/parse events for my digital LED light strip notifications (so they sit around and do nothing 99% of the time and subscribe to no events). Now, I wouldn't try to load the 80 or so pistons I had when I was in ST. That would just be kinda crazy.

[destructure00]

What you have in that one piston is really 4 different pistons. Webcore allows you to do this, which is great for grouping and applying one set of restrictions to multiple actions. But in essence, you have 4 separate set of triggers, conditions, and actions in a single piston. While RM can handle multiple triggers or conditions, each different set of actions needs it's own rule.

Your 4 actions (each requiring a separate rule) are:

1. Set Switch 54 to 85%
2. Set Switch 54 to 20%
3. Turn off Switch 54
4. Turn off Switch 53

There's a couple options on how to implement your "global" restrictions for your piston. It looks to me like you could address these individually in 3 of the 4 rules. One of them (third "if" statement in your piston) has a restriction for Switch 49 on and Switch 53 off. I don't believe that RM can do both a switch on and switch off restriction in the same rule, so you would need a 5th rule to set the private boolean for this one to true or false. Since this is necessary for one of the rules, I'm going to use it for all of them to keep them conceptually as close as possible to your current piston.

So here's how I would set it up, if you ever decide to move it to RM from webCoRE:

Rule 1 - Triggered Rule

• Triggers:
  -- Device 22, Device 23 motion (any) change to active
  -- Device 21 contact changes to open
• Conditions:
  -- Switch 53, Switch 54 (all) is off
  -- Mode is Day or Night
• Rule:
  -- Switch 53, Switch 54 (all) is off
  -- AND
  -- Mode is Day or Night
• Actions:
  -- Set dim level for Switch 54 to 85%
• Restrictions:
  -- Private boolean restriction enabled

Rule 2 - Triggered Rule

• Triggers:
  -- Device 22, Device 23 motion (any) change to active
  -- Device 21 contact changes to open
• Conditions:
  -- Switch 53, Switch 54 (all) is off
  -- Mode is Sleeping
• Rule:
  -- Switch 53, Switch 54 (all) is off
  -- AND
  -- Mode is Sleeping
• Actions:
  -- Set dim level for Switch 54 to 20%
• Restrictions:
  -- Private boolean restriction enabled

Rule 3 - Rule

• Conditions:
  -- Device 22, Device 23 motion (all) is inactive
• Rule:
  -- Device 22, Device 23 motion (all) is inactive
• Actions when True:
  -- Pending Off: Switch 54: 5 minutes
• Restrictions:
  -- Private boolean restriction enabled

Rule 4 - Rule

• Conditions:
  -- Device 22, Device 23 motion (all) is inactive
• Rule:
  -- Device 22, Device 23 motion (all) is inactive
• Actions when True:
  -- Pending Off: Switch 53: 20 minutes
• Restrictions:
  -- Private boolean restriction enabled

Rule 5 - Rule

• Conditions:
  -- Switch 49 on
  -- Mode is not Away or Automations Off
• Rule:
  -- Switch 49 on
  -- AND
  -- Mode is not Away or Automations Off
• Actions when True:
  -- Private Boolean True for Rule 1, Rule 2, Rule 3, Rule 4
• Actions when False:
  -- Private Boolean False for Rule 1, Rule 2, Rule 3, Rule 4

In rules 3 and 4, the motion sensors both being inactive makes the rule true, which sets up a scheduled
OFF action (pending cancellation) for the associated switches. The Pending Cancellation portion of the action will cancel the scheduled OFF action if the rule becomes false. The rule will become false if either of the motion sensors becomes active again before the OFF action is executed. This configuration duplicates the STAYS functionality from webCore.

[Ryan780]

Yes, it does duplicate it. However, having the 'stays' trigger would definitely make it easier, IMHO. But the webcore piston seems to be working fine so I'll leave it for now. It has been thoroughly debugged since I've been using it for over a year.

[mkig45]

Ryan,
I had some issues with motion lighting as well and I finally decided to delete all my motion lighting and used RM for them instead. Everything is working great for me now.