I have 2 dimmers that do the following: sometimes when motion lighting turns off the light, it sets the level to a wierd level. The second part is that when I come back in the rule doesn’t reset the level, it goes back to the weird level. See pics and look at 6:45 pm. The physical baffles me as well, we rarely hit switches here...
Do you have standard Z wave dimmer or Z wave plus dimmers?
I too have been VERY frustrated with Motion Lighting. It seems to be very finicky.
If RM had a "stays" trigger, it would solve 90% of my issues. I refuse to have one rule for the delayed action and then another rule to cancel that action later. It is just so tough getting these to work without proper logging of what the app is actually doing.
Standard z wave for both of my problem children...
I don't understand that. Rules aren't purchased in 10 packs or anything, they're free. 
It's been said Rule Machine is like Lego's. Like building blocks. You can't build anything cool with one Lego.
Not trying to be argumentative, just trying to understand the viewpoint.
2 Likes
No, it's a valid question. First of all, I'm a firm believer in KISS (Keep It Simple Stupid). And I look at it not only from a place of implementation but also maintenance .
I estimate that I would need at least 4 or 5 RM rules to accomplish the same thing that Motion Lighting does (correction: is trying to do) in one app. That is just too much to maintain when I have 5 different rooms with motion activated lights. I'm sorry, trying to get one of these stupid RM rules (I'm sorry but I am a webcore person and i hate...and i mean HATE rule machine) to work is a struggle. Now you want me to write 5 of them? And you're trying to tell me that 5 RM rules are all going to play nicely together? Come on....I'm just not buying it. If you had "stays" as a trigger, it would be reduced to two rules that don't ever need to interact with each other at all. One to turn them on and one to turn them off. Two totally independent rules. Doesn't that seem a whole lot cleaner than 5 with virtual switches and true/false and cancel actions?
You usually don't need two separate rules to turn things on and back off from motion in Rule Machine. The nomenclature may seem weird, but you already know the functionality. Yes, Motion Lighting can combine the functions of multiple rules in complex lighting situations with multiple options. That's why it exists. I wrote this app a long time ago for myself, and I have 25 instances of it installed. This would take probably 50 rules to accomplish, and I agree with you that it's better not to do that.
Motion Lighting can be "finicky" due to all of the options, especially those involving disabling it in some way. The next release is going to have the ability to give extensive logging so that you can tell exactly what is going on with Motion Lighting. This should make it possible to see why it doesn't do what you expect -- if in fact it is the app that is the source of some problem.
I'm not familiar with webCoRE, so I don't understand "stays" as a trigger. If you would be so kind as to explain that to me, I could do one of two things: explain how that is accomplished in Rule Machine, or, as you suggest, add that to Rule Machine. I understand the appeal of webCoRE over Rule Machine. There is some history involved, namely that Rule Machine was the predecessor of CoRE, which in turn became webCoRE. I don't pretend that RM is as easy to understand, as it is at a lower level of abstraction than webCoRE. But, in most cases, it will do the same things.
3 Likes
It's really not all that complicated. It is a trigger that fires when a device remains in the specified state for the configured period of time. So, in this instance, if Motion STAYS (or remains) inactive for 5 minutes.... That way, you're not triggering a delayed action off of going inactive that has to be canceled again if motion goes active again before the timeout. Maybe an example.
First...using the delayed action and cancel idea, you would have to set up actions like this:
- Motion active - lights on.
- Motion Inactive - delayed shutoff starts
- Motion Active - cancel delayed shutoff
- Motion Inactive - delayed shutoff starts
- Delayed shutoff occurs.
If you had stays (or remains) as a trigger, it would be much simpler. You wouldn't have to cancel the delayed shutdown.
- Motion active - lights on
- Motion inactive for 5 minutes - lights off
Does that make sense?
And i'm sure that RM can do everything the webCore can....but I invested months and MONTHS learning webCoRE. Reading every new post on the webCoRE forum. Going through as many of the example pistons on the forum as I could. And one of the reasons I decided to make the plunge into HE was that webCoRE was supposed to work. And that's not HE's fault...it was presented in a much more favorable light. But I'd invested all this time in honing this skill set and now it's basically worthless and I have to start all over again. And that is frustrating to say the least. In the end, i don't care what I have to do i just want the damn things to work. Know what i mean?
You are overthinking it. This can be accomplished with a single rule.
Conditions: motion active
Rule: motion active
When true: light on
When false: Pending off: 5 minutes: light off
Here's a similar rule I have in my closet, except 2 minutes instead of 5. Works perfectly.
Okay....but how do I add a bypass switch into that? I can't add that condition to this rule, i would have to set up another rule to disable/enable this one based on that other switch being on....right? Because in order to use the rule you've written, the whole thing has to be true or it's false, so having the bypass added as an AND condition won't work because then it will be false when the bypass is off and the lights will turn off. Which is NOT what I want.
I really don't think I'm overthinking this because I spent the last year and half designing my motion lighting automations. Unfortunately I spent that time doing them in webCoRE so they're useless to me now. If I could go back and spend the last 2 years learning groovy instead of webcore I would but unfortunately Doc Brown still hasn't brought the Dillorian back yet. 
What do you mean by bypass switch? That wasn't part of your scenario to begin with.
Realize that your time into webcore is a sunk cost. You can worry about whether or not it will be supported on HE. This is dependent on community developers as it is not (and never has been) officially supported, or you can decide to try and convert your automations to RM, which is officially integrated. I have posted this same thing a couple times, but with one fringe case exception, I was able to replicate the function of 70-ish pistons to RM with with no loss of functionality. You just have to adapt to the specifics of each app. It's like switching from Android to IOS.... I'm an Android guy through and through, but I understand that if I buy an iPhone that I'm going to have to make some changes. It's no different here. They both do the same thing, just by (slightly) different methods.
Yes...I understand all of that. But #1 none of that has anything to do with my point about the STAYS function.
and #2 I said at the beginning that I have moved over everything from webCore to motion lighting and rules machine. So, there's nothing left to move over. Now I'm just trying to get them to work...i dunno....more than once. LMAO
STAYS is not necessary based on the information you gave. If you want to give more information on your bypass scenario I or I'm sure someone else would be happy to help.
Nope. If you don't understand the concept of a Stays trigger yet then I am just not smart enough to explain it.
If you like webcore, why not continue to use it?
Because it doesn't work well with Hubitat. There are numerous reports of peoples hub locking up on them. Plus, Motion Lighting and RM respond much faster than webCoRE. I'm not complaining about having to switch, it just seems like there are a couple of things that, if you're coming from webCoRE would make the transition easier.
Likely a broken record, but Hubitat should ensure the hub has enough resources to run webcore...I agree with you that I'm not going back to RM. Been burned there already.
Thank you!! Any chance RM will get something similar?
Assuming with this that means you've stuck 100% webcore? If so I'd like to chat on # of pistons and changes you've made for reliability. I struggled to get it reliable. But I'm struggling with RM and other built in apps to even replicate some simple lighting rules. Weird things happen and then I'm back tracking in "logs" to try to figure out what happened. But there is so little information...honestly I just chock it up to something's wrong and turn the darn light on myself.
I think a really good sub forum here would be helping to translate some of our webcore pistons into rules.
Getting back to the original post should I wait for the next release for better logs? I am ok with that as it is intermittent.
Craig
Are you using the Z-wave Polling app with these devices? I'm seeing the same issues that you report, but only when using the polling app. I started another thread about it.
https://community.hubitat.com/t/z-wave-poller-phantom-physical-events-while-dimming
