The above should help. There's a nearly identical rule in the RM documentation, minus the extra time condition, which I'd recommend reading if you haven't already. Your problem is that your last IF is nested inside your ELSE-IF, and they're testing for exactly opposite conditions, so it will never get to that last IF at all if the ELSE-IF condition is false, and it will never run that IF if the ELSE-IF is true because that means the IF condition would always be false. You should also be able to solve this problem by moving your END-IF, but the above is logically equivalent and simpler. (The END-IF does not always need to be the last thing in your rule. It should match with the IF to encapsulate the exact block of code you want to control with the conditions. RM indents actions to help you see this.)
Also, I don't see a reason to use the 6 AM or 9 PM triggers. You are testing this range as conditions in your rule, but a trigger means the rule actions will run at that time, which isn't necessary with your existing actions since motion is the only thing that would turn the lights on. Also, a single trigger of "motion changed" here is equivalent to your existing two triggers of "active" and "inactive," so there's no reason to change but it could save a bit of clicking next time (you're testing these states in your actions and they're the only two possible states, so no need to make it get checked in two different places).
Thanks guys, I assumed that you had to have the time triggers to ensure reliable execution, but it is much easier to remove them. Will they cause any issues if I do not remove them, I have maybe 40 rules now that include Certain Time Triggers for actions that are in a time range.
In this rule, I don't see a reason it would--the "worst" that would happen is that if it's 6 AM and the motion sensor happened to be active, it would turn the lights on (even if, say, the sensor tripped at 5:59 which otherwise wouldn't do anything) or turn them on again even if they're already on (so effectively not doing anything at all), but otherwise all it would do is issue a harmless delayed "off" to lights that are already off (so effectively also nothing, and even the delay won't matter--say if you trigger the lights on with motion later--since it will be cancelled if motion becomes active again).
So I setup the code above and the lights seem to be staying on for 5 minutes but they randomly shut off while I am in the room and won't turn back on with motion for maybe 30 seconds or so.
Did you set the "cancel?" flag on the "Off -> ...delay 0:05:00" action? I think that was missing from the example, and that would explain the problem (otherwise the delayed off doesn't get cancelled with the "Cancel Delayed Actions" action, so you'll have a bunch of delayed "off"s stockpiled from every time the motion sensor went active, causing it to seemingly randomly turn off later).
The 30-second thing should also more or less disappear with this fix (and your five-minute delay)--it's likely your motion sensor's "reset period" where it stays "active" for so many seconds (often 30-60 seconds but configurable to more on some sensors) and won't send a new "active" message with new motion until after that time elapses.
I am just trying everything to figure the ins and outs of Hubitat out this week and because it has not fully worked yet. What do you mean by activating the cancel option?
Second, edit the line " Off: Kitchen Cabinet Lights 1, Kitchen Cabinet Lights 2 --> delayed: 0:05:00"
and make sure that this cancel option is enabled:
That is definitely a potential cause of problems. Say your motion sensor takes 30 seconds to "reset" and the following sequence happens:
Motion detected at 07:00:00
Lights turn on
Motion becomes inactive at 07:01:00
Lights scheduled to turn off at 07:06:00 (i.e., in 5 minutes)
Motion again detected at 07:02:00
The delayed actions (i.e., turning off from step 4) scheduled to be cancelled at 07:06:30 and so this action does not get unscheduled until then, but...
Motion remains active and time reaches 07:06:00, so lights turn off from step 4.
On a related note, I might have suggested this before, but this lighting automation is quite simple and could easily be handled with Hubitat Simple Lighting or Motion Lighting, two native apps provided to perform functions exactly like these with a lot less effort on your part. (Yes, you'd need multiple child apps to handle the two separate functions this one rule is doing, unless maybe you decide to use mode instead, but there is nothing wrong with that.) This is a great way to learn RM but a lot of effort to expend if that isn't your goal.
I just really don't like to watch people struggle (not saying the OP is, just in general) when there are native apps built for exactly this purpose. Contrary to a poster's belief a while back, I do indeed also enjoy watching people learn RM and, I hope, helping them along the way.
To add to this: not only are these apps there, but staff have added several features to the latter over time due to users' requests, so it's now quite powerful...and did I mention easier, less error-prone, and less time-consuming to set up? Their efforts shouldn't go to waste.
