> 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/user/es/guide/events-and-notifications/scheduling-and-dispatching/driver-change.md).

# Cambio de conductor

Controle los cambios de conductor en vehículos compartidos detectando cuándo se utiliza una nueva clave de hardware (iButton, RFID o BLE). Registra y reporta cada cambio para fines de responsabilidad.

El **Cambio de conductor** La regla ayuda a los administradores de flota a rastrear qué conductor está operando un vehículo, especialmente cuando varios conductores comparten el mismo vehículo. Esta función funciona con tecnologías de identificación del conductor como iButton, lectores RFID o llaves de hardware BLE.

## Configuración de la regla

Para usar esta regla, comience por agregar todos sus conductores a la **Gestión de flotas** → **sección Conductores**. Asigne a cada conductor su clave de hardware única, como un iButton o una etiqueta RFID. Cuando se detecta un cambio de conductor, la plataforma Navixy asigna el evento al conductor correcto, garantizando reportes y alertas precisos.

No se requieren otras configuraciones específicas de la regla. Para ver las configuraciones comunes, consulte [Reglas y Alertas](/docs/user/es/guide/events-and-notifications.md).

## Detalles del funcionamiento del sistema

* **Detección de cambio de conductor:** La plataforma identifica un cambio de conductor verificando si los datos más recientes de la clave de hardware recibidos del dispositivo GPS difieren de los datos anteriores. Si la clave ha cambiado, lo registra como un evento de cambio de conductor. Esto difiere de la [Identificación del Conductor](/docs/user/es/guide/events-and-notifications/scheduling-and-dispatching/driver-identification.md) regla en la que la alerta se activa directamente por el hardware tras una autenticación correcta del conductor, y la plataforma simplemente muestra el evento.
* **Anulaciones manuales:** Los cambios manuales de conductor realizados a través de la interfaz de usuario (es decir, en widgets) no activan un evento de cambio de conductor. Estos cambios tampoco se incluyen en el “Reporte de todos los eventos”. Sin embargo, todos los cambios de conductor manuales y automáticos se pueden revisar en detalle a través del **Identificación de conductores** reporte.
* **Temporizador de reinicio de la alerta:** El **Cambio de conductor** tiene un temporizador de reinicio de 10 segundos, lo que evita que se active más de una vez cada 10 segundos. Si se produce un evento de cambio de conductor durante este período, la plataforma suprime la alerta, manteniendo las notificaciones y los reportes precisos y concisos.
* **Compatibilidad con múltiples dispositivos:** Esta regla se puede aplicar a varios dispositivos GPS, lo que permite a los administradores de flota monitorear los cambios de conductor en diversos vehículos. Los dispositivos GPS deben ser compatibles con el evento Cambio de conductor y tener esta función integrada en la plataforma.
* **Procesamiento de eventos independiente del GPS:** La plataforma procesa los eventos de cambio de conductor incluso si los datos GPS faltan o son inválidos. Estos eventos igualmente se registran y se muestran, independientemente de si ocurrieron dentro o fuera de una Zona. Esto garantiza que todos los eventos críticos de cambio de conductor se capturen y se reporten con precisión.

## Ver también

* [**Regla de identificación del conductor**](/docs/user/es/guide/events-and-notifications/scheduling-and-dispatching/driver-identification.md): La regla utilizada para verificar y autorizar al conductor antes o durante la operación del vehículo, proporcionando alertas inmediatas y garantizando que solo los conductores autorizados puedan operar el vehículo.


---

# 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/user/es/guide/events-and-notifications/scheduling-and-dispatching/driver-change.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.
