СИ-12

[yuri]

Добрый день!

Не получается заставить СИ-12 (класс С) отправлять пакет с текущими показаниями раз в 5 минут. Пакет с настройками до устройства доходит успешно. Первые показания приходят. А вот вторые (которые должны были бы прийти примерно через 5 минут после первых) приходят только на границе следующего часа.

Прошивка устройства обновлялась в ноябре.

В чем может быть проблема ?

[petrov_ab]

Период сбора не больше периода передачи? А то передавать нечего, он и не передает...

[Support]

Добрый день!

Добрый день!

Не получается заставить СИ-12 (класс С) отправлять пакет с текущими показаниями раз в 5 минут. Пакет с настройками до устройства доходит успешно. Первые показания приходят. А вот вторые (которые должны были бы прийти примерно через 5 минут после первых) приходят только на границе следующего часа.

Прошивка устройства обновлялась в ноябре.

В чем может быть проблема ?

Необходимо проверить настройки устройства. Если есть возможность физически подключиться к устройству проводом, то подключитесь конфигуратором, нажмите "Получить настройки". После этого Вы увидите установленные в устройстве настройки. Если период сбора/ передачи 5/5 минут, смотрите настройки сети. Возможно со стороны сервера и БС установлен один частотный план, а со стороны устройства другой. Таким образом БС может не "услышать" большую часть пакетов от устройства.

Период сбора не больше периода передачи? А то передавать нечего, он и не передает...

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

[yuri]

Необходимо проверить настройки устройства. Если есть возможность физически подключиться к устройству проводом, то подключитесь конфигуратором, нажмите "Получить настройки". После этого Вы увидите установленные в устройстве настройки. Если период сбора/ передачи 5/5 минут, смотрите настройки сети. Возможно со стороны сервера и БС установлен один частотный план, а со стороны устройства другой. Таким образом БС может не "услышать" большую часть пакетов от устройства.

Период сбора не больше периода передачи? А то передавать нечего, он и не передает...

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

Подключиться к устройству проводом возможности нет (т.к. нет windows).

Настройки сбора/передачи были 1час/5минут. Командой через вебсокет сделал изменение настроек на 5/5 минут, устройство подтвердило получение этих изменений и ВООБЩЕ перестало присылать данные (по крайней мере в вебсокете НИКАКИХ сообщений с порта 2 не было более часа). На запрос выслать конфигурацию устройство тоже не ответило.

Как-то помогло выключении внешнего питания устройства (оно перешло в класс А) а минут через 5-10 включение питания снова (оно вернулось в класс С) и пятиминутные пакеты с данными стали приходить. Но это не вариант решения проблемы.

На связь с БС жаловаться пока нет оснований (устройство практически постоянно видится с не менее чем трех БС).

Отсутствия обязательных пустых пакетов с порта 2 не понятно. Может сетевой сервер про эти пакеты не сообщает через вебсокет ?

[petrov_ab]

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

ИМХО.

[Support]

Добрый день!

Подключиться к устройству проводом возможности нет (т.к. нет windows).

Настройки сбора/передачи были 1час/5минут. Командой через вебсокет сделал изменение настроек на 5/5 минут, устройство подтвердило получение этих изменений и ВООБЩЕ перестало присылать данные (по крайней мере в вебсокете НИКАКИХ сообщений с порта 2 не было более часа). На запрос выслать конфигурацию устройство тоже не ответило.

Как-то помогло выключении внешнего питания устройства (оно перешло в класс А) а минут через 5-10 включение питания снова (оно вернулось в класс С) и пятиминутные пакеты с данными стали приходить. Но это не вариант решения проблемы.

На связь с БС жаловаться пока нет оснований (устройство практически постоянно видится с не менее чем трех БС).

Отсутствия обязательных пустых пакетов с порта 2 не понятно. Может сетевой сервер про эти пакеты не сообщает через вебсокет ?

Статус пакета "SUCCESS" говорит не о успешной доставке на устройство, а о успешной отправке этого пакета. Данный статус отображается только для пакетов отправленных с сервера. Определить был ли доставлен пакет на устройство, Вы не можете.

Всё что Вам нужно сделать, это проверить настройки своей сети.

1. Частотный план на БС (всех трёх).
2. Частотный план на устройстве. Конфигуратор можно запустить с помощью Wine.
3. Частотный план на сервере.

Для настроек LoRaWAN на устройстве, рекомендую поставить:

-Режим активации - OTAA.
-Запрос подтверждения - Вкл.
-Открывать первое приёмное окно через 3 секунды. такая настройка, позволит уйти от проблемы, когда подтверждение не может быть отправлено вовремя, из-за большого пинга до БС (Можно изменить только со стороны сервера, если на сервере не изменить, а оставить 1, то эта настройка "подтянется" с сервера при join`е).
- Количество переповторов увеличить до 3-5.

[yuri]

Статус пакета "SUCCESS" говорит не о успешной доставке на устройство, а о успешной отправке этого пакета. Данный статус отображается только для пакетов отправленных с сервера. Определить был ли доставлен пакет на устройство, Вы не можете.

Режим авторизации, подтверждение и число повторов уже такие как Вы рекомендуете.

Хотелось бы уточнить возможность проверки доставка пакета на устройство. Сейчас делаю так;

Через вебсокет

1. Отправляю пакет с изменениями настроек:

{"cmd": "tx", "status": false, "err_string": "TX-ERROR", "devEui": "3137353258385F13", "data": "001000010531000105", "port": 3,
"ack": true}

2. Через какое-то время получаю пакет

{"ack":0,"appEui":"7665676173693132","cmd":"rx","data":"001000010531000105","devEui":"3137353258385F13",
"dr":"SF12 BW125 4/5", "fcnt":9,"freq":869100000,"gatewayId":"00000CAE7D2A3B9C","packetStatus":"SUCCESS","port":3,"ts":1575452810987,
"type":"CONF_DOWN"}

3. Считаю, что пакет из п.2 пришел от САМОГО устройства и является ПОДТВЕРЖДЕНИЕМ получения пакета из п.1 (устройство, порт, данные совпадают а команды разные).

Если я ошибся в п.3 то кто (если это не устройство) сформировал пакет из п.2 и откуда он взял значение для полей appEui и fcnt ?

[Support]

Режим авторизации, подтверждение и число повторов уже такие как Вы рекомендуете.
Хотелось бы уточнить возможность проверки доставка пакета на устройство. Сейчас делаю так;
Через вебсокет
1. Отправляю пакет с изменениями настроек:
{"cmd": "tx", "status": false, "err_string": "TX-ERROR", "devEui": "3137353258385F13", "data": "001000010531000105", "port": 3,
"ack": true}

Командой TX, Вы ставите серверу задачу на отправку пакета конкретному устройству. А не производите отправку здесь и сейчас.

2. Через какое-то время получаю пакет
{"ack":0,"appEui":"7665676173693132","cmd":"rx","data":"001000010531000105","devEui":"3137353258385F13",
"dr":"SF12 BW125 4/5", "fcnt":9,"freq":869100000,"gatewayId":"00000CAE7D2A3B9C","packetStatus":"SUCCESS","port":3,"ts":1575452810987,
"type":"CONF_DOWN"}

Данное сообщение публикует сервер в websocket сообщая о том, что произвел отправку, с указанием параметров.
CONF_DOWN - пакет (от сервера) требующий подтверждения о доставке
UNCONF_DOWN - пакет (от сервера) не требующий подтверждения о доставке
CONF_UP - пакет (от устройства) требующий подтверждения о доставке
UNCONF_UP - пакет (от устройства) не требующий подтверждения о доставке
Описание других типов пакетов есть в API.

3. Считаю, что пакет из п.2 пришел от САМОГО устройства и является ПОДТВЕРЖДЕНИЕМ получения пакета из п.1 (устройство, порт, данные совпадают а команды разные).
Если я ошибся в п.3 то кто (если это не устройство) сформировал пакет из п.2 и откуда он взял значение для полей appEui и fcnt ?

Вы неверно поняли.

[yuri]

Непонимание есть, это да. Неоправданно обнадежило описание поля
"gatewayId": string, // Gateways that receive data from device
для команды "rx"

Правильно ли я понимаю, что если сервер сообщил, что он отправил устройству сообщение с
указанием параметра "type":"CONF_DOWN" то в последующем он ожидает поступления от устройства подтверждения получения этого сообщения ?

Если ожидает, то как это подтверждение от устройства должно выглядеть в websocket ?

Если НЕ ожидает, то какой смысл в CONF_DOWN ?

[yuri]

Добрый день!

Как запросить у устройства текущее состояние выхода (влючен или выключен) БЕЗ СМЕНЫ этого состояния ?