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

Есть достаточно много устройств заводского исполнения для умных домов в системе Zigbee, у которых все достаточно неплохо с железом, но хромает программное обеспечение. То это платформа Tuya, где в массе своей все параметры передаются не так, как описано в стандарте, а по своему, через кластер вендора (стандарт оставил лазейку). И в принципе стандартное устройство передает данные не совсем стандартно. К тому же все это, как правило, работает через китайское облако со всеми вытекающими. Или не хватает каких-то параметров и не понятно почему производитель это не добавил.

И если взять вот этот датчик протечки, то он тоже не лишен проблем с ПО. И вроде все хорошо, и имеет стандартные кластеры, и потребление низкое (датчик спит, просыпается один раз в 4 часа и засыпает снова). В дежурном режиме его батарейки хватит минимум на несколько лет. Но, он не умеет управлять другими устройствами Zigbee напрямую. Точнее, он вообще не умеет ничем управлять. Только через координатор может присылать свое состояние - есть протечка, нет протечки. А дальше какая-то автоматизация в Умном доме, которая через координатор сможет послать команду на исполнительное устройство. И если координатор по какой-то причине не в сети, или Умный дом завис, то вся система антипротечки бесполезна.

Натолкнуло меня на написание кастомной прошивки вот это видео.

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

В датчике на видео применен модуль ZTU компании Tuya, куда установлен чип от компании Telink - TLSR8258F1KET32. SDK от этого чипа есть в открытом доступе.

Для начала покупаем такой датчик на Али. Первый вариант, второй вариант,

По первой ссылке пришел датчик именно такой же, как на видео.

А вот по второй пришел датчик, в котором не использовали модуль, а сделали сразу на чипе TLSR8258F1KET32 (правда маркировка другая, но это он).

Но по сути это одно и тоже устройство. Теперь нужно выяснить, на какие GPIO были посажены LED, кнопка и контакт протечки датчика.

Кнопка - идет напрямую на PC0. Активный уровень LOW.

LED - идет через транзисторный ключ на PB4. Активный уровень HIGH.

Контакт протечки - идет через транзисторный ключ на PD7. Активный уровень HIGH.

Рассмотрим также контактные площадки на второй плате, они нам пригодятся для загрузки прошивки и контроля.

Этих данных вполне достаточно, чтобы начать делать кастомную прошивку.

Итак. Сперва нужно выгрузить флеш-память контроллера. Это нужно, во-первых, чтобы сохранить оригинальную прошивку, мало ли, что-то пойдет не так, и нужно будет откатиться на оригинальную версию. Ну и во-вторых, нужно поглядеть на карту флеш-памяти. В принципе, если не озадачиваться обновлением ОТА с оригинальной прошивки на кастомную, этого всего можно не делать, а залить прошивку по адресу 0 с помощью проводов и программатора. Но мы хотим пойти более элегантным путем и поэтому карту надо поглядеть.

Есть два варианта расположения прошивки.

Без bootloader'а. Прошивка располагается по адресу 0 (или 0x40000, если было обновление ОТА), откуда и стартует.

С bootloader'ом. Прошивка располагается по адресу 0x8000 всегда, а по адресу 0 располагаетстя bootloader. Сперва стартует bootloader, затем он запускает прошивку.

В нашем случае мы имеем размер флеш-памяти 1М и загрузка происходит с помощью bootloader'а. Ок, значит прошивку нужно писать с учетом этого.

Теперь нужно определиться, что мы хотим получить на выходе.

1. Батареечное устройство, которое будет работать от батарейки как можно дольше.

2. Стандартное устройство с точки зрения сети Zigbee.

3. Возможность прямого биндинга на исполнительные устройства.

4. Настройка отсылаемой команды, т.е. при обнаружении протечки можно послать команду On, Off или Toggle.

Остановимся на потреблении чипа чуть подробней. Основной способ сна, который предлагает SDK, это Deep sleep with SRAM retention, т.е. это чип засыпает с сохранением переменных в SRAM. В этом режиме чип потребляет примерно от 1 до 1.4 uA. И есть еще один (на самом деле их больше, но в данном случае мы рассматривам только эти два, как самые энергосберегающие), это Deep sleep without SRAM retention. Сохранение переменных не происходит. В этом режиме чип потребляет всего 0.4 uA. Разница у них еще и в том, что во втором случае прошивка стартует, как-будто чип перегрузили. В первом варианте такого не происходит. Вот эти два режима мы и будем использовать. Первый для обычной работы модуля - вход в сеть, после нажатия на кнопку, после обнаружения протечки, после обнаружения окончания протечки, после выхода из глубокого сна. И работать так модуль будет не более 20 секунд. А потом он будет уходить в глубокий сон на 1 час и использовать для этого второй вариант. Надеюсь понятно объяснил :))

С учетом всего изложенного логика работы устройства будет выглядеть так. Датчик все время находится в режиме глубокого сна. Просыпается 1 раз в час, чтобы сообщить сети, что он жив, отправить отчет о состоянии батарейки, если оно изменилось и через 20 секунд уйти опять в режим глубокого сна. Точно так же он будет себя вести, если нажать на кнопку. Или обнаружится протечка. Или протечка закончится.

Итак, прошивка написана с учетом всех этих данных (в конце статьи будет ссылка на github с исходниками).

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

Как видно, что в таком режиме датчик должен проработать на батарейке CR2032 более 10 лет.

Для теста были забинжены два устройства. Умная лампочка и одноклавишный выключатель Акара - по сути тоже лампочка. При замыкании контактов на датчике обе лампочки выключились. После этого был остановлен z2m, обесточен координатор. И при замыкании контактов на датчике обе лампочки снова выключились. Т.е. цель - закрыть кран дажде если сеть не функционирует - достигнута.

Единственная дожка дегтя во всем этом, что какое-то устройство обязательно дожно быть роутером. Датчик протечки является EndDevice'ом. Выключатель Акара является EndDevice'ом, а вот умная лампочка является Router'ом и поэтому это все прекрасно работает без координатора. Но вот забинженный датчик протечки только на выключатель Акара уже не сможет выключить этот выключатель без координатора, так как оба устройсва являются EndDevice'ми

Для обновление дачтика со штатной прошивкой не нужно ничего паять. Нужно просто немного подредактировать конфиг z2m и обновить датчик "по воздуху" - ОТА.

Как обновить и исходники программы в проекте на github'е

Для спорщиков - я знаю, что на проводах надежней :))

Спасибы.

• SGHome_Telegram за видео и за тестирование готовой прошивки.

• Novgorod_DIYZi за идею и за тестирование различных моих поделок :))

P.S. И на всякий случай - автор ни за что не отвечает :))

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

Вокруг да около Zigbee - Обсуждение устройств, прошивок и прочего софта, работающего с Zigbee

zigdev - Группа для разработчиков zigbee девайсов/прошивок. Здесь помогают разобраться как скомпилировать/написать прошивку. Помогают с разработкой железа под зигби.

DIY DEV - группа о DIY электронике. Умные дома, интернет вещей, разработка электроники, программирование.