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. Help with Logic Routines SW1/SW2
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

Help with Logic Routines SW1/SW2

Scheduled Pinned Locked Moved Multi-System Reactor
9 Posts 3 Posters 670 Views 3 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.
  • wmarcolinW Offline
    wmarcolinW Offline
    wmarcolin
    wrote on last edited by
    #1

    Hi!

    I would like some help in developing a routine in MSR, in which I will describe the actual situation.

    I have a key on the dashboard of the HE (Switch_1), that, when put ON, should trigger a function in the air conditioning, for example, Fan in AUTOMATIC condition (Switch_2).

    So far, no problems.

    However, Switch_2 can be activated directly on the remote control of the air conditioner, which changes the Fan status from OFF to AUTOMATIC. When this happens, Switch_1, which was switched OFF, must be activated ON.

    Again no problem, the routine below makes it so that if you trigger Switch 1 OR Switch 2, the SET REACTION will align both to ON.

    I am not able to upload a screenshot, so I will describe it:

    TRIGGERS
    Entity Switch_1 is TRUE
    OR
    Entity Switch_2 is TRUE
    
    SETE REACTION
    Entity Action Switch 1 power_switch.on
    Entity Action Switch 2 power_switch.on
    
    RESET REACTION
    Entity Action Switch_1 power_switch.off
    Entity Action Switch_2 power_switch.off
    

    Well now let's get to the problem.

    We now have both switches in the ON state, i.e., whichever switch enters the ON state will turn the other one ON.

    The question now is to do the RESET. If we have an OR condition, it is not enough to just turn one switch OFF, because the other one will still be on and will not reset. For this to work then the condition should now be AND, i.e. if one of the two is turned OFF it will trigger the RESET.

    My attempts have been to use LATCH, but it actually makes it so that even if I turn OFF one switch, the routine will stay ON because the other switch is ON. I tried to make two groups, one with the OR condition and the other with the AND condition, in this case the master condition would be OR. I put LATCH in the groups, also without success.

    The easy way is to have two actions, one to turn on and one to turn off. But here I am asking for help to see if it is possible to do it in just one routine. Thanks.

    PS: does anyone know what happens that it is not possible to upload an image?

    1 Reply Last reply
    0
    • wmarcolinW Offline
      wmarcolinW Offline
      wmarcolin
      wrote on last edited by
      #2

      Hi Master @toggledbits 🙂
      Could you give some help here?
      Thanks

      toggledbitsT 1 Reply Last reply
      0
      • PablaP Offline
        PablaP Offline
        Pabla
        wrote on last edited by
        #3

        If I am understanding correctly you just need to switch the condition from OR to XOR. This will make it that the group goes true only if one or the other switches is true and will not go true if both switches are on.

        1 Reply Last reply
        0
        • wmarcolinW Offline
          wmarcolinW Offline
          wmarcolin
          wrote on last edited by
          #4

          Hola,
          The XOR doesn't work, it goes into a loop, generating the error message: is being throttled because it has changed...
          Thanks.

          1 Reply Last reply
          0
          • wmarcolinW Offline
            wmarcolinW Offline
            wmarcolin
            wrote on last edited by
            #5

            In theory what I am looking for is a "Latch" in reverse, that is, this functionality keeps the output true until the sibling is turned off as well. I think to turn off siblings if one is turned off.

            1 Reply Last reply
            0
            • wmarcolinW wmarcolin

              Hi Master @toggledbits 🙂
              Could you give some help here?
              Thanks

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

              @wmarcolin I think trying to make it a latch is both incorrect and misleading, making the problem harder than it really is. I think you're also painting yourself into a corner getting fixated on using a RESET reaction and making everything work in a single rule, as I often see people do. In practice, I very rarely use RESET myself. I have about 140 rules in my own home automation, and maybe 2-3 of them use RESET reactions. Usually the conditions under which I want to undo something that a rule does are much more complex and subtle than the conditions that triggered the change in the first place. This is often because operations in our home automation systems are not "atomic": everything happens in real time and we can never rely on the timing of a single operation or the timing of multiple operations in sequence; device status updates come from the hub with completely asynchronous and unpredictable timing (and no guarantee that they'll ever come). We have to account for this by structuring the automations accordingly.

              Keep it simple. When you want to do something, do it the simplest, most primitive, cave-man level way you can think of doing it, and break it down one step at a time.

              First, for this, eliminate the RESET reaction. The triggers and SET reaction are fine as you have them.

              The reset really needs to come from its own rule. While conceptually we might think that we can use the RESET reaction in one rule, because it's the anti-logic of the trigger (SET), that view doesn't consider the limitations of device communications with the hub and hub communications with MSR. Here's how I would do it:

              Rule #2 Triggers: -- OR --
                  Comment: Off coordination of Switch_1 and Switch_2
                  Group A: -- AND -- 
                      Comment: Detect 1 turned off while 2 is on
                      Switch_1 *changes* from TRUE to FALSE
                      Switch_2 is TRUE
                  Group B: -- AND --
                      Comment: Detect 2 turned off while 1 is on
                      Switch_1 is TRUE
                      Switch_2 *changes* from TRUE to FALSE
              Rule #2 SET Reaction:
                  Turn off Switch_2
                  Turn off Switch_1
              

              Note that since we're using changes, this rule will SET for milliseconds only, which is too fast to see in the UI. Unless you add a delay reset of a couple of seconds at the outer level, the only reliable way you'll know it's working is that both switches get turned off, but if you're watching the rule state (without delay) you're unlikely to notice that it triggered. If you use the delay, don't leave it in production as it will interfere with the logic if switches are changed rapidly; the delay is for debugging/test visibility only. Also, be sure to enter the words "true" and "false" as the operands for your changes operator -- that's important here.

              Once you have the cave-man implementation running, you can think about "optimizing" it. To which I'll ask, why? If it's simple, understandable, and working, what more do you need to achieve? Why chase some mythical perceived perfection in the artform of your rules when the simple thing you've done works perfectly and you will remember how it works 6 or 24 months later? If there are easy cleanups that don't complicate it, great, do those. But beyond that, the "tighter" you try to make the rule, the less likely you are to remember later how it works, the less likely you are to be successful troubleshooting it without the community's (or my) help, and, when you discover later "oh, I also need it to do X", the less likely you are to actually get that change to fit you're "perfect" implementation.

              I'm going to start recommending that, at least in the initial development of your rules, users never use RESET reactions. It's way too limited in its function, and people too easily get screwed into the ground trying to force themselves to use it. At a higher level view of that issue, the same goes for trying to fit everything that seems related into a single rule; Reactor isn't designed for that to be the case, and you shouldn't use it that way. R4V had elements of that, but it was a necessity due to limitations imposed by Vera, and it came at the high cost of people progressively building long, complex ReactorSensors that they then couldn't support themselves and relied on my help to troubleshoot; those Vera limitations don't apply to the MSR environment and its structure is different because of it.

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

              wmarcolinW 1 Reply Last reply
              0
              • PablaP Offline
                PablaP Offline
                Pabla
                wrote on last edited by Pabla
                #7

                I had a re-read of your logic and am a little confused. You mention that when switch_1 is turned on it turns on switch_2 which then sets your air conditioning fan to automatic. Where is the logic that sets your a/c fan to automatic? You currently have a loop in your logic.

                If basically what you are trying to create is a dummy switch that reflects the fan state of your a/c and allows you to control the fan state manually you're going to have to attack this differently.

                You will need two groups, the first group we will call the "Manual Fan Control" group the second will be "Fan Switch State". You will only need one switch in this case.

                "Manual Fan Control" Group
                
                Triggers: 
                
                First Subgroup: 
                Switch_1 == True
                AND
                Second Subgroup:
                Fan Switch State group == false
                  - Condition must occur after "First Subgroup"
                
                Set Reaction: 
                
                Sets a/c fan to automatic
                
                Reset Reaction:
                
                Sets a/c fan to off
                
                "Fan Switch State" Group 
                
                Triggers:
                First Subgroup: 
                Manual Fan Control Group == false
                AND
                Second Subgroup:
                A/C fan == automatic 
                  - Condition must occur after "First Subgroup"
                
                Set Reaction: 
                
                Set switch_1 to true
                
                Reset Reaction 
                
                Set switch_1 to false
                

                Its a little convoluted and untested so give it a try or give @toggledbits a try since his will likely work better than mine lol!!

                wmarcolinW 1 Reply Last reply
                0
                • toggledbitsT toggledbits

                  @wmarcolin I think trying to make it a latch is both incorrect and misleading, making the problem harder than it really is. I think you're also painting yourself into a corner getting fixated on using a RESET reaction and making everything work in a single rule, as I often see people do. In practice, I very rarely use RESET myself. I have about 140 rules in my own home automation, and maybe 2-3 of them use RESET reactions. Usually the conditions under which I want to undo something that a rule does are much more complex and subtle than the conditions that triggered the change in the first place. This is often because operations in our home automation systems are not "atomic": everything happens in real time and we can never rely on the timing of a single operation or the timing of multiple operations in sequence; device status updates come from the hub with completely asynchronous and unpredictable timing (and no guarantee that they'll ever come). We have to account for this by structuring the automations accordingly.

                  Keep it simple. When you want to do something, do it the simplest, most primitive, cave-man level way you can think of doing it, and break it down one step at a time.

                  First, for this, eliminate the RESET reaction. The triggers and SET reaction are fine as you have them.

                  The reset really needs to come from its own rule. While conceptually we might think that we can use the RESET reaction in one rule, because it's the anti-logic of the trigger (SET), that view doesn't consider the limitations of device communications with the hub and hub communications with MSR. Here's how I would do it:

                  Rule #2 Triggers: -- OR --
                      Comment: Off coordination of Switch_1 and Switch_2
                      Group A: -- AND -- 
                          Comment: Detect 1 turned off while 2 is on
                          Switch_1 *changes* from TRUE to FALSE
                          Switch_2 is TRUE
                      Group B: -- AND --
                          Comment: Detect 2 turned off while 1 is on
                          Switch_1 is TRUE
                          Switch_2 *changes* from TRUE to FALSE
                  Rule #2 SET Reaction:
                      Turn off Switch_2
                      Turn off Switch_1
                  

                  Note that since we're using changes, this rule will SET for milliseconds only, which is too fast to see in the UI. Unless you add a delay reset of a couple of seconds at the outer level, the only reliable way you'll know it's working is that both switches get turned off, but if you're watching the rule state (without delay) you're unlikely to notice that it triggered. If you use the delay, don't leave it in production as it will interfere with the logic if switches are changed rapidly; the delay is for debugging/test visibility only. Also, be sure to enter the words "true" and "false" as the operands for your changes operator -- that's important here.

                  Once you have the cave-man implementation running, you can think about "optimizing" it. To which I'll ask, why? If it's simple, understandable, and working, what more do you need to achieve? Why chase some mythical perceived perfection in the artform of your rules when the simple thing you've done works perfectly and you will remember how it works 6 or 24 months later? If there are easy cleanups that don't complicate it, great, do those. But beyond that, the "tighter" you try to make the rule, the less likely you are to remember later how it works, the less likely you are to be successful troubleshooting it without the community's (or my) help, and, when you discover later "oh, I also need it to do X", the less likely you are to actually get that change to fit you're "perfect" implementation.

                  I'm going to start recommending that, at least in the initial development of your rules, users never use RESET reactions. It's way too limited in its function, and people too easily get screwed into the ground trying to force themselves to use it. At a higher level view of that issue, the same goes for trying to fit everything that seems related into a single rule; Reactor isn't designed for that to be the case, and you shouldn't use it that way. R4V had elements of that, but it was a necessity due to limitations imposed by Vera, and it came at the high cost of people progressively building long, complex ReactorSensors that they then couldn't support themselves and relied on my help to troubleshoot; those Vera limitations don't apply to the MSR environment and its structure is different because of it.

                  wmarcolinW Offline
                  wmarcolinW Offline
                  wmarcolin
                  wrote on last edited by
                  #8

                  Hola my friend @toggledbits, long time without bothering you.

                  I try to make my rules as simple as possible, as you said cave-man mode.

                  What I was thinking, is that I really have many rules for the on condition, and I create a second one for the off condition. And the air conditioner example is a real situation, I have a rule for when the condition is turned on by the HE dashboard, external remote control or phone APP aligns all the statuses on, and a second rule when one of the three enters the off condition, realigns everything to off.

                  Let's say that the trigger condition is identically reversed sign, that's what I thought I was doing. As I said, in an on situation I use OR and in an off situation I use AND.

                  Anyway thank you for the enormous dedication in writing your argumentation, and I will follow with the cave rules, which work, are efficient and simpler to remember in two years 🙂

                  Thanks.

                  1 Reply Last reply
                  1
                  • PablaP Pabla

                    I had a re-read of your logic and am a little confused. You mention that when switch_1 is turned on it turns on switch_2 which then sets your air conditioning fan to automatic. Where is the logic that sets your a/c fan to automatic? You currently have a loop in your logic.

                    If basically what you are trying to create is a dummy switch that reflects the fan state of your a/c and allows you to control the fan state manually you're going to have to attack this differently.

                    You will need two groups, the first group we will call the "Manual Fan Control" group the second will be "Fan Switch State". You will only need one switch in this case.

                    "Manual Fan Control" Group
                    
                    Triggers: 
                    
                    First Subgroup: 
                    Switch_1 == True
                    AND
                    Second Subgroup:
                    Fan Switch State group == false
                      - Condition must occur after "First Subgroup"
                    
                    Set Reaction: 
                    
                    Sets a/c fan to automatic
                    
                    Reset Reaction:
                    
                    Sets a/c fan to off
                    
                    "Fan Switch State" Group 
                    
                    Triggers:
                    First Subgroup: 
                    Manual Fan Control Group == false
                    AND
                    Second Subgroup:
                    A/C fan == automatic 
                      - Condition must occur after "First Subgroup"
                    
                    Set Reaction: 
                    
                    Set switch_1 to true
                    
                    Reset Reaction 
                    
                    Set switch_1 to false
                    

                    Its a little convoluted and untested so give it a try or give @toggledbits a try since his will likely work better than mine lol!!

                    wmarcolinW Offline
                    wmarcolinW Offline
                    wmarcolin
                    wrote on last edited by
                    #9

                    Hi @Pabla 🙂

                    Thank you for your time, but let me try to better explain the situation I have using the air conditioner.

                    My equipment can be operated/command in three ways:

                    • Remote control, which basically each function just turns on and off (let's call it SW1);
                    • APP on the phone, which in this case knows the status of the device by WiFi integration / Samsung cloud (SW2);
                    • Or by the dashboard mounted on Hubitat (SW3).

                    I will detail the use case of the actions and impacts.

                    a. Turning on the a/c through the HE dashboard (SW3), the virtual button activates the Samsung integration drive, setting the mode ON, this integration with the cloud updates the status of the APP (SW2), but the remote control thinks it is off ( SW1), as it has no integration, but the air will be turned on and it will work normally.
                    b. Turning on the air through the APP (SW2), through the integration with HE, the status of the drive is modified, so my rule turns on the SW3, aligning the dashboard.
                    c. The same thing happens if you use the control (SW1), the Samsung cloud is triggered, it updates the APP status, and the HE drive with the status modification triggers the rule that turns on the SW3 virtual button. In this case, the control now knows that air is connected.

                    As you can see, I have a rule that when switching SW1 or SW2 or SW3, it will in ON ways inform the status change and align the 3 SW for all to be ON.

                    In the case of turning off, it is the opposite way, any of the 3 SW can turn off, and a second rule makes the alignment to put the 3 SW in an OFF state.

                    As our friend @toggledbits mentioned, cave-mode is the easiest, create two rules, one for each situation and everything works, that's what I have today.

                    My puzzle is that since one rule is the opposite of the other, I thought of trying to have just one, using the SET and RESET situation.

                    As I demonstrated, the SET is easy, because anyone with the OR condition solves, one that is triggered, turns it ON and puts all the others in the same status, now turning OFF is the complicated thing, because it changes the condition from OR to AND, that is, SW1 and SW2 and SW3 have to be ON to keep the device ON, if any of them turns OFF you have to turn OFF all the others.

                    Well let's to follow the cave-mode which is easier for now, in the future our genius @toggledbits maybe create a Latch in reverse 🙂

                    Thanks.

                    1 Reply Last reply
                    1
                    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
                      153

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

                    • Error After Upgrade
                      G
                      gwp1
                      0
                      4
                      107

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

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

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

                    • Links to MSR from HA
                      Tom_DT
                      Tom_D
                      0
                      1
                      96

                    • Set Reaction > Script Action
                      wmarcolinW
                      wmarcolin
                      0
                      11
                      444

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

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

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

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