Help with Logic Routines SW1/SW2
-
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.offWell 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?
-
Hi Master @toggledbits
Could you give some help here?
Thanks@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_1Note 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.
-
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 falseIts a little convoluted and untested so give it a try or give @toggledbits a try since his will likely work better than mine lol!!
-
@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_1Note 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.
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.
-
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 falseIts a little convoluted and untested so give it a try or give @toggledbits a try since his will likely work better than mine lol!!
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.
