Про користь стандартизації

Привіт Хабр! Я займаюся розробкою електроніки (благо навички охоплюють більшу частину цього цікавого захоплення). І замовили мені якось розробку GSM-логер для ЖКГ.

Крім наявності необхідних входів/виходів (у тому числі 4-20 ма) і джерела живлення 5-30 для датчиків, основною умовою було мінімізація споживання щоб мати можливість харчуватися від батарей.Після опрацювання схемотехніки і друкованої плати на весь зріст постало питання про використовуваному протоколі. Хотілося чогось простого і стандартного.

MQTT. Але MQTT це TCP із усіма достоїнствами і недоліками. А у мене акумулятор і термін роботи від 3 місяців. Для тестів був написаний примітивний протокол поверх UDP. Але оскільки не відношу себе до пионэрам, свято впевненим, що ось зараз за 2 дні напишуть щось легкотравне — продовжив пошуки чогось загальноприйнятого.

Вже не пам'ятаю як — попалося мені згадка про MQTT-SN. Протокол, що успадковує семантику MQTT, але пристосований для передачі по UDP і клієнтам з батарейним живленням. Виявилося, є такий, розроблений у надрах IBM і в подальшому відкритий для спільноти. Після прочитання опису стало зрозуміло, що ось воно, щастя, поруч.

Але потрібен брокер (так в MQTT називають сервер), звичний Mosquitto (за словами Яна Крагса від 2013) коли-небудь зможе MQTT-SN, але не зараз. Зате є RSMB, і навіть в исходниках на Git-хабі.

Джерело це добре, треба збирати. Збірка проводитися CygWin-му в Visual Studio (яку я бачив останній раз років 5 тому). Ставимо фришную версію, створюємо проект і — ніяк. На 5-10 разів (взагалі в моєму житті велику роль відіграє випадок і впертість) прописав правильно проект — і о, диво, зібрав таки брокера. Зауважу що під Linux це дія пройшло набагато простіше.

Урочисто запускаємо. Прикро але не працює. Може все-таки свій протокол це вихід? Уявивши собі обсяг роботи з написання і налагодження сервера та клієнтів — вирішив ні, мій вибір — MQTT-SN. Виявилося все просто — треба було конфігурацію прописати і вказати брокеру.
Мінімальна виглядає таким чином:

trace_output off # Діагностика, можна і включити
listener 1883 INADDR_ANY # Порт для звичайного MQTT
listener 1883 INADDR_ANY mqtts # Порт для MQTT-SN протоколу

І після цього брокер заробив. Коротко відмінності MQTT-SN від класичного MQTT.

  1. Протокол MQTT-SN працює поверх UDP, а не як звичайний TCP. Це перекладає відповідальність за контроль доставки повідомлень на програміста. Зате дозволяє пристрою витрачати менше енергії (а для мене це важливо) на підтримку каналу зв'язку через GSM.

  2. Запроваджено новий рівень QoS (Quality of Service, якість сервісу) -1. Що означає відсутність контролю доставки. Пристрій прокидається, робить потрібну роботу, відсилає результати і тут же засинає не чекаючи підтвердження.

  3. З'явилися шлюзи, які дозволяють агрегировавать дані від безлічі пристроїв і пересилати їх брокеру.
На git-е eclipsa лежать исходники клієнта MQTT-SN з прикладами. Власне треба прописати функції роботи з каналом transport_xx під свої потреби. В іншому великих проблем немає (знайшов пару помилок, треба тестувати).

На жаль, не реалізована підтримка сплячих клієнтів. Стоять заглушки. Хто зможе кинути в авторів протоколу камінь — вихідні коди доступні, допомога вітається.

Що хотів сказати в підсумку. Витративши деякий (невеликий час) я отримав готову інфраструктуру для подальшого розвитку проекту. Протокол дозволяє використовувати STM32 на 4 МГц. Я можу використовувати безліч клієнтів на різних платформах (що нереально було б зробити поодинці при написанні свого протоколу). Більш того, маючи можливість зібрати брокера під Linux я розмістив його на инстансе Amazon-а і мій замовник отримав рішення без необхідності тримати і обслуговувати сервер. Стандартні рішення (не завжди, але в переважній кількості випадків) прискорюють виконання завдання.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.