We need to go deeper...
We need to go deeper...

NB: Это скорее шуточная статья, не воспринимайте написанное всерьёз.

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

После того как удалось заставить датчик подключаться к сети, мне стало интересно, а что ещё можно сделать из термометра? Сам чип достаточно функциональный, в нём есть I2C, SPI, несколько UART, и даже USB. Жаль только, что в версии, которая стоит в датчике на выводы чипа выведено немного из того что есть внутри чипа. И ещё сама разводка платы тоже накладывает ограничения, если мы не хотим паяться к ножкам микроконтроллера или разводить отдельную плату под него. Конечно, есть модули с чипом TLSR8258 на алиэкспрессе, TB03F, TB04 но для них требуется отдельная плата или навесной монтаж, потому это не наш вариант.

Итак, что в теории можно сделать? Есть ряд свободных пинов на тестпоинтах. Можно припаять геркон и получить датчик открытия. Можно замыкать провода в воде и сделать датчик протечки. Аналогично можно сделать кнопку и что-нибудь включать. Это всё конечные устройства. Ещё можно сделать что-то посерьёзнее, например счётчик импульсов со счётчика электричества или счётчиков воды. Они всё ещё могут спать до нового импульса, тем самым позволяя работать от батарейки.

Добавляем Mesh

Ещё бывают зигби-роутеры. Это устройства, которые, помимо всего того, что делают конечные устройства, ещё могут передавать сообщения от конечных устройств другим роутерам или координатору. Для них нужно постоянное присутствие в сети, чтобы во сне не пропустить сообщения от конечных устройств, которые к ним подключились. Но тут батарейное питание уже не подойдёт, нужно будет запитать от сети. Тут из LYWSD03MMC можно придумать управление реле через транзистор и сделать умный выключатель, который при замыкании пинов будет отправлять команду на включение-выключение. Или же подключить что-нибудь к встроенному UART, например PZEM-004T и передавать параметры тока. Или же подключить к умному дому датчик воздуха ИКЕА ВИНДРИКТНИНГ. В зигби за работу сети обычно отвечает SDK, потому разработчику достаточно определить нужные кластеры и заполнять их в нужное время значениями. В SDK от Telink есть примеры устройств-роутеров: лампочка, выключатель, потому при желании можно реализовать. (Это всё идеи для DIY, пока нет готовых решений)

Отлично, в нашей воображаемой сети из LYWSD03MMC уже есть конечные устройства и роутеры.

ZigBee координатор

Остаётся место для главного узла zigbee-сети — координатора. У большинства производителей координатор, как и любое зигби устройство, работает сам по себе. Т.е. если уже есть сеть, то можно просто запитать его и он будет как-то работать с сетью, маршрутизировать её, перестраивать маршруты. Взаимодействие с внешним миром осуществляется через отправку и получение команд по UART. Если надо разрешить добавление устройств в сеть, шлём команду. Устройство подключилось — из последовательного порта приходит сообщение в соответствующем формате. Беда только, что у каждого производителя чипов свой формат сообщений.

Что же касается нашего LYWSD03MMC, то у него в ревизии B1.4 как раз на тест-поинтах

  • P7 — TX

  • B1 — RX

Картинка взята из проекта pvvx/ATC_MiThermometer для ревизии B1.4
Картинка взята из проекта pvvx/ATC_MiThermometer для ревизии B1.4

Собираем прошивку координатора из примера в SDK, предварительно указав правильные GPIO для работы UART и включив управление через последовательный порт (можно ещё взаимодействовать по встроенному в чип USB, но его у нас в термометре его нет). И переключаем проводки с прошивки через SWS на нормальные RX/TX для общения с координатором. Теперь мы можем слать команды и термометр-координатор будет нам отвечать.

В SDK от Telink есть приложение для работы с COM портом, собранное под Windows, но есть исходные коды. Приложение написано на python с использованием PySide и Qt6.

ZGC tool
ZGC tool

Программа - это хорошо, но мы же не будем вручную рулить сетью. Нам нужен zigbee2mqtt.

Zigbee2mqtt на самом деле состоит из нескольких частей: сама программа, которая обрабатывает события от устройств и отправляет в MQTT и получает оттуда команды, инферфейс, набор конверторов для работы с устройствами, сделанными не по стандарту и zigbee-herdsman, который отвечает за низкоуровневую работу с адаптерами и взаимодействие с з2м уже в приятном ему формате. Это то, что нужно доработать. Хердсман уже включает в себя протоколы для 4 разных производителей. Значит нам надо добавить ещё один для работы с telink.

Я взял за основу драйвер для zigate, т.к. немного приложил руку к его созданию. Он мне визуально немного знаком, хотя всё равно это куча непонятного кода. Скопировали, переименовали. Убираем всё что относится к протоколу работы zigate, нам надо будет всё заново писать. Запускаем с дебаг сообщениями: что-то ругается. Комментируем, запускаем снова. И так по кругу. Если вкратце, то наша задача описать в формате хердсмана

  1. Возможные сообщения, которые программа получает из COM-порта, например, появление устройства в сети

  2. Парсинг сообщения и конвертация в объект, который понимает zigbee2mqtt

То же самое и с командами, которые мы отправляем координатору. Например, включи режим спаривания на 250 секунд. Надо сообщение от з2м преобразовать в команду понятную координатору и отправить в COM-порт. Смотрим, на ошибки в логах, добавляем парсер и обработку команды, пробуем дальше. Одним глазом глядя в код ZGC tool, другим в код SDK, где идёт фактическая обработка сообщений, потихоньку добавляю необходимое в код адаптера хердсмана.

Что в результате? У меня получилось реализовать небольшую часть команд, но этого оказалось достаточно чтобы zigbee2mqtt стартовал используя термометр LYWSD03MMC как координатор, общаясь с ним по UART. Я смог подключить к нему датчик открытия дверей Xiaomi MCCGQ01LM, и он даже смог отправлять свой статус - батарейку и открыто/закрыто. Неплохо для термометра!

Конечно, данную работу нельзя назвать законченной, это proof-of-concept для исследования возможностей этого чипа в экосистеме зигби. Но возможности по кастомизации уже радуют.

Наработки по начальной поддержке протокола Telink я выложил на гитхаб.
https://github.com/devbis/zigbee-herdsman-telink/. Ещё раз хочу отметить, что это самая базовая поддержка, 95% функций не будет работать, но можно самостоятельно доработать.

Для желающих повторить эксперимент, нужно склонировать репозиторий, собрать typescript в javascript с помощью npm run build, и затем в рабочей установке z2m заменить node_modules/zigbee-herdsman на содержимое папки. Также нужно в файле settings.schema.json в поле "adapter" добавить "telink" к списку адаптеров, чтобы получилось ["deconz", "zstack", "zigate", "ezsp", "telink", "auto"]. После этого можно указывать telink в конфигурационном файле и запускать.

Зачем эти извращения?!

Мне было интересно исследовать возможности дешевого устройства и, возможно, замотивировать кого-то сделать на его основе пользовательские устройства, которые могут работать в сети зигби. Ведь это в ряде случаев может покрыть часть вопросов, которые решаются народным ESP8266/32 и кого-то избавить от проводов, нужных для питания еспешек. Правда, для этого микроконтроллера пока нет готовых автосборщиков, таких как ESPHome или Tasmota, потому порог входа будет повыше. Конечно, я не ожидаю, что это сподвигнет кого-то менять проверенные временем стики и шлюзы на координаторы на основе чипов Telink. Но и zigbee2mqtt когда-то начиналась с поддержки единственного стэка от Texas Instruments и другие адаптеры были добавлены позже. Так что всё может быть. :)

Комментарии (15)


  1. iamkisly
    06.11.2023 09:37
    +2

    не воспринимайте написанное всерьёз

    Я думаю вы недооцениваете энтузиастов )


  1. shadrap
    06.11.2023 09:37

    Ведь это в ряде случаев может покрыть часть вопросов, которые решаются народным ESP8266/32 и кого-то избавить от проводов, нужных для питания еспешек

    Позвольте...))) у меня как минимум 8 батарейных сенсоров на еспшках - прекрасно работают. И заменить мне их нечем с точки зрения дальности. Даже не столько имеется ввиду дальность еспшного вифи, сколько приемной точки доступа, переделанный в наностейшн Тплинк 5210. Надежнейшее и не дорогое решение.


    1. ksotar
      06.11.2023 09:37

      А что по потреблению/частоте опроса у них?


    1. teuchezh
      06.11.2023 09:37

      У меня тут как раз есть наностейшн м2, расскажите, как использовать во благо умного дома?


      1. shadrap
        06.11.2023 09:37
        +1

        Да как ее можно использовать?) - у меня это точка доступа уличная для всех устройств в пределах участка, это батарейные датчики или свч извещатели периметра. Никакой фантастики она не дает - хорошая надежная точка с прекрасной антенной , встроенным POE и гигабитом по кабелю. Просто раньше у меня был оригинальный TPlink 5210 и я с ним намучался - просто сборище глюков, а после того как перешил его в наностейшн - прям облегчение. самый удаленный датчик - батарейным питанием ЕСПшка , правда с внешней антенной - дистанция 200м . Лес , из других сетей только мои и одна соседа. За 8 секунд успевает все сделать, успевает и за 4 , но через раз)


        1. belokobylskiy Автор
          06.11.2023 09:37

          Напишете, пожалуста, как его перешить? Насколько наностейшн лучше традиционного опенврт?


          1. shadrap
            06.11.2023 09:37

            Как перешить - полно ссылок в инете . Насколько лучше - не знаю, смотря для чего. В сетевом плане для меня -лучшее враг хорошего. Опенврт -это целое комьюнити )). Мы же говорим о хорошем железе у TPLINK 5210 и отвратительнейшем софте, что исправляет софт от наностейшн вот и все. Вообще эта штука конечно очень прикольная. Два таких , в принципе копеечных девайса , организовывают мост с хорошим стабильным каналом на 10 и более км....


          1. vrg18
            06.11.2023 09:37

            Есть и программный способ https://www.lan23.ru/forum/node/7005


  1. shadrap
    06.11.2023 09:37

    сон 12мка , измерение - без вифи 18ма , передача 70ма , частота опроса - это кому как нужно , сенсоры раз в час просыпаются , а датчики открытия - "он деманд".


    1. belokobylskiy Автор
      06.11.2023 09:37

      Окей, ряд случаев, который я имел ввиду не включает ваш случай :)
      Зигби хорош тем, что за счёт более низкого потребления можно и отправлять чаще и обратную связь делать на уровне протокола. Например, обновить прошивку не трогая датчик или поменять параметры опроса.


      1. shadrap
        06.11.2023 09:37

        Зигби хорош - это правда) Миниатюризация и долгая работа от маленького источника энергии это огромный плюс - это прям настоящее большое преимущество...

        Насчет обратной связи "на уровне протокола" - не уверен что имеется ввиду.

        А прошивка ОТА давно регулярное дело)) Про параметры опроса даже упоминать не стоит - это странно если б это было нельзя

        Мало того , простейший есп8266 может довольно сносно работать как АП-СТА и по сути быть гейтвеем для других более удаленных , например устройств, конечно для этого ему нужно питание. Вначале я так и использовал , но после того как попробовал наностейшн перевел все на него.


        1. belokobylskiy Автор
          06.11.2023 09:37

          обратной связи "на уровне протокола"

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

          Про параметры опроса даже упоминать не стоит - это странно если б это было нельзя.

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


          1. shadrap
            06.11.2023 09:37

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

            Хмм , конечно , устройство должно проснуться для получения динамических инструкций, дальше оно может продолжить спать с измененным временем просыпания , измерения и тп . Т.е. например если устройство намерило что ничего не изменилось и передавать нечего , то оно ничего может и не передавать, но что бы получить что-то конечно нужно 70ма на секунд 4-5 потратить.

            гейтвей конечно мог хранить регистры последних данных спящих устройств - это не проблема

            А разве в вашем случае устройству не нужно проснуться для каких-то активных действий? Разве схема не одинакова - один сетевой - один батарейный\спящий


            1. belokobylskiy Автор
              06.11.2023 09:37

              Нужно, конечно, проснуться. Просто за счёт низкого потребления и коротких пакетов от батарейки можно просыпаться раз в 5-10-20 секунд и это всё ещё будет адекватно работать от одной батарейки. Для конкретно моего примера - это 2мс на 8мА (передача)

              Про "один сетевой" теперь я не понял, но если речь про координатор, то да, он должен быть всё время в сети.


              1. shadrap
                06.11.2023 09:37

                тут конечно спору нет , вифи не может с этим тягаться.

                Да конечно, имелась ввиду структура, чудес нет - она везде одинакова, преимущества зигби -это миниатюрность и длительность работы от батарей, еспшки и вифи- дальнобойность и скорость, собственно это общеизвестно, просто еще раз обсудили)))