> For the complete documentation index, see [llms.txt](https://docs.kemperconnect.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kemperconnect.de/rule-engine/overview.md).
# Overview
The KEMPER Rule Engine is the automatic guardian of your air quality. It teams up your measuring devices (e.g. AirWatch) with your filtration units (e.g. AirDome or Clean Air Tower): the measuring devices constantly watch the air — and the Rule Engine makes sure the filtration units work exactly as hard as currently needed. No more and no less.
You can find the Rule Engine for your site via the sidebar under **"Rule Engine"** (address: `/sites/[id]/rule-engine`).
## What can I do with it?
**The Rule Engine can do the following for you:**
* **React to fumes automatically:** When welding starts in the hall and dust levels rise, the filtration units ramp up on their own. Once the air is clean again, they ramp back down — without you doing anything.
* **Control the whole hall as one:** Combine several AirWatch units and several room ventilation systems in **one** rule — the Rule Engine automatically merges all readings into one picture of the hall and controls all units together. Just select all devices; the Rule Engine takes care of the rest (more on this in the next chapter).
* **Respect quiet times:** Should it be quiet at night? Should a base level of extraction always run in the morning, no matter what the sensors say? Both can be set up with schedules.
* **Save energy and wear:** The units only run as hard as the air requires. That saves electricity and protects filters and motors.
* **Play it safe when in doubt:** If a measuring device fails and the Rule Engine is "blind", it switches the units to full power as a precaution — never off.
### **Main building blocks**
| Building block | What it does | Where to find it |
| --------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------- |
| **Rule** | Connects one or more AirWatch to one or more extraction units and controls them automatically based on air quality | Overview page, **"New rule"** button |
| **Schedule** | Gives the automation a frame: minimum operation, upper limit or fixed value within a time window | Inside a rule under **Settings → Schedules** |
| **"Set now"** | Immediately and temporarily forces a fixed power — e.g. for a demonstration or maintenance | Button directly on each rule |
| **Diagnostics** | Shows what the automation last decided and whether the devices confirmed the commands | Gauge icon on each rule |
### **Short examples**
1. *"The extraction should run automatically when welding takes place."* → Create a rule, select the AirWatch and the extraction units — done. The default settings take care of the rest.
2. *"We have a large hall with four AirWatch and three room ventilation units."* → Create **one** rule and simply select all seven devices. The Rule Engine automatically combines the four readings (by default the worst one counts) and controls all three ventilation units together.
3. *"At night the system may only run quietly at most."* → Add a schedule of type **"Upper limit / quiet hours"** to the rule, e.g. daily 22:00–6:00 with at most 30%.
4. *"During the early shift a base level of extraction should always run."* → Add a schedule of type **"Minimum operation"**, e.g. Monday to Friday, 6:00–16:00 with at least 40%.
## In Detail
### Multiple AirWatch, multiple units
{% hint style="success" %}
This is one of the biggest advantages of the Rule Engine compared to the previous automation: **you no longer have to wire up each ventilation unit individually to one specific AirWatch.**
{% endhint %}
Instead, in **one** rule you simply select all measuring devices and all units of an area, the Rule Engine handles the rest on its own.
**How the interplay works:**
* **All readings are automatically combined into one control value.** By default the **maximum** counts: i.e. the worst AirWatch. If heavy welding happens at just one workstation, the whole rule reacts, even if the rest of the hall is clean.
* If you prefer to control by the **average** of all sensors instead, change this under **Settings → Expert → "Combine sensors"**.
* **Offline devices are taken out automatically.** If an AirWatch fails, goes offline or stops delivering values for too long, it simply doesn't count for a while, the rule keeps running normally with the remaining sensors. In the expanded rule card you can see for each sensor whether it currently counts (and if not, why), plus the note *"Combined reading based on X of Y sensors"*.
* **All units pull together.** Every extraction unit in the rule receives the same target, the whole hall is controlled as one unit, no device works "against" another.
* **Only when all sensors fail does the safety net kick in:** the units then ramp up to the failsafe power (see "Built-in safety").
### **Before/after:**
| Previous automation | KEMPER Rule Engine |
| ----------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Each ventilation unit is controlled by exactly one AirWatch — many individual links | One rule for the whole area — simply select all devices |
| If "its" AirWatch fails, the ventilation unit is left without control | Offline sensors drop out automatically, the remaining ones take over |
| Every link must be maintained individually | Central settings, schedules and stages for everything together |
> **Tip for large halls:** Create one rule per connected air area (e.g. "Hall North", "Hall South") and put all AirWatch and ventilation units of that area into it. Separate rules only make sense when areas really have separate air.
### How the Rule Engine thinks: target and reality
The Rule Engine works with two simple concepts:
* **The target:** How the unit should be running right now. The Rule Engine continuously recalculates the target — from the current readings and your schedules. Example: *"The unit should be switched on and running at 40% power."*
* **The reality:** How the unit is actually running right now. The Rule Engine learns this from the devices' feedback.
#### The constant reconciliation
The heart of the Rule Engine is the **reconciliation**: at short intervals it compares the target with the reality. If both match, nothing happens. If the reality deviates from the target, the Rule Engine sends the unit a command to bring it back on course.
**An example you may have experienced yourself:** You switch a filtration unit off by hand at the device. A few minutes later it turns back on by itself. That is not a bug — that is the reconciliation. The Rule Engine noticed: *"The target says ON, the reality says OFF"* — and switched the device back on.
> **Rule of thumb:** If you want the unit to run differently on a permanent basis, change the **rules or schedules** — not the switch on the device. A manual change at the device will be reverted at the next reconciliation.
#### Why the unit never runs "exactly" on the target value
A filtration unit cannot hold its air volume to the exact point — it always oscillates a little around the target value. The Rule Engine knows this: it accepts a **tolerance window** around the target. As long as the unit stays within this window, everything is fine and nothing is readjusted. Only when the unit is clearly off does the Rule Engine step in.
## Creating a rule
> **First use:** The very first time you open the Rule Engine for a site, your devices are connected to the Rule Engine once. You will briefly see the message *"Synchronising devices..."* — this only takes a moment and only happens the first time.
On the overview page, click **"New rule"** (or **"Create rule"** if no rule exists yet). A wizard guides you through four steps:
1. **Basics:** Give the rule a clear name that describes the area or system — e.g. *"Welding bay north"*. This way you will recognise the rule later.
2. **AirWatch:** Select the measuring devices whose readings should drive this rule. You can **select multiple AirWatch** — the Rule Engine automatically combines their values into one control value (by default the worst one counts, see chapter "Multiple AirWatch, multiple units").
3. **Extraction units:** Select the filtration units that should react to the air quality. Here too you can select multiple devices — they will all be controlled together.
4. **Review:** Check your selection and click **"Create"**.
The rule is now active and works with proven default settings. You can adjust all settings, schedules and expert parameters at any time later.
> **Good to know — which device can do what?** The **AirDome** can adjust its power continuously (run faster or slower). All other devices — e.g. Clean Air Tower — can only **switch on and off**: for them, any target value above 0% means ON, 0% means OFF.
#### **Note on old automations**
{% hint style="warning" %}
If this site still has automations from the older system that connect the same AirWatch to the same devices, the overview shows a red warning. Please disable the old automations first — otherwise both systems will control the same devices at the same time and get in each other's way.
{% endhint %}
***
### The overview page
Each rule appears as an expandable card.
#### The card row (collapsed)
* **Rule name** and current mode with target value (e.g. "Automatic · 40%")
* **"Live"** or **"Test mode"**: In test mode the Rule Engine computes along but sends **no** commands to the devices (more below).
* **Status indicator** (appears when needed): e.g. "Command sent" with a spinning icon when a command is on its way, or a red "Send failed".
* **Buttons:** "Set now", Diagnostics (gauge icon), "Settings", Delete (trash can) and a **switch to activate/pause** the rule.
#### The expanded card
Expand a rule to see the current status in detail:
* **Current status:** Mode, target power, power on/off, combined reading and when the last calculation ran. If the rule is currently controlled by a schedule, this is shown here too ("Currently controlled by the schedule …").
* **AirWatch:** Each sensor with its current reading and a note if it is currently not counting (offline, no fresh data, out of range).
* **Extraction units:** Each device with its **live device status** (see the section "The device status" below).
* **Summary:** Number of schedules, how many of them are active now, and the measured value in use (PM10/PM2.5).
#### Activating, pausing, deleting a rule
* **Switch off = rule paused:** The Rule Engine stops controlling these units — they remain in their last state ("frozen"). Pausing **never** switches anything off automatically.
* **Delete** removes the rule permanently — here too, the devices remain in their last state.
***
### Settings: where do I find what, and what does it mean?
Click **"Settings"** on a rule. The dialog has five tabs:
#### Tab "General"
| Setting | Meaning |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Name** | The display name of the rule. |
| **Active** | The same switch as on the card: off = rule paused, the devices stay as they are. |
| **Live / Test mode** (display only) | Whether the rule really sends commands. Live arming can only be changed by an administrator — contact support if needed. |
#### Tab "Sensors"
Here you select the AirWatch devices whose readings drive the rule — you can add or remove devices at any time. Multiple sensors are automatically combined into one control value; offline or outdated sensors temporarily don't count.
#### Tab "Units"
Here you select the extraction units the rule controls. You can add or remove devices at any time.
#### Tab "Schedules"
Here you manage the rule's time windows, explained in detail in the next chapter.
#### Tab "Expert"
Behind a safety prompt lie the fine-tuning settings of the automation.
{% hint style="danger" icon="face-eyes-xmarks" %}
**Only change these values if you know what you are doing** — wrong values can make your extraction work incorrectly. When in doubt: contact support. The default values are right for the vast majority of applications.
{% endhint %}
The following table gives a quick overview. **A detailed explanation of every single setting** — with its effect, examples and guidance on when a change makes sense — can be found at the end of this document in the chapter **"Reference: the expert settings in detail"**.
| Setting | Meaning | Default |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- |
| **Control strategy** | **Stages**: fixed power levels per threshold (see "Power stages" below). **Proportional**: power rises smoothly with the reading. | Stages |
| **Measured value** | Which dust value the rule reacts to: **PM10** (coarse dust) or **PM2.5** (fine dust). | PM10 |
| **Combine sensors** | How multiple sensor readings are combined into one control value: Maximum (safest), Average, Minimum or Weighted. With Maximum, the worst value always counts — a single smoky workstation is never "averaged away". | Maximum |
| **Smoothing** | Filters out short measurement spikes before controlling — e.g. a passing forklift. Median (recommended), Mean or None. | Median |
| **Smoothing window** | Time window each sensor is smoothed over. | 10 min |
| **Compute interval** | How often the Rule Engine recalculates and reconciles. | 10 min |
| **Deadband** | Minimum change of the target value (in percentage points) before a new command is sent. Prevents constant "flapping" and protects the devices. | 10 |
| **Minimum hold time** | Rest period between two adjustments. Your own interventions ("Set now") and the safety mode still act immediately. | 15 min |
| **Sensor timeout** | After this age a reading counts as outdated and no longer contributes. If **all** sensors deliver values that are too old, the safety mode (failsafe) kicks in. | 30 min |
| **Unit feedback timeout** | Optional: maximum age of a unit's feedback to count as confirmation. Empty = no check. | empty |
| **Failsafe power** | Power the units ramp up to when the rule is "blind" (sensor loss). Safety always ramps UP, never off. | 100% |
| **Lower/upper plausibility limit** | Readings outside these limits (e.g. negative or a stuck sensor) are treated as "no value". | 0 / empty |
| **Ventilation stages** | The stage table: from which dust level which power applies (only with strategy "Stages"). | see below |
| **Proportional mapping** | Only with strategy "Proportional": power rises linearly from the lower to the upper reading, clamped between min and max power. | — |
***
### The power stages: how readings become a decision
By default the Rule Engine works with a simple stage table: *the dirtier the air, the more power.* The default stages (PM10):
| Dust level in the air | Unit power |
| --------------------------------- | ---------- |
| Very clean (below 75 µg/m³) | Off |
| Slightly elevated (from 75 µg/m³) | 40% |
| Clearly elevated (from 200 µg/m³) | 60% |
| High (from 400 µg/m³) | 80% |
| Very high (from 650 µg/m³) | 100% |
Two things are cleverly solved here:
* **The worst value counts.** If several measuring devices hang in the hall, the Rule Engine (default setting "Maximum") follows the device with the highest reading. A single smoky workstation is therefore never "averaged away".
* **Short spikes are ignored.** A single measurement spike — say, from a passing forklift — does not trigger a reaction yet. Only when an elevated value persists for a while does the unit react. This keeps operation calm.
You can adapt the stages to your hall in the **Expert → Ventilation stages** tab.
***
### Schedules: your wishes take precedence
You find schedules under **Settings → Schedules**. With them you give the automation a frame. A schedule entry always consists of: a **name**, the **weekdays**, a **time from–to**, a **setpoint** and a **type of intervention** (in the interface: "Type"). There are three types:
#### 1. Minimum operation ("at least this much")
*"During this time window the unit runs at least at X%."*
The automation may give **more** power at any time if the air is bad — but never less than your minimum. The unit therefore never switches off during this window.
**Typical use:** base extraction during working hours. *Example: Monday to Friday, 6:00–16:00, minimum operation 40%.* Even with perfectly clean air the unit then runs at 40% — if dust rises, it automatically ramps up.
#### 2. Upper limit / quiet hours ("at most this much")
*"During this time window the unit runs at most at X%."*
The automation may give less, but never more than your upper limit — no matter what the sensors report.
**Typical use:** night quiet hours. *Example: daily 22:00–6:00, upper limit 30%.* The unit stays quiet at night, even if a reading briefly rises.
**Special case upper limit 0%:** This means *"during this window the unit is off — period."* This deliberately also applies if a measuring device fails: an off-window means off, for example in an empty hall after closing time.
#### 3. Force fixed value ("exactly this much")
*"During this time window the unit runs at exactly X% — no matter what else applies."*
The fixed value overrides everything: the readings, every minimum and every upper limit. It is the strongest tool and intended for special cases — such as a demonstration, maintenance or deliberate temporary manual operation.
If several fixed values overlap in time, the **priority** you assign on the entry decides: the entry with the higher priority wins.
#### How the three types get along
If several entries are active at the same time, a fixed order of precedence applies — deliberately built so that **safety always wins**:
1. First, the automation calculates its proposal from the readings.
2. Then the **upper limit** is applied (caps upwards).
3. Then the **minimum operation** (raises from below) — **the minimum beats the upper limit**. Example: at night "at most 30%" applies, but a safety minimum of 50% for a critical area prevails.
4. Finally a **fixed value**, if present — it overrides everything.
#### Good to know
* **Time windows may cross midnight** (e.g. 22:00–6:00).
* **Every entry has a switch to activate/deactivate it** — this way you can temporarily disable an entry without deleting it.
* **The setpoint percentage applies exactly only to the AirDome.** All other devices can only switch on/off: any value above 0% turns them ON, 0% means OFF.
* While editing, the dialog shows a live summary under **"In plain words"** of what the entry will do — e.g. *"Sets Mon–Fri, 06:00–16:00, to exactly 40%."*
***
### "Set now": the quick manual intervention
With the **"Set now"** button on each rule you immediately force a fixed power — regardless of the sensors:
1. Choose the **power**: Off, 25%, 50%, 75% or 100%.
2. Choose the **duration**: 1, 2, 4 or 8 hours.
3. Click **"Apply"**.
Technically this creates a high-priority time window for today (type "Force fixed value"). You will find it under **Settings → Schedules** and can delete or deactivate it there early at any time. After the duration expires, normal automation takes over again automatically.
***
### Why do some things not happen immediately? Inertia as protection
The Rule Engine is deliberately not a "nervous" system. It protects your units from constant back and forth. You will notice this in four places:
**1. Commands go out immediately — confirmations take time.** When you save a rule or a schedule, the Rule Engine sends the matching command to the unit right away. The unit's **feedback** ("I'm now really running at 40%") only arrives with the next regular device report — this can take a few minutes. During this time the device status shows "Command sent". This is normal and not an error.
**2. Small changes are deliberately skipped.** If the calculated target only changes minimally (less than the deadband, 10 percentage points by default), the Rule Engine does not adjust the unit. The unit's tolerance window would swallow the difference anyway — and every unnecessary adjustment command means wear. The status display then reads: *"Change too small – not sent (protects devices)."*
**3. There is a rest period between two adjustments.** The automation does not adjust the power every minute; after each change it observes a rest phase (minimum hold time, 15 minutes by default). Exceptions: when **you** deliberately change something ("Set now", new schedule) or when **safety** demands it, action is taken immediately.
**4. Switching on happens in two steps.** For units with adjustable air volume (AirDome), the Rule Engine first switches on the motor. Only when the unit reports back that the motor is running is the desired air volume set. Right after switching on, the unit may therefore run at a different power than configured for a few minutes — it is then readjusted automatically. In the interface you see two steps on the device for this: *"Switched on ✓"* and *"Adjusting volume flow …"*.
***
### The device status: what the indicators mean
For each unit you can see in the expanded rule card (and in the diagnostics) where it currently stands in the reconciliation:
| Indicator | Meaning | What you should do |
| ------------------ | ---------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Change queued** | A change is pending, the command has not been sent yet | Nothing — wait a moment |
| **Command sent** | The command is on its way, the unit's confirmation is still pending | Nothing — the confirmation typically arrives within a few minutes |
| **Confirmed** | The unit is verifiably running as desired | Nothing — all good |
| **Send failed** | The command did not get through; the Rule Engine retries automatically | If it stays this way permanently: check the unit and its connection on site |
| **Device offline** | The unit no longer reports in | Check the unit on site (power, connection) |
After every save, the interface automatically watches the devices closely until all commands are confirmed — you see the progress live on each device and as a status indicator in the card row, even when the card is collapsed.
***
### Built-in safety: failsafes and protection mechanisms
The Rule Engine has several protection mechanisms firmly built in. You don't have to configure anything for them — they are always active:
**Failsafe on sensor loss — full power, never off.** When all measuring devices of a rule fail or stop delivering values for too long (sensor timeout, 30 minutes by default), the Rule Engine is "blind". Then the principle is: better to extract too much than too little — the units ramp up to a safe, high value (failsafe power, 100% by default). The failsafe acts **immediately**, without any rest period. The interface shows a red notice for this: *"Safety mode: no fresh sensor data — running at the safe level."* The only exception: a deliberate off-window (upper limit 0%) stays off even in failsafe — e.g. in an empty hall after closing time.
**Single sensor failure — the others take over.** If only some of the measuring devices fail, no failsafe is triggered: offline sensors and sensors with outdated values are automatically removed from the calculation, and the rule keeps running normally with the remaining sensors.
**Outlier protection.** Implausible readings (e.g. negative values or a stuck sensor, configurable via the plausibility limits) are treated as "no value". Short measurement spikes are filtered out by the smoothing before any control action is taken.
**Safety wins with schedules.** In the order of precedence of schedules, minimum operation beats the upper limit — a safety minimum for a critical area therefore prevails even against a night-quiet upper limit.
**Device protection: deadband and rest period.** Minimal target changes are not transmitted (deadband), and there is a rest phase between two adjustments (minimum hold time). This protects motors and filters from constant back and forth. Your deliberate interventions and the failsafe still always act immediately.
**Pausing a rule means freezing, not switching off.** When you deactivate an entire rule, the Rule Engine stops controlling these units — they remain in their last state. Pausing never switches anything off automatically.
**Failed attempts are limited.** If the Rule Engine cannot reach a unit, it retries at growing intervals — but never in rapid fire. After several failed attempts it pauses and automatically tries again later. You can always see the current state on the device status.
**No sending to offline devices when the target is "off".** If a unit is offline and the target would be "off" anyway, the Rule Engine deliberately does not send a command into the void — the device status then shows "Device offline".
***
### Test mode and live operation
Each rule is either **Live** or in **Test mode** (shown in the card row):
* **Live:** Commands are really sent to the devices.
* **Test mode:** The Rule Engine computes normally and logs what it *would* do — but sends **no** commands. The expanded card then permanently shows the notice: *"Test mode – no commands are sent to devices."* This lets you observe a new rule first, before it really intervenes.
Switching between test mode and live can only be done by an administrator — contact support for this.
***
### Diagnostics: tracing what happened
Via the gauge icon on each rule you open the **Diagnostics**. It has four tabs:
| Tab | Content |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Status** | The current state of the rule: mode, target power, combined reading, what is currently driving the rule and the reason for the last decision — in plain language, e.g. *"Change too small – not sent (protects devices)"*. |
| **Decision log** | The history: when the automation decided what, with which reading and for what reason. |
| **Send attempts** | Every single command to the devices: time, command, whether it was accepted and the result. Entries marked "Test" were only logged, not sent (test mode). |
| **Device status** | The live reconciliation status of each device: status, setpoint, number of attempts and last attempt. |
With **"Refresh"** you reload all tabs. The diagnostics are also the right tool for support — here it is written in black and white what happened when.
***
### Frequently asked questions
**"I switched the unit off at the device — why did it turn back on?"** Because an active rule specifies the target "ON". The Rule Engine restores the target state during reconciliation. If you want to deliberately switch the unit off, use the rules or schedules — for example "Set now" with power "Off" for a certain period.
**"I deleted the schedule entry with the minimum operation — why did the unit switch off?"** Without a minimum, the air quality alone decides. If the air was clean, "off" is the correct automatic decision. The minimum was the only reason the unit was running.
**"I saved something, but nothing is happening at the unit."** The command is usually already on its way — look at the device status in the expanded card: if it says "Command sent", the Rule Engine is just waiting for the unit's confirmation. This typically takes a few minutes. Also check whether the rule is in **test mode** — then no commands are sent at all.
**"Why does the unit show 12,700 instead of the configured 12,800?"** Units never hold their air volume to the decimal point. As long as the value lies within the tolerance window around the target, everything is set correctly — the Rule Engine deliberately does not readjust.
**"What is the difference between 'pausing a rule' and 'deactivating a schedule entry'?"** Pausing the **rule** (switch on the card) = stopping the automation completely; the units stay as they currently are. Deactivating a **schedule entry** (switch on the entry) = only this one entry is dropped; the automation keeps running and recalculates the target — the unit may then ramp up or down.
**"Saved a small change, but the unit doesn't react?"** Very small changes (less than the deadband, 10 percentage points by default) are deliberately not transmitted by the Rule Engine — they would lie within the unit's tolerance window anyway and would only cause wear. The status display points this out in that case.
**"My AirWatch is shown as 'No fresh data' on the rule — what does that mean?"** The sensor has not delivered a reading for longer than allowed (sensor timeout, 30 minutes by default). It temporarily doesn't count. If all sensors of a rule deliver values that are too old, the safety mode kicks in.
**"Can I use multiple AirWatch in one rule?"** Yes — that is exactly what the Rule Engine is built for. Simply select all measuring devices of the area; the Rule Engine automatically combines the values (by default the worst AirWatch counts) and independently removes failed sensors from the calculation. Details in the chapter "Multiple AirWatch, multiple units".
**"Can I create multiple rules for the same site?"** Yes — for example one rule per hall area, each with its own AirWatch and its own devices. Just make sure that **one device is not controlled by two rules at the same time**, otherwise the rules will get in each other's way.
***
### Reference: the expert settings in detail
This chapter is aimed at trained users. You find the expert settings under **Settings → tab "Expert"** — they are only shown after a safety prompt ("I understand"). All settings apply per rule; other rules remain untouched. Changes only take effect with **"Save"**.
> **Principle:** The default values are designed for typical welding and hall applications. Always change only one setting at a time and observe the effect via the decision log in the diagnostics.
#### Control strategy
*Default: Stages*
Determines how a reading becomes a target power:
* **Stages:** The rule works with a stage table — from threshold X, power Y applies (see "Ventilation stages" below). Predictable and robust; the right choice for almost all applications.
* **Proportional:** Power rises smoothly (linearly) with the reading — without fixed stages (see "Proportional mapping" below). Useful when a unit with continuously adjustable air volume (AirDome) should breathe along as evenly as possible.
Depending on the selection, either the stage editor or the proportional editor is shown below.
#### Measured value
*Default: PM10 (coarse dust)*
Which dust value the rule reacts to:
* **PM10 (coarse dust):** The usual reference value for welding fumes and hall dust.
* **PM2.5 (fine dust):** Reacts to the finer dust fraction. Only choose this if your risk assessment explicitly targets PM2.5.
Important: The thresholds of the ventilation stages always refer to the measured value chosen here. If you switch the measured value, you should also review the stage thresholds — PM2.5 values are typically much lower than PM10 values.
#### Combine sensors
*Default: Maximum (safest)*
How the values of several AirWatch are combined into **one** control value:
| Option | Behaviour | When useful |
| -------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| **Maximum (safest)** | The worst sensor determines the power | Recommended. No workstation is "averaged away" — a single smoky area is enough for a reaction |
| **Average** | Mean of all sensors | Large, well-mixed halls where the overall load counts |
| **Minimum** | The best sensor determines the power | Only for special cases — the rule only reacts when **all** areas are polluted |
| **Weighted** | Weighted mean (weights per sensor, assigned via support) | When individual sensors are more important than others, e.g. at the main workstation |
Offline sensors and sensors with outdated values are automatically removed from the calculation with all options.
#### Smoothing
*Default: Median (recommended)*
Filters out short measurement spikes before any control action — say, a passing forklift or a single shower of sparks right next to the sensor:
* **Median (recommended):** The middle value within the time window. Individual outliers drop out completely — the most robust choice.
* **Mean:** The average within the time window. Outliers are dampened but still contribute.
* **None (latest value):** The newest reading always counts. Fastest reaction, but also the most nervous — only useful when very fast reaction matters more than smooth operation.
#### Smoothing window
*Default: 10 minutes*
The period over which each sensor is smoothed (works together with the smoothing above).
* **Larger value** → calmer but more sluggish behaviour: the rule reacts later to real changes.
* **Smaller value** → faster reaction, but more restlessness from short fluctuations.
#### Compute interval
*Default: 10 minutes*
How often the Rule Engine recalculates and reconciles target with reality. Determines the base cycle of the whole system: more frequent calculation means faster reaction to reading changes, but also more frequent opportunities to intervene. Values below 5 minutes bring little benefit in practice, since device reports only arrive every few minutes anyway.
#### Deadband
*Default: 10 percentage points*
The minimum change of the target value before a new command is sent to the devices. Example with the default value: the unit runs at 40%, the newly calculated target is 45% — the difference (5 percentage points) is below the deadband, nothing is sent. Only from 50% would it be adjusted.
* **Larger value** → fewer adjustment commands, less wear, but coarser control.
* **Smaller value** → finer control, but more switching operations.
* **0** disables this protection — not recommended.
Note: A switch between ON and OFF as well as your deliberate interventions ("Set now", new schedules) are not subject to the deadband.
#### Minimum hold time
*Default: 15 minutes*
The rest period between two automatic adjustments. After each change, the automation waits at least this long before adjusting again — even if the reading changes in the meantime.
* **Exceptions (always act immediately):** your deliberate interventions ("Set now", schedule saved) and the failsafe.
* **Larger value** → calmer operation; **smaller value** → faster tracking.
#### Sensor timeout
*Default: 30 minutes*
From this age a reading counts as outdated: the sensor then no longer contributes (shown as "No fresh data" on the rule card). If **all** sensors of a rule deliver values that are too old, the failsafe kicks in.
* **Too small:** sensors drop out already during normal reporting pauses, the failsafe kicks in unnecessarily often.
* **Too large:** the rule may keep working with outdated values for a long time.
* As a rule of thumb: at least twice the normal reporting interval of your sensors.
#### Unit feedback timeout
*Default: empty (no check)*
Optional: the maximum age of a unit's feedback for it to count as **confirmation** of a command. If a value is set, a command only counts as "Confirmed" when the matching feedback from the unit is fresh enough. If the field stays empty, the age of the feedback is not checked. Only set a value here if you deliberately want to verify confirmations more strictly — a value that is too small causes commands to remain stuck as "Sent" permanently.
#### Failsafe power
*Default: 100%*
The power the units ramp up to when the rule is "blind" (all sensors failed or outdated). Safety always ramps **up**, never off — which is why no "off" can be stored here that would apply while flying blind. Only lower this if full power in the failsafe case is demonstrably unnecessary or unreasonable (e.g. noise protection) — and your risk assessment supports it.
#### Lower / upper plausibility limit
*Default: 0 µg/m³ / empty (no upper limit)*
Readings outside these limits are treated as "no value":
* **Lower limit:** values below it (e.g. negative readings due to a sensor fault) are discarded.
* **Upper limit:** values above it (e.g. a stuck sensor permanently reporting an extreme value) are discarded. Empty = no upper limit.
Be careful with the upper limit: if it is set too low, **real** high pollution values are discarded as well — and the rule fails to react exactly when it matters most.
#### Ventilation stages
*Only with control strategy "Stages". Default table: 0 → Off, from 75 → 40%, from 200 → 60%, from 400 → 80%, from 650 → 100% (µg/m³, PM10)*
The stage table: each row consists of a threshold **"From (µg/m³)"** and a **"Power (%)"**. From the threshold onwards, the extraction runs at the given power until the next higher stage is reached. Use **"Add stage"** to add rows and the trash can icon to remove them.
Practical notes:
* The first stage (0 → 0%) defines the "air is clean" state: unit off.
* The thresholds refer to the chosen **measured value** (PM10 or PM2.5) **after** smoothing and sensor combination.
* Stages that lie too close together lead to frequent switching back and forth — deadband and minimum hold time dampen this, but cannot prevent it entirely.
* For devices that can only switch on/off (everything except the AirDome), only this counts: power 0% = OFF, anything above = ON.
#### Proportional mapping
*Only with control strategy "Proportional"*
Power rises linearly from the lower to the upper reading, clamped between min and max power. Four values:
| Field | Meaning |
| --------------- | ----------------------------------------- |
| **Reading min** | Up to this reading, the min power applies |
| **Reading max** | From this reading, the max power applies |
| **Power min** | Lower power limit (with clean air) |
| **Power max** | Upper power limit (with heavy pollution) |
*Example:* reading min 50, reading max 400, power min 20%, power max 100% — at 225 µg/m³ (the middle) the unit runs at 60%. Below 50 µg/m³ it stays at 20%, above 400 µg/m³ at 100%.
***
*In short: with rules and schedules you describe how your air should be — the Rule Engine takes care of making it so, around the clock. It checks constantly, corrects gently and always takes the safe path when in doubt.*
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kemperconnect.de/rule-engine/overview.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.