> For the complete documentation index, see [llms.txt](https://documentation.nomos-system.com/nomos-system/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.nomos-system.com/nomos-system/integrator-en/functions/presence-detection.md).

# Presence detection

Presence detection combines components of your choice into a single answer: **is anybody on site?** That answer is offered as a device called **Presence** — automations, scenes and the usage recording work with it, and the app shows it like any other device.

Which components qualify is up to you: motion detectors and presence sensors, door contacts, but also switches or the states of other systems — anything that gives evidence of somebody being there.

## Inputs

An input is a component and one of its status values. There are two kinds:

* **Presence and absence** — two-way inputs that can report both, such as a security panel or the presence report of another system.
* **Presence only** — inputs that prove somebody is there but never the opposite. A motion detector belongs here: somebody asleep does not trigger it.

At least one two-way input has to be able to report absence, otherwise presence would stay switched on forever. The page points this out for as long as it is missing.

For every input you choose the **interpretation**: either *on* means present (inverted on request), or you enter **specific values** — a panel reporting HOME, AWAY, NIGHT, OFF and ALARM is *one* input with value lists (presence: HOME, ALARM — absence: AWAY). Use every component with every status value only once.

Two times make the interpretation practical:

* **Grace period** — how long an input still counts as present after it drops. Some sources disappear briefly and answer again a few minutes later; without a grace period every one of those gaps would count as absence right away.
* **Hold time** — how long a presence-only input keeps counting after its last trigger.

## Manual override

Presence can be set by hand at any time — in the app on the device (Automatic, Present, Absent) or through scenes. The **mode** decides how long such an override holds:

* **Assisted** — a manual *away* is dropped as soon as an input reports somebody. Otherwise whatever hangs on absence would fire while somebody is on site.
* **Timed** — like *Assisted*, and the override additionally expires by itself after the set time.
* **Fixed** — the override stands until it is lifted by hand. The inputs are then only recorded.

## Quick start

Two templates create, once, what most installations build anyway:

* **Scenes for switching by hand** — the scenes *At home* and *Away*, for pressing in the app or wiring to a push-button.
* **Automation on the status change** — two log messages and an automation that writes them: one as soon as somebody is on site, the other as soon as nobody is left. Whatever else should happen goes straight into the automation.

What comes out of this is yours afterwards: rename it, rebuild it or delete it — the function never touches it again.

## The "Presence" device

When switched on, the function creates the device **Presence**. It shows the current state, takes the manual override, and is available to automations and scenes as trigger and condition. Like any device you can rename it and assign it to a room — it can only be deleted by resetting the function.


---

# 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://documentation.nomos-system.com/nomos-system/integrator-en/functions/presence-detection.md?ask=<question>&goal=<endgoal>
```

`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.
