Подходы при приеме данных IoT с облачного шлюза

Question

Я хотел бы услышать ваше мнение о случае приема данных IoT. В концентраторе AWS IoT тени вещей являются виртуальным представлением физических. Из приведенного ниже рисунка я понял, что всякий раз, когда объект отправляет данные на платформу через посредник сообщений, тени объектов и части механизма правил одновременно получают одни и те же данные датчика и обрабатывают их.

Верны ли мои выводы?

• Теневая система T hings подписывается на брокер сообщений и получает данные от датчиков, обновляет свои теневые акторы. Теневая сторона также отвечает за хранение данных датчика, например механизм поиска событий.
• Система теней вещей не выполняет никаких правил, она просто предназначена для получения источников событий и сохранения последнего известного состояния в действительных субъектах виртуальных вещей.
• Эти же данные датчика также являются входящими данными для механизма правил. Механизм правил - это просто система типов ECA (условие события), которая обрабатывает потоковые данные и решает, что с ними делать. Это означает, что все входящие данные в конечном итоге будут обрабатываться в части механизма правил.

Answer 1

Ниже приведены мои комментарии к вашим выводам.

Из приведенного ниже рисунка я понял, что всякий раз, когда объект отправляет данные на платформу через посредник сообщений, тени объектов и части механизма правил одновременно получают одни и те же данные датчика и обрабатывают их.

Изменения в тени вещи могут вызвать действие, зарегистрированное в механизме правил. Существуют определенные темы, связанные с тенью вещей, на которую вы можете подписать механизм правил, чтобы выполнить одно или несколько действий в ответ.

Теневая система Things подписывается на брокер сообщений и получает данные от датчиков, обновляет свои теневые акторы. Теневая сторона также отвечает за хранение данных датчика, например механизм поиска событий.

Вы можете обновить тень устройства с помощью API REST или выделенных тем MQTT для публикации по определенным темам теней. Как вы сказали, тень сама по себе не представляет собой систему источников событий, а представляет собой модель данных, связанную с физическим устройством.

Однако вы можете создать правило, которое прослушивает изменения в одном или нескольких теневых экземплярах и регистрирует изменения, например, в DynamoDB, в виде временных рядов. После этого у вас будет система поиска событий, позволяющая сохранять предыдущие состояния или изменения, отправленные устройством в течение произвольного периода времени.

Система теней вещей не выполняет никаких правил, она просто предназначена для получения источников событий и сохранения последнего известного состояния в действительных субъектах виртуальных вещей.

Тень вещи сохраняет желаемое и зарегистрированное состояние физического устройства в облаке. Он не выполняет правила, но выдает сообщения по темам MQTT, когда события происходят в тени. Эти сообщения могут затем быть захвачены механизмом правил для выполнения действий.

Эти же данные датчика также являются входящими данными для механизма правил. Механизм правил - это просто система типов ECA (условие события), которая обрабатывает потоковые данные и решает, что с ними делать. Это означает, что все входящие данные в конечном итоге будут обрабатываться в части механизма правил.

Механизм правил по умолчанию не прослушивает тему MQTT и, следовательно, данные, отправляемые устройствами на шлюз устройств. Вы должны зарегистрировать в движке правил темы, которые вы хотели бы прослушать, а также связанные с ними действия.

Помимо этого, механизм правил позволяет вам описывать ваши правила в ANSI SQL, что означает, что вы можете указать источник ваших данных (FROM в вашем операторе SQL), конкретные поля в полезной нагрузке JSON, которые вы хотите записать (SELECT) и необязательное условие, указывающее, при каком условии должно срабатывать правило (WHERE).

Пример прослушивания правила на фиктивную тему device/+/telemetry и заинтересованы в захвате всех полей в полученной полезной нагрузке:

SELECT * FROM device/+/telemetry

Обратите внимание, как + например, может использоваться как заполнитель для любого идентификатора устройства.