Для круглосуточного контроля температур от датчиков INVEO организована система мониторинга - Inveo Logger.
- Разработан и создан веб-интерфейс и анимация графиков истории всех температурных датчиков и журнала событий датчика затопления в HTML формате.
- Реализован многопоточный опрос и двухуровневое хранение данных.
- Спроектирована сетевая архитектура для удаленного подключения и мониторинга.
- Создан удаленный бесперебойный мониторинг через Телеграм-бота.
- Автоматизация и ввод в эксплуатацию.
- Предположительные планы развития и прогнозируемый расход трафика
Когда начинал разрабатывать данный проект, то делал акцент в первую очередь на сбор данных со всех сенсоров в единую визуальную веб-страницу c функцией сигнализации заданных критических температур и круглосуточного вахтенного мониторинга, чтобы было своевременное реагирование на проблему с перегревом или затоплением. Но если рассматривать именно данный проект в масштабе флота, то этого конечно не достаточно, но основа уже есть и на этой базе можно усовершенствовать и развивать. Система протестирована и запущена в эксплуатацию на судне.
Исходный код с файлами загружен в FLEET CLOUD / Корпоративный файлообменник флота в папку “Incoming”
Теперь подробнее:
Раздел 1. Разработан веб-интерфейса и анимации (dashboard.html, sensor_detail.html, sensor_flood.html) и сетевая архитектура
- Главный визуальный веб-интерфейс - Основной экран (Dashboard), где показаны сразу все подключенные датчики:
-
Создана визуальная сетка карточек для ПК или мобильных устройств.
-
Разработаны векторные стрелочные приборы с динамическими цветовыми секторами (зеленый/желтый/красный).
-
Реализована мигающая светодиодная индикация (LED Status) и кнопка «СБРОС ТРЕВОГИ» с визуальной пульсацией.
- Аудио-сигнализация (Web Audio API):
-
Интегрирован звук сигнализации из 8ми встроенных в ОС звуков, без использования сторонних аудиофайлов.
- Детальные карточки температур (sensor_detail) и датчика затопления (sensor_flood):
-
Разработан карточный модуль контроля температур (sensor_detail.html) и интегрированы в них:
- векторные стрелочные приборы с цветовыми секторами;
- мигающая индикацией состояния температуры (зеленый/желтый/красный);
- график с поддержкой прокрутки истории за последние 7 дней и кнопками видимой части графика за 12часов/1день/3дня/7дней.
-
Разработан карточный модуль контроля датчика затопления (sensor_flood.html) и интегрировано в него:
- визуальная капля события и название состояния DRY/WATER, которые меняются при размыкании/замыкании датчика;
- мигающая индикацией состояния датчика затопления (зеленый/красный);
- журнал событий за последние 7дней с кнопками DRY/WATER/ALL, которые показывает отдельные события.
-
Внедрен модуль редактирования заметок/комментариев с выбором цвета текста. (**Редактирование данных комментариев возможно только с локального ПК)
- Анализ и настройка сетевого подключения к контроллерам Inveo.
- В веб-интерфейс интегрировано 4 физических контроллера Inveo (Nano Temp / HERO Web), настроена адресация в локальной подсети VLAN10 (192.168.10.10, 192.168.10.20, 192.168.10.30, 192.168.10.40)
- Проанализированы/проверены протоколы опроса и запущены парсеры (перехваты) для одновременной работы с одноканальными текстовыми ответами (/temp1.txt) и многоканальными JSON-структурами (/sensorState.json).
Раздел 2. Реализация многопоточных опросов и двухуровневое хранение данных.
- Разработка и реализация модуля сбора данных
Для создания модуля сбора данных и телеметрии был выбран язык программирования Python, на котором написан управляющий скрипт-модуль в отдельном файле inveo_logger.py.
Главной задачей inveo_logger.py является фоновый непрерывный сбор свежих показателей с датчиков и их занесение в базу данных (лог-файлы) для обеспечения бесперебойного мониторинга. В основу модуля заложен принцип параллельной обработки (асинхронность / многопоточность) и жесткого контроля времени отклика.
Выбор параллельного опроса вместо последовательной «очереди» обусловлен надежностью - при обрыве кабеля, отключении питания или поломке одного из модулей Inveo задержка на одном узле никак не влияет на работу остальных датчиков. Для системы выбран оптимальный интервал опроса в 3 сек.и жесткий таймаут ожидания — 1.2 сек.. Если модуль не успевает ответить за это время, то система не блокируется, а сбрасывает этот конкретный запрос и фиксирует временное отсутствие связи. Благодаря этому модуль inveo_logger.py стабильно функционирует в режиме 24/7, и сбой одного узла не приводит к зависанию или «падению» всей системы.
Примечание: В качестве протокола сбора данных был осознанно выбран HTTP (JSON / TXT) вместо промышленной шины Modbus TCP или MQTT.
Основные причины этого решения:
- Прямой HTTP-опрос оборудования не требует разворачивания и администрирования промежуточной инфраструктуры (например, MQTT-брокера).
- Получение данных по фиксированным REST/HTTP-адресам позволяет легко изолировать сбои каждого конкретного контроллера.
- Не все модули имеют доступ к MQTT в настройках
Сбор телеметрии осуществляется путем обращения скрипта напрямую к встроенному веб-серверу контроллеров по адресам:
-
http://[IP_адрес_контроллера]/temp1.txt— для быстрого получения текущих показаний температуры в текстовом формате; -
http://[IP_адрес_контроллера]/sensorState.json— для получения полного структурированного состояния всех подключенных датчиков и входов в формате JSON.
В итоге скрипт inveo_logger.py является «сердцем» сбора данных. Фоновый Python-скрипт выполняет следующую работу:
- Каждые 3 секунды запрашивает по протоколу HTTP (JSON/TXT) все 4 физических контроллера Inveo;
- Отвечает за запись свежих замеров в отдельные CSV-файлы (лог-файлы) по каждому датчику;
- Генерирует оперативный 10-минутный файл fast_last_10m.csv для быстрого доступа актуальных графиков и интерфейса;
- Автоматически очищает устаревшие архивные записи старше 7 дней для предотвращения переполнения накопителя.
- Двухуровневое изолированное хранение замеров:
- Архивный слой: Ведение индивидуальных .csv файлов с глубиной хранения 7 дней и механизмом автоматической фоновой чистки при превышении объема.
- server.csv, gap_1.csv, gap_2.csv, gap_3.csv … т.д. — 7-мидневные полные архивы температурных замеров
- gap_flood.csv — 7-мидневны полный архив дискретных состояний датчика затопления в GAP (0 = DRY, 1 = WATER).
- Оперативный слой (fast_last_10m.csv): Формирование легкого 10-минутного среза всех каналов для обеспечения мгновенной отрисовки/загрузки основного экрана (Dashboard) и кратковременного открытия отдельных карточек, при подключении с мобильных устройств, без необходимости чтения огромных отдельных файлов архива.
Иными простыми словами, при локальном или удаленном подключении к основной визуальной веб-странице (dashboard) и открытии отдельного какого-либо датчика происходит мгновенная загрузка данных за счет файла “fast_last_10m.csv”, которая показывает историю графика темп и журнала событий в этих отдельных карточках (тут данные показаны за последние 10мин) и тем временем сразу начинается в фоновом режиме загружать индивидуальный CSV файл. И если отдельная карточка открыта более 15сек, то за эти 15сек подгружается в историю графика темп и журнал событий уже индивидуального файла CSV (данные на индикаторах и визуальных циферблатах при этом остаются работать / выгружать данные с файла “fast_last_10m.csv”). То есть индивидуальные .csv файлы нужны только для 7ми дневных истории графиков темп и журнала событий датчика затопления, которые появятся через 15 сек открытой карточки. В итоге это не грузить систему опросами объемными файлами, тем самым открывает мгновенно визуальную веб-страницу с показаниями, как для локального подключения к веб-странице, так по удаленному подключению.
Раздел 3. Спроектирована сетевая архитектура для удаленного подключения и удаленного мониторинга
На втором разделе можно было и закончить, но только для локального мониторинга на судне, но решил пойти дальше и заглянуть в перспективу возможного развития этого проекта. Тема была интересная и решил проверить себя “на вшивость” - получится или нет 
Там самым создать удаленное подключение к главной визуальной веб-странице и детальным карточкам, с возможностью посмотреть историю и журнал событий.
Для удаленного подключения внедрен безопасный внешний доступ туннелирования через cloudflared.exe.
Как работает cloudflared:
- Служба cloudflared.exe запускается на локальном ПК на судне, где находятся все рабочие файлы … .html, … .py, … .js и т.д. и сама выходит в интернет, открывая исходящее устойчивое соединение (зашифрованный туннель по протоколу QUIC/HTTP2) к ближайшему дата-центру Cloudflare.
- Безопасный доступ: Когда на удаленном девайсе вводится адрес/ссылка в браузере, запрос идет на Cloudflare, оттуда пробрасывается через запущенный в фоновом режиме активный туннель прямо на локальный ПК и локальный веб-интерфейс (например, http://localhost:8080)
- Трафик затрагивается минимально. Этот туннель выглядит как обычный исходящий HTTPS-трафик (порт 443 или 7844), такой же, как при просмотре обычного сайта в браузере. Никаких изменений в фаерволе делать не требуется.
Раздел 4. Telegram-бот и логика тревог (bot.py)
После создания туннеля и удаленного доступа к веб-интерфейсу Dashboard, через ссылку туннеля cloudflared, решил пойти дальше и создать еще чат-бот в ТГ. Для этого понадобилось создание дополнительного файла Bot.py в Python, где в управляющем скрипте были произведены следующие настроики:
- Создан алгоритм контроля порогов:
- Сигнал тревоги отправляется мгновенно в чат-бот при пересечении критического порога: темп. датчиков (temp >= Critical) или датчика затопления (Status = WATER).
- Настроено уведомлений / сообщение о восстановлении температуры или статуса DRY датчика затопления
- Административный функционал и Telegram Mini App
- Внедрены команды опроса /start, /test и команды разграничения прав доступа: /users, /broadcast, /ban, /unban.
Для прав доступа User:
— /start - приветствие и доступность команд, в имеющихся правах доступа;
— /test - создает опрос всех датчиков и выводит списком температуры и статус датчика затопления;
Для прав доступа Admin:
— /users - Статистика пользователей бота, где показано количество, подключенных пользователей к данному боту, их статус (admin/user) и их ID;
— /broadcast - уведомление в чат-боте от админа;
— /ban - бан ненужного юзера ;
— /unban - разбан случайно забаненного юзера - Настроена автоматическая рассылка сводного отчета по расписанию (UTC).
- Реализована рассылка обновленной ссылки cloudflared на главную страницу веб-интерфейса при перезапуске локального ПК.
- Реализована полноценная поддержка Telegram Mini App с открытием главного веб-интерфейса прямо внутри мессенджера.
Раздел 5. Автоматизация и ввод в эксплуатацию
- Для оперативного запуска работы всех скриптов и веб-интерфейса на судовом локальном ПК, была создана система пакетных файлов (start_all.bat, Autostart_Temp_Inveo.bat).
- Настроена автоматическая дубликация актуальной (обновленной) ссылки Cloudflare на Рабочий стол и сетевое хранилище NAS (Z:\RADIO WORK\Equipment\Inveo).
- Локальный ПК Inveo-Logger установлен в серверной, подключен в RARITAN и выведен динамик на мостике
- Судовым локальным ПК для Inveo_Logger был установлен бывший ПК с мостика^
IP: 192.168.20.92
MAC: b4:2e:99:c6:7d:92
Раздел 6. Предположительные планы развития и прогнозируемый расход трафика.
- Развитие.
Данный проект можно развивать дальше и больше. База готова и я уже интересовался, что на нее основе можно рассмотреть в масштабах флота обновленную версию этого проекта INVEO LOGGER v2. А именно, создание веб-страницы, где можно будет блоками добавлять группы сенсоров и настраивать через протоколы, IP, критические пороги и т.д. необходимые датчиков в этих группах. При этом исходный код (все файлы) “запечатать” в exe-файл, где оператору - ПКРЭ не нужно лезть в код скриптов Python или html-файлов, а просто распаковывает приложение и добавляет/удаляет группы в чистом интерфейснов окне.
В данный момент я предполагаю, что для обновленной такой версии 2 всё готово на 80% - основа уже есть.
- Расход трафика данного проекта INVEO LOGGER.
Долгое время смотрел, наблюдал, анализировал, интересовался у нейросетей (использовал несколько) и вот такая прогнозируемая таблица была составлена:
- Режим фоновой работы системы мониторинга:
| Режим работы | Интенсивность / Частота | Расход в месяц |
|---|---|---|
| Фоновый (Keep-Alive туннеля) | Постоянно (24/7) | ~50 – 80 МБ |
| Регулярные уведомления (Telegram) | 5 раз в сутки | < 1 МБ |
| Периодический контроль (1–2 раза в день) | ~30 сессий по 5 мин | ~50 – 90 МБ |
| ИТОГО (стандартная эксплуатация): | Фоновый режим + отчеты + мониторинг | ~100 – 170 МБ / мес. |
- Режим максимальной нагрузки:
При условии непрерывного использования системы - круглосуточно открытый графический/визуальный интерфейс с берега с обновлением данных каждые 2 секунды, ежедневная интенсивная диагностика, передача расширенных логов и частые уведомления:
Максимально возможный расход трафика не превысит 1,5 – 2,0 ГБ в месяц.
P.S. Понятное дело, что коды/скрипты писались с помощью нейросетей, но условия, алгоритмы и логику работы задавал я лично. Для меня было очень интересна эта тема, поэтому углублялся всё больше и больше. Было очень много нюансов, много тестов работы или не работы системы. Продумано много мелочей принципа работы. Поэтому принимаются комментарии для обсуждения - может что-то было упущено или не корректно сделано.
