[Reactor] Bug when sending MQTT boolean payloads

[tamorgen]

Good day all,
I have an notification set up for my washing machine to let me know when it's complete. I have a templete sensor set up in HAAS to let me know if it's Washing, in Standby, or off, based upon the power consumption (Shelly 1PM on outlets)

  - name: "Washing Machine"
    state: >
      {% if states("sensor.washer_switch_0_power")|float == 0  %}
        Off
      {% elif states("sensor.washer_switch_0_power")|float <= 2.9 %}
        Standby
      {% else %}
        Washing
      {% endif %}
    icon: >
      {% if states("sensor.washer_switch_0_power") == "off"  %}
      mdi:washing-machine-alert
      {% elif states("sensor.washer_switch_0_power")|float <= 2.9  %}
      mdi:washing-machine-off
      {% else %}
      mdi:washing-machine
      {% endif %}
        minutes: 2

The MSR code is relatively simple. I have a built in false positive attribute for if MSR gets rebooted, because I would suddenly get tons of notifications when I upgraded MSR.

What I'm trying to introduce, is a way to verify that I just didn't bump the knob on the washing machine when transferring loads from the washer to the dryer, which turns on the display and brings the power above the Standby threshold.

The power goes up to 3.7W for about 4 minutes if the selector knob is bumped/turned.

What would the best way to do this be? I have most of my MSR code set up for a couple of years now, and my coding logic is struggling a bit.

I think I need a power threshold to be substained for a minimum time period (say 2 or 3 minutes, above 10W), before the other triggers can act. What would the best way to do that be?

Running: latest-25082-3c348de6
Fedora 41 Server
HAAS:
Core
2025.3.4
Supervisor
2025.03.4
Operating System
15.1
Frontend
20250306.0

[tamorgen]

Any thoughts? I know I can set up a a condition to monitor the power sensor value, and make sure it is above 3.5 for 5 minutes, but the condition I need is for the power value to go to the standby value of under 2.9 after that condition is met. That's what I'm unclear how to do.

[therealdb]

I haven't moved this particular piece into MSR yet, but my logic is:

• watch for idle: if watts<5 for at least 15 secs, that's done. If previous status is running, mark as completed. Otherwise, stays idle.
• watch for watts. if idle and watts > 50 for at least 15 secs, that's running.

I think the best way to achieve this is by having two different rules. I'll probably design it with a virtual device with a string_sensor, containing the current state. I've never moved this part of my system to MSR, because I want to write a controller doing exactly this, but the logic is not complex.

[toggledbits]

@tamorgen said in Need help reducing false positive notifications:

Any thoughts? I know I can set up a a condition to monitor the power sensor value, and make sure it is above 3.5 for 5 minutes, but the condition I need is for the power value to go to the standby value of under 2.9 after that condition is met. That's what I'm unclear how to do.

Look at the condition options (for any condition). You'll see the ability to sequence conditions there -- set a condition so it can only go true after another condition has gone true.

Your problem seems simpler to me, though. Maybe I just don't get the full scope from what you wrote, but what you asked for can be done without sequencing.

If you just want to know if the machine is running, make a rule for power >5W (your 3.7W plus some headroom) sustained for at least 5 minutes (see condition options again). If you want to know if the machine is not running, make a rule for (guessing) power < 15W sustained for 5 minutes. I think you'll find these pretty effectively ignore the transitions between cycles and bumps at the controls or door left open (light on) if you get the power values right for your machine's behavior.

Now you have two rules, one to tell you that it appears to be idle, and the other that it appears to be running. We could use one rule, but by using two rules with a gap between the power values, we create additional hysteresis to prevent those false positives. For you rules that need to react to the machine going idle, use a Rule State condition to check your idle rule; for rules that need to react to the machine running, check the running rule.

[tamorgen]

@toggledbits ,
Patrick,
This is what I had come up with. I tried using latch:

The problem I ran into, is the latch condition went true after 5 minutes, and it stayed true all the way until the first condition changed, then it went false. so the "and" of the 3 conditions never becomes true. It's like I need the latch condition to stay true for 5 seconds longer.

I hadn't considered two rules, but I'll see if I can figure out what you mean. The sensor switch I have made within HAAS already is sort of a rule as you described, as it looks for the power to be above 2.9W, which is the minimum value I recorded over a wash cycle, as it pauses within the cycle. The 3.7W value comes from when the control panel is turned on by turning or pumping the cycle selector switch, so what happens is that it does set the sensor to Washing when the control panel is turned on, if you follow.

[toggledbits]

@tamorgen Frankly, it looks like you've made an overly simplistic sensor that you're trying to improve on in the rule... you're taking a low-res image of the device and trying to make it back into something higher-res.

I'd just look at the power directly in Reactor:

[tamorgen]

@toggledbits,

I tried to go about the way you mentioned, but I don't think it was quite suited for my purpose. The purpose of the rule is to send a notification through Home Assistant to my phone, and I didn't want a delay that I believe your method would have introduced. What I came up with was creating a global variable and a helper rule, that sets the global variable to true when the 300 seconds is exceeded of power being above 3.7.

Then there is a Variable Value check in the Triggers of the Notification rule:

The Reaction resets the Global rule back to false, after the cycle is completed.

It may not be the most elegant method, but it reduces the false positives on my phone when the cycle selector is bumped. For the same reason, I have the reactor uptime checked, because I would get tons of notifications on my phone when I did an update to MSR, or when my server was rebooted. I know I could completely encapsulate the logic within MSR, but the overly simplistic sensor in HAAS serves it's own purpose in HAAS for my dashboard, and HAAS can't read rule states from MSR, so for my purpose, I already have the simple sensor in place, so why reinvent the wheel?