Global Moderators group | Smart Home

toggledbits

Yup. That's from an ancient UI bug. If you edit the conditions that have that, it will fix them. I'll add some code to the rule startup check to root them out and fix them as well.

toggledbits

The old rule you are copying is probably where the problem is starting from. Before making any other changes, open the JSON file (in storage/rules) for that (old) rule and post the lines having op: "change" in them here.

toggledbits

@mgvra said in Dynamic MQTT topics and parameters:

Is there a more efficient way to handle dynamic topics? I tried passing the panel and led IDs as parameters from the UI, but I soon realized that this syntax does not work:
topic: "annunciator/panel/%parameters.panelId%/led/%parameters.ledId%/set"

This makes a lot of sense, and I don't know why it hasn't come up before. I need to run out for an errand with mi esposa, but when I get back, I'll work on this and post an updated MQTTController for you to try.

It's funny that you mention the DSKY project, because I kind of set it aside years ago, but recently got motivated to start building again, so I've spent a little time refamiliarizing myself with where I left it...

Your annunciator panel... chef's kiss!

therealdb

Very cool. And I thought my wall panel was cool

if I were you, I'll just build a custom capability and have just one device doing the work per panel. 45 properties/actions per device are totally acceptable imho.

Unfortunately, AFAIK, at the moment the only dynamic part accepted in topics is substitutions from config. I think @toggledbits will need to specifically support this new option in order to work.

toggledbits

Deadband... a range of the measurement where nothing happens; but there is usually action at the extremes of the deadband (the low and high values).

With the configuration I gave you, it's the range of humidity between 50% and 65%... if the humidity goes only from 40% to 55%, that 55% is in the "deadband" and the rule won't turn the light off if the humidity then falls below 50% (the low end of the deadband) because the humidity never exceeded the high end (65%) of the deadband. But the way the rule is set up, if the humidity does reach 65%, then the rule becomes "sensitive" and watches for the humidity to drop below 50%, and then it will turn the light off.

Deadband is also commonly used to refer to thermostats, for example, where it's commonly the small differential enforced between a heating setpoint and a cooling setpoint so that the thermostat won't try to do both at the same time, or bang back and forth between the two rapidly when the temperature is in a small range between those setpoints.

toggledbits

@tamorgen said in Condition for trend:

generally when I step into the bathroom, I manually turn on the shower light, turn on the shower, finish, and inevitably the shower light get's left on, whether it's me or my wife.

Important detail.

@tamorgen said in Condition for trend:

So, from my understanding, you are saying I just need to change the value fo the first condition to >= 65, and the second condition can stay at <= 65?

No. Both conditions >=, and you should have a deadband between them. And since you turn the light on manually, the Set Reaction in that rule can do nothing, and the Reset Reaction turns the light off.

Your image is now mixing concepts and adding condition options not discussed, not needed. Based on your graph and descriptions, I would go with exactly this (do not add any other features) and see how it goes:

Condition #1: humidity >= 65, latching output
Condition #2: humidity >= 50, default (follow) output
Set Reaction: empty
Reset Reaction: turn light off.

Note that both conditions are >=. This is the way.

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"

toggledbits

Tasmota has this inconsistency where if there's only one relay configured, it does not include the relay number; if more than one, then it adds it. There's no way for the template to know how many relays are configured, so you found the correct fix.

therealdb

@cw-kid I have them with lux, barometric, distance, and temp/humidity sensors, while also using a couple as Bluetooth bridges. in this regard, your fantasy is the real limit.

I've recently moved everything I could to ZWave, because it is better in terms of stability, but ATM there's no equivalent for fancy sensors, even if ZigBee has a denter offer.

therealdb

@cw-kid post some screenshots from mqtt explorer. It’s easier to follow, if you want my advice.

Global Moderators

Posts

Member List