====Cycle Rules====

The rules behind [[cycles|cycles]] are very similar to those for [[state_rules|states]].

There are four main types of rule when creating cycles.

^Rule Type^Usage^
|Start|Marks the beginning of a cycle*|
|End|Marks the end of a cycle|
|Ignore|Ignores any matching times|
|Milestone|Captures information about the asset performing actions|

Of these, only the **Start** rule is actually required.

===Rule Anatomy===

Cycle rules can have the following properties...

^Property^Meaning^
|type|The type of rule (start, end, ignore, milestone)|
|primary|The property being matched against.|
|value|The value to match with|
|trigger|If the rule is met at the //start// or //end// of the rule being met|

===Examples===

The following rule starts the cycle the moment the resource enters the 'Loading' state...

<code>
{                   
   "type": "start",
   "primary": "State",					
   "value": "Loading"			
}
</code>

This is the same, but the cycle begins the moment the resource **leaves** the 'Loading' state...

<code>
{                   
   "type": "start",
   "primary": "State",					
   "value": "Loading",
   "trigger": "end"		
}
</code>

In both cases, without a "end" rule the cycle will end when the 'start' condition triggers again.

===Ignore===

Adding an **Ignore** rule will ensure that specific types of state are **not** added to any totals or analytics. 

This is often used when you want to ignore certain kinds of 'noise', such as during staff breaks, changeovers and other human-related time losses.

The example below will ignore any time when the //Location// property starts with 'Delay_'.

<code>
{                   
	"type": "ignore",
	"primary": "Location",
	"value": "Delay_*"
}
</code>

===Milestone===

**Milestones** are statuses that are expected to be seen as part of a completed cycle. 

If you have any milestones defined, a cycle can not be completed without having experienced at least //one// of the defined milestones.

This helps avoid recording cycles that were incomplete or caused by noise.

You can also **capture data** at milestones - this is very useful if you have several possible directions/routes/methods that a system might choose to use.

There are two additional properties for a milestone...

^Property^Meaning^
|capture|The property value to capture|
|as|The name of the KPI/point to capture|

In the example below, our vehicles all load up on product from a single place, but //unload// at different areas around the site.

We can capture //where// they unloaded by recording the location when they reach the 'Unloading' state.

<code>
{                   
	"type": "milestone",
	"primary": "State",					
	"value": "Unloading",
	"capture": "Location",
	"as": "Destination",
        "trigger": "start"					
}
</code>