> 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 для управления по времени.
Сначала логика планирования была построена на основе времени 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 %}
\
Используя эти значения, система обнаруживает переходы времени, а не непрерывные состояния.
\
Например:
* Условие включения (например, 8 PM):Система проверяет, когда время пересекает порог:
prev_sod < 72000 AND current_sod >= 72000
* Условие выключения (например, 5 AM):
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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.