I will start by saying I a fairly new to Hubitat, but have been a long time Smartthings user. Many years ago a was a developer so while I don’t know Java really well I can read the code pretty well and understand what it is trying to do.
That said, Rule machine and its interface is new to me, but I am working through it, trying to convert all my WebCore pistons to the native Rule Machine and other Hubitat tools. I am having a problem with one of the Rule Machine routines I am trying to convert. Below I will provide the Webcore piston, my attempt at the Rule Machine Code, and the log from the device, and the rule.
I am observing a number of things. First, there is an if clause that is evaluating FALSE, as it should, but it is still running the commands contained in it as if it evaluated as TRUE. I have marked that one in the log.
Also, I may be misunderstanding how Rule machine works, but I thought that you did not necessarily have to have triggers set. My understanding has been that if you don’t use triggers, then it does a conditional match such that when the conditions become true, then the commands contained within the conditional statement execute. Is this true?
Also, I know I have identified a bug in the device driver I am using for the switch controlled here. The bug is that when a button is pressed the driver doesn’t seem to recognize it. I may be using the command in the rule wrong. I have marked the line in question. The only option in actions I could find to read a button press what the Button changed condition. I would have though that there would be an explicit Button 1 Pressed condition as there is in the trigger. Am I missing something? This has been hard for me to test because I don’t think the button press is even being registered by the driver since it won’t even register the event on Button Press 1 for the Trigger in this Rule. I have yet to be able to get in touch with the developer to see if he can fix it, and I doubt you will assist since you have built your own driver for the GE/Jasco Motion Dimmer. Unfortunately, your driver is not nearly as functional, nor does it have as many custom commands, commands that I have made use of on Smartthings, and would like to on Hubitat.
So here are the screen prints. Any help would be appreciated.
So, to your triggers, I would change them to "changed" instead of active and on/off. Keep the button 1 pushed (or, optimally break it out to a separate rule).
In the actions, you don't need the programmatic variable and you can reduce a lot of the code down.
In my motion rule, the lights come on when either motion sensor changes to active and then turns off after 2:30 unless there is continued movement or the door is closed.
In my button rule, if button 1 is pressed, it pauses the motion rule, turns the lights on to mode values and then resumes the rule when button 2 is pressed.
No; that is a webCoREian way of thinking, and it is true there (except I can't remember the terminology; something like if you don't use triggers, it will infer them based on "plain" conditions, though all are ifs and many new users have a hard time knowing). In Rule Machine--or more accurately Rule 4.0--your actions will run only when an event matches one of your triggers. It is true that you don't need triggers, but you need to run the rule actions via some other mechanism then (e.g., calling it from another rule) in order for them to ever do anything.
A button press is an event and is best used as a trigger. It is difficult to use button pushes as conditions. You technically can do so (generally as checking the last button number as a condition), but it's unlikely that you want to do so, and I'm really not sure how you got "pushed() *changed*" into a conditional or what that even means (certainly not what the webCoRE piston does in the corresponding section). If your driver is custom, there may indeed be a bug, but if you see button presses (and other events) in the logs as expected, then it's likely working fine.
My suggestion would be to leave this out of the rule--make another rule (or some other automation) to handle the button push. A separate rule with a "Button Device" trigger would work well (that's basically Button Controller, plus a bit more power from Rule Machine). I see you're setting a local variable based on this, which you can't do from another rule; rather than using a global variable (also an option), you may wish to consider using the rule's own "Private Boolean" to track this state, which you can set from another rule. I think keeping the button in here is going to get messy, though--it will evaluate all your conditions and run other sets of actions of the conditionals match.
Beyond that, most of the rule looks OK to me, but I still think you'll get some unexpected events with your multiple vastly differing triggers. What if the vanity gets turned off but motion is still active? Your rule actions will match on the first conditional and turn them back on. Separate rules with their own trigger will likely make this much less complicated. Also, do you plan to have the lights turn off with motion, too? (That would be something you could probably put into this rule.)
Thanks for the response. I am sure I am overcomplicating things. For the life of me I can't remember why I put the programmatic variable in there. I am sure I was trying to do something more complicated in the WebCore piston and then changed it later not thinking to remove the variable. As I read it now, I may not need it after all.
I had considered doing three rules, but after being steeped in WebCore, and its ease of writing very powerful and complex pistons, I felt I should continue with keeping the number of rules to a minimum and doing the most I can in one rule. I can foresee that as I build many small rules instead of one rule to handle one device (for the most part) troubleshooting conflicts may get quite complicated.
I don't currently use Modes as there are too many people with different schedules in this house. However, I like your idea of pausing the Motion Rule after the button is pressed in the Button Controller rule.
It seems like your motion rule would fire many times as you carry on your business in the bathroom. Each time your motion state changes it fires. As I am doing my thing at the sink this is likely to happen frequently. It works but I would want to put a check in there to not have it trigger if the light is already on. This can't be done in the triggers in Rule Machine since it won't let you do an AND Trigger condition, or at least I haven't figured out how to do this yet.
Thanks for the ideas. I think I will try something along those lines.
LOL, I guess I am a WebCoREian! I am not seeing button presses in this driver right now but I am still testing some things. I am not familiar with a rule's Private Boolean. I need to read up on that to understand how it is used. any examples of how it would be used would be helpful.
I have experienced this in this rule. Makes sense.
In SmartThings I simply set the motion switch to Vacancy mode instead of Occupancy. I had planned on doing that on Hubitat as well and letting the driver handle turning off the light. Saves a bunch of rule coding.
Thanks for the education on RM. I have a bunch to learn yet.
As Bruce (@bravenel) has stated many times, rules are free. There should be no performance penalty for having as many rules as you want. I also came from WC and I know what you mean, but since coming over to HE, I've gotten in the mindset of having a lot of rules doing small tasks, rather than huge rules for big tasks. While it may seem counter intuitive from a WC perspective, it actually has made things easier for me. I have ~70 rules governing the house and each rule handles a small part of the larger logic. For instance, I tend to keep my contact triggers separate from my motion triggers. That way, if my wife says that the kitchen lights aren't coming on when she walks in there, I know the exact rule to go to to test it.
For lights and such, it really doesn't matter if it fires 1,000,000 times as I recall Bruce or Mike stating that HE internally won't send a command to a device if that device is already at that state. So, the rule firing doesn't really matter. Now, if you are doing more complex things like setting states or modes or calling other rules, then you'd want to put a private boolean in there to stop it from executing more than once. Again, you're still in the WC mindset that pistons (and piston executions) cost resources. In HE, rules are executed and actions are fired only if the state of devices have changed. So, for my bathroom rules, yes, they will fire every time there is movement, but if the devices are in the same state that they were previously, no actions (besides cancelling any timers) will be called and the rule engine just happily marches on. I've had some truly UGLY rules and where I thought for sure they would bring the hub to its knees, it just kept processing.
Correct. Triggers are only OR conditions. I am hopeful Bruce adds either complex triggers or the ability to have AND triggers.
LOL, yeah, it's just my wife and I and we are both pretty strict on our schedules. I've found modes to be one of the best features of HE so far. It's much easier for me to just think "is it afternoon?" than determining times for various things to run.
Yes before I chose to move to HE I was about to try modes in SmartThings and likely will try to get around to it. I see their value, but am afraid in my household that I will have to code to many "exceptions to the rule for certain rooms. Perhaps I will reach out to you for some advice when I get around to it.
Yeah, I was actually afraid of that too and for the first month or so I had everything so over complicated that my WAF was near 0%. LOL I do have a few rooms that are exceptions to the rule (like our laundry room, crawlspace, and attic, all of which my wife always wants at 100% when the lights are on).
