At first I thought the answer was no but I realize now that the answer is actually yes, unless you make some changes to the above rule. The problem is you will want you Switch Items to be in sync with what the devices actually are so we can’t bypass the gMySwitch updates.
However, if you change your rule trigger in the above to
when
Item Switch_A01 received command or
Item Switch_A02 received command or
...
then if you just send the command string for each switch directly and postUpdate to the switches (which will not trigger the rule above) then the answer is no. You could something like:
gMySwitches.members.forEach[s |
val StringBuilder cmd = new StringBuilder
cmd.append("D:0")
cmd.append(s.name.split("_").get(1)) // get the A01 part of the switch name
cmd.append(":E")
Switch_Publisher.postUpdate(cmd.toString)
s.postUpdate(OFF) // postUpdate will not cause the rule to trigger
]
And if you wanted to reuse this command generation and publishing code in both rules you can create a lambda.
val Functions$Function3 cmdSwitch = [ String name, OnOffState st, StringItem publish |
// Build the command string
val StringBuilder cmd = new StringBuilder
cmd.append("D:")
if(st == ON) cmd.append("1") else cmd.append("0")
cmd.append(name.split("_").get(1)) // get the A01 part of the switch name
cmd.append(":E")
// Issue the command string to the socket
publish.postUpdate(cmd.toString)
]
Then your original rule would replace everything after // Build the command string with
cmdSwitch.apply(mostRecent.name, mostRecent.state, Switch_Publisher)
And the code above to turn them all off would become:
gMySwitches.members.forEach[s |
cmdSwitch.apply(s.name, OFF, Switch_Publisher)
s.postUpdate(OFF) // postUpdate will not cause the rule to trigger
]
This lets you consolidate the code that creates the command string into one place.
It is a side effect of how the state of a Group is calculated. What ends up happening (I’m making an educated guess here, I haven’t actually looked at the code yet) is when a member of a Group receives an update, the Group gets updated. BUT, then the Group checks all the other members to recalculate the Group’s own state (remember, the state of a Group is an aggregate of the states of all of its members). So for each of the other members it calculates a new state which results in an update to the Group for each member. So when you have a rule that is triggered by a Group’s update, it will actually trigger the rule once for each member of the group.
Most of the time I’ve found this doesn’t really matter but I wanted to make you aware of this behavior.
I’m throwing a lot of advanced stuff at you(lambdas, behaviors of Group updates, difference between command and update, etc). It took me months to learn some of these tricks so don’t feel bad if you are overwhelmed. This was a fun problem to work out though. I hope it helps.
