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.