Just a questions, and I think you’ve answered it before. Do I need to go through every rule and select ‘done’ after every update for either Rule or Rule-Machine…or is it just one or the other of them?
You shouldn’t ever have to do that after an update, unless for some reason there are specific instructions to do so. That particular step was recommended a few weeks ago for one particular upgrade, but is not needed now.
If you discover after a scheduled event failure, as I have by looking at a rule in the IDE, that a rule’s scheduled jobs are blown (meaning it’s waiting for a time in the past, like waiting for Godot), then opening that rule and hitting Done will give it a fresh schedule (usually). Should that step fail to restore scheduling, it’s best to remove that rule and do it over from scratch. These are known quirks of the platform that have been observed, not documented or acknowledged by SmartThings other than very vaguely.
Cool, thanks.
.……
I think this update broke one of my rules and I’m getting a not authorized error, not a big problem and I’ll delete from IDE and recreate but figured I would give you a heads up. This is the error from the logs. I do like the new feature on this update though.
java.lang.NullPointerException: Cannot get property ‘value’ on null object @ line 1161
Not sure why that would happen. But, if you can delete the bad one from the IDE as you say, you should be good going forward.
I just noticed that if you edit the Push message without turning it Off and Back On, the old message is retained in the Rule.
Not surprising. Once you input something it’s almost impossible to “erase” it. But, you can edit the string you put in, and that should be saved.
I am trying to set up my first rule using Rule Machine. My situation involves a delay. Before I create the actual rule, I just created a test rule to familiarize myself with RM. I am now running into a problem with the delay. So here’s what I am doing for the test rule
- Trigger : Foyer table lamp is turned on
- Condition (And the rule) is that the Recessed lights in the office are ON
- Action on the rule being true is that I should turn on the Hue Light and make it green
- I set the 'delay the effect of this rule by" to 5 minutes.
My intended action is that 5 minutes after the Foyer table lamp is turned on, I need to check if the Recessed Light is on. And if it is, then turn on the Hue Light
What’s actually happening is that as soon as I turn the Foyer Lamp on, the Hue Light turns on. This implies that the rule isn’t being evaluated after the intended 5 minute delay, but at the time the even is triggered.
Am I doing something wrong? Can I delay the rule evaluation ?
Another unrelated question is “at what Point does a rule get evaluated if I am not defining any triggers?”. So if I just said if light X is on, then turn on Y. Since there are no triggers, when will this condition be evaluated. Is it constantly being evaluated in an infinite loop? or is it once?
Thanks
My understanding of RM, yes
When a condition is true then the action is done. Can you post a couple screen shots of the rule setup you have? There is a delay option for turning on/off a switch or bulb in the actions. You use that set for 5 min for your delay.
When there are no triggers, we call that a rule. A rule is evaluated when any of its conditions might change state, or, in other words, whenever there is an event for one of the conditions. For a simple condition such as a light on, the rule would be evaluated whenever that light is turned on or off. Each time the rule is evaluated, if the rule-truth has changed from before, the actions are performed (just because an event occurs and an evaluation occurs, does not mean that rule truth has necessarily changed). A rule is also evaluated when it is first installed, and its action performed then depending on whether it is true or false.
When there are both triggers and conditions, we call that a triggered rule. This type of rule will only be evaluated when it is triggered, and the actions for true or false will be performed irrespective of the prior rule truth (rule truth doesn’t have to change).
When there are triggers but no conditions, we call that a trigger. A trigger’s actions will be performed whenever it is triggered by one of its trigger events.
About delays, I am almost finished reworking how delays work, and will post more yet today.
The delay capabilities built into Rule Machine have to do with delaying actions, not delaying evaluation. To delay evaluation of a rule is trickier than delaying a rule’s actions. One way to do it is by linking a trigger and a rule. The trigger is triggered by whatever (in your case, the table lamp being turned on). It’s action is delayed by 5 minutes, and will be to evaluate the rule. The rule wouldn’t have a trigger.
That would allow you to check the conditions five minutes after the table lamp is turned on. If you want the rule only to be evaluated when 5 minutes have passed from the table lamp being turned on, you’d have to give it a trigger that wouldn’t fire (e.g., a battery < 0), simply to prevent rule evaluation when the recessed lights are turned on or off.
New Release today, Version 1.6.2
This release features a complete reworking of how delays for actions are selected in Rule Machine, replacing prior selection methods. It also introduces the ability to delay for minutes, seconds or milliseconds (limited to devices). Your existing rules with delays will still work exactly as before.
The new delay selections are the first item in Actions. Selecting a delay affects all of the actions selected. To delay any action, select the delay time, and select the action.
Delays may be specified in minutes, seconds or milliseconds. Milliseconds delays are only available for devices with commands on / off / dim / toggle, open / close, or lock / unlock.
When delays are selected for a rule with conditions, there is an option to Cancel the delayed actions upon a change in the rule truth. When delays are selected as minutes, an option to delay for a random time within that number of minutes is available.
As usual, update Rule from Github, and save but don’t publish: https://github.com/bravenel/Rule-Trigger/blob/master/smartapps/bravenel/rule.src/rule.groovy
2 Likes
Wow, been away a couple of weeks. Trying to catch up… but 1337 posts.
I have Rule 1.2.13
Rule Machine 1.1
Trigger Happy 1.1
Trigger 1.1.8
I think I remove Trigger… if so HOW?
I think I over write both Rule and Rule Machine? Correct?
Thanks
To remove Trigger Happy, go to the IDE / My Locations / List SmartApps / Edit (upper right hand corner) / then uninstall your Triggers and Trigger Happy. Actually, everything should clear out if you simply uninstall Trigger Happy.
Yes to your second question. Over write Rule Machine, save and Publish for me. Over write Rule and save.
1 Like
No problem…I appreciate the opportunity to contribute to this great SmartApp!
2 Likes
I just pushed 1.6.3 with support for setting color temperature, per a request by and code from @john-paulsmith. Thanks for the contribution! Sorry it took so long to incorporate, but, as you know, I was busy with other things.
Great contribution!
Rule 1.6.3 on Github: https://github.com/bravenel/Rule-Trigger/blob/master/smartapps/bravenel/rule.src/rule.groovy
1 Like
Can you have multiple triggers in a rule all based on certain time? For example one that fires at 2 p.m. then one that fires at 10 p.m.? Or do those have to be separate rules? I am asking because on Android I can add two triggers each with Capability of “Certain Time” but both times seem to be locked to each other. when I add the second trigger of certain time and try to change the time it changes the first as well.
Unfortunately, not. You can only have one certain time per rule.
Ok, thanks. Is this a ST limitation or just coding limitation? What would be the best way to have a switch come on at a certain time and then off? Just make two separate rules?