Variables vs. helper items

I can’t do much better than already covered here by @JustinG and @jimtng but for completeness I’ll list all the ways to save data like this. Which is most appropriate will largely depend on the situation.

Technique Advantages Disadvantages
Items get restored on startup limited in the types of data that can be stored, may require a String that later needs to be parsed or a proliferation of Items, sometimes can be auto-populated through transformations and/or profiles
cache can share data between files, not just rules, Timers automatically get canceled, in some cases can even be shared between rules of different languages doesn’t get restored on startup
Persistence mostly get this for free can be slower than rules causing timing issues, only useful when needing to compare/use some previous state
Item Tags available in all rules languages, a nice way to dynamically group Items for some reason, great for boolean info some tag names are reserved, complicated data is not supported
Group membership similar to tags similar to tags
Item Metadata metadata persists until you delete it, becomes part of OH config not available in Rules DSL
Item Naming particularly easy to use with replace and split, great to be used with the semantic model best for static data, not data that changes at runtime (see Design Pattern: Encoding and Accessing Values in Rules)
Global Variables lives close to the code not possible from managed rules (see cache for alternative), only exist in the file they are defined
Transformations (e.g. .map files) can be set up separate from the rules limited in utility to mapping one value to another (e.g. an Item name to a timeout value)
Text Files (load a config from a JSON or .properties file) best for static or rarely changing data requires different formats and approaches depending what’s available in the language, can be slow

The cache and global variables and I think even Item metadata can be used with the storeStates and restoreStates actions as a way to capture the current state of a bunch of Items and restore them later.

I think that covers all the options.

To provide some examples in how I use some of the above:

  • Many of my semantic Equipment have a Status Item. I follow the same naming convention for all these so in a rule that detects that a piece of Equipment has gone down, I can get the Equipment and from there get the Status Item to update (this is for cases where I don’t detect an Equipment has gone offline except by monitoring something indirectly such as how long has it been since a sensor has reported or the Thing’s ONLINE status).

  • I autocontrol some lamps based on the cloudiness but sometimes we want the light to be ON or OFF regardless of cloudiness. When a lamp is triggered manually, I set an override Item metadata to stop changing the light based on cloudiness. The flag gets cleared at the next time of day. In hind sight a tag would probably be more appropriate.

  • I use Design Pattern: Associated Items all over the place but have doing less so as I adopt using the semantic model from my rules more.

  • For keeping track of the last time an Item was updated I use a separate Item and the timestamp profile.

That’s what Maps are for. One variable that you populate with key/value pairs.

4 Likes