> 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/ru/faq-and-troubleshooting/iot-logic/how-to-implement-event-driven-scheduling-using-unix-time-in-iot-logic.md).
# Как реализовать событийно-управляемое Планирование с использованием времени Unix в IoT Logic
Планируйте действия выходов по таймеру в IoT Logic, используя Unix-временные метки. Запускайте Команды устройства в точно заданное время при включенной непрерывной передаче данных устройством.
В этом разделе настройте таймер в IoT Logic для управления активацией выходов на устройствах. Он работает как планировщик, используя время Unix для управления по времени.
Сначала логика планировщика была построена на основе времени Unix, поскольку это единственный надежный и стабильный параметр, на который мы всегда можем опираться. Второй ключевой элемент — временная метка действительных пакетов, полученных платформой Navixy.\
Важно отметить, что эта логика требует, чтобы устройство непрерывно отправляло действительные пакеты данных на платформу. Частота сама по себе не критична; однако, если входящие сообщения не поступают, становится невозможно оценивать время или запускать какие-либо запланированные действия.
\
Теперь перейдем к узлу расчета атрибута реализованной логики.\
Этот узел извлекает:
* Текущее время события (current\_time) из последнего пакета
* Предыдущее время события (prev\_time) из предыдущего пакета
Оба значения преобразуются из миллисекунд в секунды.
Важно отметить, что **genTime** предоставляется во времени Unix (в миллисекундах) и должен быть разделен на 1000, чтобы получить время Unix в секундах, то есть формат, используемый для всех вычислений.
\
На основе этого система вычисляет:
* current\_sod (секунд в сутках)
* prev\_sod (секунд в сутках для предыдущего пакета)
Это делается с помощью операции модуля, которая извлекает количество секунд, прошедших с полуночи, фактически преобразуя время Unix в значение времени суток.
time % 86400
В этих формулах может наблюдаться временной сдвиг. Этот сдвиг определяется часовым поясом UTC, в котором выполняются вычисления.
В тестовом сценарии вычисления выполнялись в UTC -6, что привело к разнице в 6 часов. При переводе в секунды это равно:\
6 часов × 60 мин × 60 сек = 21 600 секунд.
{% code overflow="wrap" %}
```
current_sod = (current_time - offset_time) % 86400
prev_sod = (prev_time - offset_time) % 86400
```
{% endcode %}
\
Используя эти значения, система обнаруживает переходы во времени, а не непрерывные состояния.
\
Например:
* Условие включения переключателя (например, 20:00):Система проверяет, когда время пересекает порог:
prev_sod < 72000 AND current_sod >= 72000
* Условие выключения переключателя (например, 5:00):
prev_sod < 18000 AND current_sod >= 18000
Это гарантирует, что действие сработает только один раз в момент перехода, а не непрерывно в течение всего временного окна.
\
Когда логика выполняется, узел действия запустит команду выхода, чтобы изменить состояние выхода.\
На протяжении всего этого потока могут возникать некоторые ограничения, и важно их отметить, чтобы их можно было принять во внимание:
* **Зависимость от входящих данных:**
Если устройство перестает отправлять данные, действия не запускаются. Именно поэтому требуется непрерывный мониторинг устройства. Если устройство отключено, зависло или находится в режиме сна и не отправляет действительные данные, изменение состояния никогда не будет обнаружено.
* **Отсутствует гарантия точного времени выполнения:**
Действия выполняются, когда следующий пакет данных поступает после того, как порог достигнут, а не точно в запланированное время. Например, если устройство передает данные каждые 5 минут, а последний пакет был получен в 20:58, следующее сообщение поступит в 21:03. В этот момент логика будет выполнена, и действие (например, активация выхода) будет запущено.
* **Требуется обработка часового пояса:**
Поскольку время Unix задано в UTC, необходимо применить сдвиг, чтобы сопоставить его с требуемым локальным временем.
* **Отсутствует постоянное состояние планирования:**
Система не хранит будущие моменты срабатывания; она полностью опирается на сравнение в реальном времени между последовательными входящими пакетами.
Это решение имитирует планировщик в событийно-ориентированной системе, используя временные метки Unix и обнаруживая переходы времени между последовательными пакетами данных. Хотя это не настоящий планировщик, оно обеспечивает надежный и масштабируемый способ реализации автоматизации по времени без необходимости в нативной поддержке планирования.
---
# 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/ru/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.
