[Reactor] Bug when sending MQTT boolean payloads

[tunnus]

Got a warning that "Rule is being throttled because its update rate exceeds 60 updates per minute. Check for logic errors that may be causing an evaluation loop, or devices that are "flapping".

Device in question here is Aeotec Smart Switch 6 connected to Vera Plus, and its configuration is below:

Shouldn't be an evaluation loop as the rule is very simple (two AND'ed conditions where the first checks whether alarm state is "disarmed" and the second if smart switch power switch state is false).

Noticed though at the time of warning that wattage measured/reported was changing quite rapidly, so even though wattage was not used in the rule, could that be the reason for throttling? If so, is there anything else that could be done other than raising minimum change values in device configuration? Would like to retain sensitivity for other purposes.

[toggledbits]

We'd need to see the rule (and any rules/reactions that affect the device), not just the device, to make a determination about why it's flapping.

[tunnus]

@toggledbits here's the rule:

[toggledbits]

Pretty straightforward. I'm guessing it's the percentage change that's the issue. With the threshold set at 10%, a change of just 1W when the total wattage is 10W or less will send an update, for example. Some deeper examination of the range in which the excess reports occur may lead you to better values for the configuration. A device that is generating that much traffic (more than one transaction per second) is probably going to lead to other problems in the mesh on Vera, since neither getting busy nor narrow timing are strong points of the Vera ZWave stack. You may be able to address momentary drops in power demand (such as when the motors pause) by using "delay reset" or "sustained for" options to dampen spikes and drops in the device's behavior. This would also then reduce the demand on the device for high accuracy and frequent updates, and let you configure these values to let it be less chatty. I mean, if you're using this to signal you when the wash is done, do you need to know to the second?

If you really don't want to reconfigure the device, you can set the update rate higher in the engine section of reactor.yaml by setting update_rate_limit to some value higher than 60 (the default). That's a system-wide setting, so it applies to everything.

[tunnus]

@toggledbits thanks for the analysis & advice! I'm actually using this rule for a simple task that it enables power back to washing machine when in disarmed state. There's a similar rule to cut the power when in "armed away" state.

Not relating to MSR, but cannot seem to trigger configuration update for this smart switch:

Did both "save changes" and "apply changes", but both only trigger luup reload and configuration stays the same...

[toggledbits]

Hard refresh your browser after reloading Luup. It's a UI bug in UI7.

[tunnus]

@toggledbits did that, and also "configure node right now", nothing seems to change the actual configuration

[tunnus]

@toggledbits Coming back to this, eventually I was able to change the configuration (below), but still, whenever the washing machine is running, I keep getting the same alerts.

These two rules that are mentioned in the alerts do not even trigger at the time of alerts, because not all conditions are true (see previous posts, where washing machine power switch state should be false for the rule to be triggered).