Использование AWS IOT для устройств с косвенным подключением

Я подумываю об использовании AWS IoT для приложения, где за (возможно, сотнями) распределенных шлюзов (ПК или Raspberry Pi) есть несколько тысяч небольших растровых дисплеев (связанных с проприетарным беспроводным протоколом).

Пока что я придумал следующую концепцию:

  1. ПК шлюза завершает сеанс MQTT. У него нет собственной таблицы устройств.

  2. thingname = <gatewayId>_<displayId>

  3. Растровые изображения дисплея хранятся на S3 (имя файла = имя объекта)

  4. Обновление дисплеев - это просто замена файла S3, а затем обновление версии растрового изображения (например, SHA) в желаемом состоянии тени устройства.

  5. Шлюз должен будет подписаться на такие обновления, как /update/<gatewayId>/#

  6. Будет правило, которое повторно публикуется с /update/<gatewayId>_<displayId> на /update/<gatewayId>/<displayId> (поскольку имена вещей не могут содержать косые черты, а подстановочные знаки в MQTT должны быть полными компонентами пути)

  7. Для каждого полученного сообщения шлюз загружает растровое изображение из S3, отправляет его на дисплей, а затем обновляет сообщенное состояние до новой версии.

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

Подписки не являются постоянными, поэтому мне как-то нужно найти все вещи (с этого шлюза), где желаемое состояние! = Сообщаемое состояние, и обновить их снова.

Может быть такое правило? Идея состоит в том, чтобы шлюз опубликовал сообщение о повторном подключении (например, /reconnect/<gatewayId>), когда оно вернется в сеть. Правило должно найти все тени устройств для этого шлюза, где желаемое состояние! = Сообщаемое состояние, и опубликовать их.

NB: Я знаю, что могу запрограммировать механизм без тени устройства с собственной базой данных. Но идея заключалась в том, чтобы использовать для этого механизм IoT.

Другой вопрос: создание растровых изображений происходит очень быстро (может составлять 1000 в секунду), отправка на дисплеи может быть очень медленной (особенно отправка первого растрового изображения из группы может занять минуту). Таким образом, может быть создано несколько тысяч битовых карт (для одного шлюза) до того, как будет подтверждено первое сообщение. Это проблема?


amazon-web-services aws-iot
person Ruediger Jungbeck    schedule 12.11.2015    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Если я правильно понимаю ваш вариант использования, я думаю, что в вашу концепцию могут потребоваться некоторые изменения, чтобы она работала лучше. Я постараюсь ответить на ваши вопросы, разбив их на более мелкие части.

  1. Синхронизация состояния: поскольку ваши дисплеи не имеют прямой связи с AWS IoT, было бы лучше, если бы вы рассматривали свои шлюзы как things, а каждый дисплей как атрибут (например, <display_id>) соответствующего шлюза thing. Таким образом, всякий раз, когда необходимо загрузить новое изображение на дисплей, вы можете просто обновить desired state вложенный атрибут в соответствующий атрибут отображения (например, <bitmap_version> вложенный в <display_id>). Вы можете сделать это с помощью темы thing shadow UPDATE (например, $aws/things/<gateway_id>/shadow/update). Вы можете инициировать сообщение для темы UPDATE, используя Lambda, чтобы определить, когда новая версия растрового изображения дисплея была загружена в S3.

  2. Загрузка изображения: всякий раз, когда новая версия растрового изображения загружается в S3, шлюз получает новый desired state для конкретной версии растрового изображения атрибута отображения через тему thing ACCEPTED UPDATE (например, $aws/things/<gateway_id>/shadow/update/accepted), загружает новое растровое изображение, обновляет отображение через ваш собственный беспроводной протокол и обновляет reported state атрибута в теме thing shadow UPDATE.

  3. Обработка отключенных шлюзов: да, подписки не являются постоянными, но если вы рассматриваете свои шлюзы как things и каждый дисплей как атрибут этого thing, всякий раз, когда он возвращается в сеть, он может публиковать сообщение в теме GET (например, $aws/things/<gateway_id>/shadow/get), проверьте текущее состояние thing в теме ACCEPTED GET ($aws/things/<gateway_id>/shadow/get/accepted), а затем перейдите к загрузке новых растровых изображений в случае новых версий.

  4. Обработка большого объема данных. Если вам нужно обновить каждое отображение шлюза несколькими растровыми изображениями в секунду, учитывая, что у вас тысячи дисплеев на шлюз, я думаю, что проблема, с которой вы можете столкнуться, заключается в узком месте полосы пропускания. и синхронизируйте все эти сообщения MQTT с вашими thing shadow темами. Если вам нужно обновлять каждый дисплей только время от времени, я думаю, ваша концепция может работать очень хорошо.

Некоторые моменты, которые следует принять во внимание:

  1. Реализация AWS IoT MQTT не может гарантировать порядок получения сообщений. Если вам нужно, чтобы ваши сообщения приходили в определенном порядке, вы должны реализовать это в своем приложении.

  2. AWS IoT по-прежнему является бета-сервис, поэтому многие детали реализации могут измениться.

person Lucas Azevedo    schedule 13.11.2015
comment
Спасибо за ответ. 2 проблемы: за 1 шлюзом может быть несколько тысяч дисплеев. Но тень устройства составляет всего 8 КБ. Вторая проблема: я не меняю каждый дисплей каждую секунду, но я могу изменить многие / все дисплеи за одним шлюзом за короткое время (и после этого больше никаких изменений в течение нескольких часов). - person Ruediger Jungbeck; 13.11.2015
comment
Ура, я забыл об ограничении 8 КБ на размер тени устройства. Если я найду другое решение, я обновлю свой ответ. - person Lucas Azevedo; 13.11.2015
comment
Учитывая ограничение в 8 КБ, вместо того, чтобы вкладывать каждое отображение шлюза в один thing shadow, вы можете сгруппировать изображения шлюза в кластеры устройств. У каждого кластера будет свой thing shadow. Не идеальное решение, но я думаю, что его проще реализовать, чем исходную идею. - person Lucas Azevedo; 13.11.2015