Делаем свой персональный Home Assistant SkyConnect

Хотелось бы поделиться небольшой историей создания USB-устройства, функционального аналога Home Assistant SkyConnect. Далее рассказ что послужило причиной и как мне удалось реализовать задуманное.DISCLAIMER (Отказ от ответственности)
Данный проект создавался исключительно для собственных нужд и в образовательных целях. Не используйте данную информацию в коммерческих целях. 

Для начала, cразу отвечу всем вопрошающим «зачем ты сделал еще один стик? у меня уже есть такой же»:
1. Стик SkyConnect автоматически обновляется средствами Нome Аssistant, прошивка всегда поддерживается в актуальном состоянии.
2. Возможность смены протокола на Thread(Matter) илиThread(Matter) + Zigbee и обратно на Zigbee в пару кликов, с сохранением работоспособности предыдущей конфигурации (подробности здесь)

Теперь расскажу почему вообще и как всё это развивалось.
В своем доме я много лет пробовал различные системы домашней автоматизации и периодически испытывал на практике все, что существовало на тот момент. Home Assistant не был исключением, еще несколько лет назад я пробовал им начать пользоваться не один, даже не десять раз, но каждый раз что-то приводило меня к разочарованию. Все изменилось, когда разработчики решились взяться за дело всерьёз и основали компанию Nabu Casa, после этого разработка стала принимать более позитивные черты, и его стало удобно использовать. Самое главное, компонент Zigbee Home Automation (ZHA) получил достаточно большое внимание и наконец превратился в действительно работающее решение. Благодаря этому, пару лет назад я перевёл все свои устройства исключительно на использование компонента ZHA.

Используя решения Zigbee в течение длительного времени, естественно, как и многие другие, я попробовал множество различных USB-устройств Zigbee в качестве координатора. И почему-то наибольший интерес у меня вызвало именно решение от Silicon Labs, стик на основе EFR32MG21. Один из первых таких стиков на этом чипе был от Sonoff, который ещё не являлся «Plus» и не имел корпуса, но он показал достаточно стабильную и устойчивую работу именно с компонентом ZHA. Это оказалось тем что я искал. С появлением мультипротокольного решения от Silicon Labs, я успешно протестировал работу с Matter и Thread и это оказалось достаточно удобным решением, все в одном флаконе.

Буквально через какое-то время появились новые USB-стики от Sonoff, а также USB-стик от создателей Home Assistant SkyConnect. На первый взгляд такой же обычный стик, как и многие другие, основанные на чипе EFR32MG21, но как оказалось, было одно очень важное отличие от остальных — это нативная поддержка самим Home Assistant.

Я столкнулся с этим, когда после очередного обновления HA у меня вдруг перестала работать Zigbee сеть. Выяснилось, что необходимо обновить прошивку на координаторе. И тут я понимаю, что я уже не помню, как именно я это делал. Я не помню, какая у меня вообще модель стика, что вообще необходимо туда прошить. В этот момент я вспомнил про SkyConnect и про то что его не надо обновлять в ручном режиме, так как это легко делается средствами Home Assistant и можно будет забыть уже про эту игру с прошивками.

При попытке приобрести выяснилось, что эта вещь достаточно популярна, и везде, где её можно приобрести, она отсутствует в продаже.  Так как у меня были в наличии модули от eByte E104-BT11 с чипом EFR32MG21A020F1024IM32, точно таким же, как используется в SkyConnect, я подумал, а не собрать ли мне свою версию. Пошёл собирать информацию и оказалось, что это вполне реально.

Вся информация была взята из открытых источников.
1. Конфигурация, куда и что подключено на стороне EFR32MG21
2. Описание как именно определяется в HA, что это SkyConnect (PID/VID стандартный от CP2102, описание должно быть SkyConnect v1.0.)
3. Описание как аддоны определяют что подключенный стик это SkyConnect (название производителя «Nabu Casa», а название продукта «SkyConnect»)

Почитав даташиты, я узнал что с помощью программы USBXpress можно поменять нужные параметры в cp2102. Осталось дело за малым, схему нарисовать. Дело не очень хитрое, но вот красиво платы разводить это мне надо как-то заняться. Понятное дело, что можно абы как, но хотелось ведь красиво, в результате @Jager помог развести данный модуль.

Схема не сложная, CP2102 + E104-BT11, защита USB, несколько резисторов подтяжки и конденсаторы по питанию.

Печатная плата двухслойная, толщиной 1,6мм. Такая толщина недостаточна для хорошего контакта USB разъема, поэтому если не использовать корпус, то с обратной стороны желательно наклеить кусочек изоленты.
Также сразу было рассчитано, что изготовление платы и сборку (кроме модуля E104-BT11) можно заказать на jlcpcb, для совсем ленивых, типа меня 🙂. Идея использовать PCB USB, такой же, как и в SkyConnect, тоже показалась здравой. 

Иду дальше, из нарисованного в EasyEDA заказываю производство плат сразу с распайкой мелочевки. Элементы выбраны такого размера, что можно припаять самому, особенно если использовать столик для распайки/запайки LED лент с AliExpress. И останется припаять только модуль, опять же с использованием данного столика.

Первое включение без запаянного модуля, чтобы убедиться, что питание правильное и на том месте, где должно быть. Быстренько припаиваю модуль, подключаю программатор к SWD/SWC (как именно это сделать можно почитать в этой статье)

запускаю Commander, вижу, что чип определился корректно.
Для начала, конечно же, нужно прошить bootloader. Вспоминаю, что я его уже видел там же на GitHub у NabuCasa.
Беру версию посвежее (хм, а почему два года назад то.. ну ладно, потом обновлю), стираю чип, прошиваю скаченным bootloader’ом.

Дальше подключаю к USB компьютера, и система успешно распознает USB-serial адаптер CP210x. Осталось поменять Manufacturer Name и Product Name. Открываю USBXpress, меняю Product Name на «SkyConnect v1.0». Пытаюсь поменять Manufacturer Name, и первая засада, USBXpress мне вежливо говорит, что «на данном чипе поменять Manufacturer Name невозможно, и что если мне очень хочется, то можно заказать сразу с правильным именем от самих Silicon Labs» (но как я узнавал, это только от 1000 штук) — вот тебе и сюрприз.

Ладно, решил я, к этому ещё вернемся, а пока же он должен как любой другой USB Zigbee стик работать.

Беру Elelabs_EzspFwUtility.py и запускаю:

python3 Elelabs_EzspFwUtility.py probe -p /dev/tty.usbserial-0001

В ответ вижу:

2024/01/24 18:37:32 Elelabs_EzspFwUtility: Generic Zigbee EZSP adapter detected:

2024/01/24 18:37:32 Elelabs_EzspFwUtility: Firmware: 7.1.1-17

2024/01/24 18:37:32 Elelabs_EzspFwUtility: EZSP v9

Вроде все выглядит неплохо. Вставляю стик в сервер с Home Assistant, он радостно говорит, что «найдено устройство SkyConnect v1.0». Это значит, что я иду правильной дорогой, но при попытке сконфигурировать, ZHA говорит, что прошивка неправильная, но ничего делать с этим не хочет (или не может), так как выдает просто «Unknown error». Опять препятствия…

Иду на сайт, подключаю стик, выбираю «прошить», говорит «да, есть прошивка, давай обновим»,  при попытке обновления — сбой.

Посмотрев что firmware-update использует universal-silabs-flasher, устанавливаю его.

Запускаю:

universal-silabs-flasher --device /dev/tty.SLAB_USBtoUART probe

В ответ вижу ответ от бутлоадера:

universal_silabs_flasher.flasher INFO Detected bootloader version '2.1.1'

universal_silabs_flasher.flasher INFO Detected ApplicationType.GECKO_BOOTLOADER, version '2.1.1' at 115200 baudrate (bootloader baudrate 115200)

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

Собираю последнюю версию 2.4.0, заливаю через Commander

результат

universal-silabs-flasher --device /dev/tty.SLAB_USBtoUART probe

universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud

universal_silabs_flasher.flasher INFO Detected bootloader version '2.4.0'

universal_silabs_flasher.flasher INFO Detected ApplicationType.GECKO_BOOTLOADER, version '2.4.0' at 115200 baudrate (bootloader baudrate 115200)

и о чудо, все прошивки через web flasher загружаются и отвечают без вопросов. Подключаю к ZHA, все работает. Ну, это же успех, подумал я. Пробую прошивку с поддержкой мультипротокола, аддон естественно, говорит, «я не знаю, кто это, и прошивать не буду». В аддоне есть возможность указать вручную файл прошивки который нужно загрузить, чем я и воспользовался..

Все прошивается, стартует и… не работает, сплошные ошибки:

[19:12:40:603157] WARNING : In function 'core_process_rx_s_frame' in file /usr/src/cpc-daemon/server_core/core/core.c at line #818 : Remote received a packet with an invalid checksum

[19:12:40:632792] WARNING : In function 'core_process_rx_s_frame' in file /usr/src/cpc-daemon/server_core/core/core.c at line #818 : Remote received a packet with an invalid checksum

[19:12:40:660790] WARNING : In function 'core_process_rx_s_frame' in file /usr/src/cpc-daemon/server_core/core/core.c at line #818 : Remote received a packet with an invalid checksum

Но ведь Zigbee-то работает. Что за чудеса. Пошел проконсультироваться, и вот тут сразу же всплывает, что CTS надо было к RTS подключать.
Режу дорожки, припаиваю проводки, и о чудо, все работает!
Остался непобежденный Manufacturer name, но в документации то сказано можно поменять, что не так-то…
Решил найти что-то старое, нахожу много проектов на GitHub с исходным кодом, но практически везде на запись Manufacturer Name (или Vendor name) стоят заглушки типа:

CP210x_STATUS CCP2102Device::SetManufacturerString(LPVOID lpvManufacturer, BYTE bLength, BOOL bConvertToUnicode) { return CP210x_FUNCTION_NOT_SUPPORTED; }

В результате мне подсказывают про этот проект у которого есть необходимые ключи и все выглядит многообещающим. Скачиваем, запускаем, и опять препятствие, принимает все параметры, изменяет все что угодно, но Manufacturer Name остается Silicon Labs.
Утро вечера мудренее, с утра просыпаюсь с мыслью, что ведь это хранится должно в EEPROM, и что утилита то может сохранять EEPROM и записывать его обратно. Приходит идея поменять прямо в хексе, и тут мне подсказывают практически ту же мысль, утилита может менять прямо в файле.
Сохраняю дамп: 

cp210x-program.py –read-cp210x -f eeprom-content.hex

Меняю: 

cp210x-program.py -pc --set-product-string='SkyConnect v1.0' --set-vendor-string='Nabu Casa' --set-bus-powered=yes -F eeprom-content.hex > mod.hex

Записываю: 

cp210x-program.py --write-cp210x -F mod.hex

 

И наконец-то, долгожданная удача. Всё определяется, переключается, прошивается, как на на сайте так и в аддонах, в мультипротокол и обратно в Zigbee.

 

UPD: Обновление (08.02.2024)

Изначально чип EFR32MG21 запитывался от встроенного LDO cp2102. Так как по умолчанию в ZHA для SkyConnect выставляется мощность 8dBm и EFR32MG21 в таком режиме потребляет ~50мА, то выходного тока LDO cp2102 хватает с запасом. При этом сам чип EFR32MG21 может выдавать мощность в 20dBm, потребляя при этом уже 185мА в момент передачи, и в таком режиме для питания необходим дополнительный LDO. По этой причине появилась вторая версия, с минимальными изменениями.

Для желающих повторить, все необходимые файлы обоих версий в архиве + корпус.

Инструкция чем и как прошивать EFR32  от @goofyk доступна здесь 

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