New App Features in 2.2.8

[woodsy]

Wow. This is an incredible jump.

[CAL.hub]

@bravenel

Not really, only superficially. The BIG difference of Predicate Conditions is that they are set before the rule is triggered. With Rule-3.0, a Condition was tested when the rule was triggered by anything happening that would affect the rule, and then actions for true and false followed. For a Predicate Condition, nothing happens because of it changing from true to false or false to true -- that does not cause actions to run.

I'm certainly in no position to quibble about how it works under the hood, but from a user perspective, it seems like what was old is new again.

From 2016;

Not that I'm complaining. I missed conditions. (Will we be revisiting Rule Truth again? )

Thanks @bravenel

[bravenel]

@CAL.hub

Will we be revisiting Rule Truth again?

Ha, sure. But now it's Predicate truth, right? And, it gets displayed when its false.

[waynespringer79]

@CAL.hub

I missed conditions

FWIW, I took the advice when RM 3.0 was retiring and created "Master" triggers/rules/triggered rules/etc and have ever since created a RM 3.0 clone for any
new rule I created as I personally liked it better than the new 4.0 and 4.1. I'm glad to see these (in a slight way) return and happy to play around with the new 5.0.

[bill.d]

@bravenel

The easiest way to wrap your head around this is to think about restrictions: "Only run this rule if its Wednesday". A restriction in 3.0 wouldn't in and of itself cause anything to happen, it just was a pre-condition that had to be true for the rule to run at all. Predicate Condition = Pre-Condition. When it became Wednesday, the rule wouldn't say "Restricted" anymore, and it would run whenever it was supposed to run -- but it didn't run when the day changed from Tuesday to Wednesday. You will see something similar with Predicate Conditions: if they are false, the rule will show "Predicate Condition False" -- meaning, it isn't going to run.

Almost an implementation of a state machine @jwetzel1492

[BETA] Simple State Machines

Simple State Machines for Hubitat *** BETA *** Create state machines in Hubitat! *** This is a BETA *** I have not yet written up detailed instructions on install. This is a BETA, and should only be used by those already familiar with custom apps and drivers in Hubitat. There are two custom apps and two drivers to install. The best way to learn how to use this is to watch a Youtube video I made of it. The first 5 minutes are explaining the concepts. Skip to 5:03 if you just want to see…

[bill.d]

@bravenel

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.

Nice feature. Any way to make the list of grandchildren collapsable? Imagine several 6 button seeTouch keypads or even a 100 button Main Repeater. That's manageable in the old button controller, but now the whole list shows up on the main Apps page.

[bravenel]

@bill.d

Any way to make the list of grandchildren collapsable?

It is collapsable.

Before

After

[bill.d]

@bravenel

It is collapsable.

Thanks, I missed it.

[armand]

Predicates on button controller button events would be nice. So, when button is pressed, perform actions 1-3 based on the state of a device.

This would be good for enabling a fan speed controller from a button controller. Press up, increment the speed, press down, decrement the speed, and be able to avoid all the conditionals to make it happen. Anxious to start playing with the new apps.

Thanks!

[damianm]

Love the ability to add comments to rules.

[damianm]

@bravenel I have found an issue with variable comparison in Rule Machine 5.
Selecting the second variable from the dropdown also changes the first variable to the same.

Fixed in 2.2.8.136

[thebearmay]

@bravenel noticed that hub variable connectors have a new command - parse. It doesn’t take a parameter so I’m assuming that it is doing something with an internal value which makes me curious as to what. Any chance of satisfying my curiosity?

[damianm]

@bravenel There seems to be an issue with variable connectors.
Running the following rule I would expect the switch to end up in an off state, it does not.

Fixed in 2.2.8.136

BTW, is there a better place to report issues?

Update: parse does fix the issue, is this how it's meant to be used?
@thebearmay parse seems to sync the variable and connector.

[thebearmay]

@damianm

parse seems to sync the variable and connector

Thanks!

[bravenel]

@damianm

Selecting the second variable from the dropdown also changes the first variable to the same.

Obviously a bug -- will look into it. Thanks.

[bravenel]

@thebearmay

noticed that hub variable connectors have a new command - parse

This is the means by which the hub sets the connector when the variable changes.

[bravenel]

@damianm

Running the following rule I would expect the switch to end up in an off state, it does not.

I will look into it. Thanks.

parse() on a connector is not intended to be used by rules...

[terminal3]

@damianm

I have found an issue with variable comparison in Rule Machine 5.
Selecting the second variable from the dropdown also changes the first variable to the same.

I looked through this thread and didn't see that before. I just posted a thread describing the same thing. I see this as well

[Abhijeet_Ghosh]

@bravenel to clarify, after 2.2.9 update, my rule 4.0s and 4.1s will continue to work, but I will need to make all new rules in rule 5.0. Also, after 2.2.9, will I be able to edit existing rule 4.0s and 4.1s without converting them to rule 5.0s?