For example, we want to know which UUID is triggering the various alert logic

For control triggers, we need it to match the type and mac, otherwise any mac or type in the control def list could reset the trigger.

We can have n number of strategies for m number of types and o number of macs that want to manipulate a single control channel (relay).

Two other important concepts:

1. We don't want relays flapping when various strategies assert their control - for example, we have 96 cells on a Nissan leaf (each cell is able to independently generate a control trigger), what happens when 10 of them go over a threshold and a channel (ch1 for example) is turned off. Then, 9 of them return-to-normal and want to turn the control ON again, but the remaining cell is still overvoltage and is wanting the control to be OFF.

2. In the same vein, what happens when other strategies (say over-temperature and voltage) both assert off, and one returns-to-normal.

3. We can also have multiple control strategies that have different back-to-normal values. Should the back-to-normal=false strategies have priority over all other strategies?

These are all important control issues to consider and we need to evaluate and implement best practices.

We need to:

1. Add a configuration variable for the control strategy refresh interval from disk (or cloud)
2. Refresh the in-memory control strategies at the stated interval

Eventually, the control trigger should expire when "the work is done" OR the control trigger hasn't met certain criteria (such as being fully triggered over the required duration).

We also need to think about a forced "return to normal" (for example, when we have disallowed return to normal command) - how do we allow operators to force a return to normal without having to restart the software.