I’d apply Design Pattern: Associated Items (i.e note, you don’t have to put your Camera Items into a Group for this to work since you only send a command to them and don’t need to check their state).
You now have two choices. You can use the Group/Persistence hack documented in Design Pattern: Working with Groups in Rules or use triggeringItem. I’ll present triggerinItem as it sets you up for when triggeringItem will work with Groups, hopefully by the next time a new ESH baseline is merged into OH.
Unfortunately, until the new GroupTrigger gets into the OH baseline you will need a Rule that lists all of your camera as triggers. The new triggeringItem implicit variable will be set to the Item that triggers the Rule. When the GroupTrigger gets added, you can just put the Group as the trigger to the Rule and triggeringItem will be the member of the Group that triggerd the Rule (it will be a glorious day).
Then we just do a little parsing on the triggeringItem name and construct the camera’s Item name.
rule "Camera motion sensor trip"
when
Item Motion_02 changed from CLOSED to OPEN or
Item Motion_03 changed from CLOSED to OPEN or
Item Motion_26 changed from CLOSED to OPEN or
Item Motion_27 changed from CLOSED to OPEN or
...
then
val cameraNum = triggeringItem.name.split("_").get(1)
sendCommand("Camera_"+cameraNum, ON)
end
Once the GroupTrigger gets implemented the rule would look something like (notional syntax, I’ve not followed the Issue well enough to know the true syntax):
rule "Camera motion sensor trip"
when
GroupTrigger MotionSensors changed from CLOSED to OPEN
then
val cameraNum = triggeringItem.name.split("_").get(1)
sendCommand("Camera_"+cameraNum, ON)
end
I choose triggeringItem over the persistence hack because:
- it sets you up to take advantage of the new GroupTrigger when it comes down the lline
- it frees us from having to deal with the fact that the rule will trigger multiple times for each motion sensor trigger
- it does not depend on timing and persistence making the rule more robust