Control all lights from all switches
I have three outdoor lights, one over each entrance to the house, each controlled by its own switch. Behind each of these switches I installed a Micro Smart Energy Switch from Aeon Labs. Now I want to create a rule (or several rules) that if I flick one of the switches all other soon follows.
I tried a couple of rules but I always run into a race between the switches (one is in off state that tells the other to turn off and at the same time another switch is in on state that tells the others to turn on) that makes the switches turn on and off creating a psychedelic disco for the neighbours.
Is there a easy way solve this? Bonus points if the solution doesn't include lots of "waits".
If there is a way to distinguish between user changing a switch and the rules changing them I could solve it myself but the switches I bought doesn't seem to have that feature, or?
I like this idea 
Okey, this is my try to solve this race / disco puzzle.
Disclaimer: There is probably a "Zipato" or a "z-wave" way of doing this. I have a very basic understanding of the rules engine and of z-wave in general.
So, the solution has two parts; 1) only accept one(ish) user input and 2) wait for all switches to settle.
We begin with the first part only accepting one user input (not exactly true since there isn't a good concept of synchronisation AFAIK). For this I use a outdoorsync variable, when this variable is set to 0 switch changes are accepted otherwise not.
So, if we get changes on any of the switches (one rule for each switch), check if we are allowed to change the virtual device "Utelampor" (outdoor lights). If we are we set the outdoorsync variable to 1 (making sure that nobody else changes the global state/virtual device).
The next step is the rule that acts on the virtual device "Utelampor" (this rule will reset outdoorsync). This rule will try and wait for all switches to settle but having as short period of manual switch downtime as possible:
(Found a error in the above picture; the last "set variable" should of course set the outdoorsync variable to 0.)
So, if we are supposed to turn on the lights ("Utelampor ON") all three switches should be in ON state, otherwise run the scene that turns on the lights and wait, refresh and retry (10 times). Same for the OFF scenario.
In the end, if no steady state have occurred during ~10 seconds just reset oudoorsync and give up.
Caveats: If you happen to change a switch after checking that all switches are in the same correct state but before resetting the outdoorsync you could end up in an inconsistent state.
At least this works for me now but I'm sure that it contains lots of bugs. If you have some easier way of doing the same please let me know!
Okey, this is my try to solve this race / disco puzzle.
Disclaimer: There is probably a "Zipato" or a "z-wave" way of doing this. I have a very basic understanding of the rules engine and of z-wave in general.
So, the solution has two parts; 1) only accept one(ish) user input and 2) wait for all switches to settle.
We begin with the first part only accepting one user input (not exactly true since there isn't a good concept of synchronisation AFAIK). For this I use a outdoorsync variable, when this variable is set to 0 switch changes are accepted otherwise not.
So, if we get changes on any of the switches (one rule for each switch), check if we are allowed to change the virtual device "Utelampor" (outdoor lights). If we are we set the outdoorsync variable to 1 (making sure that nobody else changes the global state/virtual device).
The next step is the rule that acts on the virtual device "Utelampor" (this rule will reset outdoorsync). This rule will try and wait for all switches to settle but having as short period of manual switch downtime as possible:
(Found a error in the above picture; the last "set variable" should of course set the outdoorsync variable to 0.)
So, if we are supposed to turn on the lights ("Utelampor ON") all three switches should be in ON state, otherwise run the scene that turns on the lights and wait, refresh and retry (10 times). Same for the OFF scenario.
In the end, if no steady state have occurred during ~10 seconds just reset oudoorsync and give up.
Caveats: If you happen to change a switch after checking that all switches are in the same correct state but before resetting the outdoorsync you could end up in an inconsistent state.
At least this works for me now but I'm sure that it contains lots of bugs. If you have some easier way of doing the same please let me know!
I have the same question as you.
Also I want to be abel to toggle dimmer lights on and off, Fibaro dimmer and Qubino Dimmer!
I have the same question as you.
Also I want to be abel to toggle dimmer lights on and off, Fibaro dimmer and Qubino Dimmer!
The race is exactly as you described. You cannot assotiate more then 2 switches to each other as this will happen. A maximum of 2 switches can be associated to each other as you assotiate the 1St switch to theb2nd and then the 2ND switch to the 1St. If you assotiate more, this disco will happen.
The race is exactly as you described. You cannot assotiate more then 2 switches to each other as this will happen. A maximum of 2 switches can be associated to each other as you assotiate the 1St switch to theb2nd and then the 2ND switch to the 1St. If you assotiate more, this disco will happen.
Post your rules. BTW, there might be a slight lag in switching, and therefore you cannot fast flick the switch, as the system will not be able to cope with the quick change.
I have a simple rule (cannot post as I'm on mobile right now) that when switching a noon wall switch, 2different light switch on or off. Inside the siren there is an if,else puzzle.
Post your rules. BTW, there might be a slight lag in switching, and therefore you cannot fast flick the switch, as the system will not be able to cope with the quick change.
I have a simple rule (cannot post as I'm on mobile right now) that when switching a noon wall switch, 2different light switch on or off. Inside the siren there is an if,else puzzle.
I would suggest 3 rules each for one light switch. Or perhaps put everything in one rule and use the join statement.
I would suggest 3 rules each for one light switch. Or perhaps put everything in one rule and use the join statement.
Why is there so much lag at the moment from inputs to the Zipabox?
And the strange thing is that my Fibaro double relay works perfect no delay at all. This was one of the first rules I made.
By the way I have created a ticket for this about a week ago, but no solution to the problem from Zipato.
A couple of months ago Zipato solved my Schneider switch and 433mHz BOUF Blind. The results was amazingly fast!
See this clip: https://www.youtube.com/watch?v=cymbhvLsYM4
You can clearly see that the lag is less than a second. And the little lag that is present is probably because of the 433mHz.
This worked with the latest beta 11 may 2016.
I have not used this button at all just for test 11 of may, and a few weeks ago I wanted to use this button for my blinds and Hue lights in the bedroom. I was shocked when I discovered that the switch or the reaction from the box took over 3-4 seconds.
See clip: https://www.youtube.com/watch?v=9jMjYXSt1U8
What have happened since then? And why does the Fibaro double relay works fast?
Also I see a big problem when controlling lights that not all lights have toggle function?
As I see it you also need to be able to set a switch to Monostable or bistable.
And in your case you need to have all the switches as monostable and you need all lights to have toggle function.
This means that if you create a rule. You need to use the any command which means if any of the two states "on" or "off" will trigger the rule, and that the lights toggle every time any of the states is reached.
Am I right?
But every thing with light control is very complex with Zipato and should be esy!
Why is there so much lag at the moment from inputs to the Zipabox?
And the strange thing is that my Fibaro double relay works perfect no delay at all. This was one of the first rules I made.
By the way I have created a ticket for this about a week ago, but no solution to the problem from Zipato.
A couple of months ago Zipato solved my Schneider switch and 433mHz BOUF Blind. The results was amazingly fast!
See this clip: https://www.youtube.com/watch?v=cymbhvLsYM4
You can clearly see that the lag is less than a second. And the little lag that is present is probably because of the 433mHz.
This worked with the latest beta 11 may 2016.
I have not used this button at all just for test 11 of may, and a few weeks ago I wanted to use this button for my blinds and Hue lights in the bedroom. I was shocked when I discovered that the switch or the reaction from the box took over 3-4 seconds.
See clip: https://www.youtube.com/watch?v=9jMjYXSt1U8
What have happened since then? And why does the Fibaro double relay works fast?
Also I see a big problem when controlling lights that not all lights have toggle function?
As I see it you also need to be able to set a switch to Monostable or bistable.
And in your case you need to have all the switches as monostable and you need all lights to have toggle function.
This means that if you create a rule. You need to use the any command which means if any of the two states "on" or "off" will trigger the rule, and that the lights toggle every time any of the states is reached.
Am I right?
But every thing with light control is very complex with Zipato and should be esy!
hi david i'm a little lost on exactly what you need to achieve. I have attached a rule that would trigger all lights to the state of one switch change. But this will not have any affect on your phyical switch position if this is what you mean. Do you mean you need the switch posistion to stay constant in a 2 position switch?
hi david i'm a little lost on exactly what you need to achieve. I have attached a rule that would trigger all lights to the state of one switch change. But this will not have any affect on your phyical switch position if this is what you mean. Do you mean you need the switch posistion to stay constant in a 2 position switch?
David,
I don't know if you found a solution to your problem, but as one of my installations have several Aeon Micro Smart Energy Switches, with the direct control leads wired to the old toggle switch, I set out to find a way to make the following scenario work:
If/when someone flicks any of the physical light switches connected directly to any of the Aeon Micro Smart Energy Switches, the other several Aeon devices should switch on or off accordingly so that all lights are syncronized ON or OFF.
Enclosed is the rule I created, which works 100%. I use one of these for each switch; the only difference between Rule1, Rule2, Rule3 etc., are the actuators/sensors specified.
Additionally, I have created two scenes; one where the lights controled by the Aeon swicthes are ON, another where the lights are OFF.
The rules cause the lights to become syncronized. If you need to filter out light on/off from other sources than the physical direct switch in order to still have the possibility of controling the lights individually, you can use an extra global variable to do so which is set elsewhere and can cause these rules to ignore status changes.
Here's a short explanation of the reasoning behind the rule described:
Firstly, I don't want the switches to have more than one ON or OFF; I don't want to flood the system with unneccesary events. I thus don't want to send ON or OFF when I don't need to. In order to avoid this, I maintain a global variable containing the Current Status of the light group. The rules test to see if the event which triggered the rule requires the Current Status to change. If so, it runs the appropriate scene, and sets the new Current Status.
If you've already found a solution, I'd definitely like to hear about it, as I am curious as to which approach you took and how it worked out for you.
Best regards,
Robert
David,
I don't know if you found a solution to your problem, but as one of my installations have several Aeon Micro Smart Energy Switches, with the direct control leads wired to the old toggle switch, I set out to find a way to make the following scenario work:
If/when someone flicks any of the physical light switches connected directly to any of the Aeon Micro Smart Energy Switches, the other several Aeon devices should switch on or off accordingly so that all lights are syncronized ON or OFF.
Enclosed is the rule I created, which works 100%. I use one of these for each switch; the only difference between Rule1, Rule2, Rule3 etc., are the actuators/sensors specified.
Additionally, I have created two scenes; one where the lights controled by the Aeon swicthes are ON, another where the lights are OFF.
The rules cause the lights to become syncronized. If you need to filter out light on/off from other sources than the physical direct switch in order to still have the possibility of controling the lights individually, you can use an extra global variable to do so which is set elsewhere and can cause these rules to ignore status changes.
Here's a short explanation of the reasoning behind the rule described:
Firstly, I don't want the switches to have more than one ON or OFF; I don't want to flood the system with unneccesary events. I thus don't want to send ON or OFF when I don't need to. In order to avoid this, I maintain a global variable containing the Current Status of the light group. The rules test to see if the event which triggered the rule requires the Current Status to change. If so, it runs the appropriate scene, and sets the new Current Status.
If you've already found a solution, I'd definitely like to hear about it, as I am curious as to which approach you took and how it worked out for you.
Best regards,
Robert
(David, do I get the Bonus Points for not having "Wait" anywhere?) <VBG>
(David, do I get the Bonus Points for not having "Wait" anywhere?) <VBG>
My god Robert that is advanced. What is the advantage of using this compared to my rules?
My god Robert that is advanced. What is the advantage of using this compared to my rules?
Jacob,
Thanks for the nice comment.
While I haven't tested your rules on the Zipabox, they seem to be recursive, i.e. one rule causes the other to set off events which cause the other rule to set off events which causes the first rule to set off events which cause... and so on. This is what I have tried to avoid by maintaining a global status variable... :-)
Brgds
Robert
Jacob,
Thanks for the nice comment.
While I haven't tested your rules on the Zipabox, they seem to be recursive, i.e. one rule causes the other to set off events which cause the other rule to set off events which causes the first rule to set off events which cause... and so on. This is what I have tried to avoid by maintaining a global status variable... :-)
Brgds
Robert
But does it not run the rule once. If the state of the switch changes or if the dimmer level goes under 1% or, ok the dimmer rule I can imagine is in a loop.
Regards Jacob!
But does it not run the rule once. If the state of the switch changes or if the dimmer level goes under 1% or, ok the dimmer rule I can imagine is in a loop.
Regards Jacob!
You say it in the by-line, you avoid the whole synchronisation problem that I talk about by maintaining the light state in memory thus suppressing the changes that makes the disco! :)
And yes, you do get bonus points for not using waits. :D
Some questions; why use two variables? And what happens if one light gets out of sync with the zipabox "memory" (if I turn off the out-of-sync light it will turn on again)?
You say it in the by-line, you avoid the whole synchronisation problem that I talk about by maintaining the light state in memory thus suppressing the changes that makes the disco! :)
And yes, you do get bonus points for not using waits. :D
Some questions; why use two variables? And what happens if one light gets out of sync with the zipabox "memory" (if I turn off the out-of-sync light it will turn on again)?
David,
The "newlightstate" variable is a leftover from the debug phase where I needed variables in PUSH messages to understand what was actually going on. Cleaning it up, I definitely agree to abolish the excess variable and simply test for the state of the sensor.
The reason why I add a numeric One to the return value of the sensor is because it returns a logic/bolean True or False and I want to force it to become a true numeric. Afaik, these True and False values can't be used for anything in the current iteration of the Zipabox kernel: You cannot test if something is TRUE or FALSE using [IF <variable>]. These bolean values display as "true" or "false" in messages etc, but they do seem to be cast to integer when used, and since I specifically wanted to have a "known" state where Zero means Not Initialized, I decided to add +1 so I know that a 1 means lights are correctly set to Off and 2 means Lights On.
I really cannot see how any of the lights can become unsyncronized unless the rule is changed to allow this: Any event relating to the lights would cause the lights to syncronize :-)
David,
The "newlightstate" variable is a leftover from the debug phase where I needed variables in PUSH messages to understand what was actually going on. Cleaning it up, I definitely agree to abolish the excess variable and simply test for the state of the sensor.
The reason why I add a numeric One to the return value of the sensor is because it returns a logic/bolean True or False and I want to force it to become a true numeric. Afaik, these True and False values can't be used for anything in the current iteration of the Zipabox kernel: You cannot test if something is TRUE or FALSE using [IF <variable>]. These bolean values display as "true" or "false" in messages etc, but they do seem to be cast to integer when used, and since I specifically wanted to have a "known" state where Zero means Not Initialized, I decided to add +1 so I know that a 1 means lights are correctly set to Off and 2 means Lights On.
I really cannot see how any of the lights can become unsyncronized unless the rule is changed to allow this: Any event relating to the lights would cause the lights to syncronize :-)
hi david, not sure if you are able to test this, but I created another rule and would appreciate it if you could test it for me. Sorry I haven't been on for a while to help, but David had it sorted by the look of it.
The rule I have here uses a virtual switch ("relay") to trigger the group of "said" lights, I was wondering if by using the virtual switch this would stop the re-trigger of switches.
If you can, let me know if it works
hi david, not sure if you are able to test this, but I created another rule and would appreciate it if you could test it for me. Sorry I haven't been on for a while to help, but David had it sorted by the look of it.
The rule I have here uses a virtual switch ("relay") to trigger the group of "said" lights, I was wondering if by using the virtual switch this would stop the re-trigger of switches.
If you can, let me know if it works
Tested it but the lights just turn of! What did I do wrong?
Should i use ACTION event or CONTROL even or Attribute? Best regards!
Tested it but the lights just turn of! What did I do wrong?
Should i use ACTION event or CONTROL even or Attribute? Best regards!
Jacob,
I don't see a problem with what you want to do. You will, however, want to use global variables and virtual devices. Create one rule per switch where you trap button actions and increase/decrease values in virtual devices which in turn control dimmers. In case some lights need individual percentages to achieve same light level as others, use variables to factor the differences.
Best regards,
Robert
Jacob,
I don't see a problem with what you want to do. You will, however, want to use global variables and virtual devices. Create one rule per switch where you trap button actions and increase/decrease values in virtual devices which in turn control dimmers. In case some lights need individual percentages to achieve same light level as others, use variables to factor the differences.
Best regards,
Robert
I will try but I have some server issus at the moment! Does my.zipato work for you?
I will try but I have some server issus at the moment! Does my.zipato work for you?
There are server issues right now: I got some weird error messages when saving messages for rules, so there is something going on. I bet ZipaTech have server monitoring and are working to fix the problem.
There are server issues right now: I got some weird error messages when saving messages for rules, so there is something going on. I bet ZipaTech have server monitoring and are working to fix the problem.
Robert, I spoke too soon. :(
Your rule didn't work for me, I goes into oscillation disco too (if me and my 4 year old kid hammer the two of the switches for a while :) ). Maybe I screwed something up along the way but I don't understand how I would work.
Just walk me through this scenario, I have three switches, so I create the three rules. Me and my kid randomly gets the state into this configuration:
light_state = off, switch 1: on, switch 2 off, switch 3: on, rules running r1 and r2
- r1 executes tells the system to turn on its lights (state off and my switch is on)
- r2 executes shortly after telling the system to turn off its lights (state is now on and my switch is off)
This gives rise of at least 3 state changes that triggers the rules once again, the state of the switches are unknown at the moment since the scene on/off is done asynchronous, so I just make up a scenario here (just like I did before :) ):
light_state = off, switch 1: off, switch 2 on, switch 3: off, rules running r1, r2 and r3
- r1 executes but has nothing to do
- r2 executes and turns on the lights
- r3 executes and turns off the lights
Of course rules triggers randomly and due to the fact that rules can be paused by any other rule at any time makes this really hard.
I had to write a solution with some code before I tried it in the rules engine, it works without disco and with hammering. It has two features that makes it interesting, a sync flag that tries to make the rule execute only once and a stabilize routine that waits for the rest of the switches to be set. But it's ugly and way too complicated so I will try to make it simpler tomorrow.
Robert, I spoke too soon. :(
Your rule didn't work for me, I goes into oscillation disco too (if me and my 4 year old kid hammer the two of the switches for a while :) ). Maybe I screwed something up along the way but I don't understand how I would work.
Just walk me through this scenario, I have three switches, so I create the three rules. Me and my kid randomly gets the state into this configuration:
light_state = off, switch 1: on, switch 2 off, switch 3: on, rules running r1 and r2
- r1 executes tells the system to turn on its lights (state off and my switch is on)
- r2 executes shortly after telling the system to turn off its lights (state is now on and my switch is off)
This gives rise of at least 3 state changes that triggers the rules once again, the state of the switches are unknown at the moment since the scene on/off is done asynchronous, so I just make up a scenario here (just like I did before :) ):
light_state = off, switch 1: off, switch 2 on, switch 3: off, rules running r1, r2 and r3
- r1 executes but has nothing to do
- r2 executes and turns on the lights
- r3 executes and turns off the lights
Of course rules triggers randomly and due to the fact that rules can be paused by any other rule at any time makes this really hard.
I had to write a solution with some code before I tried it in the rules engine, it works without disco and with hammering. It has two features that makes it interesting, a sync flag that tries to make the rule execute only once and a stabilize routine that waits for the rest of the switches to be set. But it's ugly and way too complicated so I will try to make it simpler tomorrow.
But are you using "by stable" of "mono stable" switches? (Spring return)
But are you using "by stable" of "mono stable" switches? (Spring return)
David it s quiet important to know how the hardware of your switch is configuerd and how the settings on the device is set!
David it s quiet important to know how the hardware of your switch is configuerd and how the settings on the device is set!
David,
The rule works just fine. The reason why you go onto "ocsillation mode" when you and your four-year-old are hammering on/off simultaneously and for some time, is that you're filling up the event queue and the wireless signalling queue in the Zipabox and your network faster than the rules can handle them. This causes the on/off commands to be stacked up.
This can probably be fixed by putting a JOIN at the start and possibly a WAIT at the bottom of the rules. I'll test locally and let you know.
I am sorry I did't see this coming. I probably should have included a disclaimer in my post, similar to that in the enclosed pix.
Brgds Robert
David,
The rule works just fine. The reason why you go onto "ocsillation mode" when you and your four-year-old are hammering on/off simultaneously and for some time, is that you're filling up the event queue and the wireless signalling queue in the Zipabox and your network faster than the rules can handle them. This causes the on/off commands to be stacked up.
This can probably be fixed by putting a JOIN at the start and possibly a WAIT at the bottom of the rules. I'll test locally and let you know.
I am sorry I did't see this coming. I probably should have included a disclaimer in my post, similar to that in the enclosed pix.
Brgds Robert
Okey, this is my try to solve this race / disco puzzle.
Disclaimer: There is probably a "Zipato" or a "z-wave" way of doing this. I have a very basic understanding of the rules engine and of z-wave in general.
So, the solution has two parts; 1) only accept one(ish) user input and 2) wait for all switches to settle.
We begin with the first part only accepting one user input (not exactly true since there isn't a good concept of synchronisation AFAIK). For this I use a outdoorsync variable, when this variable is set to 0 switch changes are accepted otherwise not.
So, if we get changes on any of the switches (one rule for each switch), check if we are allowed to change the virtual device "Utelampor" (outdoor lights). If we are we set the outdoorsync variable to 1 (making sure that nobody else changes the global state/virtual device).
The next step is the rule that acts on the virtual device "Utelampor" (this rule will reset outdoorsync). This rule will try and wait for all switches to settle but having as short period of manual switch downtime as possible:
(Found a error in the above picture; the last "set variable" should of course set the outdoorsync variable to 0.)
So, if we are supposed to turn on the lights ("Utelampor ON") all three switches should be in ON state, otherwise run the scene that turns on the lights and wait, refresh and retry (10 times). Same for the OFF scenario.
In the end, if no steady state have occurred during ~10 seconds just reset oudoorsync and give up.
Caveats: If you happen to change a switch after checking that all switches are in the same correct state but before resetting the outdoorsync you could end up in an inconsistent state.
At least this works for me now but I'm sure that it contains lots of bugs. If you have some easier way of doing the same please let me know!
Okey, this is my try to solve this race / disco puzzle.
Disclaimer: There is probably a "Zipato" or a "z-wave" way of doing this. I have a very basic understanding of the rules engine and of z-wave in general.
So, the solution has two parts; 1) only accept one(ish) user input and 2) wait for all switches to settle.
We begin with the first part only accepting one user input (not exactly true since there isn't a good concept of synchronisation AFAIK). For this I use a outdoorsync variable, when this variable is set to 0 switch changes are accepted otherwise not.
So, if we get changes on any of the switches (one rule for each switch), check if we are allowed to change the virtual device "Utelampor" (outdoor lights). If we are we set the outdoorsync variable to 1 (making sure that nobody else changes the global state/virtual device).
The next step is the rule that acts on the virtual device "Utelampor" (this rule will reset outdoorsync). This rule will try and wait for all switches to settle but having as short period of manual switch downtime as possible:
(Found a error in the above picture; the last "set variable" should of course set the outdoorsync variable to 0.)
So, if we are supposed to turn on the lights ("Utelampor ON") all three switches should be in ON state, otherwise run the scene that turns on the lights and wait, refresh and retry (10 times). Same for the OFF scenario.
In the end, if no steady state have occurred during ~10 seconds just reset oudoorsync and give up.
Caveats: If you happen to change a switch after checking that all switches are in the same correct state but before resetting the outdoorsync you could end up in an inconsistent state.
At least this works for me now but I'm sure that it contains lots of bugs. If you have some easier way of doing the same please let me know!
What about:
- creating a group 'Outdoor Lights' for the 3 lights you want to turn on.
- creating a virtual switch 'Outdoor Switch'.
- have a rule that is triggered by the virtual Outdoor Switch to turn the group 'Outdoor Lights' on/off accordingly
- foreach of your Aeon Switch, have a rule that change the state of the 'Outdoor Switch' acccordingly (in my ex Switch ON/Off2)
What about:
- creating a group 'Outdoor Lights' for the 3 lights you want to turn on.
- creating a virtual switch 'Outdoor Switch'.
- have a rule that is triggered by the virtual Outdoor Switch to turn the group 'Outdoor Lights' on/off accordingly
- foreach of your Aeon Switch, have a rule that change the state of the 'Outdoor Switch' acccordingly (in my ex Switch ON/Off2)
Replies have been locked on this page!