Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.
  1. Home
  2. Software
  3. Multi-System Reactor
  4. [Solved] Group in Reset Reaction is being ignored
DynamicGroupController updating members issue
CrilleC
Bare-metal latest-26193 I have this group: "OKforLarm": name: OK för Larm select: - include_controller: vera - include_capability: door_sensor filter_expression: entity.attributes.door_sensor.state It contains the entities I expect but behaves a bit odd. When I open vera>device_10097 the entity attribute door_sensor.state changes to true but it won't show up as member in the group, when I also open vera>device_10095 they both shows as members and when I close vera>device_10095 it disappear from the group but when I close vera>device_10097 it lingers in the group until I restart Reactor.
Multi-System Reactor
DynamicGroupController and attributes
therealdbT
Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group. First of all, I think I found a typo in the doc: primary_attribute: "binary_sensor.state" primary_attribute_value: | d = false; each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d, d I think the correct code snippet is d = false, All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. 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 (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!
Multi-System Reactor
Arming Envisalink panel from MSR
T
Topic thumbnail image
Multi-System Reactor
Upgrade Issues
T
Topic thumbnail image
Multi-System Reactor
[SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation
G
Topic thumbnail image
Multi-System Reactor
[SOLVED] Question regarding "in" vs "contains" vs contents of the string
G
Topic thumbnail image
Multi-System Reactor
Reactor (Multi-System/Multi-Hub) Announcements
toggledbitsT
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here. Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed.
Multi-System Reactor
Logon screen timeout
G
Noticing since 170 that the lock screen doesn't switch to the logon prompt but, rather, stays on the active UI until such time as you go to click something within it. Then it jumps to the login screen. Brave browser Brave 1.92.139 (Official Build) (arm64) Chromium: 150.0.7871.114
Multi-System Reactor
[MSR] Copy&past of actions and/or drag&drop between set/reset
therealdbT
Hey @toggledbits One thing that bothers me while doing work on new systems/new features, is that I cannot copy&paste actions, and I cannot drag&drop between set and resets. #1 is for when I want to copy an action between different rules opened in two separate browser windows, while #2 is when I just need to flip a bunch of actions in the reset, or move some logic back and forth. Both will be appreciated, but I understand the technical challenges. Thanks!
Multi-System Reactor
Upgrade advice - upgrade from aarch64 to ARM64 image
T
I'm currently on version 26011. I understand that the aarch64 image is no longer supported. So, I therefore need to update to the ARM64 image. Can anyone possibly suggest how I update my docker compose.yaml file (see below). Ideally I'd like to keep my existing reactions etc. rather than start from scratch. # Multi-System Reactor template docker-compose.yml (version 22160) # # Change the lines indicated by "DO"... # services: reactor: container_name: reactor environment: # DO change the TZ: line to set your local time zone. # See valid TZ list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones TZ: GB # # DO NOT change this path. Your directory location is in "source" below. REACTOR_DATA_PREFIX: /var/reactor # DO change the image below to the one you are using (e.g. armv7l or aarch64 for RPi 4) image: toggledbits/reactor:latest-aarch64 restart: "always" expose: - 8111 ports: - 8111:8111 volumes: # DO change the /home/username/reactor below to the directory you created for # your local data; DO NOT change the /var/reactor part - /home/pi/docker/reactor:/var/reactor - /etc/localtime:/etc/localtime:ro tmpfs: /tmp
Multi-System Reactor
Alexa for MSR, any interest?
MikeReadingtonM
Topic thumbnail image
Multi-System Reactor
[RESOLVED] Telegram notification broke with latest update
3
Topic thumbnail image
Multi-System Reactor
[RESOLVED] Phantom device, “INFO” appears
wmarcolinW
Topic thumbnail image
Multi-System Reactor
[RESOLVED] Mode Status NULL
wmarcolinW
Topic thumbnail image
Multi-System Reactor
[RESOLVED] HTTP query failing after version 26177
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Question about the find function
wmarcolinW
Topic thumbnail image
Multi-System Reactor
[Answered] OK to remove old json files?
3
Topic thumbnail image
Multi-System Reactor
Deprecation Announcement: 32-bit ARM *docker* images
toggledbitsT
If you are using the armv7l docker image, the OpenJS Foundation that publishes node is no longer producing 32-bit builds as of v24. That means the last supported LTS version of node for armv7l is v22, which will go End-of-Life in May 2027. Therefore, the Reactor armv7l image is now deprecated and will only be produced until node v22 goes EOL, and I will not publish armv7l images beyond that date. If you are running an RPi 3 or earlier with Reactor, you are on this image, and will need to upgrade hardware to a 64-bit model and use the arm64 image. If you need help getting it done, ask in this category.
Multi-System Reactor
[Solved] build 26150 - engine not starting
G
@toggledbits I pulled the image (well, Watchtower did) and within minutes the whole system went offline. The log looks like it ends with 26143. [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-mkahsmgf/26qq82mw-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lqyfljfi/22f8on0t-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lsb61rw8/24oenqi2-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/rule-lrh58he0:S-1c00gfib-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/1c00dylr-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/1nam9w5u-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-miuh2qqi/22ls4lql-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-kwc6rmci/rule-kwc6rmci:S-1vj8sdfc-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-kwc6rmci/rule-kwc6rmci:S-1qanz01x-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/24lq19p6-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-mk0o8iox/23oy468y-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-miscg2h3/rule-miscg2h3:S-22gmbq1c-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-kxgrfjke/238p0old-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-m7ccsso5/re-m7ccsso5-1r0myjxa-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/19nl9wq2-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/rule-ladyja6a:S-yl3xk9t-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/rule-ladyja6a:S-yl3vv5m-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-ln7j2nqp/re-ln7j2nqp-22mx9lzd-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-ln7j2nqp/22mx87c8-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-licneppy/1mzwe7ht-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ml3194ih/25jqt1j4-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-kxgrg7kf/227hshak-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-reactorexmachina/13ua1p95-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-reactorexmachina/13uagam7-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-grpvl9oypg/rule-grpvl9oypg:R-134x4cbv-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-grpvl9oypg/rule-grpvl9oypg:R-134x2fyl-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-lscjrws1/238p5c22-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lbwr0jvq/1xkczf03-cons [latest-26143]2026-05-31T15:23:44.547Z <Structure:NOTICE> Structure Structure#1 stopped [latest-26143]2026-05-31T15:23:44.547Z <app:NOTICE> Closing APIs... [latest-26143]2026-05-31T15:23:44.547Z <wsapi:NOTICE> wsapi: closing... [latest-26143]2026-05-31T15:23:44.547Z <wsapi:NOTICE> wsapi: disconnecting from "192.168.1.23#82" (1001 service closing) [latest-26143]2026-05-31T15:23:44.548Z <httpapi:NOTICE> HTTP API closing... [latest-26143]2026-05-31T15:23:44.549Z <wsapi:NOTICE> wsapi: server closed [latest-26143]2026-05-31T15:23:44.549Z <httpapi:INFO> HTTP server closed. [latest-26143]2026-05-31T15:23:44.549Z <app:NOTICE> Stopping timers... [latest-26143]2026-05-31T15:23:44.551Z <app:null> Shutdown complete, process ID 1 [latest-26143]2026-05-31T15:23:44.551Z <app:null> Closing logs... [latest-26143]2026-05-31T15:23:44.551Z <default:null> Closing log I can SSH to the VM. Alas, I do not have the previous image for 26143 as I'm a little too quick sometimes on housekeeping.
Multi-System Reactor
http request action & digest auth
tunnusT
I’m using the HTTP Request action in MSR and need to authenticate against an endpoint that uses HTTP Digest authentication. Now that endpoint was changed to use SHA-256 in digest auth, so I would like to know if MSR supports it, or is it limited to MD5-based digest auth?
Multi-System Reactor

[Solved] Group in Reset Reaction is being ignored

Scheduled Pinned Locked Moved Multi-System Reactor
7 Posts 2 Posters 1.9k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • 3 Offline
    3 Offline
    3rdStng
    wrote on last edited by 3rdStng
    #1

    They say plagiarism is the best form of flattery, right? Or something like that. Thanks go to @gwp1 for the great title of this subject. I'm trying to get into using the new (to me) group option within the Set and Reset Reactions. I have the Set action working beautifully, however my reset reaction is not. What I am after, which maybe this isn't even possible, is one rule for the motion sensed in my garage. Upon motion, and it night time, turn on the lights. And upon no motion, and no motion for 10 minutes, turn off the lights.

    MSR Docker on unRAID: latest-22293
    Hubitat 2.3.3.137
    HaaS 2022.10.4

    Trigger:
    If motion is detected by either sensor

    Set Reaction:
    Only turn the lights on between 30 minutes before sunset and 30 minutes after sunrise.

    Reset Reaction: (I've tried a few variations, each with conditional options set.)
    Tried: Both Motion sensors, in an AND group or individually as an AND, are False and sustained false for 10 minutes.
    Tried: Rule State (this rule itself) is False and sustained false for 10 minutes.

    Basically the additional condition I am putting into the Reset Reaction group is being ignored and as soon as either motion sensors is false from it's normal reset time, the lights turn off. I would like to have a 10 minute delay before the lights go off. In case I'm moving around and re-trigger a sensor. Are additional conditions allowed within the Reset Group option? Or am I way off and should just break this into two rules? One for on and one for off?

    EDIT: Forgot to include my reasoning for not putting the Delay reset for 600 within the Trigger. I want the garage lights to come on again, if they are off, after the motion sensors native timeout has reset. For example, if I go in the garage, the lights automatically turn on. When I leave the garage, I will turn them off. But if I return within 2 minutes, and less than 10 minutes, turn the lights back on again for me.

    5cd34edf-11b0-4929-9841-2f635c761881-image.png

    1 Reply Last reply
    0
    • toggledbitsT Offline
      toggledbitsT Offline
      toggledbits
      wrote on last edited by toggledbits
      #2

      Yeah, that's not how you do that. The Reset reaction runs as soon as your triggers go false. What you really need to do is keep your triggers from going false too early. Your motion sensors have a reset period that is shorter than your ten minute wish (that is, they signal no motion on their own timing, which appears to be shorter than 10 minutes, not at all unusual), so you need to stretch out that time.

      Since you already have your triggers in an OR group, this will be easy. Just open the condition options for your OR group, and in the "Follow" section for "delay reset", add a 600 second delay. This is a resettable delay that will restart every time motion is detected, so if motion is detected during the 10 minute delay, the delay will restart anew, keeping the lights on until there is truly no motion detected for 10 minutes.

      Your Reset reaction can then just turn the lights off; it needs nothing else (no groups or constraints — remove those).

      Edit: to be specific about the reason your Reset reaction doesn't work as you've shown it, as I said, when both motion sensors no longer signal motion, that OR trigger group goes false, and the Reset reaction runs. Since you have a group with constraints, the first thing that happens is that Reactor checks to see if the constraints have been met, and in Reactor's view, your constraint is "Garage - on" (rule) has been false for 10 minutes; there's no way it can be at that moment, and Reactor isn't going to stop there and wait for that to be true; that's not how constraints work. The constraint test is instantaneous, and Reactor only runs the group actions if the constraint conditions are true in that instant. Reactor sees they are not, so skips the power off actions and the Reset reaction is then done working. Reactor will not run it again when the constraint is satisfied, because again, that's not how constraints work.

      Edit 2: Also, please don't reuse/plagiarize another existing thread's title. That's really confusing for people searching later, or even reading now. A better and more specific title (for both of those posts) would be appreciated. Post titles should be more descriptive of the problem. Refer to the posting guidelines for examples.

      Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

      3 1 Reply Last reply
      1
      • toggledbitsT toggledbits

        Yeah, that's not how you do that. The Reset reaction runs as soon as your triggers go false. What you really need to do is keep your triggers from going false too early. Your motion sensors have a reset period that is shorter than your ten minute wish (that is, they signal no motion on their own timing, which appears to be shorter than 10 minutes, not at all unusual), so you need to stretch out that time.

        Since you already have your triggers in an OR group, this will be easy. Just open the condition options for your OR group, and in the "Follow" section for "delay reset", add a 600 second delay. This is a resettable delay that will restart every time motion is detected, so if motion is detected during the 10 minute delay, the delay will restart anew, keeping the lights on until there is truly no motion detected for 10 minutes.

        Your Reset reaction can then just turn the lights off; it needs nothing else (no groups or constraints — remove those).

        Edit: to be specific about the reason your Reset reaction doesn't work as you've shown it, as I said, when both motion sensors no longer signal motion, that OR trigger group goes false, and the Reset reaction runs. Since you have a group with constraints, the first thing that happens is that Reactor checks to see if the constraints have been met, and in Reactor's view, your constraint is "Garage - on" (rule) has been false for 10 minutes; there's no way it can be at that moment, and Reactor isn't going to stop there and wait for that to be true; that's not how constraints work. The constraint test is instantaneous, and Reactor only runs the group actions if the constraint conditions are true in that instant. Reactor sees they are not, so skips the power off actions and the Reset reaction is then done working. Reactor will not run it again when the constraint is satisfied, because again, that's not how constraints work.

        Edit 2: Also, please don't reuse/plagiarize another existing thread's title. That's really confusing for people searching later, or even reading now. A better and more specific title (for both of those posts) would be appreciated. Post titles should be more descriptive of the problem. Refer to the posting guidelines for examples.

        3 Offline
        3 Offline
        3rdStng
        wrote on last edited by 3rdStng
        #3

        Thank you for the very detailed explanation. I haven't really dove into constraints before and clearly I need to so I understand them better.

        @toggledbits said in Group in Reset Reaction is being ignored:

        open the condition options for your OR group, and in the "Follow" section for "delay reset", add a 600 second delay. This is a resettable delay that will restart every time motion is detected, so if motion is detected during the 10 minute delay, the delay will restart anew

        This is exactly how I have all my Motion rules defined. And they work as expected. But in this particular rule, I want the Set reaction to trigger again if it detected motion by either sensor after their timeout and before the 10 minute reset delay within MSR.

        Use case: I enter the garage, the lights turn on. I leave the garage and manually turn the lights off. (Assuming there is a 10 minute delay reset defined) I return to the garage 2 minutes later, the sensors detect movement, I would like the lights to turn back on.

        With the 10 minute reset delay defined, MSR will see the rule still as true at that 2 minute mark and not fire the Set reaction again, correct?

        @toggledbits said in Group in Reset Reaction is being ignored:

        please don't reuse/plagiarize another existing thread's title

        I will fix this.

        EDIT: If the solution for this is to have two rules, I am perfectly fine with that. I just happened to see that Groups were an option within the reactions now and was determining if there is a way to consolidate rules. But if I need an ON and and OFF rule, I'm good with that.

        1 Reply Last reply
        0
        • toggledbitsT Offline
          toggledbitsT Offline
          toggledbits
          wrote on last edited by
          #4

          OK. Then I think two rules will probably be the easiest way.

          Your "On" rule is simple then... either sensor senses motion (OR group with two conditions as before), turn on the light in the Set reaction. No constraints, delays, etc., and no reset reaction, in this rule.

          Your "Off" rule is an AND group with two conditions: the light is on (Entity Attribute condition) AND the "On" rule has been false for 10 minutes (sustained for delay on a Rule State condition looking at the "On" rule with the is FALSE operator). Set reaction turns the light off.

          Any time motion is sensed, the "On" rule will turn on the light (harmless if it's already on). If the light is on and the "On" rule hasn't seen anything for 10 minutes, the "Off" rule triggers and turns off the light. If you turn off the light manually, and then go back in the room a moment later, the "On" rule will turn the light back on.

          Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

          3 1 Reply Last reply
          2
          • toggledbitsT toggledbits

            OK. Then I think two rules will probably be the easiest way.

            Your "On" rule is simple then... either sensor senses motion (OR group with two conditions as before), turn on the light in the Set reaction. No constraints, delays, etc., and no reset reaction, in this rule.

            Your "Off" rule is an AND group with two conditions: the light is on (Entity Attribute condition) AND the "On" rule has been false for 10 minutes (sustained for delay on a Rule State condition looking at the "On" rule with the is FALSE operator). Set reaction turns the light off.

            Any time motion is sensed, the "On" rule will turn on the light (harmless if it's already on). If the light is on and the "On" rule hasn't seen anything for 10 minutes, the "Off" rule triggers and turns off the light. If you turn off the light manually, and then go back in the room a moment later, the "On" rule will turn the light back on.

            3 Offline
            3 Offline
            3rdStng
            wrote on last edited by
            #5

            @toggledbits I like your off rule. It is a different approach than what I have. The end result of both is the same though.

            My off rule has the sensors in an AND group (when the sensor is true) with a delay reset of 10 minutes. There is no Set reaction. Only a reset reaction to turn the light off.

            1 Reply Last reply
            0
            • toggledbitsT Offline
              toggledbitsT Offline
              toggledbits
              wrote on last edited by
              #6

              Not sure you want an AND group with that construction... it requires both sensors to detect motion for the group to be true at the same time. That may be right a lot of the time, but I'll bet it's not some of the time...

              Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.

              3 1 Reply Last reply
              1
              • toggledbitsT toggledbits

                Not sure you want an AND group with that construction... it requires both sensors to detect motion for the group to be true at the same time. That may be right a lot of the time, but I'll bet it's not some of the time...

                3 Offline
                3 Offline
                3rdStng
                wrote on last edited by
                #7

                @toggledbits You are correct. I had an extra motion sensor and was planning on putting it on the opposite side. While I was testing, with three sensors in the AND group, it dawned on me that all three would have to have triggered and gone false for this to work. This won't happen if you only enter the garage a few feet and never to the other side. I ended up creating my rules exactly how your example was and it's working great. Thanks for the insight and example.

                1 Reply Last reply
                1
                • toggledbitsT toggledbits locked this topic on
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                Recent Topics

                • DynamicGroupController updating members issue
                  toggledbitsT
                  toggledbits
                  0
                  4
                  11

                • DynamicGroupController and attributes
                  therealdbT
                  therealdb
                  1
                  5
                  58

                • Arming Envisalink panel from MSR
                  toggledbitsT
                  toggledbits
                  0
                  5
                  80

                • Upgrade Issues
                  T
                  tbully
                  0
                  9
                  199

                • [SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation
                  toggledbitsT
                  toggledbits
                  0
                  10
                  201

                • [SOLVED] Question regarding "in" vs "contains" vs contents of the string
                  G
                  gwp1
                  0
                  5
                  95

                • Reactor (Multi-System/Multi-Hub) Announcements
                  toggledbitsT
                  toggledbits
                  5
                  147
                  128.2k

                • openLuup console disappeared - 500 - Internal Server Error
                  A
                  a-lurker
                  0
                  2
                  158

                • Logon screen timeout
                  G
                  gwp1
                  0
                  5
                  183

                • [MSR] Copy&past of actions and/or drag&drop between set/reset
                  toggledbitsT
                  toggledbits
                  0
                  9
                  332

                • Upgrade advice - upgrade from aarch64 to ARM64 image
                  toggledbitsT
                  toggledbits
                  0
                  4
                  195
                Powered by NodeBB | Contributors
                Hosted freely by 10RUPTiV - Solutions Technologiques | Contact us
                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • Unsolved