Difference between revisions of "Rule Machine"

From Hubitat Documentation
Jump to: navigation, search
m
Line 1: Line 1:
Rule Machine<sup>®</sup> is a powerful automation tool for Hubitat.
+
<p><strong>Rule Machine®</strong> is a generalized rule engine for Hubitat. It allows you to predicate actions to be taken by Hubitat by a logical rule based on specified conditions of your system.  Rule Machine also provides Triggers, basic event-causes-action building blocks, and Triggered Rules where an event causes a rule evaluation.  Rules, Triggers, Triggered Rules, and Actions work together to create sophisticated automations.</p>
  
The Rule Machine<sup>®</sup> User Guide has five sections below:
+
<h2>What are rules?</h2>
  
*Conditions and Trigger Events
+
<p>A rule is a method of specifying certain conditions and their truth relationships in order to cause some action to take place in Hubitat.  </p>
  
*Actions
+
<p>For example, one person posed this case:</p>
  
*Expert Features: Custom Commands
+
<p>Suppose my presence or my wife’s presence is home, there is motion in the bedroom, it’s between 8 PM and 11PM, and the temperature is below 65 — if those conditions are met, turn on the electric blanket.</p>
  
*Restrictions
+
<p>In order for this action to take place in Hubitat, based on those conditions, Rule Machine will evaluate those conditions, and if they are met, turn on the electric blanket.  <strong>Rule Machine</strong> allows you to specify the conditions, the rule they must meet, and the desired actions to take place. This is called a <strong>Rule</strong>.</p>
  
*Appendix
+
<h2>What are triggers?</h2>
  
==Conditions and Trigger Events==
+
<p>A Trigger is a simple mechanism through which some event in your system causes a selected action to take place. This is a basic building block of automations. </p>
Rules and Triggers respond to events on the selected devices. In the case of a Rule, it evaluates its rule upon any event affecting its Conditions. In the case of a Trigger, it is fired whenever the selected event occurs.
 
  
Devices with the following capabilities may be Conditions or Trigger Events: [with noted exceptions]
+
<p>For example: if the door opens, turn on the light.  </p>
  
'''Acceleration'''
+
<h2>What are triggered rules?</h2>
  
"active" or "inactive"
+
<p>A triggered rule adds a rule to be evaluated for a triggered event. Wwhen any of its trigger events fire,  it evaluates the conditions under the rule and then takes actions based on the truth outcome of that evaluation.  This is called a <strong>Triggered Rule</strong>.</p>
  
'''Battery'''
+
<h2>What are actions?</h2>
 +
Actions are a set of actions that can be taken.  These don't do anything by themselves.  They can be used by Rules, Triggers and Triggered Rules as an action.  One defined set of actions can be used by multiple other rules or triggers without having to be defined for each one.
  
value
+
<h2>What are conditions and events?</h2>
  
'''Between Two Times''
+
<p><strong>Rule Machine</strong> allows a wide range of possible conditions and events to be selected.  For rules we select conditions.  For triggers we select events.  Conditions and events are closely related because each event results in a condition.  For example, the door opening is an event and results in the condition of the door being open.  Both rules and triggers rely on events to cause their actions.  Rules examine the conditions, and act on truth change.  Triggers act on events.  </p>
  
only between selected times
+
<p>Events are created by the devices in your system.  Each device creates events appropriate to the type of device.  When you create a rule, Rule Machine listens for any event that might affect the truth of the rule. When a rule receives a selected event, it evaluates the truth of its rule, and then takes selected actions based on that evaluation.  A trigger also listens for events.  When a trigger receives a selected event, it either takes the selected actions unconditionally (if no conditions were specified), or it causes the conditions to be evaluated under the rule and actions taken accordingly.</p>
  
'''Button''' [Only available as Trigger Event]
+
<p>Rule Machine allows the following conditions/events in a Hubitat system to be tested in a rule or acted upon in a trigger.  Each condition results in a single test. There may be as many conditions as you want in a rule, or as many event triggers as you want in a trigger.  The supported conditions, events and states that can be tested are listed below.  Note: Days of week and Time of day are not available in a trigger.  There are additional events available for triggers; see below.</p>
  
"number": "pressed"or "held"
+
<pre>Acceleration:     active / inactive
 +
Battery:     value
 +
Contact:     open / closed
 +
Days of week:      Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
 +
Dimmer level:     value
 +
Door:     open, closed, opening, closing, unknown
 +
Energy meter:     value
 +
Garage door:     open, closed, opening, closing, unknown
 +
HSM status:        armed away, armed home, disarmed
 +
Humidity:     value
 +
Illuminance:     value
 +
Lock:     locked / unlocked
 +
Mode:     any of your hub's modes
 +
Motion:     active / inactive
 +
Music player:     playing, paused, stopped
 +
Power meter:     value
 +
Presence:     present / not present or arrives / leaves
 +
Private Boolean: true / false
 +
Rule truth: true / false
 +
Smoke detector:    clear, detected, tested
 +
Switch:     on / off
 +
Temperature: value
 +
Thermostat mode: heat / cool / auto / off / emergency heat
 +
Thermostat state: heating / cooling / fan only / idle / pending heat / pending cool
 +
Time of day: between two times, including sunrise / sunset with offsets
 +
Water sensor: dry / wet
  
'''Contact:'''
+
Note: value means compare current value to a number
 +
      or to another device with an offset</code></pre>
  
"open" or "closed"
+
<p>Triggers respond to these additional events:</p>
  
'''Certain Time''' [Only available as Trigger Event]
+
<pre><code>Button:          pressed / held
 +
Certain Time:    at a certain time, including sunrise / sunset with offset
 +
Cloud End Point: hitting URL fires
 +
Local End Point: hitting URL fires
 +
Periodic:        Allows periodic schedules for minutes, hourly, daily, weekly, monthly or yearly
 +
Physical switch: on / off</code></pre>
  
at a certain time, including sunrise or sunset with offset
+
<p>For each condition/event that refers to a device, one or more devices can be selected, and then the device state required for the condition to be met can be selected.  When multiple devices are selected, the condition/event may apply for ANY (default) or ALL of the devices.  </p>
  
'''Days of week''' [Only available as Condition]
+
<p>For example, the conditions for the electric blanket case are,</p>
  
"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"
+
<blockquote><p>my presence or my wife’s presence is present (ANY)<br>bedroom motion is active<br>time of day is between 8:00 PM and 11:00 PM<br>bedroom temperature is &lt;  65</p></blockquote>
  
'''Dimmer level'''
+
<h2>How is a rule defined?</h2>
  
value
+
<p>A rule is a logical expression built up using the conditions and the three logical operators <code>AND</code>, <code>OR</code> and <code>NOT</code>, along with parenthesized sub-rules, each of which is itself a logical expression.  A logical expression defines the logical relationship between the various conditions.  In order to decide if the end action should be taken or not, <strong>Rule Machine</strong> evaluates the truth of the defined rule.  In the electric blanket case, we have a very simple rule: </p>
  
'''Door'''
+
<blockquote><p>my presence or my wife’s presence is present AND<br>bedroom motion is active AND<br>time of day is between 8:00 PM and 11:00 PM AND<br>bedroom temperature is &lt;  65</p></blockquote>
  
"open", "closed", "opening", "closing", "unknown"
+
<p>There can be more complex rules than this.  Suppose we want the same basic rule, but want it to apply if either bedroom motion is active or the bedroom door is closed.  We would add the additional condition of “bedroom door is closed”.  That rule would be this:</p>
  
'''Energy meter'''
+
<blockquote><p>my presence or my wife’s presence is present AND<br>(bedroom motion is active OR bedroom door is closed) AND<br>time of day is between 8:00 PM and 11:00 PM AND<br>bedroom temperature is &lt;  65</p></blockquote>
  
value
+
<p>In this example, we have used parentheses to group two conditions into a sub-rule: (bedroom motion is active <code>OR</code> bedroom door is closed).  <strong>Rule Machine</strong> allows arbitrarily complex rules to be defined, with parentheses used to group conditions into sub-rules.  To use this feature of sub-rules in parentheses, you must first turn on the "Advanced Rule input" option, at the beginning of the Define Rule page.  It allows nested sub-rules to any depth, and it allows any number of conditions.  To help you see exactly the rule you are building, <strong>Rule Machine</strong> displays the partial rule at each step as you define it.  See screen shots in a following post.</p>
  
'''Garage door'''
+
<p><strong>Rule Machine</strong> is a fully generalized rule engine.  The logical expression can be described as a sequence of terms, separated by operators, where each term is either a condition or a parenthesized sub-rule (available with Advanced Rule input enabled), and the operators are <code>AND</code>, <code>OR</code> and <code>NOT</code>.  The evaluation of a rule or sub-rule is strictly left to right.  If at any point in the evaluation, the truth value preceding an <code>AND</code> operator is <code>false</code>, the sub-rule or the rule itself is <code>false</code> without further evaluation.  Similarly, if the truth value preceding an <code>OR</code> operator is <code>true</code>, the sub-rule or the rule itself is <code>true</code> without further evaluation.  For those familiar with coding, there is no operator precedence as to <code>AND</code> and <code>OR</code>, only for <code>NOT</code> that applies to the term it precedes.  Each rule or sub-rule may have as many terms as desired, each separated by <code>AND</code> or <code>OR</code>.  Any term may be logically negated by preceding it with the <code>NOT</code> operator.</p>
  
"open", "closed", "opening", "closing", "unknown"
+
<h2>Rule Evaluation for Rules</h2>
  
'''Humidity'''
+
<p>A rule is installed with conditions, rule, and actions. For a rule, whenever something happens in Hubitat that could affect the conditions, <strong>Rule Machine</strong> evaluates the rule to see if it is <code>true</code> or <code>false</code>.  If it becomes <code>true</code>, then it will take some selected actions; if it becomes <code>false</code>, it can take some other selected actions.  In the case of the electric blanket, the rule would be evaluated whenever any of the following things happen:</p>
  
value
+
<blockquote><p>my presence or my wife’s presence arrives or leaves<br>the bedroom motion goes active or inactive<br>the bedroom door is opened or closed<br>the time becomes 8:00 PM, or becomes 11:00 PM<br>the bedroom temperature is reported</p></blockquote>
  
'''Illuminance'''
+
<p>Since our rule for this case involves all of these possible events, any of those events might be the one that changes the evaluation outcome from <code>false</code> to <code>true</code>.  If that happens, <strong>Rule Machine</strong> will turn on the electric blanket.</p>
  
value
+
<p><strong>Rule Machine</strong> only acts on the change of rule state from <code>false</code> to <code>true</code>, or <code>true</code> to <code>false</code>, except in the case of a trigger event causing rule evaluation.  It may evaluate the rule many times, depending on what sort of events are subscribed to, but only a truth change causes action.  A trigger causing rule evaluation will result in action if the rule is true, without regard to prior rule truth or rule truth changing.</p>
  
'''Lock'''
+
<p>The evaluation of a rule  is strictly from left to right.  If at any point in the evaluation, the truth value preceding an <code>AND</code> operator is <code>false</code>, the rule is <code>false</code> without any further evaluation.  Similarly, if the truth value preceding an <code>OR</code> operator is <code>true</code>, the rule is <code>true</code> without any further evaluation.  You must take this into consideration as you define your rule, if you have many terms.</p>
  
"locked" or "unlocked"
+
<h2>Triggered Rule</h2>
  
'''Lock Codes'''
+
<p>When a trigger event of a triggered rule occurs the conditions are evaluated under the rule, and then actions are taken based on the true/false outcome.  Only a trigger event will cause rule evaluation, and the action will be performed irrespective of the prior rule truth (unlike a rule, above).</p>
  
value
+
<h2>Actions for Rules,  Triggers, Triggered Rules and Actions</h2>
  
'''Mode'''
+
<p>When a rule proves <code>true</code>, after previously <code>false</code>, <strong>Rule Machine</strong> will do the actions selected on the Actions for True page.  When a Rule proves <code>false</code>, after previously <code>true</code>,  <strong>Rule Machine</strong> will do the actions on the Actions for False page.  When a Trigger event occurs for a trigger, <strong>Rule Machine</strong> will do the actions selected on the Actions page.  When a trigger event occurs for a Triggered Rule, <strong>Rule Machine</strong> will evaluate the rule and do the Actions for True or Actions for False accordingly.  </p>
  
any of your location’s modes
+
<blockquote>
 +
<p>The actions supported are the following:</p>
 +
<p>Delay these actions by minutes, seconds, or milliseconds, with optional cancel on change,  or random time<br>
 +
Switches to turn on<br>
 +
Switches to turn off<br>
 +
Switches to toggle<br>
 +
Switches to turn on or off after a delay<br>
 +
Switches to turn on or off after a delay, pending cancellation<br>
 +
Button to push<br>Button to push per mode<br>
 +
Capture switches state<br>
 +
Restore switches state, with optional delay, cancellable<br>
 +
Dimmers to level A, or to track event dimmers<br>
 +
Dimmers to level B<br>
 +
Dimmers to toggle<br>
 +
Dimmers to adjust +/-<br>
 +
Dimmers to level per mode<br>
 +
Set color temperature<br>
 +
Set colors<br>
 +
Raise shade<br>
 +
Lower shade<br>
 +
Stop shade<br>
 +
Adjust shade — up, stop, down, stop<br>
 +
Fan to adjust — low, medium, high, off<br>
 +
Open garage door<br>
 +
Close garage door<br>
 +
Locks to lock<br>
 +
Locks to unlock<br>
 +
Valves to open<br>
 +
Valves to close<br>
 +
Thermostats to set<br>
 +
Set Hubitat Safety Monitor state<br>
 +
Send or speak message, push, notification or SMS, with triggering device name<br>
 +
Change mode<br>
 +
Take photos<br>
 +
Control music player<br>
 +
Beep tone device<br>
 +
Set Private Boolean for this Rule or other Rule, with optional delay, cancellable<br>
 +
Evaluate Rules<br>
 +
Run Rule actions<br>
 +
Update Rules <br>
 +
Custom commands (see below)</p>
 +
</blockquote>
  
'''Motion'''
+
<p><strong>Note</strong>: Multiple phone numbers may be entered for SMS messages, each separated by a comma.  Phone numbers must begin with +1.</p>
  
"active" or "inactive"
+
<h2>Rule - Trigger Integration</h2>
  
'''Music player'''
+
<p>One of the most powerful features of Rule Machine is the ability of Rules and Triggers to be combined to create sophisticated automations.  Just as with the devices in your system, the Rules you have in Rule Machine have a state, their truth state.  Both Rules and Triggers can use rule-truth as a condition or as an event.  This leads to many possibilities, several of which are very useful:</p>
  
"playing", "paused", or "stopped"
+
<p>A Trigger can use rule-truth as an event.  When a Rule changes state, a Trigger can take actions.  This integration allows you to have additional actions for each Rule.  If you need more Actions for True, simply create a Trigger tied to rule-truth for that Rule becoming true, and you have additional actions available in the Trigger.  For example, suppose you want one Rule to start a sequence of actions.  Perhaps do one thing after 3 minutes, something else after 10 minutes, and then a final thing after 30 minutes.  One Rule plus two Triggers can do this, where each Trigger is tied to the rule-truth, then has an action that it delays taking for 10, or 30 minutes; the rule itself has the action of true of doing something after 3 minutes.</p>
  
'''Periodic''' [Only available as Trigger Event]
+
<p>A Rule can also use rule-truth as a condition.  This feature allows generalized linking of Rules.  One example would be to have a master set of conditions, that several Rules would need.  One Rule has those conditions but no actions.  The other Rules have the first rule-truth as a condition, and have whatever additional conditions they need, and take whatever actions they want.  This can make repetitive rule creation much simpler, or lead to very sophisticated automations.</p>
  
Allows periodic schedules for minutes, hourly, daily, weekly, monthly or yearly
+
<p>Both Triggers and Rules can take an action to cause a selected Rule (or Rules) to be evaluated.  This would allow, for example, a button to cause a Rule to be evaluated, through the use of a Trigger tied to the button.  Or, at a certain time of day, a Rule can be caused to be evaluated.  The reason these things might be useful, is that ordinarily a Rule only takes action when it changes truth state.  By causing a rule evaluation, the actions will be taken as selected for that Rule based on its truth, irrespective of the prior state of the rule-truth for that Rule.</p>
  
'''Physical switch''' [only available as Trigger Event]
+
<p>Both Triggers and Rules can also cause a selected Rule or Rules to have their Actions for True run irrespective of the Rule's Conditions or Rule.  This allows for triggers to share a Rule's actions, while preserving its Rule (vs. Triggered Rule) nature.  It is also possible to create a Rule that has no Triggers and no Conditions, a Rule that only has Actions.  Such a Rule can be run from any other Trigger or Rule as an action.</p>
  
"on" or "off"
+
<p><strong>Warning</strong>: When using any of the Rule - Trigger Integration features, <strong>do not change the name of any Rule, Trigger or Actions referenced by another rule</strong>.  The name of a rule is the linkage mechanism, and it is not possible to correct for a rule name change in the rules that make reference to it.  Consequently, changing the name of a rule will cause all of the rules that reference that rule to be broken.  Similarly, removing a rule would cause all of the rules that reference that rule to be broken.</p>
  
'''Power meter'''
+
<p><strong>Further Warning</strong>: It is possible with Rule-Trigger integration and Private Boolean to create rules with circular logic, possible indirect circular logic.  These are doomed to fail, sometimes by falling into infinite loops.  DO NOT use these features to create circularity, and be careful about the logic patterns you create by linking rules.  </p>
  
value
+
<h2>Custom Commands</h2>
  
'''Presence'''
+
<p>The Custom Commands section of Rule Machine allows you to discover commands available for virtually any device, including custom device types and otherwise not supported devices.  Once you've found a command you want to use, you can set parameters for it, and save it as a Custom Command.  These Custom Commands can be used in Actions for any rule (Actions for True, Actions for False, Actions).  Once you have saved one or more Custom Commands, the action "Run custom commands" becomes available in Actions, as the very last option.</p>
  
"present" / "not present"  or  "arrives" / "leaves"
+
<p>These are some notable examples of published devices with custom capabilities:</p>
  
'''Private Boolean'''
+
<ul>
 +
<li>Fibaro RGBW controller, all of the buttons in the device detail tile have associated custom commands.</li>
 +
<li>Sonos and other Speaker devices, playTrackAndRestore and playTrackAndResume being two that are useful.</li>
 +
<li>Thing Shields, every ThingShield has nothing but custom commands, you can now run these commands directly from Rule Machine.</li>
 +
<li>Thermostats often have commands that can be useful but are otherwise not exposed in Rule Machine.</li>
 +
<li>Multi channel relays; these can be controlled directly instead of with virtual switches.</li>
 +
</ul>
  
"true" or "false"
+
<p>Any device that formerly required a custom app to support could be a candidate to migrate and control using Rule Machine.</p>
  
'''Rule truth'''
+
<p>Here are a few examples in use with Rule Machine:</p>
  
"true" or "false"
+
<ul>
 +
<li>softwhite() and deepfade() on an Fibaro RGBW controller that uses <span class="mention">@twack</span> device type</li>
 +
<li>playTrackAndRestore('https://s3.amazonaws.com/smartthingssmartapps/Boss+is+arriving.mp3',6,30) on a Samsung Speaker</li>
 +
<li>fanOff() on a custom AEON dual switch device by <span class="mention">@Mike_Maxwell</span> </li>
 +
</ul>
  
'''Switch'''
+
<blockquote>
 +
<p>With custom commands, you can explore any device you have to see the commands that it offers. There are two steps required to use those commands in your rules.</p>
 +
<ol>
 +
<li>Create, test and save your custom command with "Tap to create Custom Commands" on the Rule Machine main page</li>
 +
<li>Incorporate the saved custom command into your rules with "Run custom commands"</li>
 +
</ol>
 +
<p><strong>1. Create, test and save your custom command</strong></p>
 +
<ul>
 +
<li>Open Rule Machine</li>
 +
<li>Under Expert Features "Tap to create Custom Commands"</li>
 +
<li>Select a capability for devices to test for available commands (if unsure, try Actuator)</li>
 +
<li>Select a device of that capability to test for commands</li>
 +
<li>Select New custom command to see the available commands, then select the command you want</li>
 +
<li>Once selected, the command will be tested on the selected device and the results of the command execution shown</li>
 +
<li>Add any required parameters to the command</li>
 +
<li>After the command is executing against the device as expected, select Save command now, then Done, then Done again to return to the Custom Commands page</li>
 +
<li>The saved custom command will now be available in your new and existing rules</li>
 +
</ul>
 +
<p><strong>2. Select the custom command to run in your rule and the devices to run it on</strong></p>
 +
<ul>
 +
<li>Create a new rule or edit an existing one</li>
 +
<li>In the Actions section (at the very bottom), select Run custom command, then select the custom command (saved above) and the devices to run it on</li>
 +
</ul>
 +
<p>Be sure that each device selected supports the selected command; any errors will be trapped and shown in the logs.</p>
 +
<p><strong>3. Manage custom commands</strong><br>One or more custom commands can be removed by selecting them in Delete Custom Commands, then Delete commands now, then Done. You can also test saved custom commands against other devices you might select.</p>
 +
</blockquote>
  
"on" or "off"
+
<p><strong>Tips</strong>:</p>
  
'''Temperature'''
+
<ul>
 +
<li>Un-select your test device or the "saved command to test" before leaving the custom commands page, otherwise the command will execute the next time you open the page.</li>
 +
<li>Un-Select "available device commands" after saving the new command, otherwise the command will execute the next time you open the page.</li>
 +
<li>Un-Select "parameter type" for each of your parameters, in reverse order (ie 3,2,1) after saving the new command, this is just a convenience thing.</li>
 +
<li>The success or failure of any parameters can't be determined by expert, use the logging in the IDE if you're having issues getting a command to function.</li>
 +
<li>If your wizBang device isn't in the list, add capability actuator to it.</li>
 +
</ul>
  
value
+
<p><strong>Cautions</strong>:<br>Using custom commands exposes commands on device types that aren't published or supported by Hubitat. When you expose these commands and play with them, you are doing so at your own risk. No one will have any sympathy when you successfully execute <code>wipeDisk()</code> on your new Samsung appliance and have bricked it. </p>
  
'''Thermostat mode'''
+
<h2>Dedication</h2>
  
"heat", "cool", "auto", "off" or "emergency heat"
+
<p>Rule Machine is dedicated to Alan Turing.  He gave us the concept of an abstract machine that could compute, and from that we built small implementations of his vision. Today, we all use them every day of our lives.</p>
  
'''Thermostat state'''
+
<h2>More Information</h2>
  
"heating", "cooling", "fan only", "idle", "pending heat" or "pending cool"
+
See [this post](https://community.hubitat.com/t/what-is-the-best-way-to-know-what-hubitat-can-and-cant-do/2143/23) for a mini-tutorial on Rule-Trigger Integration and Private Boolean.
 
 
'''Time of day''' [Only available as Condition]
 
 
 
between two times, including sunrise or sunset with offsets
 
 
 
'''Water sensor'''
 
 
 
"dry" or "wet"
 
 
 
Note: '''value''' means compare current value to a number or to another device with an offset
 
 
 
'''Limitation:''' a rule may only have at most one each of Days of week, Mode, or Time of day as conditions. If you need logic for two different Time of day periods, that would have to be done in two separate rules. A trigger can have at most one each of Certain Time, Mode change, or Periodic schedule as trigger events. If you need more time events, that would have to be done in separate triggers.
 
==Actions==
 
 
 
*Rules, Triggers, Triggered Rules and Actions run selected Actions.
 
 
 
*Rules and Triggered Rules run Actions for True or Actions for False depending on Rule evaluation outcome.
 
 
 
*Triggers and Actions just run Actions.
 
 
 
'''Delay these actions''' [by minutes, seconds, or milliseconds, with optional cancel on change, or random time]
 
 
 
This selection causes all of the selected actions in a Rule (for Actions for True, Actions for False, or simply Actions) to be delayed. A delay of minutes or seconds may apply for any action. Delays of less than 60 seconds may not work reliably. A delay of milliseconds only applies for actions on, off, dim level, open, and close. For delays in Rules of minutes or seconds, an option to Cancel on truth change is available. If selected, should the rule truth change before expiration of the delay, the delayed actions are cancelled. A random delay is also available. This will be for a random number of seconds up to the delay time selected.
 
 
 
'''Turn on these switches'''
 
 
 
This action turns on the selected switches.
 
 
 
'''Turn off these switches'''
 
 
 
This action turns off the selected switches.
 
 
 
'''Toggle these switches'''
 
 
 
If the selected switches are on, this action turns them off, and if they are on, it turns them off.
 
 
 
'''Turn on or off these switches after a delay'''
 
 
 
This action turns on or turns off the selected switches after a delay. The choice between on or off is available, with off being the default. Delays of minutes, seconds or milliseconds may be selected. Delays of less than 60 seconds may be less reliable. Delays of up to 5000 milliseconds seem to be fairly reliable.
 
 
 
'''Turn on or off these switches after a delay, pending cancellation'''
 
 
 
This action turns on or turns off the selected switches after a delay, pending a change of rule truth. Should rule truth change before the expiration of the delay, the delayed action is cancelled. The choice between on or off is available, with off being the default. This action is not available for Triggers or Actions, only for Rules. (Rules Rule!)
 
 
 
'''Push a button'''
 
 
 
This action causes the selected button to be pushed.
 
 
 
'''Push button per mode'''
 
 
 
This action causes a selected button to be pushed depending upon the current mode. Multiple modes with corresponding buttons can be selected.
 
 
 
'''Set these dimmers'''
 
 
 
This action sets the selected dimmers to the selected level with an optional fade time, or tracks another dimmer’s level.
 
 
 
Track event dimmer works along with a Condition or Trigger Event of “Dimmer level”. When this dimmer level event causes the rule to run this action, the selected dimmers are set to the same level as the dimmer that triggered the rule. This can be used in automations where a group of dimmers follow another dimmer as it changes level. The typical usage for a Trigger is to have a Trigger Event of “Dimmer level >= 0”, and then Track Dim as the action.
 
 
 
'''Set these other dimmers'''
 
 
 
This action sets the selected dimmers to the selected level with optional fade time, allowing a second dimmer level for each rule.
 
 
 
'''Toggle these dimmers'''
 
 
 
If the selected dimmers are on, this action turns them off. If the selected dimmers are off, it sets them to the selected level. Optional fade time may be selected.
 
 
 
'''Adjust these dimmers'''
 
 
 
This action adjusts the selected dimmers’ level up or down by the selected amount, with optional fade time. Dimmer values range from 0 to 100. Adjusting to 0 does not necessarily mean that the device is turned off.
 
 
 
'''Set these dimmers per mode'''
 
 
 
This action sets the selected dimmers to the level selected for the current mode, with optional fade time. Multiple modes with corresponding dimmer levels can be selected.
 
 
 
'''Capture the state of these switches'''
 
 
 
This action captures the state of the selected switches, including on/off, hue, saturation and level. The captured state can be used in the “Restore the state of captured switches” action.
 
 
 
'''Restore the state of captured switches'''
 
 
 
This action restores the state to the devices selected in the “Capture the state of these switches” action, restoring the devices to the state captured by the most recent Capture action run. It is up to the user to design and use the rule such that Capture occurs prior to Restore. It is possible to select a delay for Restore, and optionally to Cancel such a delay on rule truth change.
 
 
 
'''Set color temperature for these bulbs'''
 
 
 
This action sets the colour temperature for the selected bulbs. {a sic compromise}
 
 
 
'''Set color for these bulbs'''
 
 
 
This action sets the colour and level for the selected bulbs.
 
 
 
'''Open these garage doors'''
 
 
 
This action opens the selected garage doors.
 
 
 
'''Close these garage doors'''
 
 
 
This action closes the selected garage doors.
 
 
 
'''Locks to lock'''
 
 
 
This action locks the selected locks.
 
 
 
'''Locks to unlock'''
 
 
 
This action unlocks the selected locks.
 
 
 
'''Adjust this fan — Low, Medium, High, Off'''
 
 
 
This action adjusts a fan switch with successive trigger events first to low, then medium, then high, then off. To simply set a fan switch to low, medium or high, treat it as a dimmer and set the dimmer level to 20, 50, or 80 respectively.
 
 
 
'''Open these valves'''
 
 
 
This action opens the selected valves.
 
 
 
'''Close these valves'''
 
 
 
This action closes the selected valves.
 
 
 
'''Set these thermostats'''
 
 
 
This action sets various settings of a thermostat. The thermostat mode, heating setpoint, cooling setpoint, and fan setting can be selected. It is possible to adjust the heating or cooling setpoints up or down by a selected amount. For thermostat mode, the choices are “auto”, “heat”, “cool”, “off” and “emergency heat”. For the setpoints and adjustments, the number input may have a decimal fraction, e.g. 21.5, which is helpful with degrees Celsius devices. For fan setting, the choices are “on” and “auto”.
 
 
 
'''Set the mode'''
 
 
 
This action sets the location mode to the selected mode.
 
 
 
'''Send http request'''
 
 
 
Sends asyncGET to URL; allows %device% and/or %value% in URL for last event device and/or value
 
 
 
'''Send or speak a message'''
 
 
 
This action sends a push or notification, as selected, and optionally includes the name of the device that triggered the actions. It can also send an SMS to multiple phones (separate the numbers with *). This action also supports devices that speak or process text to speech.
 
 
 
'''Take photos'''
 
 
 
This action takes a burst of photos with the selected camera.
 
 
 
'''Evaluate Rules'''
 
 
 
This action causes the selected Rules to be evaluated.
 
 
 
'''Run Rule Actions'''
 
 
 
This action causes the Actions for True or Actions for the selected Rules to be run.
 
 
 
'''Update Rules'''
 
 
 
This action causes the selected Rules to be updated to refresh subscriptions and schedules.
 
 
 
'''Evaluate Rules after delay'''
 
 
 
This action causes the selected Rules to be evaluated after a delay of a selected number of minutes. This action allows the Rule it is used in to be the Rule selected to be evaluated after the delay; this is a looping mechanism.
 
 
 
'''Set private Boolean'''
 
 
 
This action sets the Rule’s private Boolean variable to true or false, and/or the private Boolean variable of other Rules to true or false. There is an option to delay this. If the action is to set the rule’s own private Boolean with a delay, the delayed action is treated as an event, causing rule evaluation or possibly a trigger event. Setting a private Boolean of another rule is treated as an event by that rule. Setting a rule’s own private Boolean is not an event unless it is delayed. Private Boolean with a delay may be used to create a looping mechanism. It is possible to have a delay cancelled upon rule truth change.
 
 
 
'''Run custom commands'''
 
 
 
This action runs selected custom commands. Custom commands must first be created and saved in the Expert Features section of Rule Machine<sup>®</sup>.
 
 
 
'''Switches Per Mode'''
 
 
 
Activates selected switches during specified mode.
 
 
 
'''Activate Scene Per Mode'''
 
 
 
Activates selected Scene during specified mode.
 
 
 
'''Delay (Cancel) Per Mode'''
 
 
 
Delays automation by a specified amount of time during selected modes.
 
==Expert Features: Custom Commands==
 
With custom commands, you can explore any device you have to see the commands that it offers. There are two steps required to use those commands in your rules, and then a third to manage your commands.
 
 
 
*Create, test and save your custom command with “Tap to create Custom Commands” on the Rule Machine<sup>®</sup> main page
 
 
 
*Incorporate the saved custom command into your rules with “Run custom commands”
 
 
 
*Manage custom commands with “Delete saved commands” and “Test saved command on…”
 
 
 
#Create, test and save your custom command
 
 
 
:*Open Rule Machine<sup>®</sup>
 
 
 
:*Under Expert Features “Tap to create Custom Commands”
 
 
 
:*Select a capability for devices to test for available commands (if unsure, try Actuator)
 
 
 
:*Select a device of that capability to test for commands
 
 
 
:*Select New custom command to see the available commands, then select the command you want
 
 
 
:*Once selected, the command will be tested on the selected device and the results of the command execution shown
 
 
 
:*Add any required parameters to the command
 
 
 
:*After the command is executing against the device as expected, select Save command now, then Done, then Done again to return to the Custom Commands page
 
 
 
:*The saved custom command will now be available in your new and existing rules
 
 
 
#Select the custom command to run in your rule and the devices to run it on
 
 
 
:*Create a new rule or edit an existing one
 
 
 
:*In the Actions section (at the very bottom), select Run custom command, then select the custom command (saved above) and the devices to run it on
 
 
 
Be sure that each device selected supports the selected command; any errors will be trapped and shown in the logs.
 
 
 
#Manage custom commands
 
 
 
One or more custom commands can be removed by selecting them in Delete Custom Commands, then Delete commands now, then Done. You can also test saved custom commands against other devices you might select.
 
==Restrictions==
 
The Restrictions section of defining a rule allows you to restrict when or under what conditions the rule may run. When restricted, the rule does nothing and timers are ignored. Restrictions may seem similar to some Conditions, but they are actually quite distinct. Restrictions do not participate in the logic of the Conditions and the Rule in any way. Restrictions simply enable or disable the rule from doing things. Conditions, on the other hand, are subscribed to their events, and those events cause rule evaluations to occur, and possibly actions to run. A restriction doesn’t do any of those things, it merely restricts.
 
 
 
The restriction options are:
 
 
 
'''Only during a certain time [including sunrise or sunset with offsets]'''
 
 
 
This setting restricts when a rule may run to a certain time period, start and stop. Outside of the selected time period, the rule will do nothing, all outstanding timers are ignored.
 
 
 
'''Only on certain days of the week'''
 
 
 
This setting restricts when a rule may run to certain days of the week. On days not selected, the rule will do nothing, all outstanding timers are ignored.
 
 
 
'''Only when mode is …'''
 
 
 
This setting restricts the rule to only run when the location’s mode is one of the modes selected. At any time when not in one of the selected modes, the rule will do nothing, all outstanding timers are ignored.
 
 
 
'''Switch to disable Rule'''
 
 
 
This setting selects a switch device, possibly virtual, which if on disables the rule. If off, the rule is enabled. There is an option to reverse the meanings of on and off, so that on means enable, and off means disable. When the rule is disabled, the rule will do nothing, all outstanding timers are ignored.
 
 
 
'''Enable/Disable with private Boolean?'''
 
 
 
This setting allows the rule’s private Boolean variable to act as an enable / disable selector. If this option is selected, then the rule is enabled when its private Boolean is true, and is disabled when its private Boolean is false. Other rules may set the rule’s private Boolean. The private Boolean variable is initialized to true when a rule is created, so when selecting this option to use private Boolean to disable, the rule will start out enabled. When the rule is disabled, the rule will do nothing, all outstanding timers are ignored.
 
 
 
==Appendix==
 
 
 
'''Order of execution'''
 
 
 
Actions within a rule are done in the following order:
 
 
 
capture devices<br/>
 
switch on<br/>
 
refresh device<br/>
 
poll device<br/>
 
start z-wave poller dimmer<br/>
 
start z-wave poller switch<br/>
 
stop z-wave poller dimmer<br/>
 
stop z-wave poller switch<br/>
 
toggle<br/>
 
flash<br/>
 
delay off<br/>
 
delay off cancel<br/>
 
switch per mode<br/>
 
delay per mode<br/>
 
push button<br/>
 
button per mode<br/>
 
track dimmer<br/>
 
set dimmer<br/>
 
set other dimmer<br/>
 
toggle dimmer<br/>
 
adjust dimmer<br/>
 
dimmer per mode<br/>
 
fade dimmer over time<br/>
 
activate scene<br/>
 
scene per mode<br/>
 
set color temp<br/>
 
color temp per mode<br/>
 
set color<br/>
 
garage open<br/>
 
garage close<br/>
 
lock<br/>
 
unlock<br/>
 
adjust fan<br/>
 
raise shade<br/>
 
lower shade<br/>
 
stop shade<br/>
 
adjust shade<br/>
 
open valve<br/>
 
close valve<br/>
 
thermostat<br/>
 
hsm setArm<br/>
 
set mode<br/>
 
player<br/>
 
toner<br/>
 
http get<br/>
 
resume rule<br/>
 
private Boolean true<br/>
 
private Boolean false<br/>
 
evaluate rule<br/>
 
rule actions<br/>
 
stop rule actions<br/>
 
pause rule<br/>
 
camera<br/>
 
notify<br/>
 
send sms<br/>
 
speak<br/>
 
media<br/>
 
switch off<br/>
 
restore devices<br/>
 
repeat seconds<br/>
 
repeat minutes<br/>
 
repeat hours<br/>
 
execute custom commands<br/>
 

Revision as of 18:27, 10 May 2019

Rule Machine® is a generalized rule engine for Hubitat. It allows you to predicate actions to be taken by Hubitat by a logical rule based on specified conditions of your system. Rule Machine also provides Triggers, basic event-causes-action building blocks, and Triggered Rules where an event causes a rule evaluation. Rules, Triggers, Triggered Rules, and Actions work together to create sophisticated automations.

What are rules?

A rule is a method of specifying certain conditions and their truth relationships in order to cause some action to take place in Hubitat.

For example, one person posed this case:

Suppose my presence or my wife’s presence is home, there is motion in the bedroom, it’s between 8 PM and 11PM, and the temperature is below 65 — if those conditions are met, turn on the electric blanket.

In order for this action to take place in Hubitat, based on those conditions, Rule Machine will evaluate those conditions, and if they are met, turn on the electric blanket. Rule Machine allows you to specify the conditions, the rule they must meet, and the desired actions to take place. This is called a Rule.

What are triggers?

A Trigger is a simple mechanism through which some event in your system causes a selected action to take place. This is a basic building block of automations.

For example: if the door opens, turn on the light.

What are triggered rules?

A triggered rule adds a rule to be evaluated for a triggered event. Wwhen any of its trigger events fire, it evaluates the conditions under the rule and then takes actions based on the truth outcome of that evaluation. This is called a Triggered Rule.

What are actions?

Actions are a set of actions that can be taken. These don't do anything by themselves. They can be used by Rules, Triggers and Triggered Rules as an action. One defined set of actions can be used by multiple other rules or triggers without having to be defined for each one.

What are conditions and events?

Rule Machine allows a wide range of possible conditions and events to be selected. For rules we select conditions. For triggers we select events. Conditions and events are closely related because each event results in a condition. For example, the door opening is an event and results in the condition of the door being open. Both rules and triggers rely on events to cause their actions. Rules examine the conditions, and act on truth change. Triggers act on events.

Events are created by the devices in your system. Each device creates events appropriate to the type of device. When you create a rule, Rule Machine listens for any event that might affect the truth of the rule. When a rule receives a selected event, it evaluates the truth of its rule, and then takes selected actions based on that evaluation. A trigger also listens for events. When a trigger receives a selected event, it either takes the selected actions unconditionally (if no conditions were specified), or it causes the conditions to be evaluated under the rule and actions taken accordingly.

Rule Machine allows the following conditions/events in a Hubitat system to be tested in a rule or acted upon in a trigger. Each condition results in a single test. There may be as many conditions as you want in a rule, or as many event triggers as you want in a trigger. The supported conditions, events and states that can be tested are listed below. Note: Days of week and Time of day are not available in a trigger. There are additional events available for triggers; see below.

Acceleration:	    active / inactive
Battery: 		    value
Contact:		    open / closed
Days of week:       Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
Dimmer level: 	    value
Door: 			    open, closed, opening, closing, unknown
Energy meter:	    value
Garage door: 	    open, closed, opening, closing, unknown
HSM status:         armed away, armed home, disarmed
Humidity:		    value
Illuminance:	    value
Lock:			    locked / unlocked
Mode:			    any of your hub's modes
Motion:			    active / inactive
Music player: 	    playing, paused, stopped
Power meter:	    value
Presence:		    present / not present or arrives / leaves
Private Boolean: 	true / false
Rule truth: 		true / false
Smoke detector:     clear, detected, tested
Switch:			    on / off
Temperature:		value
Thermostat mode: 	heat / cool / auto / off / emergency heat
Thermostat state: 	heating / cooling / fan only / idle / pending heat / pending cool
Time of day:		between two times, including sunrise / sunset with offsets
Water sensor: 		dry / wet

Note: value means compare current value to a number 
      or to another device with an offset</code>

Triggers respond to these additional events:

<code>Button:          pressed / held
Certain Time:    at a certain time, including sunrise / sunset with offset
Cloud End Point: hitting URL fires
Local End Point: hitting URL fires
Periodic:        Allows periodic schedules for minutes, hourly, daily, weekly, monthly or yearly
Physical switch: on / off</code>

For each condition/event that refers to a device, one or more devices can be selected, and then the device state required for the condition to be met can be selected. When multiple devices are selected, the condition/event may apply for ANY (default) or ALL of the devices.

For example, the conditions for the electric blanket case are,

my presence or my wife’s presence is present (ANY)
bedroom motion is active
time of day is between 8:00 PM and 11:00 PM
bedroom temperature is < 65

How is a rule defined?

A rule is a logical expression built up using the conditions and the three logical operators AND, OR and NOT, along with parenthesized sub-rules, each of which is itself a logical expression. A logical expression defines the logical relationship between the various conditions. In order to decide if the end action should be taken or not, Rule Machine evaluates the truth of the defined rule. In the electric blanket case, we have a very simple rule:

my presence or my wife’s presence is present AND
bedroom motion is active AND
time of day is between 8:00 PM and 11:00 PM AND
bedroom temperature is < 65

There can be more complex rules than this. Suppose we want the same basic rule, but want it to apply if either bedroom motion is active or the bedroom door is closed. We would add the additional condition of “bedroom door is closed”. That rule would be this:

my presence or my wife’s presence is present AND
(bedroom motion is active OR bedroom door is closed) AND
time of day is between 8:00 PM and 11:00 PM AND
bedroom temperature is < 65

In this example, we have used parentheses to group two conditions into a sub-rule: (bedroom motion is active OR bedroom door is closed). Rule Machine allows arbitrarily complex rules to be defined, with parentheses used to group conditions into sub-rules. To use this feature of sub-rules in parentheses, you must first turn on the "Advanced Rule input" option, at the beginning of the Define Rule page. It allows nested sub-rules to any depth, and it allows any number of conditions. To help you see exactly the rule you are building, Rule Machine displays the partial rule at each step as you define it. See screen shots in a following post.

Rule Machine is a fully generalized rule engine. The logical expression can be described as a sequence of terms, separated by operators, where each term is either a condition or a parenthesized sub-rule (available with Advanced Rule input enabled), and the operators are AND, OR and NOT. The evaluation of a rule or sub-rule is strictly left to right. If at any point in the evaluation, the truth value preceding an AND operator is false, the sub-rule or the rule itself is false without further evaluation. Similarly, if the truth value preceding an OR operator is true, the sub-rule or the rule itself is true without further evaluation. For those familiar with coding, there is no operator precedence as to AND and OR, only for NOT that applies to the term it precedes. Each rule or sub-rule may have as many terms as desired, each separated by AND or OR. Any term may be logically negated by preceding it with the NOT operator.

Rule Evaluation for Rules

A rule is installed with conditions, rule, and actions. For a rule, whenever something happens in Hubitat that could affect the conditions, Rule Machine evaluates the rule to see if it is true or false. If it becomes true, then it will take some selected actions; if it becomes false, it can take some other selected actions. In the case of the electric blanket, the rule would be evaluated whenever any of the following things happen:

my presence or my wife’s presence arrives or leaves
the bedroom motion goes active or inactive
the bedroom door is opened or closed
the time becomes 8:00 PM, or becomes 11:00 PM
the bedroom temperature is reported

Since our rule for this case involves all of these possible events, any of those events might be the one that changes the evaluation outcome from false to true. If that happens, Rule Machine will turn on the electric blanket.

Rule Machine only acts on the change of rule state from false to true, or true to false, except in the case of a trigger event causing rule evaluation. It may evaluate the rule many times, depending on what sort of events are subscribed to, but only a truth change causes action. A trigger causing rule evaluation will result in action if the rule is true, without regard to prior rule truth or rule truth changing.

The evaluation of a rule is strictly from left to right. If at any point in the evaluation, the truth value preceding an AND operator is false, the rule is false without any further evaluation. Similarly, if the truth value preceding an OR operator is true, the rule is true without any further evaluation. You must take this into consideration as you define your rule, if you have many terms.

Triggered Rule

When a trigger event of a triggered rule occurs the conditions are evaluated under the rule, and then actions are taken based on the true/false outcome. Only a trigger event will cause rule evaluation, and the action will be performed irrespective of the prior rule truth (unlike a rule, above).

Actions for Rules, Triggers, Triggered Rules and Actions

When a rule proves true, after previously false, Rule Machine will do the actions selected on the Actions for True page. When a Rule proves false, after previously true, Rule Machine will do the actions on the Actions for False page. When a Trigger event occurs for a trigger, Rule Machine will do the actions selected on the Actions page. When a trigger event occurs for a Triggered Rule, Rule Machine will evaluate the rule and do the Actions for True or Actions for False accordingly.

The actions supported are the following:

Delay these actions by minutes, seconds, or milliseconds, with optional cancel on change, or random time
Switches to turn on
Switches to turn off
Switches to toggle
Switches to turn on or off after a delay
Switches to turn on or off after a delay, pending cancellation
Button to push
Button to push per mode
Capture switches state
Restore switches state, with optional delay, cancellable
Dimmers to level A, or to track event dimmers
Dimmers to level B
Dimmers to toggle
Dimmers to adjust +/-
Dimmers to level per mode
Set color temperature
Set colors
Raise shade
Lower shade
Stop shade
Adjust shade — up, stop, down, stop
Fan to adjust — low, medium, high, off
Open garage door
Close garage door
Locks to lock
Locks to unlock
Valves to open
Valves to close
Thermostats to set
Set Hubitat Safety Monitor state
Send or speak message, push, notification or SMS, with triggering device name
Change mode
Take photos
Control music player
Beep tone device
Set Private Boolean for this Rule or other Rule, with optional delay, cancellable
Evaluate Rules
Run Rule actions
Update Rules
Custom commands (see below)

Note: Multiple phone numbers may be entered for SMS messages, each separated by a comma. Phone numbers must begin with +1.

Rule - Trigger Integration

One of the most powerful features of Rule Machine is the ability of Rules and Triggers to be combined to create sophisticated automations. Just as with the devices in your system, the Rules you have in Rule Machine have a state, their truth state. Both Rules and Triggers can use rule-truth as a condition or as an event. This leads to many possibilities, several of which are very useful:

A Trigger can use rule-truth as an event. When a Rule changes state, a Trigger can take actions. This integration allows you to have additional actions for each Rule. If you need more Actions for True, simply create a Trigger tied to rule-truth for that Rule becoming true, and you have additional actions available in the Trigger. For example, suppose you want one Rule to start a sequence of actions. Perhaps do one thing after 3 minutes, something else after 10 minutes, and then a final thing after 30 minutes. One Rule plus two Triggers can do this, where each Trigger is tied to the rule-truth, then has an action that it delays taking for 10, or 30 minutes; the rule itself has the action of true of doing something after 3 minutes.

A Rule can also use rule-truth as a condition. This feature allows generalized linking of Rules. One example would be to have a master set of conditions, that several Rules would need. One Rule has those conditions but no actions. The other Rules have the first rule-truth as a condition, and have whatever additional conditions they need, and take whatever actions they want. This can make repetitive rule creation much simpler, or lead to very sophisticated automations.

Both Triggers and Rules can take an action to cause a selected Rule (or Rules) to be evaluated. This would allow, for example, a button to cause a Rule to be evaluated, through the use of a Trigger tied to the button. Or, at a certain time of day, a Rule can be caused to be evaluated. The reason these things might be useful, is that ordinarily a Rule only takes action when it changes truth state. By causing a rule evaluation, the actions will be taken as selected for that Rule based on its truth, irrespective of the prior state of the rule-truth for that Rule.

Both Triggers and Rules can also cause a selected Rule or Rules to have their Actions for True run irrespective of the Rule's Conditions or Rule. This allows for triggers to share a Rule's actions, while preserving its Rule (vs. Triggered Rule) nature. It is also possible to create a Rule that has no Triggers and no Conditions, a Rule that only has Actions. Such a Rule can be run from any other Trigger or Rule as an action.

Warning: When using any of the Rule - Trigger Integration features, do not change the name of any Rule, Trigger or Actions referenced by another rule. The name of a rule is the linkage mechanism, and it is not possible to correct for a rule name change in the rules that make reference to it. Consequently, changing the name of a rule will cause all of the rules that reference that rule to be broken. Similarly, removing a rule would cause all of the rules that reference that rule to be broken.

Further Warning: It is possible with Rule-Trigger integration and Private Boolean to create rules with circular logic, possible indirect circular logic. These are doomed to fail, sometimes by falling into infinite loops. DO NOT use these features to create circularity, and be careful about the logic patterns you create by linking rules.

Custom Commands

The Custom Commands section of Rule Machine allows you to discover commands available for virtually any device, including custom device types and otherwise not supported devices. Once you've found a command you want to use, you can set parameters for it, and save it as a Custom Command. These Custom Commands can be used in Actions for any rule (Actions for True, Actions for False, Actions). Once you have saved one or more Custom Commands, the action "Run custom commands" becomes available in Actions, as the very last option.

These are some notable examples of published devices with custom capabilities:

  • Fibaro RGBW controller, all of the buttons in the device detail tile have associated custom commands.
  • Sonos and other Speaker devices, playTrackAndRestore and playTrackAndResume being two that are useful.
  • Thing Shields, every ThingShield has nothing but custom commands, you can now run these commands directly from Rule Machine.
  • Thermostats often have commands that can be useful but are otherwise not exposed in Rule Machine.
  • Multi channel relays; these can be controlled directly instead of with virtual switches.

Any device that formerly required a custom app to support could be a candidate to migrate and control using Rule Machine.

Here are a few examples in use with Rule Machine:

With custom commands, you can explore any device you have to see the commands that it offers. There are two steps required to use those commands in your rules.

  1. Create, test and save your custom command with "Tap to create Custom Commands" on the Rule Machine main page
  2. Incorporate the saved custom command into your rules with "Run custom commands"

1. Create, test and save your custom command

  • Open Rule Machine
  • Under Expert Features "Tap to create Custom Commands"
  • Select a capability for devices to test for available commands (if unsure, try Actuator)
  • Select a device of that capability to test for commands
  • Select New custom command to see the available commands, then select the command you want
  • Once selected, the command will be tested on the selected device and the results of the command execution shown
  • Add any required parameters to the command
  • After the command is executing against the device as expected, select Save command now, then Done, then Done again to return to the Custom Commands page
  • The saved custom command will now be available in your new and existing rules

2. Select the custom command to run in your rule and the devices to run it on

  • Create a new rule or edit an existing one
  • In the Actions section (at the very bottom), select Run custom command, then select the custom command (saved above) and the devices to run it on

Be sure that each device selected supports the selected command; any errors will be trapped and shown in the logs.

3. Manage custom commands
One or more custom commands can be removed by selecting them in Delete Custom Commands, then Delete commands now, then Done. You can also test saved custom commands against other devices you might select.

Tips:

  • Un-select your test device or the "saved command to test" before leaving the custom commands page, otherwise the command will execute the next time you open the page.
  • Un-Select "available device commands" after saving the new command, otherwise the command will execute the next time you open the page.
  • Un-Select "parameter type" for each of your parameters, in reverse order (ie 3,2,1) after saving the new command, this is just a convenience thing.
  • The success or failure of any parameters can't be determined by expert, use the logging in the IDE if you're having issues getting a command to function.
  • If your wizBang device isn't in the list, add capability actuator to it.

Cautions:
Using custom commands exposes commands on device types that aren't published or supported by Hubitat. When you expose these commands and play with them, you are doing so at your own risk. No one will have any sympathy when you successfully execute wipeDisk() on your new Samsung appliance and have bricked it.

Dedication

Rule Machine is dedicated to Alan Turing. He gave us the concept of an abstract machine that could compute, and from that we built small implementations of his vision. Today, we all use them every day of our lives.

More Information

See [this post](https://community.hubitat.com/t/what-is-the-best-way-to-know-what-hubitat-can-and-cant-do/2143/23) for a mini-tutorial on Rule-Trigger Integration and Private Boolean.