Can you add the following to your HassController config, restart, and post the contents of the dump file created (named <controllerid>-fan_kitchen_seashell_hood_ventilation_fan.json). Thank you!

    config:
      # other stuff
      dump_entity:
        "fan_kitchen_seashell_hood_ventilation_fan": true

I'm not sure how I can help here. Your assessment seems correct. Like the other recent post, the displayed states here show the triggers going true substantially before the constraints did, so the constraints prevented the rule from SETting.

That seems like a logic issue. You need different approach, and I can't really gauge how you want this to work, and what the system limitations and risks are. That's knowledge only you can possess, at least not without a much lengthier explanation/q&a about what all this is meant to do, what you want it to do, etc.

I can, however, throw out some things based on assumptions (and because they are assumptions, they may be completely useless to your problem and not make any sense)... assuming two key goals: you don't want to start A/C unless solar power is high, and once A/C is running you want to keep it that way, at least for a while. You could move the solar power condition to triggers and latch it. To make sure A/C is stopped if solar drops too low, add a trigger condition requiring solar > whatever minimum, so you basically have solar >= ACthreshold (latched) AND solar > ACminimum in the triggers. If solar momentarily drops below threshold, the latch keeps the A/C running, but when it drops below minimum, that condition going false resets the latch (and presumably allows the A/C to turn off). Additionally, you could add a delay reset on the A/C, to enforce a minimum runtime. This is often recommended to avoid cycling compressors too often, but also helps make sure that the money you spent on the startup inrush gets some useful life. Be careful here, though, because you now introduce the possibility that the A/C could run when the solar is below minimum (held on by the time delay).

I will also repeat advice I've given previously... sometimes it is easier and, in fact, necessary to separate "turn on" and "turn off" logic into separate rules. I know there's a big temptation to use the SET and RESET reactions of a single rule, but it can make the triggers and constraints excessively complex to support. For example, I have a dehumidifier in my garage (where I live, my tools would rust every summer otherwise). Three garage doors, temperature, humidity, standby generator operation, and other large loads in the space are all considerations for both stop and start, but with varying logic. One aspect perhaps similar to your rule here, is that the dehumidifier isn't stopped when the garage door opens for a short period (e.g. a car pulls in or out of the garage), because of the wear on the compressor starting it, and brief periods of door open don't significantly drag on dehumidification, but long periods definitely do. I have one rule with just the start conditions, and those conditions include (a) the dehumidifier hasn't been running for at least ten minutes (prevent short cycling; it doesn't have smart controls), (b) the doors are all closed, (c) the humidity has been above threshold for 30 minutes (via a "sustained for" option on that condition). If those are met, the unit is started (via the SET reaction). In the rule with stop conditions that turns the unit off, the triggers are (a) dehumidifier has been on for at least five minutes, and (b) the start rule isn't SET (i.e. the conditions that call for it to be on are no longer met), also sustained for at least five minutes. SET reactions only; no RESET reactions. While the basic logic isn't complicated, it would be very difficult to get the independent timing of the two (on and off) processes to work in a single rule. By the way, I have a separate rule to detect if doors are open; I don't look at each individual entity in every rule, because...

More general advice to the community: many (most?) posts lately have had huge monolithic rules posted. I don't recommend it. I don't do this to myself, and I wrote the darned thing. I make liberal use of the Rule State condition and separate out chunks of logic into small, easy to define, easy to debug, easy to test condition-only (no reaction) rules that are tested by other (action-oriented) rules. Modular design. Using the overrides on the UI makes it easier to test, because you can SET and RESET your input rules at will and in any order. When devices fail or change, there are then a lot fewer rules to update. I always start with this approach on anything new. If I later find it's overkill for the task, I can always import the input (condition-only) rules into the action rule and get rid of them.

Again, just some thoughts/rambling without deeper knowledge of the task...

In the first image, the triggers show true as of 9:42:09. The constraints show true 10 seconds later. That's a not pass. The constraints have to be true at the instant the triggers are also true (or before), or the rule does not SET. If the constraints become true later, that doesn't matter, the rule does not SET.

Your third image shows the same. Triggers true at 10:31:53, but constraints didn't go true until 10:32:12 (19 seconds later).

From the docs:

This is now available in build 26242. The config has changed slightly, so review the final documentation for correct usage and examples.

Reactor build 26242

• DynamicGroupController: Custom attributes (calculated) see docs;
• Expressions: new map() and reduce() array functions see docs;
• HassController: Bless HA to 2026.8.3

A couple of things here...

• Editing the rule will cause re-evaluation, which is likely why you have repeated RESETs in the history with no SETs between.
• As hard as I try, and I keep looking, finding, and fixing, the UI can get out of sync with the running engine/service, so always hard-refresh when the UI isn't making sense.
• If a Rule has been edited, especially multiple times, and it's not performing as expected, reset the Rule. There's button for that: Even restarting Reactor doesn't do what this button does.
• Beyond that, it would also be handy to see the top part of the screen shot that has been cut off (the Triggers group heading and stuff above it).

No backup? Restore from backup (recommended) is the best way, of course.

Beyond that, recreating it should not be difficult, but there have been key changes since that original post. Some detail beyond "did not work" is necessary here. Show your work and tell us about your environment.

Here are the docs for what I have built thus far. Comments and suggestions on functionality appreciated!

Custom Attributes

In addition to setting the primary attribute for a dynamic group, users may add custom attributes to the group. The values of these custom attributes are typically derived from attribute values of the group's members. For example, a group of temperature sensors can have a calculated average of the readings of all the sensors.

Custom attributes are defined under the calculate: object in a group's configuration. Here's a possible configuration for the example given above as a group with ID temp_sensors. The select configuration simply selects all entities having the temperature_sensor capability, for illustration purposes (in practice, we'd probably want to include_entity some specific entities for this purpose).

        temp_sensors:
          select:
            - include_capability: temperature_sensor
          calculate:
            - attribute: 'temperature_sensor.value'
              source:
                attribute: temperature_sensor.value  # Where to get data values
              op: average

This is the most basic form of custom attribute configuration. The calculate object is an array of configuration objects. The attribute key is required for each array element and specifies the attribute to be defined and calculated on the group. The source substructure tells DynamicGroupController what attributes on the member entities should be used for calculation. Any member entity that does not have the specified source attribute, or for which the attribute's value is null, is simply ignored. The op tells DGC how to reduce (or aggregate) the multiple values from the member entities down to a single value. Pre-defined operations for op are defined below:

!!! note "null Member Attribute Values"
All of the above operations ignore null values from the source, unless otherwise indicated.

There may be circumstances where the source values require some pre-conditioning or filtering. This is enabled by the value_expr subkey under source. The result of the expression is the value that will be added to the array of values for op or reduce_expr. For example, in our temperature sensor group, some of the sensors return temperatures in Celsius, and others in Fahrenheit. We can use value_expr to convert the values to a consistent unit, so that the resulting reduction operation yields a consistent value in that same unit:

        temp_sensors:
          select:
            - include_capability: temperature_sensor
          calculate:
            - attribute: 'temperature_sensor.value'
              source:
                attribute: temperature_sensor.value  # Where to get data values
                # Convert Celsius temperatures to Fahrenheight
                value_expr: >
                  local units = entity.attributes.temperature_sensor.units;
                  local d = ( units === 'C' || units === '°C' ) ? value * 1.8 + 32 : value;
                  ( d <= 0 || indexOf( ['C','F','°C','°F'], units ) < 0 ) ? null : d
              op: average
              prec: 2  # two decimal digit max result

Step by step, the value_expr above first fetches the member entity's temperature units into a local variable called units. Since the attribute under source is temperature_sensor.value, the context variable value will contain the raw value from that attribute. The second line of the expression then checks if the units are Celsius, and if so, converts them to Fahrenheit (if units are not Celsius, it just takes the current value) and assigns it to a local variable d. Finally (third line of the expression), if the value is in range and the units are known, the value of d is returned, otherwise null. As stated above, most of the predefined operations ignore null values in their computation. So value_expr can function both to condition values and to filter them.

The prec key allows you to define the number of decimal digits precision for the result value; the result is rounded to comply. For example, a calculated value of 3.14159265 with prec: 4 results in 3.1416.

If none of the pre-defined operations addresses the need, the op: key can be replaced with an expression defined by reduce_expr:. The result value of the expression will be the value assigned to the custom attribute. The context for reduce_expr includes the following variables: group refers to the group entity being defined; members is an array of canonical IDs of the member entities at the time of evaluation (which may change in a truly dynamic group); and values is an array of the member values (as derived from source).

        temp_sensors:
          select:
            - include_capability: temperature_sensor
          calculate:
            - attribute: 'temperature_sensor.value'
              source:
                attribute: temperature_sensor.value  # Where to get data values
              # Compute harmonic mean (not predefined) using expression (trivialized for illustration)
              reduce_expr: >
                local s = 0;
                each v of values: do
                  s = s + (1.0 / v)
                done;
                len(values) / s
              prec: 2  # two decimal digit max result

Finally, custom attributes that should have fixed values can be defined by simply supplying value: under source:, like this:

            - attribute: 'temperature_sensor.units'
              source:
                value: '°F'

Make sure the data type of the value configured matches the expected type of attribute being defined.

@therealdb said in DynamicGroupController and attributes:

Number 2 seems more logical. Right now all we have are empty values.

I have this working, but I have had a busy week and then wife's birthday this weekend, so it might be another couple of days before I turn it loose. Just letting you know I haven't forgotten.

Reactor build 26221

SECURITY! - BARE-METAL USERS: It is always recommended that you update package dependencies whenever installing Reactor updates. After unpacking the Reactor archive, go into the reactor directory (where app.js lives) and run npm run deps to update package dependencies. This is particularly important to address security updates for many packages.

• DynamicGroupController: Fix an issue where a filter_expression-controlled group would miss an attribute update.
• Engine/Reactions: The log level for the result of Group and While action predicates (i.e. the conditions) has been raised to INFO (4) from DEBUG0 (5). This may help users more easily identify logic bugs in their actions without the need to change the Engine log level (the Engine is dauntingly verbose even at DEBUG0 level).
• HassController: Bless HA to 2026.7.4

Yes, I found this as well. I have a fix that I've been running/testing, not yet into a build. I will get it done before the end of the weekend.

Yes!

Question on your feature request... generally, a capability has to be defined on an entity to assign an attribute within that capability. A Group is a subclass of Entity that normally has a limited set of capabilities and attributes that don't vary from group to group (i.e. the sys_group capability is pretty much it).

I can see adding attributes to a Group two ways:

1. Like with actions, the capabilities the Group allows follows the superset of capabilities of the Group's members, so the group would inherit those capabilities and you would be allowed to set attributes (via expressions in config) for them, or...
2. In config, you set what capability you want to assign and set attributes for, and then supply the logic (expression) to drive the attribute. In this scenario, the only additional capabilities that are assigned to the Group are those you explicitly name in config.

Thoughts?

@therealdb said in DynamicGroupController and attributes:

I think the correct code snippet is d = false,

The grammar allows semicolon (;) to end a subexpression, so in that context, the two should be interchangeable.

@therealdb said in DynamicGroupController and attributes:

But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic

I understand. Nice. I will look at this in greater depth over the weekend.

OK. EnvisalinkController won't be of much help there, since Honeywell is all I have to test with (and therefore all it currently supports). If at some point you think you may want to try it, let me know.

Gotta love AI... this thread sent me digging on the unsolved problem, and I just decided to ask Grok why I'm getting arming CIDs but not disarms... on my panel, opening reports are off by default. Thirty seconds in programming mode to enable opening reports and there they are! So now, I have parity... correct user IDs when arming and disarming (using EnvisalinkController).

Maybe check your panel configuration and ensure both arming (closing) and disarming (opening) reports are enabled?

I've written an EnvisalinkController for Reactor that I use, rather than HA's integration, but result is somewhat consistent in that it's unexpected/inconsistent (I'm on an Ademco/Honeywell panel). For me, arming produces the right user ID in a partition CID event and email from EyezOn. But alas, state isn't consistent with EVL3/4, and there does not seem to be a corresponding disarm CID event, and the overall keypad message/status event (which must be used to detect disarming) doesn't seem to report the user slot that disarmed the alarm (nor do I get an email from EyezOn that the alarm was disarmed, which given no CID event, makes sense). A bit different from your results, but frustrating nonetheless.

It's all good! Many, many, many has been the time where an extra pair of eyes helped me. That's why I'm thrilled to have my son working on this project with me now. I'm glad it was something easy (no patch and build needed). Onward!!!

@gwp1 OK, so just to be clear on what I think I see, when the lights are ON as the log shows (so that the rule Master Bath Lights is SET aka true in Rule State conditions), and based on the other rule states as shown in the groups you posted above...

This reaction group is true:

And this reaction group is also true at the same time:

That seems like your problem. Shouldn't that circled OR be an AND? Because in that interior group, any one of those conditions being true (the Primary Defer Controller condition specifically) will make the interior group true, and therefore the parent OR group true.

In Default/Open - No Deferral, did you mean to have an "OR" in the second interior group? That looks a bit suspicious.

Reactor tries to be conservative about state when you edit a rule. That's to avoid whipping devices around every time you hit "Save". If you've been editing a rule and it stops behaving consistent with its intent, try the Reset Rule button first... it will wipe the entire state of the rule and force a full re-evaluation. Faster and less dramatic than restarting Reactor entirely.