Цепочки правил ThingsBoard для повторной публикации телеметрии на новую тему - PullRequest
Новая
       30

Цепочки правил ThingsBoard для повторной публикации телеметрии на новую тему

0 голосов
/ 18 октября 2018

  • мы используем ThingsBoard Server и ThingsBoard Gateway для управления устройствами IoT, и у нас есть такая потребность:

    1. IoT устройства devicesOfTypeA публикует сообщения в v1 / devices / me / telemetry
    2. Сервер ThingsBoard передает определенные сообщения, а затем публикует новые сообщения в новую тему и т. Д. V1 / devices / devTypeB / request
    3. IoT устройства devicesOfTypeB, подписанный на v1 / devices / devTypeB / #, получит вновь сгенерированные сообщения

  • нам интересно, сможем ли мы реализовать требование путем настройки цепочек правил ThingsBoard, этоКажется, что Rule Chains - действительно удивительный инструмент, который может делать все:)

У кого-нибудь есть какие-нибудь подсказки?Мы новички в ThingsBoard, после прочтения большей части документа, особенно разделов «Обработка данных и действия» в Руководство по ThingsBoard Doc , мы не выяснили, возможно ли решение цепочек правил.

1 Ответ

0 голосов
/ 18 октября 2018

Первый вариант:

  • deviceB подписывается на свой собственный атрибут (область действия = общая) (имя атрибута deviceB = deviceATemeprature)

  • устройство А публикует телеметрию (температура = 40)

  • Цепочка правил

    • принимать сообщения от устройства А
    • сохранять его как телеметриюDeviceA
    • изменить отправителя сообщения на deviceB
    • преобразовать исходное сообщение в сообщение атрибута обновления (полезная нагрузка сообщения с {"температура": "40"} на {"deviceATemeprature": "40"};)
      атрибут сохранения

При использовании этого алгоритма устройство B будет уведомлено об обновлении телеметрии deviceA.

Второй параметр:

Это похоже, но вместо подписки на атрибуты, устройство B подписывается на тему RPC.Механизм правил отправляет команду RPC на устройство B каждый раз, когда обновляется телеметрия устройства A.

PS : ваш случай не является стандартным, и неясно, зачем вам нужна такая сложная топология.Я не уверен, что устройства должны теперь об атрибутах / телеметрии от других устройств.Более распространенный случай - когда вам нужно запустить какую-то функцию на устройстве, когда состояние другого устройства изменяется с состояния A на состояние B.В этом случае вам необходимо реализовать всю логику внутри RuleChain, внедрить API RPC на своих устройствах и запустить этот API из механизма правил.

...