Skip to main content
A substitute rule’s correction is not a one-off write. Mangrove keeps checking it as the data around it changes, and undoing or editing the rule affects earlier corrections in different ways. For setting up the rule, see Create a Data Rule. For reading a value’s correction history, see Substituting a value.

​
When data arrives late or changes

A rule judges new data points as they arrive, unless it runs only on demand. Corrections it has already written are also worked out again when nearby data changes, and rewritten if the answer is different. That happens when:
  • A method earlier in the rule’s chain can now produce a value. With Forward fill then Constant 400, a bad value with nothing before it gets 400. When an earlier data point arrives late, there is something to copy, and the correction is rewritten to that value.
  • A data point the correction was worked out from is edited or deleted.
  • Data points arrive in, or leave, the window a method reads, so the same method now gives a different number.
The correction history in the Event Detail drawer shows the new value as re-derived by the rule, with the cause beneath it. The earlier correction stays in the history. A correction is not rewritten once someone has edited or restored the value by hand, or once the data point has gone into a filed report. If you learn the true value of a corrected data point, type it in on the data point. It is added to the history on top of the rule’s correction, and the rule stops rewriting that value. With Require approval on, a rewrite is not written straight away. It becomes a new proposal, and the current value stays until someone approves or rejects it. Rejecting it keeps the current correction. A correction written by an earlier version of the rule is left as it is. See Approve corrections.

​
Undoing corrections

There are three ways to put corrected values back, and they differ in whether the rule may correct those values again. Revert run and the API revert leave two kinds of correction in place: one on a data point that has gone into a filed report, and one that someone has corrected since. Before you confirm, Revert run counts what it will remove and what it will leave, with the reason for each. Neither revert runs the rule again. The rule corrects those values the next time it evaluates them, for example when you use Evaluate a period.

​
Editing a rule does not redo earlier corrections

Changing a substitute rule’s methods or condition saves a new version, and it applies to values the rule judges from then on. Values it already corrected keep the value they have. To apply new methods to values the rule already corrected:
1

Revert the runs that wrote them

On the rule’s Runs tab, use Revert run on each run whose corrections you want to redo. Over the API, Revert a rule’s corrections removes them all at once.
2

Evaluate the period again

Use Evaluate a period on the same tab, over the dates you reverted. The current version corrects the values with its own methods.
Do not use Restore to original for this. A restored value is one the rule will not correct again, so it stays at its captured value.

​
Rules that correct the whole run

A rule set to correct The whole run follows the run as data arrives. Each new repeat is corrected, and so are the earlier repeats in the run, even outside the rule’s window. A value another rule already corrected stays with that rule. See Catching a stuck sensor.