Is there anyway to setup rules taking precedent over other rules, so if one is active or has been triggered, another that adjusts the same condition wont trigger?
This should be possible to solve using the variable concept. You have a trigger called "Check variable" and an action called "Set variable". The variable can either be set on a global scope or set per miner.
You can design the first rule to set a variable to "1" when running. The second rule could check the variable value and only run if the value is "0". This way you can have one rule to change the behavior of when another rule should run.
Looks like when I restart AM, some of the global variables disappear from tools > rules > variables? Do they automatically show up when rules get called that trigger them or if they aren't there will the program throw a error?
Also how do you get something to trigger once on a variable state change? Seems they're set to constantly repeat. You can set time limit, but that's not applicable nor do I want triggers to run when the variable states don't change.
Thanks
When starting Awesome Miner, all global variables not referenced by any rule will be removed. The original idea was to avoid getting a large number of unused variables but there can be scenarios where this behavior isn't preferred. I will remove the automatic cleanup of global variables in the next release.
If you would reference a variable that doesn't exist it will be considered to have a value of 0 if you read it and it will be created if you write to it.
It's true that the "Check trigger" will run every 5 seconds if the condition is true. Can you combine with "Limit actions to run at most once every" or "Limit actions per day" depending on the behavior you want? Another possibility is to make use of a second variable that you set to "1" in the rule action and you check for it to not be "1" in the trigger condition.
Isn't that just a loop or completely break the automation till it's manually reset?
I saw the run X number of minutes, but when you have a interaction that's semi-random in nature, you can't set something like that up. I think 'on state change' instead of running in a loop would be possible and often times preferable depending on what you're looking for.