> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/rules-engine/triggers/multiple-devices.md).
# One Trigger for Multiple Devices
Use one Kilo trigger for several devices, with each device evaluated separately and able to start the same rule.
A trigger watches device readings for a condition, such as a cold room being too warm. When several assets need the same monitoring, select them in one trigger and connect that trigger to a rule. You can maintain one condition and one response instead of copying the setup for every asset.
Each watched device is evaluated separately. Two rooms can exceed the temperature limit at different times, qualify independently, and start the same rule with their own device identity. For trigger creation and rule connection, see [Triggers](/rules-engine/triggers.md).
## What stays independent
Every watched device has its own condition state and, when configured, its own start and clear waits. One room becoming active or returning to normal does not advance or reset another room's wait.
AND/OR choices combine readings within each device's evaluation. Selecting several rooms does not mean they must all be too warm at once. The selected devices belong to this trigger; the selection does not create a reusable group elsewhere in Kilo.
## Select the devices
1. Add the condition's normalized keys—the common names of the readings it uses. Include any keys needed by a separate clear condition.
2. Under **Devices**, use **Search devices** to find devices that provide those readings. A compatible device supplies at least one required key; the final selection must cover all keys.
3. Select the devices you need. **Select all shown** adds the currently loaded eligible results. Use **Load more devices** to load further results before adding them. When all results for the current search are loaded, the button reads **Select all**.
4. Search again if needed. Earlier selections remain selected; **Clear selection** empties the selection.
5. Review **How this trigger will run** before clicking **Create trigger** or **Save changes**.
A trigger needs at least one watched device and accepts up to **500 selected devices** in total, including devices that only provide shared readings. Up to **10 distinct normalized keys** can be used across the start and clear conditions.
If a device is missing, check its **Mapping** tab. The relevant sensor needs an incoming source mapping. When two mapped sensors on one device answer the same key, the form directs you to resolve that ambiguity on **Mapping**; there is no sensor selector in the trigger form. Review existing uses before changing a device's mapping.
Each evaluated device gets a row in the preview.
## Use several readings from each device
Suppose each pump provides vibration and running-state readings. A condition could require vibration above a chosen limit **AND** the pump to be running. Kilo evaluates that pair separately for each selected pump.
For this arrangement, every watched pump supplies both readings. A missing key is not supplied automatically by another pump unless the selection forms a valid shared-reading arrangement.
## Use one shared reading
A **shared reading** is supplied by one selected device and used in every watched device's evaluation. For example, several doors can each provide their own open state while one building controller supplies a heating-on reading. Each door is checked against the same heating status.
To configure this example:
1. Add the door-state and heating-state keys and their comparisons to the condition.
2. Select the door devices and the controller supplying the heating state.
3. Check the key description **Devices answering this key are the watched ones**. For this example it should describe the door-state key.
4. In the preview, confirm that every door has an **Evaluated device** row and that **Uses** identifies the controller's shared heating reading.
For each additional key, either every watched device must supply it, or exactly one selected device must supply it for all of them. A shared provider can itself be a watched device. Different additional keys can have different shared providers; each shared key still needs one unambiguous provider.
A key supplied by only some watched devices or several possible shared providers is rejected unless every watched device supplies it individually. Resolve the preview's explanation by changing the selection or mappings. A change to a shared reading can affect several device evaluations even though their states and waits remain separate.
## Read the run preview
The form determines which devices can be evaluated from the selected keys and their mappings. Check the displayed result rather than assuming every selected device is watched independently.
| Column | Meaning |
| -------------------- | ------------------------------------------------------------------------------------------- |
| **Check** | The row number of an independent device evaluation. |
| **Evaluated device** | The device whose condition is being watched and whose identity goes to the rule. |
| **Uses** | The input readings for that evaluation, including the named provider of any shared reading. |
The controller in the door example supplies an input but has no door-evaluation row. Save only after the expected doors and inputs appear. If the preview reports an unanswered or ambiguous key, fix it before saving.
## Identify the affected device
In a connected rule's **Set Alarm** node, include the watched device's name in **Motivation Message**:
```cel
"Temperature needs attention: " + vars.device_name
```
The name is not inserted automatically. The rule also receives the watched device and sensor IDs. It receives a trigger signal, not an individual sensor reading, so **`vars.value` is unavailable**. Use enrichment if the response needs another reading; see [CEL Reference](/rules-engine/cel-reference.md#available-after-the-start-event).
## Change the selection later
Edit the trigger to add or remove devices. Review the preview and any countdown-reset warning before saving. Removing a watched device stops monitoring it and requests clearing of its associated active trigger alarms through running rules. If a dependent rule was stopped, check **Alarm → Inbox** for unresolved incidents.
A mapping-change warning beside a saved trigger means its input mapping needs review. Check the device's **Mapping** tab, then edit the trigger and verify its selected inputs and preview. A mapping change does not automatically redesign the trigger for you.
## See also
* [Triggers](/rules-engine/triggers.md) — create the condition and connect a response
* [Trigger Timing](/rules-engine/triggers/trigger-timing.md) — qualify, clear, and repeat independently per device
* [Metrics](/devices/metric-templates.md) — normalized keys and mappings
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.kiloiot.io/rules-engine/triggers/multiple-devices.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
