Lorawan-stack: Регистрация многоадресной рассылки и нисходящая многоадресная рассылка

@MatteMoveSRL спасибо за вашу проблему. Если вы являетесь клиентом TTI с планом поддержки, лучше всего использовать канал поддержки.

Здесь мы используем шаблоны задач, чтобы получать информацию в структурированном виде.

Я заметил, что регистрация многоадресного устройства не приводит к _активации режима многоадресной рассылки_, а вместо этого является _активацией режима ABP_. Почему это так?

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

Я не могу отправлять нисходящие сообщения с платформы, потому что возникают ошибки «нет доступного нисходящего пути» . Я также попытался отправить нисходящую ссылку с помощью MQTT в Windows, как показано ниже, но на мое конечное устройство ничего не приходит.

См. https://thethingsstack.io/devices/class-c-multicast/ , затем второе примечание в группе многоадресной рассылки и приведенный ниже пример того, как запланировать нисходящий канал.

@johanstokking Большое спасибо за ответы!

Я обновил свои проблемы, чтобы получить информацию в структурированном виде, как вы предложили. Я надеюсь, что это понятно

Я до сих пор не понимаю этих двух моментов:

Вместо этого правильный ответ нисходящей линии mosquitto_pub? Потому что я не видел, чтобы что-то поступало на мои физические конечные устройства OTAA.

Я не понимаю, как соотнести мои OTAA-устройства с моей многоадресной группой через консоль. Я хотел бы видеть, например, многоадресную группу (с его McAddress и Mckeys), куда я могу добавить свои устройства OTAA, потому что неясно, как многоадресный нисходящий канал может достичь моих устройств OTAA.

Заранее большое спасибо за ваше время и ответ.

@MatteMoveSRL Верен ли вместо этого ответ нисходящей ссылки mosquitto_pub? Потому что я не видел, чтобы что-то поступало на мои физические конечные устройства OTAA.

Помимо абсолютного времени, которое находится в прошлом, оно не выглядит неправильным.

Но является ли gtwid подключенным шлюзом? Видите ли вы нисходящий канал, запланированный в консоли, при просмотре трафика шлюза?

@MatteMoveSRL Я не понимаю, как сопоставить мои устройства OTAA с моей группой многоадресной рассылки через консоль. Я хотел бы видеть, например, многоадресную группу (с его McAddress и Mckeys), куда я могу добавить свои устройства OTAA, потому что неясно, как многоадресный нисходящий канал может достичь моих устройств OTAA.

Мы еще не реализовали протокол Remote Multicast Setup на сервере приложений. Поэтому мы не соотносим это. Многоадресное устройство является виртуальным устройством. Если ваше конечное устройство понимает нисходящий канал как в одноадресном, так и в многоадресном канале, все должно быть в порядке.

@johanstokking Спасибо за быстрый ответ

Но является ли gtwid подключенным шлюзом?

Да, шлюз подключен, и я использовал «gw-test» вместо «gtwid» в команде mosquitto.

Видите ли вы нисходящий канал, запланированный в консоли, при просмотре трафика шлюза?

Нет, я не вижу ни одного нисходящего канала, поступающего в «живые данные» моего шлюза, но вместо этого я видел некоторые данные, поступающие в раздел «живые данные» моего приложения «foo»:

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

То есть вы имеете в виду, что нисходящее сообщение поступает на все устройства OTAA, подключенные к шлюзу, как широковещательное сообщение, а не на определенную группу устройств OTAA?

Нет, я не вижу ни одного нисходящего канала, поступающего в «живые данные» моего шлюза, но вместо этого я видел некоторые данные, поступающие в раздел «живые данные» моего приложения «foo»:

Пожалуйста, подпишитесь на журнал событий шлюза с;

$ ttn-lw-cli events --gateway-id gtw-test

Также включите журналы отладки ( log.level: debug ).

Затем запланируйте сообщение по нисходящему каналу и просмотрите журналы и события шлюза.

То есть вы имеете в виду, что нисходящее сообщение поступает на все устройства OTAA, подключенные к шлюзу, как широковещательное сообщение, а не на определенную группу устройств OTAA?

Да, именно так работает LoRaWAN. Каждое устройство класса C, прослушивающее эту частоту с этой конкретной скоростью передачи данных, получит сообщение. Они просматривают DevAddr сообщения, чтобы увидеть, соответствует ли оно (многоадресному) сеансу, для которого у них есть сеансовые ключи. Если это так, они обрабатывают сообщение и проверяют, соответствует ли NwkSKey MIC и т. д.

Говоря о которых; Вы уверены, что частота и скорость передачи данных правильные? Класс C использует для этого параметры RX2. Конечные устройства должны прослушивать эти параметры для многоадресных кадров нисходящей линии связи.

@johanstokking Спасибо за ответ.

Да, именно так работает LoRaWAN. Каждое устройство класса C, прослушивающее эту частоту с этой конкретной скоростью передачи данных, получит сообщение. Они просматривают DevAddr сообщения, чтобы увидеть, соответствует ли оно (многоадресному) сеансу, для которого у них есть сеансовые ключи. Если это так, они обрабатывают сообщение и проверяют, соответствует ли NwkSKey MIC и т. д.

Спасибо, я понял. Вы были действительно ясны.

Говоря о которых; Вы уверены, что частота и скорость передачи данных правильные? Класс C использует для этого параметры RX2. Конечные устройства должны прослушивать эти параметры для многоадресных кадров нисходящей линии связи.

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

Пожалуйста, используйте форумы для дополнительных вопросов; мы не отвечаем на вопросы по проблемам GitHub. См. также шаблоны задач.