How do You realize the situation when two z-wave switches imitate cross switches? (for example stair switches). When I wrote a simple rule, the switches looped and I had a disco 
I have this situation, but only one switch is the real actor (connected to the light and actually switching it) and the second switch is just a trigger.
I have a rule for the triggerswitch which fires whenever the triggerswitch state changes. The rule then checks if the actorswitch is on or off - and switches it to the other state:
//Regel Schalten Treppenlicht oben von Flur unten
rule "SW_EING_S1"
when
Item SW_EING_S1 changed
then
if (SW_TREP_SO.state == ON )
{
sendCommand(SW_TREP_SO, OFF)
}
else
{
sendCommand(SW_TREP_SO, ON)
}
end
In this rule from my installation SW_EING_S1 is the triggerswitch and SW_TREP_SO ist the actor switch connected to the light.
1 Like
First: Thank You for help.
Second: In my situation only one switch is the real actor too, and the second switch is just a trigger, but… I forgot to mention: I have touch switches with a light indicator. For this reason, I need a rule that will also move light indication from actor swich (connected to the light) to trigger switch (the blind one).
So … when I wrote second rule with opposite direction… discotheque… 
To solve this, I think you will first need to log a bit of traffic when operating the two switches to understand what type of events that are generated in OpenHAB, e.g. are they sending commands and/or state updates.
Then based on this knowledge, hopefully, you can make something work with clever use of dfferent trigger conditons in you rules, e.g. trigger on received commands and/or state updates.
This is a tough one and it will be very difficult to solve without sitting in your environment and experimenting. Some initial thoughts include:
-
Put a latch on your rule that processes the ON/OFF commands from the two Items configured so it ignores the command caused when you send the command to the other switch to update its light
-
Use a timestamp or persistence to ignore any commands that occur too soon after one has been processed (like a latch but using a timestamp)
-
Add logic to your rule to ignore any commands received that put the two switches into the same state. For example, in the default state both switches are in the same state. You touch one to turn on the light which triggers a rule. The rule now sees that the two switches are in different states so it sends the command to the OFF switch to turn ON. This second command triggers the rule again but now both switches are in the same state so ignore the command.
This last idea is probably the “correct” one.
I’ve spent a lot of time in order to create working rule for three and two different switches. I used third idea proposed by rlkoshak. I couldn’t find ready to use solution in community. I would like to share my solution with hope I will help someone.
Solution for three switches:
Items:
Switch GF_Porch_Light1 "Light 1 Porch" <light> (GF_Porch, gLight) ["Lighting", "Switchable"] {channel="mqtt:topic:sonoffbridge:wiatrolap-p1"}
Switch GF_LivingRoom_Light1 "Porch LR" <light> (GF_LivingRoom, gLight) ["Lighting", "Switchable"] {channel="mqtt:topic:sonoffbridge:przedpokoj-dol-p1"}
Switch GF_Garage_Light3 "Porch Garage" <light> (GF_Garage, gLight) ["Lighting", "Switchable"] {channel="mqtt:topic:sonoffbridge:garaz-p3"}
Rule:
rule livinigroomPorchMAINchange
when
Item GF_LivingRoom_Light1 changed
then
if (GF_LivingRoom_Light1.state != newState) { GF_LivingRoom_Light1.sendCommand(newState) }
if (GF_Porch_Light1.state != newState) { GF_Porch_Light1.sendCommand(newState) }
if (GF_Garage_Light3.state != newState) { GF_Garage_Light3.sendCommand(newState) }
end
rule porchChange
when
Item GF_Porch_Light1 changed
then
if (GF_LivingRoom_Light1.state != newState) { GF_LivingRoom_Light1.sendCommand(newState) }
end
rule garageChange
when
Item GF_Garage_Light3 changed
then
if (GF_LivingRoom_Light1.state != newState) { GF_LivingRoom_Light1.sendCommand(newState) }
end
Example for two switches:
Items:
Switch FF_Hol_Light1 "Stairs" <light> (FF_Hol, gLight) ["Lighting", "Switchable"] {channel="mqtt:topic:sonoffbridge:przedpokoj-gora-p1"}
Switch GF_Stairs_Light1 "Stairs" <light> (GF_Stairs, gLight) ["Lighting", "Switchable"] {channel="mqtt:topic:sonoffbridge:schody-dol-p1"}
Rule:
rule stairsMain
when
Item FF_Hol_Light1 changed
then
if (FF_Hol_Light1.state != newState) { FF_Hol_Light1.sendCommand(newState) }
if (GF_Stairs_Light1.state != newState) { GF_Stairs_Light1.sendCommand(newState) }
end
rule downstarisChange
when
Item GF_Stairs_Light1 changed
then
if (FF_Hol_Light1.state != newState) { FF_Hol_Light1.sendCommand(newState) }
end
2 Likes
This is a very old topic, before profiles were introduced. You can now have an Item follow the state of another Item, without using any rules. Look into the follow profile…
I agree it is old topic but I couldn’t find working solution. I also tried to use follow option in item, but always after turn on switch I got disco. It is complicated logic, because when I turn on light on switch one then all other switches need to turn on. When second switch turn on then other needs to turn on and so on. The problem appeared when switch one followed by the switch two and the two followed by the switch one. I’ve always received disco after this configuration. If you have working solution for cross switch based on items could please share an example.
What was your Item configuration when using the follow profile? Which version of OH?
@rossko57, are you aware of an issue when using the follow profile with multiple Items?
I am not, but it is a brain-ache exercise working out expected consequences.
The usual stumbling block with the follow profile for stairway switching is that it is not smart enough not to pass along e.g. an ON when Item already ON.
(In familiar rule terms, the follow is triggered on update and not limited to change.)
When real devices respond to a command with state, this can easily create a feedback loop.
A few real devices respond first with "old’ state before actioning commands - instant disco.
Rules can be made as smart as you like, especially the part about acting on change not update.
Another way to look at it is that follow profile is good in a master-slave relationship, but a problem when used peer-to-peer fashion.
I have wondered about an enhancement to follow profile, e.g. an option for “change only” but pretty sure it would get rejected.
The channel it operates in is supposed to be stateless in openHAB design, so it has no memory. Likewise it is not supposed to have a view of linked Items. There’s no way to detect “change” at a channel level without breaking design guidelines.
Writing rules to provide this function, with various subtleties to fit the situation and devices, is not that burdensome.
Rossko 57 explained behaviour of follow option. My openhab version is not needed. I thought that cross switch is commonly used in light switches. Adding cross switch option to follow parameter might be misunderstood. In my opinion additional parameter that allow to group multiple switches in order to build cross switch might be useful.
Thank you for help. I hope that my example will be useful for someone else.