Как реализовать планирование на основе событий с использованием Unix Time в IoT Logic
В этом разделе мы настроим таймер в IoT Logic для управления активацией выходов на устройствах. Он будет выполнять функции планировщика, используя время Unix для управления по времени.
Сначала логика планировщика была построена на основе времени Unix, поскольку это единственный надежный и стабильный параметр, на который мы всегда можем рассчитывать. Второй ключевой элемент — это временная метка корректных пакетов, полученных платформой. Важно отметить, что эта логика требует, чтобы устройство непрерывно отправляло на платформу корректные пакеты данных. Частота сама по себе не критична; однако если входящие сообщения не поступают, становится невозможно оценить время или запустить какие-либо запланированные действия.
Теперь перейдем к узлу расчета атрибута реализованной логики. Этот узел получает:
Текущее время события (current_time) из последнего пакета
Предыдущее время события (prev_time) из предыдущего пакета
Оба значения преобразуются из миллисекунд в секунды.
Важно отметить, что genTime предоставляется во времени Unix (в миллисекундах) и должен быть разделен на 1000, чтобы получить время Unix в секундах, которое и будет использоваться во всех расчетах.
Из этих значений система рассчитывает:
current_sod (секунды суток)
prev_sod (секунды суток для предыдущего пакета)
Это выполняется с помощью операции по модулю, которая извлекает количество секунд, прошедших с полуночи, фактически преобразуя время Unix в представление времени суток.
В этих формулах может наблюдаться временной сдвиг. Этот сдвиг определяется часовым поясом UTC, в котором выполняются расчеты.
В тестовом сценарии расчеты выполнялись в UTC -6, что привело к разнице в 6 часов. В пересчете на секунды это составляет: 6 часов × 60 мин × 60 сек = 21 600 секунд.
Используя эти значения, система определяет переходы времени, а не непрерывные состояния.
Например:
Условие включения (например, 20:00): Система проверяет, когда время пересекает порог:
Условие выключения (например, 05:00):
Это гарантирует, что действие будет запущено только один раз в момент перехода, а не непрерывно в течение всего временного окна.
Когда логика выполняется, узел действия отправит команду на выход, чтобы изменить состояние выхода. В этом потоке могут возникнуть некоторые ограничения, и важно их отметить, чтобы их можно было принять во внимание:
Зависимость от входящих данных:
Если устройство перестает отправлять данные, действия не будут запускаться. Поэтому требуется непрерывный мониторинг устройства. Если устройство отключено, подавлено или находится в спящем режиме и не отправляет корректные данные, изменение состояния никогда не будет обнаружено.
Нет гарантии точного времени выполнения:
Действия выполняются, когда после достижения порога поступает следующий пакет данных, а не точно в запланированное время. Например, если устройство передает данные каждые 5 минут и последний пакет был получен в 20:58, следующее сообщение придет в 21:03. В этот момент логика будет выполнена и действие (например, активация выхода) будет запущено.
Требуется обработка часового пояса:
Поскольку время Unix указано в UTC, необходимо применить смещение, чтобы привести его к нужному местному времени.
Нет постоянного состояния планирования:
Система не хранит будущие моменты срабатывания; она полностью полагается на сравнение в реальном времени между последовательными входящими пакетами.
Это решение имитирует планировщик в событийно-ориентированной системе, используя временные метки Unix и определяя переходы времени между последовательными пакетами данных. Хотя это и не является настоящим планировщиком, оно предоставляет надежный и масштабируемый способ реализации автоматизации по времени без необходимости в нативной поддержке планирования.
Последнее обновление
Это было полезно?