larshei / statux Goto Github PK

Using multiple Rule Sets is mostly prepared.

The Rule Set loaded initially is set as the :default variant and the message processing pipeline can already handle multiple Rule Sets.

To be implemented:

1. Add more RuleSets to a Tracker
2. Assign RuleSets to tracked entities (store in EntityStatus.rule_set_name)
   1. If the RuleSet is replaced, but e.g. the available options change, what do we want to do? Reset the current EntityStatus? Keep the intersection, remove/add others as needed? Transition the current_state to nil or keep as-is (or either, depending if the option still exists)?
3. Choose the RuleSet based on EntityStatus.rule_set_name

Allow bitstring specific constraints:

1. contains
2. begins_with
3. ends_with

1. Add transition times to history
2. Calculate total time spent in each option when transitioning and maybe even add a percentage for each option
   1. Should allow to filter for devices that spend more/less time in specific status/options
3. Somehow audit forced status updates

Each tracked Entity holds a history of its state transitions as a list.
The list should be as short as possible for less memory and computation requirements,
but as long as needed to be useful. So this will be different for every project.

1. Configure history length as fixed length (Integer)
2. Configure history length as fixed duration (Duration)
3. Maybe add these things to the Rule Set file?
   -> Would require adjusting the parser and also the rule set?
   Not sure how complex the Rule Set file should become 🙈
   In any case, default values should be given and it should be configurable via environment or args as well.