Gradually turn on lights.

[toggledbits]

LOL. To explain... as a trigger, it's an event... when the value changes, the condition is momentarily true, then quickly becomes false. If you imagine an attribute changing value from 0 to 1, it's true for a moment, but then not true (false) a moment later because now 1 == 1. If you later encountered a constraint with changes in it, it's unlikely to ever be true, because 1 still == 1... it hasn't changed since the trigger fired. And because of that, it makes no sense to have it there, so... it isn't.

[gwp1]

@toggledbits To explain... I have a curtain at the giant patio sliding door.

After sunset, if Mode == Away it closes to 28% (open enough not to mess with the cat's door out into the screened room. (Do NOT block the cat's door into the screened room...)

There's also an option if the cat door does happen to be closed that the above results in the curtain closing all the way... don't tell the cat.

After sunset, if Mode == Evening it closes to 60%, allowing me to open said door for some fresh air.

I was looking to add an option for "if Mode Changes from Away to Evening (ie, I just returned home) it would set the curtain back to 60%.

No major thing - I'll think on it a spell and conjur a workaround ruleset.

[therealdb]

@gwp1 said in [Resolved] No "Changes" in Reaction Group:

I was looking to add an option for "if Mode Changes from Away to Evening (ie, I just returned home) it would set the curtain back to 60%.

Try metadata. I have a global variable to get the previous house mode (ad another one to get the current one):

getEntity( "vera>housemode" ).attribute_meta.x_vera_housemode.mode.previous_value

In your case, it should be

getEntity( "hubitat>sys_mode" ).attribute_meta.string_sensor.previous_value

Just create another variable with the current mode and compare them. It's OK to add it to the current rule if you prefer.
It's pretty easy to create groups with forking logic with this feature

[gwp1]

@therealdb It's very early and sans coffee when I'm seeing this but it makes perfect sense. I already track current_mode as a variable (for no other reason than I figured I'd want it for some reason like this.)

Where I'm falling down (and, again, it's early...) is how you're using

getEntity( "hubitat>sys_mode" ).attribute_meta.string_sensor.previous_value

to populate my new Global Expression previous_mode.

[therealdb]

@gwp1 previous value was added a couple of weeks ago. Look at docs about Metadata and it should be easy to understand.

[gwp1]

@therealdb Told you it was too early... totally blanked on how to create the expression lol. Thanks!

[gwp1]

@therealdb It's happy up to this point:

Oddly, extending to the full path returns null even though it's clear there's data "Night".

UPDATE: Gahhhhh, missed it. Needed to add .value. to the path. All good now!

Here is the end result which is exactly what I'd hoped to achieve with the changes operator.

Many thanks @therealdb!

[therealdb]

@gwp1 yeah, previous value is the best thing since sliced bread. Thanks @toggledbits !

[therealdb]

and, if you need to know when the value was modified, try .previous_last_modified instead of .previous_value

[toggledbits]

To be clear: the time the value was last modified is last_modified... the previous_last_modified is the timestamp of the modification before that.

Example: an attribute changes to 2 at 14:45:00, so ....attributes.value is 2 and ....attribute_meta.value.last_modified is 14:45:00. A minute later, it changes to 0, so then ....attributes.value is 0, ....attribute_meta.value.last_modified is 14:46:00, ....attribute_meta.value.previous_value is 2 and ....attribute_meta.value.previous_last_modified is 14:45:00.