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.

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.

@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!

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.

@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:

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

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

@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"

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.

@cw_kid in your post here the configuration you posted is incorrect -- the indenting is invalid, and that will prevent anything from working for that entity.

Honestly, I can't at this stage really get a read on where you are. Between you jumping in with random AI changes and others commenting, your config is a moving target and I can't follow it. If you want my help, I will send you a link so you can upload your config and I can look at it and potentially fix it. Otherwise, I'll let you continue to learn on your own and seek help from others.

Sorry, my bad, change the include section to look like this (I'll fix the example above as well):

        include: 
          - tasmota_generic_relay
          - tasmota_sensor_temperature_humidity

Also, you can use yamllint.com to sanity-check your entire config file.

@cw-kid By the numbers:

1. tasmota_discovery is not a thing in Reactor, so that won't work.
2. The AI-recommended use of 0.0.0.0 for the host IP address of your MQTT broker (mosquitto) is correct and recommended.
3. implementation: MQTTController is the correct usage (class is deprecated).
4. You should use the 127.0.0.1 (aka loopback) address for the MQTTController's source configuration in reactor.yaml whenever the MQTT broker (i.e. mosquitto) is running on the same host as Reactor; otherwise, use the LAN interface address (192.168.0.4 in your case).
5. system: and extension_path are also not a thing in Reactor configuration (another AI fantasy fact).
6. All ESP32s and other MQTT clients should use the LAN address for the MQTT host (192.168.0.4 as shown in your image; that's correct).

You need to use one of the available templates for Tasmota described in the MQTTController documentation or create a configuration of your own. The latter may be necessary for your configuration, but we need more info. Please show more of the Tasmota device configuration (screen shots), so we can help you with that.

Until then, just choose the simple included switch/relay configuration template to get things working (i.e. so you can see that Reactor sees the device and may be able to control it).

  # In the controllers section of reactor.yaml:
  - id: mqtt
    enabled: true
    implementation: MQTTController
    name: Mosquitto
    config:
      source: mqtt://127.0.0.1:1883/
      log_topics: ['tele','stat','tasmota']  # only for testing, disable when not in use (makes big log file)
      entities:
        tasmota_fan_controller:
          name: "Tasmota Fan Controller"
          topic: fan_controller  # matches topic configured in Tasmota
          unit: 0  # relay number on the device
          include:
            - tasmota_generic_relay
            - tasmota_sensor_temperature_humidity

This may be all you need. Try it and see what happens. Don't forget to look at the logs when things aren't working as expected. And look at the mqtt-topics.log file to see what data you are getting (post a nice snippet of it here, along with everything else requested, if the device isn't working in Reactor).

Here's another one that is very likely to not have significant downtime: https://checkip.amazonaws.com/

If you still get errors with this one, I suspect your local network or something off with the configuration of your host.

Best add some error detection, then.

In your x_vera_device.set_variable action, where you have the substitution ${{ myIP }}, change it to ${{ trim(myIP) }}

Ref: String Functions

The endpoint has 15 seconds to answer by default (i.e. default timeout)... that's a long time for such a simple request. https://icanhazip.com is a popular choice for this purpose, apparently, and may be more reliable. Its response is plain text rather than JSON, but based on your use, that's more direct.

In any case, network errors are a fact of life, and requests will fail. If that's important to your process, error handling should be added (e.g. detect failed requests and skip changing the Vera variables).

@cw-kid The capture variable having a null value is a pretty indication that there was an error. You have the "Suppress alerts on HTTP errors" box checked, so you're silencing your first option for notification of an error on the request. But then, there could be another location...

Article here that may be of interest to some:

Jean-Luc Aufranc (CNXSoft)  /  Feb 5  /  Hardware

Raspberry Pi 4 dual RAM variant introduced to mitigate RAM price increases and supply challenges - CNX Software

Desperate times call for desperate measures. Raspberry Pi has decided to introduce a dual RAM variant of the Raspberry Pi 4 to allow DRAM supply chain

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

Refer to the documentation for VirtualEntityController

The name is incorrect at ZWave-JS (on the node itself) if that's the case, so to keep your sanity later, make sure you go all the way back to the source and work your way forward from there.

Reactor only changes the entity name when the entity is first created. From there on, it sticks, no matter what the underlying hub does. To change the name, hit the "Rename" button on the entity in the detail pane (see your latest screen shots).

Also future note. When posting log snippets, please don't use grep or other filtering. Find the lines of interest, and post 20-25 of context before and as much context after as is relevant. Not all relevant log messages may contain the string you are searching for.

@tamorgen said in Set reaction triggering wrong z-wave device:

Here are some logs of me turning the entities on and off from HAAS.

You've shown here all stuff from ZWaveController, not HassController...? I don't think that would be helpful here anyway, because it would only show the HA entity IDs, and HA doesn't embed ZWave node numbers in their entity names. You would have to go look at the device in HA to confirm the node numbers. In HA's UI, go to Settings > Integrations > ZWave > Devices. Find the device you think is your Front Porch Lights switch, and click it. In the Device Info area, there's a Z-Wave Info heading with an arrow — click the arrow to expose the node number.

You said you updated ZWaveJSController, but it's still not showing me the expected log data. Can you confirm that in the startup messages for Reactor, ZWaveJSController reports it is version as 25304. If not, your update was not successful.

You can also go back to the ZWave-jS UI and command node 137 on from there, and see which device ZWave-JS switches. If it's the same device that Reactor switches, your Z-Wave nodes or HA devices are incorrectly identified.

What is clear in the Reactor logs so far is that ZWave node 137 is being told to do something, and ZWave node 137 responds back that it received the command its values changed. Nowhere along the way do the logs mention 136. If there was something wrong with what ZWaveJSController was commanding ZWaveJS to do, I would expect it log that it was performing an action on 137, but then gets update reports from 136, and that's not what is happening. I can also see in your Z-Wave data that node 137 is named "Front Porch Lights" at the node itself, which is consistent with the Reactor entity name, so Reactor/ZWaveJSController thinks it is doing the right thing.

I would start looking at the root, which is the ZWaveJS-UI, and make sure that node 137 is really your porch lights and you can command them on and off from there. If that's not the case, change the device name in Z-WaveJS UI, and then make sure the names in both HA and Reactor for nodes 136 and 137 match that data. Right now, it appears they do not.