BLE модули TB-04/TB-03F (TLSR8253F512)

[Slacky]

А вот наверно сейчас глупый вопрос задам

А на TB-04 можно сразу запустить два комплекта RX-TX?

По пинам там все выходит, я про программный вариант ...

Спасибо.

 

[pvvx]

У чипа TLSR825x UART одна.
Кто такие "комплекты RX-TX"?

 

[Slacky]

У чипа TLSR825x UART одна.
Кто такие "комплекты RX-TX"?

Ну вы же поняли

Плохо, что одна. Ну ладно, знать придется смотреть в сторону другого чипа ...

 

[pvvx]

У W801 (178р/шт), CH582M (>200р/in), TG-12F/TG7100C(>200р/шт), BL702: ZB1 (200р/шт)/ RV debug (300р/шт), PB-03F (модуль 70р/шт, kit 200р/шт) и т.д. по несколько UART (до 6 шт).
Это часть ссылок из моих заказов, не все - которые подешевше и лень ковырять список и искать только с BLE, давно пришли и валяются... Т.е. проверенные ссылки.
Вот только кому UART сдались? Никакой чип к нему не прикрутить, и комп/смарт так-же. UART = Мертвый интерфейс.

 

[Slacky]

Извините, но вот еще вопрос. Даже наверно вопросы.

Так как я любитель, в некоторых вопросах наверно даже дилетант, то мне сложно оценить - а правильным ли я путем иду?

Есть у меня идея все-таки сделать считыватель кодов электросчетчика "Каскад" через оптопорт. Передающий светодиод передает команды, фотодиод - принимает ответы. Из интернета вычитал, что обычный диод потребляет в районе 20 мА.

А теперь вопрос - имеет ли смысл с таким потреблением заморачиваться BLE и батарейкой?

Или лучше взять какой-нибудь WiFi-модуль и запитать его от сети?

Хотя, с другой стороны, нужно ли снимать показания чаще раза в сутки?

Спасибо. Может кто пнет в нужную сторону )

 

[pvvx]

Есть у меня идея все-таки сделать считыватель кодов электросчетчика "Каскад" через оптопорт.

А электросчетчик куда подключен? Тоже батарейку измеряет?
Тут только по одному из двух вариантов - если есть и не запрещен доступ к выходам сети со счетчика (вообще в щиток), то и питать там. Ну и второй вариант и так понятный. Но это какое-то безобразие и тогда сами запрещальщики пусть и лепят то, что требуется. Без них во втором случае не обойтись.
Но есть ещё возможные исключения - вы тот запрещальщик

 

[pvvx]

А теперь вопрос - имеет ли смысл с таким потреблением заморачиваться BLE и батарейкой?

Это смотря какая батарейка. 3000 мА.ч?
Такое как-бы лезет в любую коробочку и доступно...

Или лучше взять какой-нибудь WiFi-модуль и запитать его от сети?

А тут уже назвать батарейкой можно только поддон с акб от Теслы, или ради дешевизны какой б.у от Лифан.
Соотношения к батарейкам более десятикратные у BLE и WiFi. Т.е. по объему батарейки не менее чем в 10 раз.
Или к транзистору и трансику AC-DC адаптера... Где быстрее усохнут емкости?

 

[pvvx]

И ещё (но тут только мой опыт - другие говорят у них всё не так) мне приходиться передергивать раз в неделю, две адаптеры с WiFi устройствами на малых SoC подключенные к моим HA . Чаще всего к ним просто нет доступа, хотя соединение с роутером активно. Типичная беда убогой реализации TCP стека и отсутствия MMU для “heap”, что несовместимо с непрерывной работой – т.е. глючит “сокет” и IP порты – не хотят соединяться и HA плодит простыни логов. Это неизбежно, если у них нет встроенной периодической перезагружалки. Для некоторых WiFi устройств это решается перезагрузкой роутера – они заново соединяются и начинают работать. Но это приходится делать вручную, т.к. на сеть (роутеры/модемы/HA) стоит автономка, а автомат их перезагрузок, если и работает, то не то время когда зависают его клиенты. Третья группа WiFi побрякушек иногда теряет связь с роутерами при включении-отключении внешней эл.сети. Так-же бежать и лечить коммутацией питания.
Т.е. за 2 года работы с HA у меня нет ни одного WiFi устройства, которое бы не зависло или не заглючило... кроме реализаций на linux.

А BLE устройства, коих у меня в попечении всегда не менее 50 шт, тоже “глючат”, но не чаще раза в год – требуют замену батареек. В них ничего в памяти не засерается, т.к. они каждый рекламный интервал практически перезагружаются и все стеки CPU и прочие буфера с инициализацией внутренних адаптеров всегда новенькие и чистенькие. А помнить им надо до пары байт, и то для оптимизации потребления…

 

[pvvx]

C ZigBee тоже есть приключения. Но это больше связано с реализацией их сети и является излечимым фактором, если это ваши устройства и имеете доступ к изменению кода и конфигурации сети.

 

[pvvx]

Я не пропагандирую BLE. У него много "но" – нет быстрой обратной связи. И если используется безответная реклама, то такую сеть не положить передачей пары байтиков. Орде из кричащих BLE безразлично, что там в эфире, а частота повторов передач успешно справляется с коллизиями на приемной стороне. У Wifi всё наоборот – пару кривых или неверно понятых битиков рушит всю связь. Т.е. надежность нулевая, если не предусмотрено множество обходов и дополнительных фич выходов из таких ситуаций. На ZigBee и MESH это так-же сказывается. А большинству пользователей нужна надежность, а не “безопасность данных”. Хотя шифрование немного увеличивает отброс кривых битиков за счет большей контрольной суммы и ещё немного за счет увеличенной проверке входных параметров...
В итоге BLE и вырывается вперед для реализации тупеньких дешевых датчиков в сфере IoT. Включил и забыл, но батарейка напомнит

 

[Slacky]

В общем я подумаю над вариантом ble, но запитаю его от щитка. Смысл что-то измерять, если 220 отключат.

 

[Slacky]

А вот еще с чем столкнулся.

Если нет шифрования, то размер пакета, который передается функции bls_ll_setAdvData составляет у меня 27 байт и все прекрасно работает.

А вот с шифрованием размер пакета увеличивается и составляет уже 35 байт. И вот тут облом. Код возврата bls_ll_setAdvData - 0x12.
HCI_ERR_INVALID_HCI_CMD_PARAMS = 0x12,

Если выкинуть пару данных из пакета, уменьшив размер, то все прекрасно работает и с шифрованием.

Я пока не очень понимаю, как это обойти ...

 

[Slacky]

Порылся в примерах, нашел, что 'if legacy ADV, max length 31 bytes is enough'. Нужно смотреть в сторону ext_adv ...

 

[pvvx]

А вот с шифрованием размер пакета увеличивается и составляет уже 35 байт. И вот тут облом.

Нет никакого облома. Передаете данные по очереди - функциональными частями.
Считаете номер передачи рекламы и меняете по этому счетчику данные.

int app_advertise_prepare_handler(rf_packet_adv_t * p)    {
    (void) p;
    adv_send_count++; // count & id advertises
    ....
    bls_ll_setAdvData(adv_buf.data, adv_buf.data_size);
}

// добавить в init ble
    bls_set_advertise_prepare(app_advertise_prepare_handler); // todo: not work if EXTENDED_ADVERTISING

Второй вариант - изредка передавать пачку реклам с доп. данными и другим, более коротким интервалом. Это как во всех Xiaomi.
Обычно интервал у такой пачки ~50 ms и 4...16 сообщений в пачке.
bls_ll_setAdvDuration(время всего цикла в us, 1);
После отработки выпадает bls_app_registerEventCallback (BLT_EV_FLAG_ADV_DURATION_TIMEOUT, &ev_adv_timeout);
В void ev_adv_timeout(u8 e, u8 *p, int n) восстанавливаете стандартный вариант рекламы.

 

[pvvx]

MJWSD05MMC и многие другие термометры в оф. версии работают по второму типу - гонят пачки, когда сменилась температура или влажность (но не чаще 60 сек) или типа, а постоянно передает тупую рекламу с шагом 10 сек:

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

 

[Slacky]

Пример из SDK с ext_adv не зашел сразу. Шлет нули.

0x0201062316D2FC4100000000000000000000000000000000000000000000000000000000000000

Но думаю, он мне не подойдет, так как на машинке, где крутится HA, модуль bluetooth версии 4.2, если память не изменяет ...

 

[pvvx]

Нужно смотреть в сторону ext_adv ...

Смотрите в недописанный SDK от Telink - в доке указано, читайте, что это демо версия и все кто не имеет исходников либ BLE идут лесом, т.е. в реальности кушают глюки.
Я уже среверсил нужные куски, чтобы это можно было использовать, но тесты ещё не завершены окончательно.
В ext_adv нет такого типа рекламы, чтобы по ней было возмождно соединение и сканирование одновременно. Т.е. вам потребуется 2 ext_adv разных типов. А это не реализовано в SDK, как и отключение ext_adv модуля для перехода к старенькому типу Работает только через полную перезагрузку, путем разных ветвей инициализации всех дров BLE.
И для ext_adv вам потребуется специальный адаптер. А их нет в дешевке
А уж для ext_adv с LongRange - тут только золотом платить или самому лепить адаптер.
Как раз срачем по данному поводу и занимался утром - https://github.com/pvvx/ATC_MiThermometer/issues/221 - учился писать через google переводчик
Заодно ковыряя отлаживая уже полу-рабочую версию термометров с полным LongRange.

 

[pvvx]

Заодно ковыряю отлаживая уже полу-рабочую версию термометров с ext_adv и полным LongRange, да опционально со старыми вариантами реклам (Legacy). Отлажу и забуду - уточняйте быстрее вопросы про ext_adv, т.к. там полный дикий лес из-за множества вариантов со всех сторон, и все неоднозначные (опыта у народа вообще с этим нет).

 

[Slacky]

Нет никакого облома. Передаете данные по очереди - функциональными частями.
Считаете номер передачи рекламы и меняете по этому счетчику данные.

int app_advertise_prepare_handler(rf_packet_adv_t * p)    {
    (void) p;
    adv_send_count++; // count & id advertises
    ....
    bls_ll_setAdvData(adv_buf.data, adv_buf.data_size);
}

// добавить в init ble
    bls_set_advertise_prepare(app_advertise_prepare_handler); // todo: not work if EXTENDED_ADVERTISING

Про счетчик не очень понял. Как увеличение счетчика определит нужные данные? Вот было 0, стало 1. Через какое-то время стало 255. Как?

 

[Slacky]

Заодно ковыряю отлаживая уже полу-рабочую версию термометров с ext_adv и полным LongRange, да опционально со старыми вариантами реклам (Legacy). Отлажу и забуду - уточняйте быстрее вопросы про ext_adv, т.к. там полный дикий лес из-за множества вариантов со всех сторон, и все неоднозначные (опыта у народа вообще с этим нет).

Да вроде запустил. Но опять же, 4.2 такой пакет не видит.