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] Random ghosting of lights when Away
Gradually turn on lights.
Tom_DT
I have several lights that I would like to turn on very gradually over 15 or 20 seconds. from 0 to .25 in .01 increments. I have tried a few things that came nowhere near working, so here I am.
Multi-System Reactor
Stop the MSR by an external switch on Hubitat.
wmarcolinW
Use case: When performing home maintenance, such as air conditioning, I want all rules involving air conditioning to be disabled. To do this, to day, I have a virtual switch that I placed within all rules involving air conditioning, meaning that if I turn it off, none of them work. Then another situation: the water pump system and garden irrigation, another switch. In short, I had to create several virtual switches in Hubitat to disable rules in MSR. Unfortunately, however, I was unable to cover all scenarios, so I wondered if it would be possible for MSR to support a virtual MSR switch, which, when configured in the reactor settings, would function as a general on/off switch for MSR. If it is configured and turned off, the entire rules and actions in MSR stops working, except for the status change reading process, specifically for this switch, which, when turned on, would restart the MSR. Would it be possible to do something like this? Any recommendations from the experts?
Multi-System Reactor
Error After Upgrade
T
Topic thumbnail image
Multi-System Reactor
Reset attribute value of entity in event handler
R
Topic thumbnail image
Multi-System Reactor
Need help figuring out how to delay a reset on reaction
T
Topic thumbnail image
Multi-System Reactor
Way to search for rules (rule state) in other rules
T
@toggledbits, not sure if this is a feature request or I'm using the search tool wrong. You have a "Search for rule" in the Rules Set tab in MSR. It works nicely to find a rule and bring up said rule, but can it/could it be used for as a "where used?" global search? For instance, I have a fairly large set of rules, divided up into 10 different rulesets. There's easily a hundred individual rules, and many of the rules have Rule State triggers, which of course refer to other rules. Amongst my troubleshooting today, I came across what may have been a duplicate or troubleshooting attempt, but I can't tell if it's actually used as a Rule State in another rule without opening each rule that I suspect it may be a part of. Thanks.
Multi-System Reactor
Links to MSR from HA
Tom_DT
I am using Home Assistant a lot recently. On a dashboard showing the devices, I would like to show a link to the MSR rule that controls the devices. Is there a way to link directly into MSR?
Multi-System Reactor
Set Reaction > Script Action
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Errors after updating to MQTTController build 25139
tunnusT
I'm running MSR build 25139 on Docker, using MQTT controller 24293, and everything working as expected. But if I try to upgrade to MQTTController build 25139, I'm getting the following errors on MSR UI: An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.god Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.green Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa filter pump auto off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.red Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa filter pump auto run" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.pump Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa watchdog" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.status Last 11:20:37 My MQTT configuration (local_mqtt_devices.yaml) for the related entity is: layzspa_message: type: ValueSensor capabilities: ["temperature_sensor", "value_sensor", "power_sensor"] primary_attribute: power_sensor.value events: "layzspa/message": "power_sensor.value": json_payload: true if_expr: '! isnull( payload?.PWR )' expr: "float(payload.PWR)" "value_sensor.air": json_payload: true if_expr: '! isnull( payload?.AIR )' expr: "float(payload.AIR)" "value_sensor.pump": json_payload: true if_expr: '! isnull( payload?.FLT )' expr: "float(payload.FLT)" "value_sensor.god": json_payload: true if_expr: '! isnull( payload?.GOD )' expr: "float(payload.GOD)" "value_sensor.lock": json_payload: true if_expr: '! isnull( payload?.LCK )' expr: "float(payload.LCK)" "value_sensor.unit": json_payload: true if_expr: '! isnull( payload?.UNT )' expr: "float(payload.UNT)" "value_sensor.error": json_payload: true if_expr: '! isnull( payload?.ERR )' expr: "float(payload.ERR)" "temperature_sensor.green": json_payload: true if_expr: '! isnull( payload?.GRN )' expr: "float(payload.GRN)" "temperature_sensor.red": json_payload: true if_expr: '! isnull( payload?.RED )' expr: "float(payload.RED)" "temperature_sensor.target": json_payload: true if_expr: '! isnull( payload?.TGT )' expr: "float(payload.TGT)" "temperature_sensor.value": json_payload: true if_expr: '! isnull( payload?.TMP )' expr: "float(payload.TMP)" "temperature_sensor.virtual": json_payload: true if_expr: '! isnull( payload?.VTM )' expr: "round(float(payload.VTM), 1)" "temperature_sensor.ambient": json_payload: true if_expr: '! isnull( payload?.AMB )' expr: "float(payload.AMB)" "layzspa/Status": "value_sensor.status": if_expr: '! isnull( payload )' expr: "payload" "layzspa/button": "value_sensor.button": if_expr: '! isnull( payload )' expr: "payload" and in reactor.yaml I have: "layzspa_states": name: "Lay-Z-Spa States" friendly_name: 'Lay-Z-Spa States' include: layzspa_message I realize my MQTT configuration might be a bit unorthodox, but could there still be something unintentional in the latest MQTTController build? If needed, I can provide detailed logs.
Multi-System Reactor
🎉 My very first MSR controller: OpenSprinkler
therealdbT
Since today is my birthday - and I still pretend to be unconventional - I'm giving away a present to this wonderful community and I'm releasing my first OpenSprinkler controller for MSR. It was real fun to code it - and while it's still WIP, it seems to work OK for me. It's polling-based at the moment, but I'll add support for updates via MQTT very soon (it's already partially coded). Get it at (install is similar to MQTTController and such): https://github.com/dbochicchio/reactor-opensprinkler Feel free to try it. It's beta software, but it's stable. I'll update it weekly until all the tasks from my todo list are empty. Since I've learnt a lot from this controller, I'll explore new controllers soon.
Multi-System Reactor
Advice reqeusted to migrate MSR from Bare Metal to Container
T
Good day all, I'm in the process of trying to shut down my 10 year old Linux home server that served many purposes, but primarily it's what I used for my NAS/Plex Media server. I migrated the NAS aspect of the server in November of last year to a true NAS solution (Ubiquti UNAS Pro), which is rack mount and much more efficient than my old tower, which it's only side benefit was heating my home office during the winter. Unfortunately it also means heating my home office during the summer, which were about to be in full swing. I have two things running on this 10 year old server at this point. MSR and pi-hole. I'm running Plex Media Server on Fedora Workstation in Podman on mini PC, which is much more energy efficient than my old tower. My next step is to migrate MSR. I know there are images of MSR out there, and creating it is well documented. I'm going to be using Podman instead of Docker for various reasons, but they work very similar. What I don't know, is what I need to do to migrate my existing Bare Metal installation over to a container. Has anyone done this? Any advice?
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
Can´t restart or upgrade/deploy MSR
F
Topic thumbnail image
Multi-System Reactor
[Solved] Limit HA Entity in MSR
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Organizing/ structuring rule sets and rules
R
Hi guys, Just wondering how you guys organize your rule sets and rules. I wish I had an extra layer to have some more granularity, but my feature request was not popular. Maybe there are better ways to organize my rule sets. I use the rule sets now primarily for rooms. So a rule set per room. But maybe grouping by functionality works better. Any examples/ suggestions would be appreciated.
Multi-System Reactor
Moving MSR from a QNAP container to RP 5 - some issues
Tom_DT
Topic thumbnail image
Multi-System Reactor
Widget deletion does not work and landing page (status) is empy
M
Topic thumbnail image
Multi-System Reactor
Need help reducing false positive notifications
T
Topic thumbnail image
Multi-System Reactor
Deleting widgets
tunnusT
Hopefully a trivial question, but how do you delete widgets in a status page? Using build 22266
Multi-System Reactor
MQTT configuration question
tunnusT
I have the following yaml configuration in local_mqtt_devices file x_mqtt_device: set_speed: arguments: speed: type: str topic: "command/%friendly_name%" payload: type: json expr: '{ "fan": parameters.speed }' While this works fine, I'm wondering how this could be changed to "fixed" parameters, as in this case "fan" only accepts "A", "Q" or a numeric value of 1-5?
Multi-System Reactor

[SOLVED] Random ghosting of lights when Away

Scheduled Pinned Locked Moved Multi-System Reactor
37 Posts 4 Posters 3.4k Views 5 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.
  • toggledbitsT toggledbits

    @toggledbits Here's a prototype for "Reactor Ex Machina"...

    Lights to be cycled are placed in a global expression like this:

    d8d23e46-153d-4e70-a20f-9c7f471f5cb1-image.png

    This is the "Cycler". It triggers when a variable it owns called cycler_stim changes (and is non-zero, which is the resting/deactivated state value).

    8f9e65fe-825a-416e-b49a-4e4c9ad30e02-image.png 1dce63c0-7534-4cf4-bd0f-21fc52e09646-image.png cc0b02e5-692f-4b21-8854-c3c5cf091a31-image.png

    When the cycler is "stimulated", it picks a random device from REM_lights and toggles it. Then it goes into a random delay between 10 and 30 minutes, after which it increments cycler_stim, effectively stimulating itself (for lack of a better description) and the cycle begins again.

    This is the "activate" rule. It determines when light cycling should start. It just sets cycler_stim to 1, and the Cycler will automatically start going.

    447a50c8-13c7-4873-b194-8220b70c3f6f-image.png

    This is the "deactivate" rule; it determines when cycling should stop. Depending on the complexity of your activate/deactivate rules, you could also do this in the reset reaction of Activate. It sets cycler_stim to 0 and turns off all the controlled lights.

    5a9655c1-afab-4a15-a6b5-242629f07e2a-image.png

    G Offline
    G Offline
    gwp1
    wrote on last edited by
    #23

    @toggledbits sanity check: shouldn't this equate 00:00:30 - 00:01:30 for cycling time? (Testing purposes.)

    79bf859b-879c-42de-b9c8-5373fc1ecb8e-image.png

    It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

    *Hubitat C-7 2.4.1.177
    *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

    *HASS 2025.6.0
    w/ ZST10-700 fw 7.18.3

    *Prod MSR in docker/portainer
    MSR: latest-25139-fbd67abc
    MQTTController: 25139
    ZWave Controller: 25139

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

      Good eye! I realized that after taking the screen shot, was too lazy at that moment to reshoot it, so I left it suspecting that it would be a while before someone caught on. You beat my estimate! I'll amend the post text to highlight the discrepancy in situ, but yes, what you see there are my "test" values, and you should set them according to whatever timing you wish.

      Edit: Mystery intensifies. It turns out my memory was incorrect, and I did go back and fix the screen shot. Capture below is what I am seeing in my post:

      c4f96e88-aac3-42af-9f08-15c144d8e601-image.png

      Notice the green "modified" bar on the left as well. So, I have no idea where that image you have is living right now, where you saw it. Is it possible we can see two different versions of the same post? That would be... unhelpful...

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

      G 1 Reply Last reply
      0
      • toggledbitsT toggledbits

        Good eye! I realized that after taking the screen shot, was too lazy at that moment to reshoot it, so I left it suspecting that it would be a while before someone caught on. You beat my estimate! I'll amend the post text to highlight the discrepancy in situ, but yes, what you see there are my "test" values, and you should set them according to whatever timing you wish.

        Edit: Mystery intensifies. It turns out my memory was incorrect, and I did go back and fix the screen shot. Capture below is what I am seeing in my post:

        c4f96e88-aac3-42af-9f08-15c144d8e601-image.png

        Notice the green "modified" bar on the left as well. So, I have no idea where that image you have is living right now, where you saw it. Is it possible we can see two different versions of the same post? That would be... unhelpful...

        G Offline
        G Offline
        gwp1
        wrote on last edited by gwp1
        #25

        @toggledbits This is on me for not being clear: the screenshot in my reply was of MY system - I wanted someone else's eyes on it as I've stared at it so long any obvious error will be lost to me at this point.

        If mine IS correct then this takes me back around to wondering what I've broken elsewhere in this that the cycler isn't kicking at no more than 1 1/2 minutes but, rather, taking 12 minutes.

        *Hubitat C-7 2.4.1.177
        *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

        *HASS 2025.6.0
        w/ ZST10-700 fw 7.18.3

        *Prod MSR in docker/portainer
        MSR: latest-25139-fbd67abc
        MQTTController: 25139
        ZWave Controller: 25139

        1 Reply Last reply
        1
        • G gwp1

          @toggledbits sanity check: shouldn't this equate 00:00:30 - 00:01:30 for cycling time? (Testing purposes.)

          79bf859b-879c-42de-b9c8-5373fc1ecb8e-image.png

          It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

          LibraSunL Offline
          LibraSunL Offline
          LibraSun
          wrote on last edited by LibraSun
          #26

          @gwp1 said in Random ghosting of lights when Away:

          It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

          Weird. From your screenshot, I definitely would have expected a Delay time of 00:30 to 01:30, not twelve minutes! And you're certain none of your Trigger conditions have a "Delay" or "Latch" or really long "Pulse" condition?

          FYI, in case it matters, where you increment your Cycle Timer by 1, if you don't want that number to grow indefinitely large over time, consider:

          ${{ (cycler_stim + 1) % 100 }}
          
          G toggledbitsT 2 Replies Last reply
          0
          • LibraSunL LibraSun

            @gwp1 said in Random ghosting of lights when Away:

            It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

            Weird. From your screenshot, I definitely would have expected a Delay time of 00:30 to 01:30, not twelve minutes! And you're certain none of your Trigger conditions have a "Delay" or "Latch" or really long "Pulse" condition?

            FYI, in case it matters, where you increment your Cycle Timer by 1, if you don't want that number to grow indefinitely large over time, consider:

            ${{ (cycler_stim + 1) % 100 }}
            
            G Offline
            G Offline
            gwp1
            wrote on last edited by
            #27

            @librasun No "delay", "latch", or "pulse" conditions. I'm not strong in expressions so my path forward is usually to emulate EXACTLY what the sample shows... then work backwards poking, editing (re: breaking) until I understand it better.

            *Hubitat C-7 2.4.1.177
            *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

            *HASS 2025.6.0
            w/ ZST10-700 fw 7.18.3

            *Prod MSR in docker/portainer
            MSR: latest-25139-fbd67abc
            MQTTController: 25139
            ZWave Controller: 25139

            LibraSunL 1 Reply Last reply
            1
            • G gwp1

              @librasun No "delay", "latch", or "pulse" conditions. I'm not strong in expressions so my path forward is usually to emulate EXACTLY what the sample shows... then work backwards poking, editing (re: breaking) until I understand it better.

              LibraSunL Offline
              LibraSunL Offline
              LibraSun
              wrote on last edited by
              #28

              @gwp1 Agreed. Smart approach! I should have notated on my example that the % operator stands for modulo which in MSR (as with most modern programming languages) yields the "remainder" after division by the whole number on the right side.

              Thus, this would have the effect of keeping your cycler_stim variable from ever growing past 99. Hardly important; you may even prefer it the way it current behaves, growing by 1 indefinitely (which acts as a sort of historical counter).

              G 1 Reply Last reply
              0
              • LibraSunL LibraSun

                @gwp1 Agreed. Smart approach! I should have notated on my example that the % operator stands for modulo which in MSR (as with most modern programming languages) yields the "remainder" after division by the whole number on the right side.

                Thus, this would have the effect of keeping your cycler_stim variable from ever growing past 99. Hardly important; you may even prefer it the way it current behaves, growing by 1 indefinitely (which acts as a sort of historical counter).

                G Offline
                G Offline
                gwp1
                wrote on last edited by
                #29

                @librasun I'm happy to share screenshots of the entire ruleset just in case I've missed something.

                *Hubitat C-7 2.4.1.177
                *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                *HASS 2025.6.0
                w/ ZST10-700 fw 7.18.3

                *Prod MSR in docker/portainer
                MSR: latest-25139-fbd67abc
                MQTTController: 25139
                ZWave Controller: 25139

                G 1 Reply Last reply
                0
                • LibraSunL LibraSun

                  @gwp1 said in Random ghosting of lights when Away:

                  It just took 00:12:00 to cycle and I've been staring at this 'til I'm cross-eyed.

                  Weird. From your screenshot, I definitely would have expected a Delay time of 00:30 to 01:30, not twelve minutes! And you're certain none of your Trigger conditions have a "Delay" or "Latch" or really long "Pulse" condition?

                  FYI, in case it matters, where you increment your Cycle Timer by 1, if you don't want that number to grow indefinitely large over time, consider:

                  ${{ (cycler_stim + 1) % 100 }}
                  
                  toggledbitsT Offline
                  toggledbitsT Offline
                  toggledbits
                  wrote on last edited by
                  #30

                  @librasun said in Random ghosting of lights when Away:

                  ${{ (cycler_stim + 1) % 100 }}

                  Careful here... this will produce a 0 after 100 iterations and stop cycling, because cycler_stim==0 is used as "not cycling/deactivated".

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

                  G 1 Reply Last reply
                  2
                  • toggledbitsT toggledbits

                    @librasun said in Random ghosting of lights when Away:

                    ${{ (cycler_stim + 1) % 100 }}

                    Careful here... this will produce a 0 after 100 iterations and stop cycling, because cycler_stim==0 is used as "not cycling/deactivated".

                    G Offline
                    G Offline
                    gwp1
                    wrote on last edited by
                    #31

                    @toggledbits Good catch. I wasn't going down this path any time soon - but - as I said, I poke at things I'm new at and prob would have at some point.

                    *Hubitat C-7 2.4.1.177
                    *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                    *HASS 2025.6.0
                    w/ ZST10-700 fw 7.18.3

                    *Prod MSR in docker/portainer
                    MSR: latest-25139-fbd67abc
                    MQTTController: 25139
                    ZWave Controller: 25139

                    1 Reply Last reply
                    0
                    • G gwp1

                      @librasun I'm happy to share screenshots of the entire ruleset just in case I've missed something.

                      G Offline
                      G Offline
                      gwp1
                      wrote on last edited by
                      #32

                      @gwp1
                      7c3b11af-d64a-4446-9d10-44af65d3276d-image.png

                      0201fd94-f2da-41c6-9b7d-ce588f766fbe-image.png a7743609-fb36-40e1-9963-ff210ae2b14c-image.png

                      961bd1c2-d7e6-4020-b397-d23607e4621f-image.png

                      *Hubitat C-7 2.4.1.177
                      *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                      *HASS 2025.6.0
                      w/ ZST10-700 fw 7.18.3

                      *Prod MSR in docker/portainer
                      MSR: latest-25139-fbd67abc
                      MQTTController: 25139
                      ZWave Controller: 25139

                      toggledbitsT 1 Reply Last reply
                      0
                      • G gwp1

                        @gwp1
                        7c3b11af-d64a-4446-9d10-44af65d3276d-image.png

                        0201fd94-f2da-41c6-9b7d-ce588f766fbe-image.png a7743609-fb36-40e1-9963-ff210ae2b14c-image.png

                        961bd1c2-d7e6-4020-b397-d23607e4621f-image.png

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

                        @gwp1 I was playing with this a bit more. Timing-wise it works fine for me but I did notice occasionally it would stall. This seems to be a race condition between the way the Set reaction's group executes vs the reevaluation of the Cycler rule. The purpose of the group is to stop cycling when deactivated, so we can do this differently and get rid of the race:

                        New "Deactivated":

                        84f6cca8-f3cc-4fc0-aabc-8eb24d3288e6-image.png

                        And then remove the Group from "Cycler" and do the "Set Variable" directly:

                        8ba3fd76-1da6-4dd8-b4e0-a8198b24d0a5-image.png


                        Detail of the problem/race: Groups in Reactions are queued as sub-reactions of the parent reaction. The parent blocks in the execution queue while the child group runs, and when the child group finishes, the parent is allowed to resume. But these are, in effect, two different threads of execution. As originally offered, the child thread can finish and the parent, having nothing more to do (since the child is the last thing), signals completion and is removed from the queue. The problem comes from the "Set Variable" requesting a re-evaluation inside the subgroup. Once the subgroup thread stops, it is likely, but not guaranteed, that the parent reaction will get control next; when it doesn't, it's the evaluation that occurs, and when this happens, it sees cycler_stim has changed and is non-zero, and tries to queue the Set reaction. But a reaction can only be queued once: if a reaction is already executing, it will not be queued again. So, the evaluation succeeds as expected, but can't queue the next run of Set reaction because the prior run, which is effectively at its end but hasn't declared itself finished yet, is still on the queue. So the new Set doesn't get queued because the old one is there. The old one, with nothing more to do, finally gets to execute again and declares itself finished, and at that point, no reactions are queued and the process stalls.

                        The fix: By making the stop of the Cycler Set reaction explicit, we ensure that it stops when needed and is removed from the queue. By removing the "Set Variable" from the group (and removing the group entirely), its update of cycler_stim is done in the main reaction thread, which finishes before the re-evaluation is allowed to begin, thus allowing the re-evaluation to queue the Set reaction again as it must.

                        It's worth noting that this is a side-effect of writing a rule and reaction that attempts to perpetuate itself, to run in an effectively infinite loop. In that, it works against some internal design choices meant to prevent such behaviors that might otherwise be "runaway" in normal circumstances.

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

                        G 1 Reply Last reply
                        0
                        • LibraSunL Offline
                          LibraSunL Offline
                          LibraSun
                          wrote on last edited by LibraSun
                          #34

                          One of the most tantalizing, yet ultimately frustrating, aspects of MSR is its potential use for "looping" of this exact type. I think by now we've all taken a stab at it (I know I have), but many of those attempts run into a wall which I call "chicken or the egg".

                          That is, on the one hand, you have to somehow "bootstrap" a looping Rule so that its Trigger conditions get it going ... but on the other hand, those conditions must not simply remain "true" or else the Rule will not loop at all. So the user is forced down one or more alleyways involving "pulse" or "interval" or revolving variable values, or -- as in this above example -- externally launching and un-launching the Rule from another rule. Whichever method you choose (I've tried them all, lol), there are potential stumbling blocks along the way.

                          Few, if any, users can "see" all of those prospective hazards ahead of time. MSR in some instances is designed to push back against looping: Do it too quickly, and throttling kicks in. Do it without careful synchronization, and child processes get tripped up (as has happened here). Do it with callous disregard for memory-hogging subroutines and you can bog the system down to a halt.

                          Ask me how I know. 🙂

                          By now, I think I've made every possible mistake one can make in MSR -- always my own fault -- and nearly every time I've botched a "looping Rule" I have had to fight the impulse to ask @toggledbits for a formalized "Loop" action within reactions. Like, "Why can't we have a DO..WHILE crutch here?"

                          Then I think, no, it's best we don't. Because (a) we're talking about a fairly advanced construct here, that (b) probably does not belong in the hands of beginning users, and (c) looping by its very nature stands at odds with an engine designed to carry out deterministic procedures in a synchronous, queued fashion.

                          NOTE: It's not coincidental that a Reaction's ability to directly re-run itself was removed early on in the development of MSR!

                          I know I'm waxing philosophical here. And I'm sure we'll all carry on crafting custom loops of one type or another -- from the simplest each/in enumerator with performAction() buried inside, to grandiose Rule A ► Rule B behemoths. For me, the fun of it will forever be the question of "How?"

                          G 1 Reply Last reply
                          0
                          • LibraSunL LibraSun

                            One of the most tantalizing, yet ultimately frustrating, aspects of MSR is its potential use for "looping" of this exact type. I think by now we've all taken a stab at it (I know I have), but many of those attempts run into a wall which I call "chicken or the egg".

                            That is, on the one hand, you have to somehow "bootstrap" a looping Rule so that its Trigger conditions get it going ... but on the other hand, those conditions must not simply remain "true" or else the Rule will not loop at all. So the user is forced down one or more alleyways involving "pulse" or "interval" or revolving variable values, or -- as in this above example -- externally launching and un-launching the Rule from another rule. Whichever method you choose (I've tried them all, lol), there are potential stumbling blocks along the way.

                            Few, if any, users can "see" all of those prospective hazards ahead of time. MSR in some instances is designed to push back against looping: Do it too quickly, and throttling kicks in. Do it without careful synchronization, and child processes get tripped up (as has happened here). Do it with callous disregard for memory-hogging subroutines and you can bog the system down to a halt.

                            Ask me how I know. 🙂

                            By now, I think I've made every possible mistake one can make in MSR -- always my own fault -- and nearly every time I've botched a "looping Rule" I have had to fight the impulse to ask @toggledbits for a formalized "Loop" action within reactions. Like, "Why can't we have a DO..WHILE crutch here?"

                            Then I think, no, it's best we don't. Because (a) we're talking about a fairly advanced construct here, that (b) probably does not belong in the hands of beginning users, and (c) looping by its very nature stands at odds with an engine designed to carry out deterministic procedures in a synchronous, queued fashion.

                            NOTE: It's not coincidental that a Reaction's ability to directly re-run itself was removed early on in the development of MSR!

                            I know I'm waxing philosophical here. And I'm sure we'll all carry on crafting custom loops of one type or another -- from the simplest each/in enumerator with performAction() buried inside, to grandiose Rule A ► Rule B behemoths. For me, the fun of it will forever be the question of "How?"

                            G Offline
                            G Offline
                            gwp1
                            wrote on last edited by
                            #35

                            @librasun And to think all this waxing philosophical is due to my silly ask to ghost lights in the house 🙂

                            Thank you both for you wisdom and infinite patience!

                            Thank you @toggledbits for not just providing a path but explaining the path so I (and others) can learn -- really appreciated.

                            *Hubitat C-7 2.4.1.177
                            *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                            *HASS 2025.6.0
                            w/ ZST10-700 fw 7.18.3

                            *Prod MSR in docker/portainer
                            MSR: latest-25139-fbd67abc
                            MQTTController: 25139
                            ZWave Controller: 25139

                            1 Reply Last reply
                            1
                            • toggledbitsT toggledbits

                              @gwp1 I was playing with this a bit more. Timing-wise it works fine for me but I did notice occasionally it would stall. This seems to be a race condition between the way the Set reaction's group executes vs the reevaluation of the Cycler rule. The purpose of the group is to stop cycling when deactivated, so we can do this differently and get rid of the race:

                              New "Deactivated":

                              84f6cca8-f3cc-4fc0-aabc-8eb24d3288e6-image.png

                              And then remove the Group from "Cycler" and do the "Set Variable" directly:

                              8ba3fd76-1da6-4dd8-b4e0-a8198b24d0a5-image.png


                              Detail of the problem/race: Groups in Reactions are queued as sub-reactions of the parent reaction. The parent blocks in the execution queue while the child group runs, and when the child group finishes, the parent is allowed to resume. But these are, in effect, two different threads of execution. As originally offered, the child thread can finish and the parent, having nothing more to do (since the child is the last thing), signals completion and is removed from the queue. The problem comes from the "Set Variable" requesting a re-evaluation inside the subgroup. Once the subgroup thread stops, it is likely, but not guaranteed, that the parent reaction will get control next; when it doesn't, it's the evaluation that occurs, and when this happens, it sees cycler_stim has changed and is non-zero, and tries to queue the Set reaction. But a reaction can only be queued once: if a reaction is already executing, it will not be queued again. So, the evaluation succeeds as expected, but can't queue the next run of Set reaction because the prior run, which is effectively at its end but hasn't declared itself finished yet, is still on the queue. So the new Set doesn't get queued because the old one is there. The old one, with nothing more to do, finally gets to execute again and declares itself finished, and at that point, no reactions are queued and the process stalls.

                              The fix: By making the stop of the Cycler Set reaction explicit, we ensure that it stops when needed and is removed from the queue. By removing the "Set Variable" from the group (and removing the group entirely), its update of cycler_stim is done in the main reaction thread, which finishes before the re-evaluation is allowed to begin, thus allowing the re-evaluation to queue the Set reaction again as it must.

                              It's worth noting that this is a side-effect of writing a rule and reaction that attempts to perpetuate itself, to run in an effectively infinite loop. In that, it works against some internal design choices meant to prevent such behaviors that might otherwise be "runaway" in normal circumstances.

                              G Offline
                              G Offline
                              gwp1
                              wrote on last edited by
                              #36

                              @toggledbits IT LIVES!! Set to 00:00:05 - 00:00:10 for testing and lights are cycling randomly as expected.

                              f2f07728-7a83-41e9-85e9-11d781b56d92-image.png

                              *Hubitat C-7 2.4.1.177
                              *Proxmox VE v8, Beelink MiniPC 12GBs, SSD

                              *HASS 2025.6.0
                              w/ ZST10-700 fw 7.18.3

                              *Prod MSR in docker/portainer
                              MSR: latest-25139-fbd67abc
                              MQTTController: 25139
                              ZWave Controller: 25139

                              1 Reply Last reply
                              1
                              • LibraSunL Offline
                                LibraSunL Offline
                                LibraSun
                                wrote on last edited by
                                #37

                                You, sir, are living the dream.

                                1 Reply Last reply
                                0
                                • toggledbitsT toggledbits locked this topic on
                                • G gwp1 referenced this topic on
                                • R retireditguy referenced this topic on
                                • K kellyjelly32 referenced this topic on
                                Reply
                                • Reply as topic
                                Log in to reply
                                • Oldest to Newest
                                • Newest to Oldest
                                • Most Votes


                                Recent Topics

                                • Gradually turn on lights.
                                  G
                                  gwp1
                                  0
                                  4
                                  94

                                • Stop the MSR by an external switch on Hubitat.
                                  wmarcolinW
                                  wmarcolin
                                  0
                                  1
                                  16

                                • Error After Upgrade
                                  G
                                  gwp1
                                  0
                                  4
                                  86

                                • Reset attribute value of entity in event handler
                                  R
                                  RHCPNG
                                  0
                                  5
                                  170

                                • Need help figuring out how to delay a reset on reaction
                                  G
                                  gwp1
                                  0
                                  22
                                  860

                                • Way to search for rules (rule state) in other rules
                                  T
                                  tamorgen
                                  0
                                  3
                                  92

                                • Links to MSR from HA
                                  Tom_DT
                                  Tom_D
                                  0
                                  1
                                  78

                                • Set Reaction > Script Action
                                  wmarcolinW
                                  wmarcolin
                                  0
                                  11
                                  419

                                • Wiring Samotech SM308-S into light fitting
                                  akbooerA
                                  akbooer
                                  0
                                  2
                                  136

                                • Errors after updating to MQTTController build 25139
                                  toggledbitsT
                                  toggledbits
                                  0
                                  6
                                  232

                                • 🎉 My very first MSR controller: OpenSprinkler
                                  therealdbT
                                  therealdb
                                  5
                                  13
                                  898

                                • Advice reqeusted to migrate MSR from Bare Metal to Container
                                  T
                                  tamorgen
                                  0
                                  5
                                  246
                                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