Назад

Декодируйте любые данные телематических датчиков с IoT Logic

Benjamin Hayes
Автор

Benjamin Hayes

12 сентября 2025 г.
Декодируйте любые данные телематических датчиков с IoT Logic

Кратко

  • Большинство трекеров уже «пробрасывают» байты RS-232/485 в облако, поэтому вы получаете сырой ASCII или HEX, а не аккуратно разобранные значения.
  • IoT Logic превращает этот сырой поток в полезные метрики с помощью визуального конвейера: декодирование в Initiate Attribute (JEXL и побитовые операции), память на 12 показаний, развилки IF/THEN и параллельная раздача результатов — без собственного бэкенда.
  • Анализатор потоков данных упрощает отладку: вы видите сырой вход и вычисленные поля в реальном времени и всегда имеете под рукой последние 12 валидных значений — как на рентгене.
  • На практике это «включил и работай»: парсинг пар ключ-значение Technoton через Teltonika, извлечение ID водителя из туннелей Queclink, декод 0x9B кадров Concox, подъём оборотов и учёта пассажиров из Digital Matter или Streamax — затем тревоги, блокировка или включение реле.
  • Повторно используйте простые выражения: битовые маски, дельты «текущее против предыдущего» и проверки, учитывающие время, с srvTime или genTime, чтобы подавлять шум, ловить тренды, оставаться независимыми от вендора и выпускать дашборды без новых бэкенд-проектов.

Представьте. Ваш трекер онлайн и стабильно шлёт данные, но необычный датчик на RS-232 — топливный зонд, RFID-ридер, а может и счётчик пассажиров — говорит не на том языке, что ваше облачное приложение. Вместо этого он выдаёт сырые кадры: 79 79 … 9B … 0D 0A или загадочную строку вроде can_tot_fuel_used=2076.4139.

IoT Logic Support Sensor Readings

GPS-устройство, видеорегистратор или MDVR не пытаются это осмыслить. Они просто действуют как шлюз, оборачивая сырые байты и отправляя их в облако без изменений. Такая гибкость отлична для редких или нишевых датчиков, но может пугать, когда клиент ждёт красивые дашборды и тревоги в тот же день.

Именно для этого мира и создан IoT Logic от Navixy. Он позволяет взять эти байты, «очистить» биты и поля простым визуальным потоком, переиспользовать выражения на базе JEXL (да, включая побитовые), рассуждать на основе последних 12 показаний, делать ветвления IF/THEN и отображать, пересылать или даже отдавать команды назад устройствам — без собственного бэкенда.

Сначала — немного реальности: большинство трекеров уже пересылают сырые данные датчиков

Во всей отрасли режимы «прозрачный» и «pass-through» встречаются повсюду:

  • Teltonika (FMB/FMC): выставьте RS-232/485 в TCP ASCII/Binary, и всё, что шлёт периферия, идёт прямо на сервер, инкапсулированное как Codec 12; буферизованные выгрузки — а при включённой отметке времени — используют Codec 13. ASCII ждёт <CR><LF>; Binary уходит после ~30 мс тишины. Парсинга на устройстве нет.

  • Queclink (GV/GL): протокол @Track включает +RESP:GTDAT для ASCII-тоннеля; в даунлинк можно отправлять AT+GTDAT. Для бинарных/hex нагрузок часто используют отчёт GTDTT.

  • Jimi/Concox: пакет 0x9B «Transparent Transmission» заворачивает RS-232 данные (ASCII/HEX) с небольшим заголовком/CRC, чтобы сервер смог декодировать.

  • Ruptela: Transparent Channel применяет команды 14/114 для подъёма/спуска сырых последовательных байтов. Он даже ставит метку времени прихода данных со стороны RS-232.

  • Suntech/STLab: в пакетах семейства ST300 есть пользовательские поля RS-232 (сотни байт в сообщении) — пересылаются на платформу.

  • Digital Matter (G120/G150): явный RS-232 Passthrough; BLE-шлюзы пересылают данные меток/датчиков.

  • Streamax (MDVR/видеорегистраторы): MDVR предоставляют RS-232/RS-485 для периферии (счётчики пассажиров, LED-табло и т. п.), пересылая события/значения вместе с видеотелеметрией.

Как IoT Logic наводит порядок в «спагетти» из последовательного порта

IoT Logic даёт конвейер «перетащи и отпусти»:

GPS Gateway Transparent Mode

Вы декодируете, обогащаете и маршрутизируете — всё в одном месте.

Initiate Attribute — ваш блок-декодер. Вы создаёте именованные атрибуты и преобразуете сырой поток с помощью языка выражений Navixy (на базе JEXL): от разбиения строк до математики и битовых масок.

Ещё одна сильная сторона: IoT Logic хранит текущее значение и до 12 предыдущих по каждому параметру. В выражении value('sensor', N, 'valid') позволяет получить «сейчас» (индекс 0) или пройти назад по 12 позициям чистой валидной истории. Можно запросить и время устройства (gen), и время сервера для каждого значения через genTime() / srvTime(). Это делает тривиальными антидребезг, проверки дельты и трендовую логику — без базы данных.

Когда нужно принять решение, узел Logic вычисляет булево выражение и разделяет поток (IF/THEN). А когда пора действовать, узел Action может отправить команды устройствам или дернуть внешние системы. Для распространения результатов узел Output Endpoint параллельно отдаёт их в интерфейс Navixy и/или ваши приложения/сервисы.

Для «живой» отладки Анализатор потоков данных показывает сырой вход с устройства и вычисленные атрибуты на лету — с последними 12 значениями на виду. Это рентген вашего конвейера.

Как это работает на практике: четыре коротких кейса

1) Teltonika + CAN-адаптер Technoton: текст на входе, метрики на выходе

Адаптер Technoton по RS-232 шлёт ASCII-данные в виде пар ключ-значение:

can_ign=1;can_speed=54;can_tot_fuel_used=2076.4139

В режиме TCP ASCII Teltonika трекер пересылает каждую строку после <CR><LF> прямо на сервер как Codec 12/13. Initiate Attribute в IoT Logic парсит пары, сохраняет can_speed числом и пишет скорость изменения fuel_used, используя предыдущее валидное значение по индексу 1. Если speed > 0 при установленном бите «дверь открыта», узел Logic поднимает тревогу; если фиксируется резкое падение топлива при выключенном зажигании, Action может щёлкнуть реле или послать команду.

2) Queclink GTDAT (ASCII) и GTDTT (HEX): ID водителей и не только

Отчёт +RESP:GTDAT у Queclink — это буквально текстовый серийный туннель; сервер может послать AT+GTDAT вниз, чтобы поговорить с периферией. Для бинарных полезных нагрузок GTDTT несёт hex. В IoT Logic вы один раз делите или декодируете hex, после чего держите поля вроде driver_id как атрибуты первого класса. Дальше просто: если ID карты не в белом списке, ветвитесь в «unauthorized» и через Action отправляете команду иммобилизации.

3) Concox 0x9B: шестнадцатеричные кадры, которые просто работают

Трекеры Concox упаковывают байты периферии в 0x9B. Пример структуры пакета:

79 79 … 9B 03 … 02 31 42 30 30 31 33 46 37 37 37 38 38 03 … 0D 0A

Эти внутренние байты декодируются в RFID-строку; IoT Logic сохраняет её, сравнивает с предыдущим значением (индекс 1) для фильтрации дублей и выдаёт только изменения. Если это топливный зонд, мы сопоставляем байты литрам, сглаживаем окном из 12 значений и публикуем.

Официальное определение «прозрачной передачи» для 0x9B тоже публично, если нужны подробности «по проводу».

4) Digital Matter и Streamax: обороты и подсчёт людей без лишнего кода

G120/G150 от Digital Matter поддерживают RS-232 Passthrough; датчик барабана Dingtek DZ300, к примеру, отдаёт обороты барабана (+/– указывает направление). Вы поднимаете это в атрибут и ветвитесь по состоянию ВОМ (PTO), чтобы ловить «миксер на холостых».

Для перевозки людей MDVR от Streamax несут счётчики по RS-232/RS-485; IoT Logic объединяет «IN/OUT» с BLE-датчиком температуры и включает дополнительный вентилятор, если в салоне тесно и жарко.

Пара приёмов выражений, которые пригодятся часто

Флаги-биты в масках

Есть набор битов состояния OBD/CAN или флаги дверей? Можно вытащить только нужный:

(value('status_flags', 0, 'valid') & 0x10) != 0

Это проверяет, установлен ли бит 4, и пропускает дальше только если да.

Текущее против предыдущего

Нужно поймать резкие скачки или провалы? Сравните последнюю и предыдущую величины:

value('fuel_l', 0, 'valid') - value('fuel_l', 1, 'valid')

Добавьте порог — и получите мгновенный антидребезг или фильтр «плескания» топлива — без SQL-акробатики.

Правила, чувствительные ко времени

Иногда важна не только величина, но и как долго она держится. Пример: поднять тревогу, если температура выше 26 °C держится три минуты:

srvTime('temp', 0, 'valid') - srvTime('temp', 1, 'valid') > 180000
&& value('temp', 0, 'valid') > 26

Потоки остаются чистыми и читаемыми, потому что узлу Logic нужен лишь да/нет. Узел Initiate Attribute делает тяжёлую работу (переименование, масштабирование, маскирование), а узел Action решает, что делать дальше: включить реле, обновить интерфейс или отправить событие в MQTT или ваше приложение.

Почему команды выпускают релизы быстрее и с меньшими затратами

С IoT Logic вам не нужно каждый раз поднимать новый бэкенд-сервис, когда в поле появляется очередной датчик. Один раз декодируете в Initiate Attribute, переиспользуете на устройствах и остаетесь независимыми от вендора — будь то Teltonika, Ruptela, Concox, видеорегистратор или BLE-метка.

Одновременно Анализатор потоков данных даёт мгновенную видимость сырых и обработанных значений, а выходы параллельно уходят и в дашборды Navixy, и в ваши системы. Меньше кастомного кода, меньше головной боли у поддержки и никаких бюджетных баталий за «ещё один датчик».

Готовы превратить сырые байты в понятные и применимые метрики? Давайте превратим ваш поток данных в результаты, свяжитесь с нашим отделом продаж чтобы спланировать развёртывание.