> 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/expert-center/es/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md). # Cómo implementar programación dirigida por eventos usando tiempo Unix en IoT Logic Programe acciones de salida basadas en temporizador en IoT Logic usando marcas de tiempo Unix. Active Comandos del dispositivo en momentos exactos con el reporte continuo del dispositivo activado. En esta sección, configure un temporizador en IoT Logic para controlar la activación de salidas en los dispositivos. Esto funciona como un programador al usar tiempo Unix para el control basado en tiempo.
Primero, la lógica del programador se construyó con base en tiempo Unix, ya que es el único parámetro confiable y consistente del que siempre podemos depender. El segundo elemento clave es la marca de tiempo de los paquetes válidos recibidos por la plataforma Navixy.\ Es importante señalar que esta lógica requiere que el dispositivo envíe continuamente paquetes de datos válidos a la plataforma. La frecuencia en sí no es crítica; sin embargo, si no se reciben mensajes entrantes, resulta imposible evaluar el tiempo o activar cualquier acción programada. \ Ahora, pasando al nodo de cálculo del atributo de lógica implementada.\ Este nodo recupera: * El tiempo actual del evento (current\_time) del paquete más reciente * El tiempo anterior del evento (prev\_time) del paquete anterior Ambos valores se convierten de milisegundos a segundos.
Es importante señalar que **genTime** se proporciona en tiempo Unix (milisegundos) y debe dividirse entre 1000 para obtener el tiempo Unix en segundos, que es el formato usado para todos los cálculos. \ A partir de estos, el sistema calcula: * current\_sod (segundos del día) * prev\_sod (segundos del día del paquete anterior) Esto se hace usando la operación de módulo, que extrae la cantidad de segundos transcurridos desde la medianoche, convirtiendo de manera efectiva el tiempo Unix en una referencia de hora del día. 
time % 86400
Puede observarse un desfase horario en estas fórmulas. Este desfase está determinado por la zona horaria UTC en la que se realizan los cálculos. En el escenario de prueba, los cálculos se realizaron en UTC -6, lo que dio como resultado una diferencia de 6 horas. Al convertirlo a segundos, esto equivale a:\ 6 horas × 60 min × 60 sec = 21,600 segundos. {% code overflow="wrap" %} ``` current_sod = (current_time - offset_time) % 86400 prev_sod = (prev_time - offset_time) % 86400 ``` {% endcode %} \ Usando estos valores, el sistema detecta transiciones de tiempo, no estados continuos. \ Por ejemplo: * Condición de encendido (p. ej., 8 PM):El sistema verifica cuándo el tiempo cruza el umbral: 
prev_sod < 72000 AND current_sod >= 72000
* Condición de apagado (p. ej., 5 AM): 
prev_sod < 18000 AND current_sod >= 18000
Esto garantiza que la acción se active solo una vez en el momento de la transición, en lugar de de forma continua durante toda la ventana de tiempo. \ Una vez que se cumple la lógica, el nodo de acción activará el comando de salida para cambiar el estado de salida.\ Pueden surgir algunas limitaciones a lo largo de este flujo, y es importante destacarlas para que puedan tomarse en cuenta:
* **Dependiente de los datos entrantes:** Si el dispositivo deja de enviar datos, no se activan acciones. Por eso se requiere una supervisión continua de la unidad. Si el dispositivo está desconectado, bloqueado o en Modo ahorro energía sin enviar datos válidos, el cambio de estado nunca se detecta.
* **Sin garantía de una hora exacta de ejecución:** Las acciones se ejecutan cuando llega el siguiente paquete de datos después de cumplirse el umbral, no exactamente en la hora programada. Por ejemplo, si el dispositivo reporta cada 5 minutos y el último paquete se recibió a las 20:58, el siguiente mensaje llegará a las 21:03. En ese momento, la lógica se habrá cumplido y la acción (p. ej., activación de salida) se activará.
* **Se requiere manejo de la zona horaria:** Como el tiempo Unix está en UTC, debe aplicarse un desfase para alinearlo con la hora local deseada.
* **Sin estado persistente de programación:** El sistema no almacena tiempos de activación futuros; depende por completo de comparaciones en tiempo real entre paquetes entrantes consecutivos. Esta solución simula un programador en un sistema basado en eventos usando marcas de tiempo Unix y detectando transiciones de tiempo entre paquetes de datos consecutivos. Aunque no es un programador verdadero, ofrece una manera confiable y escalable de implementar automatización basada en tiempo sin requerir compatibilidad nativa con la programación. --- # 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/expert-center/es/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md?ask=&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.