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

# Événements de changement d'entrée

Comment la table des événements de changement d'entrée détecte les changements d'entrée discrets et comment l'interroger.

La transformation des événements de changement d'entrée enregistre chaque fois que l'entrée discrète d'un appareil change d'état et que ce changement correspond à une `input_change` règle. Chaque ligne dans `processed_common_data.input_change_events` représente un changement correspondant : quelle entrée a basculé, sa nouvelle valeur, quand et où cela s'est produit, et quelle règle il satisfaisait.

Comme les événements du conducteur basés sur des règles, les événements de changement d'entrée s'exécutent selon un calendrier fixe plutôt qu'en continu. Une fonction d'actualisation réévalue une fenêtre de données brutes toutes les 15 minutes, de sorte qu'une nouvelle ligne peut avoir jusqu'à 15 minutes de décalage par rapport au changement réel de l'entrée sur l'appareil.

{% hint style="info" %}

* Tous les horodatages sont stockés en UTC.
* Seuls les changements qui correspondent à une `input_change` règle produisent une ligne. L'activité des entrées discrètes qui ne correspond à aucune règle reste disponible dans `raw_telematics_data.additional_data`, simplement pas affiché ici.
  {% endhint %}

## Table de sortie : processed\_common\_data.input\_change\_events

Chaque ligne représente un changement d’entrée détecté qui correspondait à un `input_change` règle. La table est indexée sur `device_id`, `device_time`, et `rule_id`.

<table><thead><tr><th width="180">Champ</th><th width="100">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>device_id</code></td><td>entier</td><td>Identifiant de l'appareil.</td></tr><tr><td><code>traceur_id</code></td><td>entier</td><td>Identifiant de l'objet (véhicule/actif) associé à l'appareil.</td></tr><tr><td><code>étiquette du Traceur</code></td><td>texte</td><td>Nom du Traceur lisible par l'humain. Déjà dénormalisé dans ce tableau, donc contrairement à Trajets, aucune jointure vers <code>raw_business_data.objects</code> est nécessaire pour l’afficher.</td></tr><tr><td><code>device_time</code></td><td>horodatage</td><td>Moment où le changement d’entrée s’est produit sur l’appareil.</td></tr><tr><td><code>rule_id</code></td><td>entier</td><td>Identifiant de la <code>input_change</code> règle correspondante.</td></tr><tr><td><code>input_number</code></td><td>entier</td><td>Numéro d’entrée, indexé à partir de 1, correspondant à la position dans la <code>discrete_inputs</code> chaîne de bits dans <code>raw_telematics_data.additional_data</code>.</td></tr><tr><td><code>input_value</code></td><td>entier</td><td>Nouvelle valeur de l’entrée après le changement : <code>0</code> ou <code>1</code>.</td></tr><tr><td><code>event_type</code></td><td>texte</td><td>Toujours <code>input_change</code>.</td></tr><tr><td><code>event_comment1</code></td><td>texte</td><td>Premier commentaire configuré sur la règle correspondante.</td></tr><tr><td><code>event_comment2</code></td><td>texte</td><td>Deuxième commentaire configuré sur la règle correspondante.</td></tr><tr><td><code>zone_id</code></td><td>entier</td><td>Identifiant de la zone géographique dans laquelle l'appareil se trouvait lorsque le changement s'est produit. Null si la règle n'est pas liée à une zone.</td></tr><tr><td><code>zone_label</code></td><td>texte</td><td>Nom de cette zone. Null si la règle n'est pas liée à une zone.</td></tr><tr><td><code>latitude</code></td><td>numérique</td><td>Latitude au moment du changement, en degrés.</td></tr><tr><td><code>longitude</code></td><td>numérique</td><td>Longitude au moment du changement, en degrés.</td></tr><tr><td><code>created_at</code></td><td>horodatage</td><td>Quand la ligne a été écrite par l'actualisation planifiée.</td></tr></tbody></table>

Les exemples ci-dessous montrent des modèles de requête courants. La requête de base renvoie les changements récents des entrées, triés par appareil et par heure. La deuxième filtre sur un numéro d'entrée et une valeur spécifiques. La troisième filtre sur une règle spécifique.

{% tabs %}
{% tab title="Requête de base" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    libellé de l'objet,
    heure de l'appareil,
    input_number,
    valeur d'entrée,
    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="Filtrer par saisie" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    libellé de l'objet,
    heure de l'appareil,
    valeur d'entrée,
    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="Filtrer par règle" %}
{% code overflow="wrap" expandable="true" %}

```sql
SELECT
    device_id,
    libellé de l'objet,
    heure de l'appareil,
    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 %}

## Comment les changements d'entrée sont détectés

Une ligne dans ce tableau n'est pas écrite au moment précis où une entrée change sur l'appareil. Elle est écrite lors de la prochaine actualisation planifiée, qui réévalue une fenêtre de Données brutes par rapport au dernier état connu de chaque appareil.

{% stepper %}
{% step %}

#### Actualisation planifiée

Toutes les 15 minutes, la fonction d'actualisation lit la fenêtre la plus récente de lignes à partir de `raw_telematics_data.additional_data`.
{% endstep %}

{% step %}

#### Comparaison avec le dernier état connu

L'état actuel de chaque appareil `discrete_inputs` et `discrete_outputs` les chaînes de bits sont comparées, bit par bit, à l'état enregistré lors du précédent rafraîchissement. Seuls les bits qui ont réellement basculé sont pris en compte ensuite.
{% endstep %}

{% step %}

#### Correspondance avec les règles

Un bit ayant basculé devient un événement candidat si son numéro d'entrée et sa nouvelle valeur correspondent à la condition configurée sur une `input_change` règle. Voir [Déclenchement par entrée](/docs/user/fr/guide/events-and-notifications/inputs-and-outputs/input-triggering.md) pour savoir comment ces règles sont configurées, et la [Référence des types de règles](https://navixy.com/docs/navixy-api/user-api/resources/tracking/tracker/rules/rule_types) pour la liste complète des types de règles.
{% endstep %}

{% step %}

#### Vérification de zone

Si la règle correspondante est liée à une zone géographique, l’actualisation confirme que l’appareil se trouvait à l’intérieur de cette zone au moment du changement avant d’écrire une ligne. Les règles qui ne sont pas liées à une zone ignorent cette vérification.
{% endstep %}

{% step %}

#### Mise à jour du dernier état connu

Une fois l’actualisation terminée, le dernier état binaire de chaque appareil est enregistré pour être comparé lors de l’exécution suivante.
{% endstep %}
{% endstepper %}

## Personnalisation

Les événements de changement d’entrée ne sont pas personnalisés via un workflow Transformation Builder, comme c’est le cas pour Trajets. Les lignes qui apparaissent ici reflètent directement les `input_change` règles configurées sur votre compte : pour modifier ce qui est enregistré, ajoutez, modifiez ou supprimez les règles correspondantes plutôt qu’un modèle de transformation. Voir [Déclenchement par entrée](/docs/user/fr/guide/events-and-notifications/inputs-and-outputs/input-triggering.md) pour savoir comment configurer ces règles.

## Étapes suivantes

* [**Transformations courantes**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations.md): Retour à l'index des transformations.
* [**Trajets**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations/trips.md): Une transformation sœur qui s'exécute également selon un calendrier sur des données télématiques brutes.
* [**Événements de conducteur fondés sur des règles**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations/rule-based-driver-events.md): Une transformation sœur qui enregistre les infractions de conduite selon le même calendrier de 15 minutes.
* [**Couche de données brutes**](/docs/analytics/fr/iot-query/schema-overview/bronze-layer.md): Explorer `additional_data`, la table source qui alimente les événements de changement d’entrée.
* [**Déclenchement par entrée**](/docs/user/fr/guide/events-and-notifications/inputs-and-outputs/input-triggering.md): Configurez les `input_change` règles qui déterminent quels changements d’entrée sont enregistrés ici.


---

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