Updated Github. I think that bug is fixed. Let me know… Thanks!!
Question about Temperature Comparison. It’s a little unlcear as to whether the symbol stands for greater than or less than. I want to set up a trigger if a temp goes above 75, for example. Do I use:
Sensor
.>
75
or
Sensor
<
75
Just looking for a clarification. This is really awesome work! Thanks!!
The symbol is relative to the second operand, so > means greater than x; < means less than x.
Ok, that’s what I was thinking… The screen layout was just throwing me a little. Thanks for the quick response!
New version released: Version 1.1.4
Now supports setting the SHM alarm state. https://github.com/bravenel/Rule-Trigger/blob/master/smartapps/bravenel/trigger.src/trigger.groovy
And, yet another update, Version 1.1.5.
Release notes:
- Fixed a bug concerning using presence as a trigger
To update: copy code for Trigger from Github https://github.com/bravenel/SmartThingsPublic/blob/master/smartapps/bravenel/trigger.src/trigger.groovy
Paste it into Trigger in IDE, overwriting previous version, and Save. Do not publish!
Bruce, I noticed when updating from github, I believe you are forced to publish for the update to work. For some reason the parent app (I.e: rule or trigger) gets updated while rule engine and happy trigger don’t require an update.
Why is publishing bad?
I concur. I very much appreciate both apps, but would love to see them together.
What is really cool is that there are people like Bruce who are willing to put so much effort into helping the community.
You would have several intractable problems to solve, each of which on its own leads to confusion of purpose and outcome. For example, some triggers have no state, so can’t be used as conditions to a rule. Triggers can cause actions that a rule cannot meaningfully do, due to contextual issues. Look at the list of actions for Rule and for Trigger, and you’ll see some of these differences. And, look at the list of conditions for the two apps, more differences.
From a UI perspective, one could perhaps slap the two apps together, and attempt to sort out the above issues, but the result would confuse everybody.
For what it’s worth, I have 10 rules and 27 triggers. Triggers are far and away the more common type of automation. Most of the custom small smartapps that I used to write for people were triggers, simply an odd combination of event and action not covered by ST’s standard apps. I bet you that half the rules people have written are in fact triggers (single condition, only true actions). Each has it’s place in automating your home.
Bruce -
Have you looked at the UI and logic in the SRBuilder app?
Yes I have.
There are significant differences of approach, with similarities. SRBuilder is single trigger driven, leading to condition rule testing. Rule Machine is entirely state based only on conditions / rule, driven by any event that affects the state of the conditions. The example rule in the OP for Rule Machine can’t be done in SRBuilder without limiting it to a single trigger, or using multiple rules, because it’s logic wasn’t based on a single triggering event. Trigger Happy also allows multiple triggers for a set of actions, of course with no rule at all.
I see your point. The thing is, there are apps that do this already. Some functions are missing and none of them work within ST like yours.
Here is a prime example of the usefulness of combining these concepts.
Trigger: press button
Conditions:
If Garage is open
Then close garage
If garage is closed And after sunset
Then open garage and turn on light
Else open garage
So you want a button to toggle the open / close state of the door, with an added action of turning on the light if it’s after sunset. Correct?
The way garage doors are set up they have virtual momentary buttons that open / close them. So your case devolves to a single trigger (push button, turn on virtual momentary button), and a single rule (conditions: virtual momentary on, door open, time between x and y; rule: door open and time between x and y; action: turn on light).
This works, even if you use a different method of opening the garage door.
It was just one example. I can come up with several. For each I’m sure an alternative method can be imagined. The point is an engine with a trigger, condition, action model covers them all.
But trying to create, manage, and debug such an engine is near impossible. At least while having a life.
Now that’s just silly. It is no more effort. If Bruce doesn’t want to do it that’s his prerogative, but to say it’s ‘near impossible’ is absurd. We all still appreciate everything he has already done.
Simple Rule Builder already does it. It is a third party web app, so there are the inherent issues that come with that, but it has triggers, conditions and actions. So does Smart Rules, but that’s a mobile app, so there’s that. Also Smart Rules has limited conditions.
Anyway, I was simply agreeing with another poster who thought it would be a good idea. I am not trying to start an argument. I don’t really care enough about this topic to continue this line of discussion.
New version posted: Version 1.1.6
Release notes:
- Added Smart Home Monitor alarm state changes as triggers
This completes the integration of Smart Home Monitor into Trigger Happy. You can test and set SHM alarm state.
To update: copy code for Trigger from Github https://github.com/bravenel/SmartThingsPublic/blob/master/smartapps/bravenel/trigger.src/trigger.groovy
Paste it into Trigger in IDE, overwriting previous version, and Save. Do not publish.
Bruce
Thanks so much for Trigger Happy and Rules - now using this for everything
Would it be possible to add camera support - so for example, when a door is opened (triggered by contact sensor) a camera takes a photo?
As I learn more about groovy, I’m interested to know what I might alter to change the ability to delay a switch from Minutes (your default) to Seconds.
Is it solely contained within this…
input “delayedOffTrue”, “capability.switch”, title: “Turn on/off these switches after a delay (default is OFF)”, multiple: true, required: false, submitOnChange: true
if(delayedOffTrue) {
input “delayOnOffTrue”, “bool”, title: “Turn ON after the delay?”, multiple: false, required: false, defaultValue: false, submitOnChange: true
input “delayMinutesTrue”, “number”, title: “Minutes of delay”, required: true, range: “1…*”, submitOnChange: true
if(delayMinutesTrue) {
def delayStrTrue = "Delayed " + (delayOnOffTrue ? “On:” : “Off:”) + " $delayedOffTrue: $delayMinutesTrue minute"
if(delayMinutesTrue > 1) delayStrTrue = delayStrTrue + "s"
setActTrue(delayedOffTrue, delayStrTrue)
If so, what would I change?
The reason being… I have a contact relay on the Christmas wishlist with the plans to control a garage door, but everything I read says it needs to be turned on, then toggled off 3-4 seconds after (which I’m hoping to automate with your app).