> 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/es/iot-query/schema-overview/transformation-layer/common-transformations/input-change-events.md).

# Eventos de cambio de entrada

Cómo la tabla de eventos de cambio de entrada detecta cambios discretos de entrada y cómo consultarla.

La transformación de eventos de cambio de entrada registra cada vez que una entrada discreta de un dispositivo cambia de estado y ese cambio coincide con una `input_change` regla. Cada fila en `processed_common_data.input_change_events` representa un cambio coincidente: qué entrada cambió de estado, su nuevo valor, cuándo y dónde ocurrió, y qué regla cumplió.

Al igual que los eventos de conductor basados en reglas, los eventos de cambio de entrada se ejecutan según una programación fija en lugar de de forma continua. Una función de actualización reevalúa una ventana de Datos brutos cada 15 minutes, por lo que una nueva fila puede tardar hasta 15 minutes en reflejar el cambio real de la entrada en el dispositivo.

{% hint style="info" %}

* Todas las marcas de tiempo se almacenan en UTC.
* Solo los cambios que coinciden con una regla configurada `input_change` generan una fila. La actividad de entrada discreta que no coincide con ninguna regla sigue disponible en `raw_telematics_data.additional_data`, solo que no se muestra aquí.
  {% endhint %}

## Tabla de salida: processed\_common\_data.input\_change\_events

Cada fila representa un cambio de entrada detectado que coincidió con una `input_change` regla. La tabla se indexa por `device_id`, `device_time`, y `rule_id`.

<table><thead><tr><th width="180">Campo</th><th width="100">Tipo</th><th>Descripción</th></tr></thead><tbody><tr><td><code>device_id</code></td><td>entero</td><td>Identificador del dispositivo.</td></tr><tr><td><code>id_del_objeto</code></td><td>entero</td><td>Identificador del objeto (vehículo/activo) asociado con el dispositivo.</td></tr><tr><td><code>etiqueta de objeto</code></td><td>texto</td><td>Nombre de Objeto legible para humanos. Ya está desnormalizado en esta tabla, así que, a diferencia de Viajes, no se hace join con <code>raw_business_data.objects</code> se necesita para mostrarlo.</td></tr><tr><td><code>device_time</code></td><td>timestamp</td><td>Momento en que se produjo el cambio de la entrada en el dispositivo.</td></tr><tr><td><code>rule_id</code></td><td>entero</td><td>Identificador de la <code>input_change</code> regla que coincidió.</td></tr><tr><td><code>input_number</code></td><td>entero</td><td>Número de entrada, basado en 1, que coincide con la posición en la <code>discrete_inputs</code> cadena de bits en <code>raw_telematics_data.additional_data</code>.</td></tr><tr><td><code>input_value</code></td><td>entero</td><td>Nuevo valor de la entrada después del cambio: <code>0</code> o <code>1</code>.</td></tr><tr><td><code>tipo de evento</code></td><td>texto</td><td>Siempre <code>input_change</code>.</td></tr><tr><td><code>comentario del evento 1</code></td><td>texto</td><td>Primer comentario configurado en la regla coincidente.</td></tr><tr><td><code>comentario del evento 2</code></td><td>texto</td><td>Segundo comentario configurado en la regla coincidente.</td></tr><tr><td><code>id de zona</code></td><td>entero</td><td>Identificador de la Zona en la que estaba el dispositivo cuando ocurrió el cambio. Nulo si la regla no está vinculada a una zona.</td></tr><tr><td><code>etiqueta de zona</code></td><td>texto</td><td>Nombre de esa zona. Nulo si la regla no está vinculada a una zona.</td></tr><tr><td><code>latitude</code></td><td>numeric</td><td>Latitud en el momento del cambio, en grados.</td></tr><tr><td><code>longitude</code></td><td>numeric</td><td>Longitud en el momento del cambio, en grados.</td></tr><tr><td><code>created_at</code></td><td>timestamp</td><td>Cuando la fila fue escrita por la actualización programada.</td></tr></tbody></table>

Los ejemplos a continuación muestran patrones comunes de consulta. La consulta básica devuelve los cambios recientes de las entradas ordenados por dispositivo y tiempo. La segunda filtra por un número de entrada y un valor específicos. La tercera filtra por una regla específica.

{% tabs %}
{% tab title="Consulta básica" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECCIONAR
    device_id,
    Objeto,
    device_time,
    número de entrada,
    valor de entrada,
    etiqueta de zona
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="Filtrar por entrada" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECCIONAR
    device_id,
    Objeto,
    device_time,
    valor de entrada,
    etiqueta de zona
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="Filtrar por regla" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECCIONAR
    device_id,
    Objeto,
    device_time,
    número de entrada,
    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 %}

## Cómo se detectan los cambios de entrada

Una fila en esta tabla no se escribe en el instante en que una entrada cambia en el dispositivo. Se escribe en la siguiente actualización programada, que reevalúa una ventana de Datos brutos frente al último estado conocido de cada dispositivo.

{% stepper %}
{% step %}

#### Actualización programada

Cada 15 minutos, la función de actualización lee la ventana más reciente de filas de `raw_telematics_data.additional_data`.
{% endstep %}

{% step %}

#### Comparando con el último estado conocido

El valor actual de cada dispositivo `discrete_inputs` y `discrete_outputs` las cadenas de bits se comparan, bit por bit, con el estado registrado en la actualización anterior. Solo los bits que realmente cambiaron se consideran más adelante.
{% endstep %}

{% step %}

#### Coincidencia con reglas

Un bit que cambió de estado se convierte en un evento candidato si su número de entrada y su nuevo valor coinciden con la condición configurada en una `input_change` regla. Consulte [Activación por entrada](/docs/user/es/guide/events-and-notifications/inputs-and-outputs/input-triggering.md) para saber cómo se configuran estas reglas, y la [Referencia de tipos de reglas](https://navixy.com/docs/navixy-api/user-api/resources/tracking/tracker/rules/rule_types) para ver la lista completa de tipos de regla.
{% endstep %}

{% step %}

#### Comprobación de zona

Si la regla coincidente está vinculada a una Zona, la actualización confirma que el dispositivo estaba dentro de esa zona en el momento del cambio antes de escribir una fila. Las reglas que no están vinculadas a una zona omiten esta comprobación.
{% endstep %}

{% step %}

#### Actualización del último estado conocido

Una vez que se completa una actualización, se registra el estado binario más reciente de cada dispositivo para compararlo en la siguiente ejecución.
{% endstep %}
{% endstepper %}

## Personalización

Los eventos de cambio de entrada no se personalizan mediante un flujo de trabajo de Transformation Builder de la misma manera que Viajes. Las filas que aparecen aquí reflejan directamente cualquiera de `input_change` las reglas configuradas en su cuenta: para cambiar lo que se registra, agregue, edite o elimine las reglas correspondientes en lugar de una plantilla de transformación. Consulte [Activación por entrada](/docs/user/es/guide/events-and-notifications/inputs-and-outputs/input-triggering.md) para saber cómo configurar estas reglas.

## Próximos pasos

* [**Transformaciones comunes**](/docs/analytics/es/iot-query/schema-overview/transformation-layer/common-transformations.md): Volver al índice de transformaciones.
* [**Viajes**](/docs/analytics/es/iot-query/schema-overview/transformation-layer/common-transformations/trips.md): Una transformación hermana que también se ejecuta según un horario sobre Datos brutos de telemática.
* [**Eventos de Conductor basados en reglas**](/docs/analytics/es/iot-query/schema-overview/transformation-layer/common-transformations/rule-based-driver-events.md): Una transformación hermana que registra infracciones de Manejo en el mismo horario de 15 minutos.
* [**Capa de Datos brutos**](/docs/analytics/es/iot-query/schema-overview/bronze-layer.md): Explorar `additional_data`, la tabla de origen que alimenta eventos de cambio de entrada.
* [**Activación por entrada**](/docs/user/es/guide/events-and-notifications/inputs-and-outputs/input-triggering.md): Configurar las `input_change` reglas que determinan qué cambios de entrada se registran aquí.


---

# 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/es/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.