I am trying to shorten and optimize some of my rules as my understanding of OH grows, but I’m not sure if this is the best approach to solving my particular problem. FWIW, I’m abbreviating the description of the problem as much as I can because the initial write-up was painfully long.
I have a scene selection (Number item) in which these are many different configurations possible. The rule logic flows like:
rule receives command (Number) which selects a configuration.
rule captures the current state of all items (over 70). Right now, these are individual variables. Lots of code…not very flexible. Many of these items are in groups already.
rule changes the states of items to new states based on configuration variables that define what the new state should be. Again, lots of code…
rule performs an action while these items are in this state.
rule returns the state of all items back to the initial state (while working around a very irritating firmware bug).
My question is whether using ArrayList is the right approach to simplifying much of this. I would capture the initial states of items (again, over 70) in an ArrayList (they all persist via mapdb) before the rule changes anything (because the very action of changing things makes the firmware report an incorrect state and messes up the whole rule). Then read all of the states that I want to change the items to would be read into a second ArrayList. This should shorten (somewhat) the lines of code. Finally, I need to compare the ArrayList of the inital state to the changed state, and that way I can correct for the firmware bug by altering the final state if some things don’t match correctly (ie, I know how the buggy firmware can corrupt the state, so I can compare and fix accordingly based on observed behavior).
Hopefully this is enough detail to provide some direction on whether this is the right approach. I can provide as much detail as necessary, but I’m sure I’m running a risk of TL;DR already… I don’t know much about Java methods on handling this, so I’m just looking for some starter direction/documentation.
Thanks for the feedback @ssalonen. I believe I can probably use those in a Map<Item,state> context around a group. Do you know if those group items will be filled in a deterministic manner (item 1, item 2, etc) or will they fill in some random order (item2, item 1, … ) variably and if they’ll hold their values even if states change during the rule execution? I ask because one of the main problems I have is this firmware issue where if some states are changed intentionally they may unintentionally change the state of an item during the rule execution. If that occurs, I can’t return the state correctly at the end. This is one of the major headaches I have and why I have them coded the way I do right now. It seems (though I am not sure) that when dealing with groups of items, ensuring the order of items isn’t possible. The only way I have checked this is via logInfo output, though, and that alone may not reflect how it’s actually being handled behind the scenes.
Perhaps you don’t understand how Maps work in general. Maps never store values in order. The whole point of a Map is to be efficient, giving you nearly a constant access time for any element no matter how many elements are stored in the Map. But order doesn’t really matter based on your description. Call storeStates and it will capture the states of all the Items in what ever order they happen to be in as fast as it can and return them in the map. The order they were captured and the order they are stored in the Map don’t matter.
But if at any point you need to access them in some sort of order, that should be possible too by sorting the key set of the map and then iterating over that. But one of the main intended uses of storeStates and restoreStates is that you would never need to do that.
Any changes made to Items after you call storeStates have no impact on the values stored in the Map returned by storeStates. The Map stores the Items states as they were when the call was made and do not change if the Item changes state after the call to storeStates. It wouldn’t be a very useful Action otherwise. The whole point is to capture the state of a bunch of Items so you can restore them later.
