> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/input-change-events.md).

# События изменения входов

Как таблица событий изменения входов обнаруживает дискретные изменения входов и как выполнять к ней запросы.

Преобразование событий изменения входов записывает каждый раз, когда дискретный вход устройства меняет состояние и это изменение соответствует настроенной `input_change` правилу. Каждая строка в `processed_common_data.input_change_events` представляет одно совпавшее изменение: какой вход переключился, его новое значение, когда и где это произошло и какому правилу оно соответствовало.

Как и события водителя на основе правил, Input change events запускается по фиксированному расписанию, а не непрерывно. Функция обновления пересчитывает окно Сырые данные каждые 15 минут, поэтому новая строка может отставать от фактического изменения входа на устройстве до 15 минут.

{% hint style="info" %}

* Все метки времени хранятся в UTC.
* Только изменения, которые соответствуют настроенному `input_change` правилу, создают строку. Активность дискретного входа, которая не соответствует ни одному правилу, по-прежнему доступна в `raw_telematics_data.additional_data`, просто не отображается здесь.
  {% endhint %}

## Таблица вывода: processed\_common\_data.input\_change\_events

Каждая строка представляет одно обнаруженное изменение входных данных, которое соответствовало `input_change` правилу. Таблица индексируется по `device_id`, `device_time`, и `rule_id`.

<table><thead><tr><th width="180">Поле</th><th width="100">Тип</th><th>Описание</th></tr></thead><tbody><tr><td><code>device_id</code></td><td>целое число</td><td>Идентификатор устройства.</td></tr><tr><td><code>object_id</code></td><td>целое число</td><td>Идентификатор Объект (транспортное средство/Актив), связанный с устройством.</td></tr><tr><td><code>метка_объекта</code></td><td>текст</td><td>Читаемое человеком имя Объекта. Уже денормализовано в эту таблицу, поэтому, в отличие от Поездки, не требуется join к <code>raw_business_data.objects</code> необходимо для его отображения.</td></tr><tr><td><code>device_time</code></td><td>timestamp</td><td>Момент, когда изменение входа произошло на устройстве.</td></tr><tr><td><code>rule_id</code></td><td>целое число</td><td>Идентификатор <code>input_change</code> правила, которое сработало.</td></tr><tr><td><code>input_number</code></td><td>целое число</td><td>Номер входа, начиная с 1, соответствующий позиции в <code>discrete_inputs</code> битовой строке в <code>raw_telematics_data.additional_data</code>.</td></tr><tr><td><code>input_value</code></td><td>целое число</td><td>Новое значение входа после изменения: <code>0</code> или <code>1</code>.</td></tr><tr><td><code>event_type</code></td><td>текст</td><td>Всегда <code>input_change</code>.</td></tr><tr><td><code>event_comment1</code></td><td>текст</td><td>Первый комментарий, настроенный в совпавшем правиле.</td></tr><tr><td><code>event_comment2</code></td><td>текст</td><td>Второй комментарий, настроенный в совпавшем правиле.</td></tr><tr><td><code>zone_id</code></td><td>целое число</td><td>Идентификатор зоны, в которой находилось устройство в момент изменения. Null, если правило не связано с зоной.</td></tr><tr><td><code>zone_label</code></td><td>текст</td><td>Имя этой зоны. Null, если правило не связано с зоной.</td></tr><tr><td><code>latitude</code></td><td>numeric</td><td>Широта в момент изменения, в градусах.</td></tr><tr><td><code>longitude</code></td><td>numeric</td><td>Долгота в момент изменения, в градусах.</td></tr><tr><td><code>created_at</code></td><td>timestamp</td><td>Когда строка была записана плановым обновлением.</td></tr></tbody></table>

Примеры ниже показывают распространенные шаблоны запросов. Базовый запрос возвращает недавние изменения входов, упорядоченные по устройству и времени. Второй фильтрует по конкретному номеру входа и значению. Третий фильтрует по конкретному правилу.

{% tabs %}
{% tab title="Базовый запрос" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    Объект_метка,
    device_time,
    input_number,
    входное значение,
    zone_label
FROM processed_common_data.input_change_events
WHERE device_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, device_time;
```

{% endcode %}
{% endtab %}

{% tab title="Фильтр по вводу" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    Объект_метка,
    device_time,
    входное значение,
    zone_label
FROM processed_common_data.input_change_events
WHERE input_number = 3
  AND input_value = 1
  AND device_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, device_time;
```

{% endcode %}
{% endtab %}

{% tab title="Фильтр по правилу" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    Объект_метка,
    device_time,
    input_number,
    input_value
FROM processed_common_data.input_change_events
WHERE rule_id = 12345
  AND device_time >= CURRENT_DATE - INTERVAL '7 days'
ORDER BY device_id, device_time;
```

{% endcode %}
{% endtab %}
{% endtabs %}

## Как обнаруживаются изменения входа

Строка в этой таблице не записывается в момент, когда на устройстве изменяется вход. Она записывается при следующем запланированном обновлении, которое повторно оценивает окно Сырых данных относительно последнего известного состояния каждого устройства.

{% stepper %}
{% step %}

#### Запланированное обновление

Каждые 15 минут функция обновления считывает самое последнее окно строк из `raw_telematics_data.additional_data`.
{% endstep %}

{% step %}

#### Сравнение с последним известным состоянием

Текущие `discrete_inputs` и `discrete_outputs` битовые строки сравниваются побитово со состоянием, записанным при предыдущем обновлении. Дальнейшее рассмотрение получают только те биты, которые фактически переключились.
{% endstep %}

{% step %}

#### Сопоставление с правилами

Переключившийся бит становится кандидатом на событие, если номер его входа и новое значение соответствуют условию, настроенному в `input_change` правиле. См. [Срабатывание по входам](/docs/user/ru/guide/events-and-notifications/inputs-and-outputs/input-triggering.md) для описания того, как настраиваются эти правила, и [Справочник типов правил](https://navixy.com/docs/navixy-api/user-api/resources/tracking/tracker/rules/rule_types) для полного списка типов правил.
{% endstep %}

{% step %}

#### Проверка зоны

Если совпавшее правило связано с Зона, обновление подтверждает, что устройство находилось внутри этой зоны в момент изменения перед записью строки. Правила, которые не связаны с зоной, пропускают эту проверку.
{% endstep %}

{% step %}

#### Обновление последнего известного состояния

После завершения обновления последнее битовое состояние каждого устройства записывается для сравнения при следующем запуске.
{% endstep %}
{% endstepper %}

## Настройка

События изменения ввода не настраиваются через рабочий процесс Transformation Builder так же, как это делается для Поездки. Строки, которые отображаются здесь, напрямую отражают, какие `input_change` правила настроены в вашей учетной записи: чтобы изменить то, что записывается, добавляйте, редактируйте или удаляйте соответствующие правила, а не шаблон преобразования. См. [Срабатывание по входам](/docs/user/ru/guide/events-and-notifications/inputs-and-outputs/input-triggering.md) как настроить эти правила.

## Следующие шаги

* [**Обычные преобразования**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations.md): Назад к индексу преобразований.
* [**Поездки**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/trips.md): Родственное преобразование, которое также выполняется по расписанию на основе сырых телематических данных.
* [**События водителя на основе правил**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/rule-based-driver-events.md): Родственное преобразование, которое записывает нарушения вождения по тому же 15-минутному расписанию.
* [**Слой сырых данных**](/docs/analytics/ru/iot-query/schema-overview/bronze-layer.md): Изучить `additional_data`, исходная таблица, которая передает события изменения входных данных.
* [**Срабатывание по входам**](/docs/user/ru/guide/events-and-notifications/inputs-and-outputs/input-triggering.md): Настройте `input_change` правила, определяющие, какие изменения входных данных записываются здесь.


---

# 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://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/common-transformations/input-change-events.md?ask=<question>&goal=<user_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.