That’s the first of a series of a few dozen posts. Search on the forum is currently broken unfortunately so the link to them isn’t working from that post. So see Topics tagged designpattern for a list of some of the DPs that have been tagged as such. I’ve written a lot of them but others have contributed too. Here is a site search from duck-duck-go that shows more of them.
Several DPs could apply (in no particular order:
- Design Pattern: DRY, How Not to Repeat Yourself in Rules DSL
- Design Pattern: How to Structure a Rule
- Design Pattern: Separation of Behaviors
- Design Pattern: Associated Items
There are a couple of state machine DPs as well which might be useful.
Almost all of the time a Map is used in Rules with the name of the Item being the key and the Timer associated with that Item as the value. That lets you have one Rule that handles the behavior for lots of Items. You can get the name of the Item that triggered the rule with triggeringItem.name.
But notice I said the name, not the Item itself as the key. I never looked into it way back when but I definitely ran into troubles when I used the Item as the key. The hash seems to change for the Item Object over time so from one run of the rule to the next the Item may no longer be able to pull the value out of the Map.
If you are on OH 3, than I believe you can get at the triggering Item using ir.getItem(event.name) but this is mainly going on some comments on on the GitHub Issue for triggeringItem not working. I’ve not tried this from Rules DSL in OH 3 and can’t guarantee it will work. But that’s how you would do it in Jython or JavaScript.