Based on my experience this may not work long term. For awhile I was using the Item object itself as the key to a HashMap of Timers and after awhile I couldn’t pull the Timers out with the Item any more. The problem is that every time the Rule runs the Item Object gets recreated for the Items used in the Rule. Because of that the Hash function returns a different value and thus no longer can be used to pull the value out of the Map. I’ve also found that the Item gets stale and calls to MyItem.sendCommand stop working over time.
Maybe this is something has been fixed. But using the Item’s name as the key works much better and will continue to work in case this is still a problem or becomes a problem again.
This is definitely an anti-pattern. Your Items are the logical model for your home automation. They should ALL have meaningful names and names that are meaningful in relation to how it is used. Zwave_Node12 is a horrible Item name. LivingRoom_Lamp is a better Item name. It says what it is and what it’s used for.
You would be far better off fixing the names of your Items instead of patching over the problem using variables. This is what they call in software development “technical debt”. You eventually the “loan” comes due and it almost always ends up costing way more than you expect.
Rules are the most complex part of your OH setup. If you can move any of that complexity out of the Rules and into Items, or Things, or Persistence then you should do that. It will lower the overall complexity of your OH system. See Design Pattern: DRY, How Not to Repeat Yourself in Rules DSL for other techniques you can use to simplify your Rules logic.
grep variableName myrules.rules
returns all places where the variableName exists.
VSCode and other editors have find and replace.
Fear of missing a change to a variable name is a poor excuse to using proper Item names. I cannot stress the importance of this enough.
