Errors after updating to MQTTController build 25139

[tunnus]

just to be clear, you have "changes from (any) to (any)" in your rule?

[ibrewster]

That is correct, yes - and it works when going from 0-->any. After that, however, the condition evaluates to true, the rule is set, and so further changes do not trigger it again, as per the documentation (once true it remains true and the rule is not run again until it evaluates to false, i.e. 0)

[ibrewster]

Ahhhh, I think I finally got it! If I add a second condition of device.dimming.level <> switch.dimming.level, then the rule is set whenever the switch changes, and quickly reset once the device is set to the same level, allowing the next change in switch level to properly trigger the rule again.

Only took me two days and a forum post to figure that one out...

[toggledbits]

Please show your work (post screen shots of your rules).

What you are describing doesn't make sense to me, and your fix seems unnecessary. I'd like to understand why, but I need to see your actual rules (please see the posting guidelines for this category as well).

[ibrewster]

@toggledbits said in Run rule on dimmer change?:

Please show your work (post screen shots of your rules).

As I mentioned, I tried to do so, but the forum gives me errors. Specifically, it will show the image as uploading, get to 100%, pause, drop back to 60% (or so), give me a message stating "Looks like your connection to SmartHome Community was lost, please wait while we try to reconnect", the progress goes up to 100% again, and then I get an error stating "Something went wrong while parsing server response", and the image is not uploaded, leaving me with something like this:

![Screenshot 2023-12-01 at 8.55.28 AM.png]([[error:parse-error]])

So as far as I can tell, no screen shot posting is possible.

Perhaps walking through the steps of what happens will help?
The rule is set up with a single Trigger:

Entity Attribue -- Inovelli 2-in-1 (the switch) -- dimming.level -- changes -- from <blank> to <blank>

A local expression is set up with the following code that gets the current dimming.level value:

SwitchLevel = getEntity( "ezlo>device_65655fb712a3b714bdbcb935" ).attributes.dimming.level

And a Set Reaction to set the LR Fan Light to the same level:

Entity Action -- LR Fan Light -- dimming.set -- ${{SwitchLevel}}

1. We start with the switch at 0 (off), and the rule is reset as expected
2. We then set the switch to some other value (say, 50% or .5)
   2a. The rule is now set, and the Set Reaction runs as expected.
   2b. The rule remains set at this point - only going back to a dimming level of 0 will reset it.
3. We then set the switch to another value, say 75% or .75
   3a. Since the rule is already in a set state, the Set Reaction does not run again, meaning the LR Fan light does not change dimming level

Adding in the rule of the LR Fan Light level <> SwitchLevel allows the rule to drop back to a reset state after setting the LR Fan Light Level, thereby allowing it to run again the next time the switch level changes.

[tunnus]

If you only have a single trigger with changes -operator, the rule is immediately reset after the change (i.e. when change stops), so I don't quite get how your rule could stay set?

[ibrewster]

@tunnus said in Run rule on dimmer change?:

If you only have a single trigger with changes -operator, the rule is immediately reset after the change

That is not the behavior I am seeing. Sorry!

[tunnus]

...and you don't have "delay reset" -condition option in use?

[ibrewster]

Reactor latest-23302-b7def56a; docker on Ubuntu 20.04; With Vera Plus and Ezlo Plus controllers

Nope, the delay reset box is empty (nor have I tried to make any modifications in that section of the rule).

Although now that you mention it, it does seem odd, since while the rule remains set, if I toggle the rule open in the Rule Set list, the condition is evaluating to false, which (I would think) should reset the rule...right?

I have updated reactor recently, but let me try again in case 23302-b7def56a isn't the latest, and has a bug here...

EDIT: Nope, doesn't appear there are any updates available

[ibrewster]

Ok, now I'm really confused. As part of my attempt to update reactor, the docker container obviously got restarted - and now the rule is working as expected, with only the change condition. I have no idea why the change in behavior, but at least it is now working as you guys expected.

[toggledbits]

Sounds to me like your UI was out of sync. A hard refresh should be done any time things don't look like expected.