Release 2.2.8 introduces a number of new features, new apps, and new app features. These include Hub Variables, a new version of Rule Machine, Rule 5.0, Button Controller 5.0, and Button Rule 5.0.
Hub Variables
We have added Hub Variables as a Setting for the hub. Hub Variables are quite similar to Global Variables in Rule Machine, but implemented in the hub rather than in the RM parent app. This provides for the use of Hub Variables in other apps, not just in RM. Hub Variables are very efficient, being implemented directly in the hub.
Hub Variables are one of five types: Number, Decimal, String, Boolean and DateTime. We have extended the Time type of variable to DateTime, allowing both time and date to be set. The use of date has very limited applicability for now, specifically in the Certain Time trigger for Rule 5.0, where triggering on a specific date is possible; by using a DateTime connector, that can be a variable Date and Time.
Each Hub Variable can have an associated Connector. A Connector is a virtual device linked to the Hub Variable. When the Hub Variable value changes, so does the Connector value, and vice versa. When the Connector device is set to a different value, the corresponding Hub Variable is set to that value. Connectors can be used in any app.
The UI for managing Hub Variables can be found in Settings. This allows for the creation of a Hub Variable, changing its value, creating a Connector for it, and removing it. If a Hub Variable is in use by an app, the name of the Hub Variable is shown in orange, and clicking that shows the apps it is in use by. When a Connector is created, the type of Connector is shown in blue, and clicking that opens a new tab with the Connector device page. The value of the variable can be changed by clicking on the purple text in the Value column. When a Connector exists, the variable value is shown with the selected attribute for the Connector. For example, a Boolean variable for which a Switch Connector is created, will show "on" or "off" as the possible values, instead of "true" and "false".
To remove a Connector, open the device page for the Connector and remove it from that page. If the Connector is in use by any apps, be sure to clean up those apps first; the warning to do so is presented to prevent mistakes.
To remove a Hub Variable, click on Delete for that variable. If the variable is in use by an app, an appropriate warning will be provided, and those apps should be cleaned up before deleting the Hub Variable.
Rule Machine
There is a new version of the main Rule Machine parent app. In order to transition to Hub Variables it is necessary to introduce this new parent app, as the former parent app incorporates support for Global Variables, which are replaced by Hub Variables going forward. Due to the need for ongoing backwards compatibility with existing rules, it is a requirement that the older version of Rule Machine not be changed with respect to Global Variables. Thus, the new parent app is introduced in 2.2.8. The older parent is now called Rule Machine Legacy. We've learned that it is better to have less rather than more functionality in a major parent app such as Rule Machine. This is one of the motivations behind moving away from Global Variables., as well as improving variable performance with Hub Variables supported directly by the hub system.
Rule Machine remains the means going forward to create new rules, and those rules will be Rule 5.0 (see below). All existing instances of Rule-4.1 will continue to function, and there is no need to convert these rules to Rule 5.0. Rule Machine Legacy will continue to be available until release 2.2.9, so in the interim it is possible to create either Rule-4.1 rules or Rule 5.0 rules. We encourage you to move to using the new Rule Machine and Rule 5.0 going forward.
Rule 5.0
There are a number of improvements in Rule 5.0 relative to Rule-4.1. These include Predicate Conditions, Hub and Local Variable usage, and Wait for Conditions for Duration.
Predicate Conditions
There is a new option to define Predicate Conditions ā essentially a logical expression like any other in rules. When defined, the rule will only be triggered if the Predicate Conditions are true. Subscriptions are made to the devices used in Predicate Conditions, so the truth is updated as the devices and other conditions change state. Predicate Conditions are based on the state of the selected conditions before an event triggers the rule. An event triggering a rule therefore does not change the truthfulness of the Predicate Conditions as pertain to that triggering of the rule. The truthfulness of the Predicate Conditions is again established after the rule has run, if it does run.
Predicate Conditions have two main uses: First is to restrict a rule to only run when certain conditions are true. As such, a wide variety of custom restrictions can be used. Second is to implement state transition based rules. If an initial state for such a transition is set as the Predicate Conditions, then a trigger that realizes the transition can fire, but only when that initial state is in true, in other words, the rule only runs for the intended state transition.
As an example, suppose we want a rule that runs when the mode changes from Away to Evening. A regular trigger on Mode becomes Evening would fire whenever the mode becomes Evening. But we want the rule to only fire if mode is Away, and then becomes Evening. The Predicate Condition is Mode is Away, and the trigger event is Mode becomes Evening. This rule below realizes this particular state transition:
When the Predicate Conditions are found to be false, trigger subscriptions and scheduled jobs are suspended until the Predicate Conditions become true again. Even if these events were to fire, the rule would not run its actions if the Predicate Conditions are not true at the time immediately before the triggering event.
Hub Variables and Local Variables
Whereas the prior version of Rule Machine supported Global Variables, in the new Rule Machine and Rule 5.0 these are replaced by the hub system-native Hub Variables. Hub Variables offer the same functionality that Global Variables did in previous versions. Rule 5.0 also retains the option of Local Variables. The primary reason for Local Variables is that the scope of variable names is local to the specific rule in which they are defined. Should there be a Hub Variable of the same name as a Local Variable, the Local Variable prevails within the rule that defines it. Otherwise, the functionality of Hub Variables and Local Variables is almost identical to previous versions (see below for changes). Performance of each type of variable should be comparable, without large overheads as was sometimes the case with Global Variables.
Variable usage in actions
Where variables can be used in actions, there are explicit options to do so. The previous use of %variable-name% in an input setting remains only for use in strings inputs for actions. Primarily this would be used in Send Message type actions, or setting a variable where the source input is a string. In all other cases, the use of %something% in value inputs has been eliminated in favor of explicit selection of variables.
Variables as triggers
In previous versions of Rule, a Global Variable could be used as a trigger. This is no longer supported as such. However, any variable connector can be used as a trigger to accomplish the same result. Connectors can be used in other apps, including Dashboards, to represent a variable and read or set its value.
Wait for Conditions for Duration
A new option for Wait for Conditions is to select a duration of time. Wait for Conditions has an option to select a timeout period. If the Conditions donāt become true prior to the timeout expiring, the Wait is over upon the timeout expiration. The duration option is different: The duration option specifies an amount of time that the Conditions must remain continously true for the Wait to conclude.
Wait for Conditions with duration is useful for many automations that require the passage of some time in a certain state. For example, suppose we want to send a notification if a door has been left open for more than 5 minutes. This rule could be triggered by the door opening, and than have a Wait for Conditions that the door is open for a duration of 5 minutes, Following the Wait, weād have the notification action. If the door is closed before 5 minutes are up, the Wait will not conclude. If the door opens again, as with all Waits the pending Wait is canceled, and a new one begins. Only if the door is opened and remains open for 5 minutes will the Wait conclude, and the notification be sent.
Wait for Conditions allows a fulll logical expression. It is possible that during the wait period events may occur that affect the Conditions, but do not alter their truthfulness. In these cases the waiting continues, the clock still running, so to speak. But, on the other hand, if an event occurs that renders the Conditions false, the clock is stopped, and the waiting for the conditions to become true ensues. Should the Conditions become true again, the clock will start over, waiting for the full duration to run before the Wait concludes.
In the case where the ruleās trigger event is closely related to the Conditions, as for example in the case above about the door remaining open, please note that two subscriptions will fire, one for the trigger, and one for the pending wait. The trigger will win out, canceling the pending wait, but if logging is on, both outcomes of the event will show in the logs. N.B. It is important never to use a changed trigger with a Wait for Conditions on a related event. If this is done, the rule will retrigger on every event related to the Conditions, and the Wait will never conclude since the Wait is cancelled by the trigger.
Removal of embedded Button Controller functionality from Rule
The previous trigger type of āButton deviceā has been removed from Rule 5.0. This trigger selection opened a page allowing basically the same functionality as Button Controller within a rule. This embedded form of Button Controller allowed for the full advanced action functionality of Rule-4.1, far exceeding the functionality of Button Controller 3.1. In its place there is a new version of Button Controller that has this functionality (see below).
Device Event Description Text
The description text sent with most device events can be retrieved in a rule using %text%. This description text could be put in a String variable, and then inspected for a specific value.
House Keeping and Shared Conditions
One issue that came up frequently for Rule-4.1 and prior versions was that often after editing a rule a device that at one time was used by that rule, but was no longer, would show as still In Use By that rule. Rule 5.0 does a better job at this sort of housekeeping.
However, there is one issue that arises from this housekeeping to be aware of: If a condition is used in more than one action in a rule, or between the Predicate Conditions and a Conditional action (a shared condition), and you delete one of these actions, the condition will be deleted along with it. This will break other references to the shared condition, as it no longer exists. So use shared conditions carefully, and only if you're sure you don't plan to delete the actions they are used in.
Button Controller 5.0 and Button Rule 5.0
A new version of Button Controller is now released in 2.2.8. This version replaces both the older Button Controller 3.1, and the previous embedded version of Button Controller functionality in Rule-4.1 as the āButton deviceā trigger. Each button's actions for Button Controller 5.0 is its own rule, called Button Rule 5.0.
Button Rule 5.0 shares the same code base as Rule 5.0, and offers all of the same functionality for actions with one notable exception: Button Rule 5.0 does not offer Local Variables. It does allow use of Hub Variables.
Each specific buttonās actions, an instance of Button Rule 5.0, is a āgrandchildā app of Button Controllers, and a child app of the Button Controller 5.0 for that button device. This makes each buttonās actions more efficient as a stand-alone app.
Button Controllers does not yet support export/import or cloning of Button Controller 5.0 / Button Rule 5.0 apps. We hope to support this feature in a future release. In 2.2.8 we have introduced a new structure: grandchildren apps (Button Rule 5.0 is the first and only such), and we need to make some further platform improvements to support export/import/clone for them.
Prior Versions
As is the norm for new app releases, the prior releases of Rule Machine Legacy, Rule-4.1, and Button Controller-3.1 will continue to work without modification. There is no need to replace existing automations. If you have Rule Machine Legacy installed, you will be able to continue to create Rule-4.1 automations until Release 2.2.9. Even after its 'retirement', existing Rule-4.1 instances will continue to work, and it will be possible to edit/export/import and clone them. We encourage you to check out the new Rule Machine, Rule 5.0, and Button Controller 5.0, as these releases represent significant improvements over prior versions.
Do not attempt to import Rule-4.1 rules into Rule Machine, only into Rule Machine Legacy. This is not supported and will throw an error. Rule 5.0 has no backwards compatibility to Rule-4.1.
