If any switch is operated to become off, then all go off
If any switch is operated to become on, then all go on
I think this can be done using “follow me” profiles, but I’m not 100% sure of the setup.
Or is it better to use rules in order to avoid loops ?
Or maybe a profile to operate switch 2 depending on switch 1, another profile to operate switch 3 depending on switch 2, and a rule to operate (sendCommand) switch 1 depending on switch 3 (to break loops)
No, a rule will be needed for this. The problem is that the follow profile only goes one way. For example, if Channel B follows Channel A, updates from Channel A will flow to Channel B as commands. So far so good. However, updates from Channel B do not flow to Channel A as commands.
The follow profile only works if one Channel always follows another but never the other way around.
For this case you’ll need to use a rule.
Assuming this is even possible, which I’m pretty sure it’s not, it will be less complicated using Rules.
Put all the Switch Items into a Group. Trigger the rule with a Member of changed trigger. Inside the rule, command any member of the Group that isn’t already the state that was changed to. The rule will trigger N-1 for N switches but only the first trigger will have the rule do anything and by triggering on changes you will avoid loops.
No, just one rule is needed. You don’t care whether it changes to ON or OFF, just that it changed.
In Rules DSL it’d look something like this:
rule "Sync switches"
when
Member of SwitchGroup changed
then
SwitchGroup.members
.filter[ item | item.state != newState ]
.forEach[ item | item.sendCommand(newState) ])
end
In JS in the UI the action script would look something like this:
It’s really just a one liner. But the subtlety that makes it work is in the rule trigger and that you only send a command to Items that are not already in the same state. If you used received command or received update or just send the command to all the Items it wouldn’t work and you’s likely get into a loop or at a minimum trigger the rule a bunch more times than necessary.
In openHAB 4, there’s also triggeringGroup which is handy in this situation
rule "Sync switches"
when
Member of SwitchGroup changed
then
triggeringGroup.members
.filter[ item | item.state != newState ]
.forEach[ item | item.sendCommand(newState) ])
end
in JRuby, triggeringGroup is available as event.group
rule "Sync Switches" do
changed SwitchGroup.members
run do |event|
event.group.members.ensure.command(event.state)
end
end
It’s very useful when you have multiple groups, so you can use one rule
rule "Sync Switches" do
changed SwitchGroup1.members
changed HallwayGroup.members
changed LivingRoomGroup.members
run do |event|
event.group.members.ensure.command(event.state)
end
end
Or you can also write it as:
rule "Sync Switches" do
changed SwitchGroup1.members, HallwayGroup.members, LivingRoomGroup.members
run do |event|
event.group.members.ensure.command(event.state)
end
end
Oh the group function. No, the group function is irrelevant. The group function is only used to update the group's state. In the rules above, we’re dealing directly with the group’s members, and not using/checking the group’s state at all. So you don’t need to have any group function and just have a plain simple group.