Condition for trend

[tamorgen]

Is there a way to set a condition for a trending number? I just installed a Zooz ZSE44 Temp/Humidity sensor in one of my bathrooms. I wanted to set a condition based upon how quickly the Humidity sensor reports the humidity level trending down (say after a shower).

If you look at the graph below from the device, you can see the humidity spiking at 5 am, then dropping, then spiking again, then dropping. I'm trying to set up a condition when the level trends up or down quickly.

[tamorgen]

I think I may have figured out a way...

If I use a Latch condition when the Humidity goes above 60, and then another condition when it goes below 45 (dependent on the first condition being true first), that should give me the result I'm looking for; that being the shower isn't being used anymore, and the shower light can be turned off. Am I correct in my understanding of how Latch works, in that that condition will stay true until the Set Reaction triggers?

[toggledbits]

VirtualEntityController can sample another entity's data and do time-series aggregation (moving average, rate of change, etc.).

Refer to the documentation for VirtualEntityController

[tamorgen]

@toggledbits said in Condition for trend:

VirtualEntityController can sample another entity's data and do time-series aggregation (moving average, rate of change, etc.).

Thanks for that. I wasn't familiar with that, and it sounds like what I was initially looking for.

[tamorgen]

So, for some reason, my Latch method isn't working. I see the humidity go above 70, and I see the first condition go true. When I'm done showering, and fan evacuates the excess humidity, it drops back down and goes below 65, and that condition becomes true.

The second condition has the restriction that it must occur after the first condition is met.

I guess the second condition resets the Latched condition, so both conditions aren't true at the same time?

Is there another way to do a first condition, then the second condition that I'm missing?

[toggledbits]

@tamorgen said in Condition for trend:

I guess the second condition resets the Latched condition, so both conditions aren't true at the same time?

Correct. Both conditions cannot be true at the same time.

Your relatively simple logic here doesn't need a latch. Just use two rules, one to turn the fan on at humidity >= 70, and the other to turn it off when humidity <= 65.

If you insist on a latch in one rule, then you need to pair the latching condition with a condition that stays true until it's time to reset it. Really, all you need to do is reverse the operand in your second condition: it should be humidity >= 65 (and this second condition not latching). When humidity rises, the second condition will go true before the first (latching) condition, but won't Set the rule because both must be true. When the humidity gets to 70, the first will go true, so both will then be true, and the Set Reaction then runs to turn the fan on. As humidity comes down below 70, the first condition will become logically false, but remain in true state because it is latched while the second condition also remains true (i.e. humidity hasn't yet reached the low cutoff). When the humidity drops below 65, the second condition will go false, causing the reset of the latch on the first condition. The Reset Reaction then runs (it turns the fan off).

That said, seasonally and with local changes in weather, your indoor humidity varies, and using fixed values like this may not work out very well over the course of a year. I've tried. That's why I added aggregates/trending to VirtualEntityController. You can have VEC create a rate aggregate over 5 minutes. You'd need to "tune" the condition's rate value test, but as a starting point for the conditions, let's say if the rate of change exceeds 2.0 (which is % humidity per minute, the unit VEC will report for rate, equating to about 10% (positive) change in the five minute sampling period), your rule turns the fan on. It may be a little trickier figuring out when to turn the fan off. As a practical matter, I've found that having the fan run on a timed basis for 30 minutes once triggered is a simplifying assumption that works out perfectly in my bathroom, but you could also look at rate (e.g. rate of change is <0.0167 sustained for 15 minutes, for example). I would always add a time component to the run of exhaust fans in any case, because these simple fans aren't built for long runtimes (bathroom exhaust fans have started fires from running too long).

controllers:
- id: virtual
  enabled: true
  implementation: VirtualEntityController
  name: Virtual Entity Controller
  config:
    entities:
      - id: "master_bath_rh_rate"
        name: "Master Bath Humidity Change Rate"
        type: ValueSensor
        capabilities:
          value_sensor:
            attributes:
              value:
                model: time series
                aggregate: rate
                entity: "mqtt>shelly_handt3"
                attribute: "humidity_sensor.value"
                interval: 150
                retention: 300
                precision: 3
        primary_attribute: "value_sensor.value"