Well, it doesn’t hurt to have them in the Rules DSL. But the only time it is required is if you want to use return false;
to exit early.
There are several reasons, some of which will go away in the not too distant future.
There are only two ways to trigger a Rule using a Group and have the Rule trigger when members of the Group change or receive an update: changed
or received update
.
One can use changed
if the Group’s aggregation function is properly configured so when the members of the Group change state the Group changes state in a detectable way which is usually possible using SUM. And this would probably work in this case but see below for why I don’t.
If one uses received update
the Rule will trigger any time any member of the Group receives and update. However, as a side effect of how the Group’s state is calculated, the Rule will actually trigger N-1 times for that one update where N is the number of members of the Group. This would probably work here as well but it will take a lot of extra code to deal with the multiple triggers to avoid getting lots of alerts for one update to a member. Also, since the Rule triggers for all updates it means the Rule will trigger when I restoreOnStartup the members of the Group as the Items goe from NULL to what ever their restored states are.
So let’s assume I used changed
with a sane aggregation function like SUM. Then I have to figure out which Item actually changed. There are two ways I can handle this. The first is to just generate an alert/set Timers, etc for everything that is OPEN and ignore which Item triggered the Rule. I use this approach in lots of places and it does work successfully. However, in this case it will take a lot more code to implement, more than the extra lines caused by listing all the Items as separate triggers.
The second is to use the Persistence LastUpdate hack (see the Working with Groups in Rules for details). That hack requires Persistence and a Thread:sleep at the front to give persistence a chance to save the latest states. It’s only two line of code so it isn’t that big of a deal, but I really don’t like the dependency on timing.
So, to ensure that the Rule only triggers once per Item change and to avoid needing to use the persistence hack and instead use the triggeringItem implicit variable I need to list each Item separately as triggers to the Rule.
Soon there will be introduced a new Rule trigger that we can use on Groups that will populate triggeringItem with the member of the Group that caused the Group to change or update. At that point I can use that new trigger with the Group without a lot of extra work.
About 90% of my posts, including this one, is from my phone.
I can’t get it to show up as a device I can cast to. That was one of my first ideas but I dropped it as not supported. Maybe I need to look into it more. Searching online reveals mixed results with some saying it works and some saying it used to work but is no longer supported.
For now I’m going down the MQTT text message to send the announcement to the AIY. I may go back and try chromecast again.