![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Типы данных для телеметрии
В процессе пиления датчика co2 столкнулся с такой фигней: если датчик сам не передает тип данных - то каждая доработка софта на контроллере датчика вынуждает дорабатывать и парсер его сообщений, чего делать совершенно нет желания.
Поначалу данные в udp-пакетах с датчика выглядели так: 2016-10-29T21:26:40.990599,ff8601e440402eb92e
Потом вот так, чтобы сразу видеть концентрацию: 2016-10-29T23:48:35.310594,ff86027840042e305e,632
А потом я решил это дело засунуть сразу в эластик с кибаной, чтобы рисовать графики, причем у нас туда данные (мониторинг нашего софта) идут в виде json-объектов в сообщениях через mq-сервер. Наиболее прямой путь такое делать - это поля от датчика разложить в виде полей json-объекта, тогда эластик автодетектит типы полей и все становится сразу доступным для запросов и графиков.
Но прога, которая транслирует udp-пакеты в mq сообщения - вообще говоря, тестовый/отладочный клиент от моей mq-либы и впихивать в нее прибитые гвоздями имена полей от одного конкретного датчика - лютый грех, такой код должен быть универсальным, очевидно.
Поэтому формат пакета превратился в: "utc=2016-10-30T12:04:08.740605,hex=ff8602db40402e30bf,co2=731", а программа просто конвертирует это в json и добивает служебными полями от себя (уникальный идентификатор ноды, тип сообщения, и прочее такое). В таком варианте я смогу, например, добавить еще пакетов от других датчиков - давления, освещенности, влажности, радиации и температуры, не переделывая транслятор.
Фактически, это структурный тип данных - смысл данных определяется тем, какие в нем есть поля. Это очень удобно для обобщенной обработки.
При этом, когда я работаю с чужими железками, там почти всегда типы данных прибиты гвоздями - начиная от просто упакованных бинарных структур, заканчивая csv с позиционным назначением полей или бинарным массивом из кучи бинарных пакетов с CRC и прочим.
Понятно, что так сильно экономится GPRS-трафик для телеметрии и байтики в прошивке, но почему бы этим устройствам сразу после подключения по TCP не передавать метаданные протокола, которые можно было бы грузить в парсер и он автоматом бы становился совместимым с тем, что устройство будет передавать после этого.
Т.е. хотя бы передавать csv заголовок для csv-форматов, или массив "тип, имя, длина" для бинарных структур или еще что-нибудь в том же духе.
Поначалу данные в udp-пакетах с датчика выглядели так: 2016-10-29T21:26:40.990599,ff8601e440402eb92e
Потом вот так, чтобы сразу видеть концентрацию: 2016-10-29T23:48:35.310594,ff86027840042e305e,632
А потом я решил это дело засунуть сразу в эластик с кибаной, чтобы рисовать графики, причем у нас туда данные (мониторинг нашего софта) идут в виде json-объектов в сообщениях через mq-сервер. Наиболее прямой путь такое делать - это поля от датчика разложить в виде полей json-объекта, тогда эластик автодетектит типы полей и все становится сразу доступным для запросов и графиков.
Но прога, которая транслирует udp-пакеты в mq сообщения - вообще говоря, тестовый/отладочный клиент от моей mq-либы и впихивать в нее прибитые гвоздями имена полей от одного конкретного датчика - лютый грех, такой код должен быть универсальным, очевидно.
Поэтому формат пакета превратился в: "utc=2016-10-30T12:04:08.740605,hex=ff8602db40402e30bf,co2=731", а программа просто конвертирует это в json и добивает служебными полями от себя (уникальный идентификатор ноды, тип сообщения, и прочее такое). В таком варианте я смогу, например, добавить еще пакетов от других датчиков - давления, освещенности, влажности, радиации и температуры, не переделывая транслятор.
Фактически, это структурный тип данных - смысл данных определяется тем, какие в нем есть поля. Это очень удобно для обобщенной обработки.
При этом, когда я работаю с чужими железками, там почти всегда типы данных прибиты гвоздями - начиная от просто упакованных бинарных структур, заканчивая csv с позиционным назначением полей или бинарным массивом из кучи бинарных пакетов с CRC и прочим.
Понятно, что так сильно экономится GPRS-трафик для телеметрии и байтики в прошивке, но почему бы этим устройствам сразу после подключения по TCP не передавать метаданные протокола, которые можно было бы грузить в парсер и он автоматом бы становился совместимым с тем, что устройство будет передавать после этого.
Т.е. хотя бы передавать csv заголовок для csv-форматов, или массив "тип, имя, длина" для бинарных структур или еще что-нибудь в том же духе.
no subject
no subject
no subject
no subject
no subject