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. MSR Set Reaction not working anymore
Reverse proxy & API ACL
tunnusT
I'm trying to allow anonymous access from a local network to /api/v1/log, but the problem now with the reverse proxy configuration is that this access is open via proxy to the internet. At least I wasn't able to configure ACL so that only an access from a local network would be permitted. reactor.yaml: baseurl: "http://192.168.1.12:8111" proxy_baseurl: "https://external.com:30000" trusted_proxy: "192.168.1.12" Local traffic would originate from 192.168.1.0/24 network. Synology is acting as a reverse proxy and hosting MSR as a docker container (which has its own network and IP 172.18.0.5). MSR build is latest-26298-fbb75fb8 users.yaml: - url: "/api/v1/log" method: "GET" source_ip: 172.18.0.0/24 allow: true Using the above ACL works, but it enables access via proxy also. If I use source_ip: 192.168.1.0/24, then it doesn't work either locally or remotely. So I'm kinda lost what should I use as source_ip in this case?
Multi-System Reactor
Grouped devices
G
I've seen many of you using Dynamic Group Controller. I'm using it myself for monitoring device battery levels. I've read and re-read the Dynamic Group Controller docs and still cannot come to an answer for my question so let me paint my scenario: I've migrated from EchoSpeaks in Hubitat ('cause borked and seemingly unmaintained) to Alexa Devices in Home Assistant ('cause not borked in 2026.11.0) to be able to send TTS to my Echo devices. In EchoSpeaks I could create groups. Sweet. In Alexa Devices I don't seem to be able to do so. As such, my thought was "wait - isn't there a way in MSR?" Is this an effective scenario that Dynamic Group Controller can be used for?
Multi-System Reactor
MFA
T
Topic thumbnail image
Multi-System Reactor
Login protections
tunnusT
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
Reactor Inspect - a small read-only helper panel for MSR
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Reactor Build 26284 stuck at Loading Reactor UI
T
Topic thumbnail image
Multi-System Reactor
MSR with reverse proxy
tunnusT
I'm trying to use MSR via reserve proxy in Synology DSM, but MSR page does not load https://<public ip>:30000/reactor/en-US/ At the same time logging page loads normally https://<public ip>:30000/api/v1/log I thought maybe authentication was messing it up, but there was no deny entries in the log, and also disabling authentication did not make any difference. For this use case VPN is not an option (that works, but as said not an option for this particular use case). Any ideas what could cause this? MSR build latest-26242-28d69aa8, Chrome browser
Multi-System Reactor
Missing attribute after upgrade
3
Topic thumbnail image
Multi-System Reactor
[MSR] Native fan capabilty
therealdbT
Nothing more to add. I see we have hvac_blower, but, anyway, maybe a native fan on the same assumptions of the fan from HASS could be reasonable. I have a couple of them. ie, this is from ESPHome via HASS. x_hass.domain="fan" x_hass.entity_id="fan.kitchen_seashell_hood_ventilation_fan" x_hass.floor_id=null x_hass.services=["fan","esphome"] x_hass.source="esphome" x_hass.state="off" x_hass_attr.friendly_name="Seashell Hood Ventilation Fan" x_hass_attr.percentage=50 x_hass_attr.percentage_step=25 x_hass_attr.preset_mode="" x_hass_attr.preset_modes=[] x_hass_attr.supported_features=49 Thanks.
Multi-System Reactor
[MSR] Rule do not fire
therealdbT
Topic thumbnail image
Multi-System Reactor
Rule condition shows TRUE in UI but Rule never transitions to SET — survives full restart
N
Build: latest-26221-b25bb3e3, Docker on Synology. Hi, I have a Rule whose Trigger/Constraints reference other Rules via Rule State ... is TRUE. At some point it stops firing. Expanding the rule's condition tree in the UI shows every Trigger and Constraint condition green/TRUE — confirmed live by walking into the room and watching Motion go true in real time. Rule History shows no new SET, just old reset entries. Tried, on the same rule, same evening: recreating the trigger conditions with fresh IDs, recreating the constraint conditions with fresh IDs (flat and wrapped in a new Group — wrapping in a Group produced one SET, but it didn't reproduce on repeat attempts with the same structure), and finally a full container restart with a verified-correct saved rule. Still no SET, even with a fresh live motion event right after the restart. Separately, I found that this rule (and its 10 per-room clones) share identical internal condition/group IDs with each other — leftover from a batch clone done months ago, never regenerated. Not sure if that's related, since fixing the IDs didn't reliably fix the symptom either. Has anyone seen a Rule State condition show TRUE in the UI without the Rule ever producing a SET, surviving a clean restart? Thanks in advance
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
Unofficial thread for compatibility
tunnusT
As there are statements about compatibility for home assistant versions in MSR new version announcements (e.g. "HassController: Bless Hass to 2025.7.3"), I thought it would be good idea to track other controllers as well. As an example, I can confirm that build "latest-25208-c53e8513" works with Hubitat Elevation C-8 platform version 2.4.2.134 using Maker API. Updates: (the latest versions first in the list) OK: build "latest-25264-2fbe9217" with Hubitat C-8 platform v. 2.4.3.123
Multi-System Reactor
Ooops - Deleted Reactor Ex Machina II
R
I accidentally deleted Reactor Ex Machina II (REM II) from my Reactor rules. I tried to recover it by deleting the .json and .dval in the Rules subdirectory and then recreating it from Togglebits original posting, but that did not work. Does anyone know how to recover REM ll ?
Multi-System Reactor
Bail out of failed reaction?
T
Topic thumbnail image
Multi-System Reactor
Arming Envisalink panel from MSR
T
Topic thumbnail image
Multi-System Reactor
[Solved] DynamicGroupController updating members issue
CrilleC
Edit: Solved in latest-26221. 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
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

MSR Set Reaction not working anymore

Scheduled Pinned Locked Moved Multi-System Reactor
6 Posts 2 Posters 1.7k 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.
  • B Offline
    B Offline
    basai
    wrote on last edited by
    #1

    Iron: QNAP NAS
    Running MSR and HAAS on Docker (QNAP Container Station)
    Reactor (Multi-hub) stable-22203-81a2f3cc
    Home Assistant Core 2022.6.7
    Vera 1.7.5186 (7.31)
    Config files are stored in shared volumes on the NAS.
    Office light in example is joined to Vera-Plus

    Hello all,

    I decided to upgrade MSR to latest-amd64. It wasn’t until afterwards that I noticed all rulesets broken. So unfortunately I’m not sure if this was already broken before or I broke it after upgrading. Yes poor judgement on my part for being complacent.

    Never the less, this is broken globally across all rulesets, even though I can see the triggers change to “True” (Turn green).

    For this example, I have a boolean helper toggle in HAAS called “TV MODE HAAS SW”.

    When toggled ‘on’, MSR should turn my Vera office light OFF and it doesn’t, but if I manually select the play button to the right of the line in the Set Reaction, it executes properly and turns off the Vera office light.

    The MSR Rule does not have any Constraints set.

    I can see in MSR it recognizes the state changes yet doesn’t execute the “Set Reaction”.

    Any help greatly appreciated.

    Log files from reactor.log and screen shots to follow:

    Reactor.log when toggling the haas helper, Set Reaction doesn’t execute.

    [stable-22203]2022-10-02T21:21:34.799Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) starting evaluation; because entity-changed Entity#hass>input_boolean_tv_mode
    [stable-22203]2022-10-02T21:21:34.800Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) evaluated; rule state transition from RESET to SET!
    [stable-22203]2022-10-02T21:21:34.819Z <Rule:INFO> TV MODE ON (Rule#rule-l2hvuz8r) evaluation complete
    [stable-22203]2022-10-02T21:21:34.820Z <Engine:INFO> Enqueueing "TV MODE ON<SET>" (rule-l2hvuz8r:S)
    [stable-22203]2022-10-02T21:21:34.835Z <Engine:NOTICE> Starting reaction TV MODE ON<SET> (rule-l2hvuz8r:S)
    [stable-22203]2022-10-02T21:21:34.835Z <Engine:INFO> TV MODE ON<SET> all actions completed.
    

    Reactor.log when manually triggering the Set Reaction with the play button which correctly turns off the light

    [stable-22203]2022-10-02T21:23:25.035Z <HassController:null> HassController#hass: sending payload for power_switch.off on Entity#hass>light_office_86 action: [Object]{ "type": "call_service", "service_data": { "entity_id": "light.office_86" }, "domain": "homeassistant", "service": "turn_off" }
    

    When toggled ON
    toggled_on.png

    Rule config screen
    tv_mode_config.png

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

      I'm seeing a lot of conflicting information in your report. 22203 is not latest, it's the older stable (and your log entries confirm this as well). Your office light being turned off in the SET reaction you show is on Hass, not on Vera.

      I would upgrade to the true latest 22274 for starters; I won't really spend time troubleshooting on anything but the current (latest development build) version (i.e. if you're having a problem, make sure you test on the latest version before seeking help -- see the posting guidelines).

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

      B 1 Reply Last reply
      0
      • toggledbitsT toggledbits

        I'm seeing a lot of conflicting information in your report. 22203 is not latest, it's the older stable (and your log entries confirm this as well). Your office light being turned off in the SET reaction you show is on Hass, not on Vera.

        I would upgrade to the true latest 22274 for starters; I won't really spend time troubleshooting on anything but the current (latest development build) version (i.e. if you're having a problem, make sure you test on the latest version before seeking help -- see the posting guidelines).

        B Offline
        B Offline
        basai
        wrote on last edited by
        #3

        @toggledbits

        Apologies for the confusion.

        I was trying to indicate, although poorly, that I did install 'latest' at first which didn't correct the problem and then opted to go with 'stable' thinking that was the better choice.

        As far as the MSR Set Reaction using haas vs vera per my report, I was testing both and neither worked when the rule is triggered, however the light does turn off when I manually select the play button next to the Set Reaction Rule for either the set haas or vera case. Unfortunately I neglected to reflect that correctly in my report and hence the mismatch / confusion

        HTH
        -bh

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

          There are quite a few people on latest, including myself on three systems. If there was a problem with reactions, I think there would be more than one report. Please try reinstalling latest, restart, and then confirm in the log entries that you have the correct version running (as of this weekend that would be latest-22274). I suspect your attempted upgrade didn't go as planned.

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

          1 Reply Last reply
          0
          • B Offline
            B Offline
            basai
            wrote on last edited by
            #5

            Howdy, Honestly I didn’t really think this was an MSR Set Reaction pandemic and was more than likely a locally induced error of some sort.

            This is fixed now based on something you said in your last reply suspecting an update problem which pulled me out of a loop and put me on the right path.

            Summary: Upgrading to latest-22274 fixed the problem but QNAP’s Container Station using the Docker Hub Tab would only download and install latest-22179. Not sure if this is a QNAP bug or feature.

            Detail: For the benefit of any QNAP NAS users out there I’ll explain.

            Using QNAP NAS’s Container Station, searching for “reactor” in the “Docker Hub” tab I would select "latest-amd64”, but it would only install latest-22179 and not the actual latest-22274. Picking up the NAS and shaking it a few times, turning it off and on again, or putting more quarters in it didn't help.

            In the past I didn’t find a need to do the following since I believe Container Station should be doing this all by self, and if not, user error on my part.

            So to fix this I ssh’d to the QNAP NAS CLI and ran.

            docker pull toggledbits/reactor:latest-amd64
            

            Which returned the following, I was feeling optimistic seeing the "pull completes' "

            [basai@basai ~]$ docker pull toggledbits/reactor:latest-amd64
            latest-amd64: Pulling from toggledbits/reactor
            8663204ce13b: Already exists 
            8c392e9e905c: Already exists 
            36ce72f2f129: Already exists 
            2e8529c47e46: Already exists 
            26c2865d7fe4: Pull complete 
            b45a2cf2a065: Pull complete 
            ac02d13d40de: Pull complete 
            2bd82a6d3d8c: Pull complete 
            Digest: sha256:a192e403200a62664cec40f40f61499218ac9a0cae3b8ed8390f87679505105d
            Status: Downloaded newer image for toggledbits/reactor:latest-amd64
            docker.io/toggledbits/reactor:latest-amd64
            [basai@basai ~]$
            

            After this completed, now when I went to create a new docker by going into container station, searching for “reactor” in the “Docker Hub Tab” and selected “latest-amd64” it correctly installed latest-22274 and also pre-populated the NODE_PATH variable correctly which wasn’t happening before.

            Problem solved and MSR is working as expected again.

            Thanks you for your help, MSR Rocks!
            -bh

            toggledbitsT 1 Reply Last reply
            0
            • B basai

              Howdy, Honestly I didn’t really think this was an MSR Set Reaction pandemic and was more than likely a locally induced error of some sort.

              This is fixed now based on something you said in your last reply suspecting an update problem which pulled me out of a loop and put me on the right path.

              Summary: Upgrading to latest-22274 fixed the problem but QNAP’s Container Station using the Docker Hub Tab would only download and install latest-22179. Not sure if this is a QNAP bug or feature.

              Detail: For the benefit of any QNAP NAS users out there I’ll explain.

              Using QNAP NAS’s Container Station, searching for “reactor” in the “Docker Hub” tab I would select "latest-amd64”, but it would only install latest-22179 and not the actual latest-22274. Picking up the NAS and shaking it a few times, turning it off and on again, or putting more quarters in it didn't help.

              In the past I didn’t find a need to do the following since I believe Container Station should be doing this all by self, and if not, user error on my part.

              So to fix this I ssh’d to the QNAP NAS CLI and ran.

              docker pull toggledbits/reactor:latest-amd64
              

              Which returned the following, I was feeling optimistic seeing the "pull completes' "

              [basai@basai ~]$ docker pull toggledbits/reactor:latest-amd64
              latest-amd64: Pulling from toggledbits/reactor
              8663204ce13b: Already exists 
              8c392e9e905c: Already exists 
              36ce72f2f129: Already exists 
              2e8529c47e46: Already exists 
              26c2865d7fe4: Pull complete 
              b45a2cf2a065: Pull complete 
              ac02d13d40de: Pull complete 
              2bd82a6d3d8c: Pull complete 
              Digest: sha256:a192e403200a62664cec40f40f61499218ac9a0cae3b8ed8390f87679505105d
              Status: Downloaded newer image for toggledbits/reactor:latest-amd64
              docker.io/toggledbits/reactor:latest-amd64
              [basai@basai ~]$
              

              After this completed, now when I went to create a new docker by going into container station, searching for “reactor” in the “Docker Hub Tab” and selected “latest-amd64” it correctly installed latest-22274 and also pre-populated the NODE_PATH variable correctly which wasn’t happening before.

              Problem solved and MSR is working as expected again.

              Thanks you for your help, MSR Rocks!
              -bh

              toggledbitsT Offline
              toggledbitsT Offline
              toggledbits
              wrote on last edited by
              #6

              @basai said in MSR Set Reaction not working anymore:

              putting more quarters in it didn't help

              LOL! That inflation is hitting everything, isn't it?

              Glad it worked out!

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

              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

              • Reverse proxy & API ACL
                tunnusT
                tunnus
                0
                3
                24

              • Grouped devices
                G
                gwp1
                0
                1
                14

              • MFA
                toggledbitsT
                toggledbits
                0
                17
                311

              • Login protections
                toggledbitsT
                toggledbits
                0
                2
                108

              • Reactor (Multi-System/Multi-Hub) Announcements
                toggledbitsT
                toggledbits
                5
                152
                150.9k

              • Reactor Inspect - a small read-only helper panel for MSR
                G
                gwp1
                2
                6
                358

              • Reactor Build 26284 stuck at Loading Reactor UI
                T
                tamorgen
                0
                16
                1.4k

              • MSR with reverse proxy
                tunnusT
                tunnus
                0
                12
                702

              • Missing attribute after upgrade
                3
                3rdStng
                0
                3
                409

              • Use of Google Gemini as an MSR and Hubitat configuration aid
                therealdbT
                therealdb
                0
                2
                235

              • [MSR] Native fan capabilty
                therealdbT
                therealdb
                1
                3
                241

              • [MSR] Rule do not fire
                therealdbT
                therealdb
                0
                4
                340
              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