Just Nommy - Blog [Ru]

Глубокая зачистка секретов в Gitlab

2026-03-17T00:00:00+00:00

Итак, мы случайно git commit -a -m "I don't know how to use git"</code>. Ну, или просто проморгали тот факт, что после сеанса неистового дебага в коммите оказались креды от какого-нибудь особо важного сервиса, которые там быть не должны. Все мы люди, в конце концов. Поэтому сейчас будем разбираться как сделать так, чтобы минимизировать ущерб.

Сценарий первый: ничего не предвещает</h1>
Мы заметили вовремя, что что-то пошло не так и не сделали git push</code>.

Вешаем себе медальку за внимательность, редактируем файл, делаем git commit --amend</code> и радуемся жизни.

Но это только если оплошность произошла в последнем коммите.</p>
Если оплошность произошла несколько коммитов назад и мы так и не сделали git push</code>, то тут есть два плюс-минус нормальных варианта.</p>

git reset --soft <commit_sha></code>, редактируем файл и снова создаём чистый коммит.</li>
git rebase -i <commit_sha></code> и наслаждаемся увлекательным процессом интерактивного ребейза.</li>
</ul>
Ну и ещё альтернативный рут с использованием фиксапов, но это изначально надо в рабочем пайплайне иметь.</p>
Сценарий второй: Почему я идиот?</h1>
Мы не заметили вовремя, что что-то пошло не так и всё же сделали git push</code>.</p>
Во-первых — любые попавшие в паблик креды нужно максимально быстро ревокнуть</strong>.</p>
Во-вторых — готовимся, что нас будут бить. Возможно даже ногами.

Чтобы били не так сильно, делаем всё то же, что и в первом случае, а потом git push --force-with-lease</code></p>

И обычно на этом этапе заканчивается большинство гайдов "Что делать если я запушил креды в гит?", а также по-настоящему начинается то, чем я хочу поделиться.

Прошаренные люди знают, что в Git существует reflog, и переписанный коммит всё равно остаётся на диске доступный для восстановления. 

И люди, которые делают Gitlab тоже об этом знают, поэтому Гитлаб периодически запускает housekeeping таски, подчищающие таки висящие коммиты.</p>
Чтобы не ждать, пока уборщица подметёт за вами, почистить мусор можно в Settings > General > Advanced > Prune unreachable objects</code>.

Однако есть случаи, когда эта кнопка, несмотря на свой опасный красный цвет, не зачищает висящий коммит.

Проверить этом можно, попытавшись открыть его прямой ссылкой. Что-то вроде gitlab.example.com/group/project/-/commit/46a9d30f7a7d86adf34299367b0be7ffd0700eb60b079f3cad246c57409bd471</code></p>
Показывает 404? Всё хорошо (относительно). А иногда снова показывает старый код, и вот они наши креды прям открытм текстом.</p>
Сценарий третий: Господи, за что мне это?</h1>
Тут следует сделать отступление и поговорить про вещи, которых нет в гите, но есть в Гитлабе. CI/CD и Merge Requests.

Мы же как-то можем видеть в окне MR'а список коммитов, диффы и вот это вот всё.

И оно никуда не исчезает. Даже когда ветка удалена, MR закрыт и про это уже все забыли.</p>
Особенно приятно это узнать, когда репозиторий существует несколько лет и кто-то когда-то оставил ключ от API в отдельной ветке, в одном из самых первых MR.

Бонусные очки, если репозиторий достался в наследство и доступы к аккаунту уже пять лет как потеряны, а на носу SOC 2 аудит.</p>
И именно об этом сценарии мы сейчас поговорим. Именно в контексте селфхостед Гитлаба, потому что на облаке нам рута никто не даст.</p>
Также небольшой дисклеймер, что написанное относится к Gitlab 18.6.2, а весь механизм keep-around'ов нервирует не одну меня, так что в будущем всё может измениться.</p>
Зачистка основной истории</h2>
СДЕЛАЙ БЭКАП!!!</strong>

Вот прям капсом и с тремя восклицательными знаками. Продолбать нужные данные при переписывании истории — это неиллюзорный шанс и лучше бы иметь точку восстановления.</p>
Дальше нам надо запустить произвольно выбранный сканер и записать полные хеши коммитов, в которых оказались креды.

Ну, просто потому что это удобно будет, да и сканер по десять раз гонять — процесс долгий.</p>
А вот дальше уже можно запускать BFG</a>, git-filter-repo</a> или ещё какую тулзу для зачистки истории от нежелательных строк. Тут вообще не принципиально.</p>
Дальше git push --force --all</code>, вот это вот всё, ну там в мануале тулзы будет написано.</p>
Поиск сущностей</h2>
Прежде чем начать зачищать удалённый репозиторий, нужно бы отследить где вообще эти коммиты используются, чтобы случайно не сломать Гитлабу интерфейс.</p>
Так что делаем gitlab-rails console</code> и начинаем вспоминать Ruby</p>
commit_sha = "</span><target_commit_hash></span>"
</span>
</span># Список ID пайплайнов
</span>Ci</span>::</span>Pipeline</span>.where(</span>sha:</span> commit_sha).map(&</span>:id</span>)
</span>
</span># Список MR
</span>MergeRequestDiffCommit</span>.where(</span>sha:</span> commit_sha).map(&</span>:merge_request_diff</span>).map(&</span>:id</span>).uniq
</span></code></pre>
Печатает некрасиво, зато дебажить удобно.</p>
Я не уверена, что эти сущности обязательно удалять надо, но от греха подальше в целом можно. А то мало ли ещё где всплывёт.

Это можно и через консоль сделать, но на этом этапе паранойя обычно достигает такого уровня, что лучше уж через UI.</p>
Поиск репозитория</h2>
Тут прежде чем открывать консоль, нужно сходить в UI и посмотреть ID репозитория. Он находится в Settings > General > Naming, descriptions, topics > Project ID</code></p>
А дальше снова возвращаемся в консоль и делаем</p>
Project</span>.find(</span>PROJECT_ID</span>).repository.disk_path
</span></code></pre>
Это выдаст нам относительный путь в духе @hashed/5d/0d/5d0db47fcc1b04bcf18b2f6d7d2f8d9c40589f3bf329b55baf7084cb553e8da8.git</code>.

Относительный он к пути хранилища, так что если у вас NixOS, то это по-умолчанию /var/gitlab/state/repositories/</code>. В случае других вариантов рекомендую свериться с чертежом.</p>
Склеиваем вместе и поехали:</p>
cd</span> /var/gitlab/state/repositories/@hashed/5d/0d/5d0db47fcc1b04bcf18b2f6d7d2f8d9c40589f3bf329b55baf7084cb553e8da8.git
</span>
</span># Ветки, в которых остался коммит
</span>git</span> branch</span> --contains </span><commit_sha>
</span>
</span># Теги, в которых остался коммит
</span>git</span> tag</span> --contains </span><commit_sha>
</span>
</span># Рефы, в которых остался коммит
</span>git</span> for-each-ref</span> --contains </span><commit_sha>
</span></code></pre>
Поиск в ветках и тегах обязательно должен выдавать пустой результат. Если результат не пустой — что-то недочистили и время вернуться к первому шагу.</p>
А вот список рефов из последней команды — это те самые штуки, которые не дают Гитлабу нормально зачистить коммиты. Выглядит это как-то так:</p>
d6cb0ea8746201dfb0a9303563bd52e31555541a25fc9e1dbfda8f757a9c92bb    commit  refs/keep-around/d6cb0ea8746201dfb0a9303563bd52e31555541a25fc9e1dbfda8f757a9c92bb
</span>4ef7ba090eb92e6a95f727b73cf2f1979ba83ee6bb63a4dc902790793b9274c6    commit  refs/keep-around/4ef7ba090eb92e6a95f727b73cf2f1979ba83ee6bb63a4dc902790793b9274c6
</span>fd3fa98ec1d67c155f2e9900023460bd4c41f6b87b2344188a4a1b1b51ee6fbf    commit  refs/keep-arount/fd3fa98ec1d67c155f2e9900023460bd4c41f6b87b2344188a4a1b1b51ee6fbf
</span>d602c43e76a1e51e77b9aa441f5250d14b05ce55b213214aa287610b22b8df5a    commit  refs/merge-requests/512/merge
</span>ae2e6f410385c1e78c2be5bb839299b14db296a9048ddb04a5605e035e023816    commit  refs/merge-requests/712/merge
</span></code></pre>
Логично предположить, что refs/merge-requests</code> относятся к merge request'ам, а вот с refs/keep-around</code> чуточку другая история. Насколько я поняла (а поняла я не очень хорошо) Gitlab создаёт эти рефы для CI тасок, но вроде и не только. Поэтому их зачистка может сломать что-то кроме CI, который мы (в теории) зачистили на прошлом этапе.</p>
Так что на свой страх и риск:</p>
git</span> update-ref</span> -d </span><ref_name>
</span></code></pre>
И в конце с чистой совестью делаем</p>
git</span> reflog expire</span> --expire</span>=now</span> --all
</span>git</span> gc</span> --aggressive --prune</span>=now
</span></code></pre>
Сценарий четвёртый: Hans, get the flammenwerfer!</h1>
git@sweetiebelle in /var/gitlab/state/repositories/52/66/5266a2866c3d458909112a2a85958e690e5b5b10ac3ef8e97b50f195ff145d74.git λ git for-each-ref --contains b682940 | wc -l
</span>6251
</span></code></pre>
ДА БЛЯ!!!</strong></p>
Пойду репозиторий заново создавать.</p>

Тестируем "экзотические" p2p VPN 2025-09-27T00:00:00+00:00 С чего всё начал лось</h1> Мой стандартное решение "на каждый день", когда дело доходит до связаывания компьютеров в одну сеть — Wireguard. Wireguard хорош, умеет в p2p, и в целом так-то никаких минусов не имеет. Минусы имеет нахождение части моей домашней инфраструктуры на территории под контролем страны, которая заблокировала Wireguard по сигнатурам. Что, конечно же, максимально отвратительно, а ещё отвратительнее то, что блокировки уже давным-давно перестали подчиняться хоть какому-то законодательству. В итоге получается непонятный чёрный ящик, который может делать что угодно, вести себя как угодно и никто уже не знает, как эта шайтан-железка вообще работает. А значит настало время пенетрации. Почему не обфускация?</h1> На самом деле есть несколько проектов, которые позволяют обфусцировать Wireguard трафик и пробить фаерволл. udp2raw</a>, wstunnel</a> и прочие отлично с этим справляются. И ещё Amnezia VPN</a> сделали свой собственный форк Wireguard'а, специально для пробития государственной цензуры. Но главная проблема обфускации — это уменьшение эффективного MTU пакета. Ну, потому что один пакет мы оборачиваем в другой пакет, и вот этот оверхед место занимает. A это не хорошо. Чего я хочу от VPN</h1> p2p mesh сеть Wireguard — это конечно хорошо, но пропускать весь трафик через один сервер чревато последствиями. Последствия обычно включают запуск марсохода, чтобы переключить VPN на другой сервер в случае блокировки по IP или просто потому что серверу стало нехорошо. Да и гонять трафик через половину планеты только чтобы постучаться в машину, которая находится на расстоянии вытянутой руки — это что-то неправильное. </li> Open source and selfhosted В таких делах полагаться на third-party провайдера либо опасно, либо бесполезно. Тот же Tailscale, например, знаменит своими географическими блокировками, так что полагаться на него бессмысленно. А так как Tailscale делает это не по желанию левой пятки (надеюсь), то нет никаких гарантий, что другие сервисы не поступят так же. </li> Идеологически правильный VPN Этот пункт тут существует специально для Headscale и ZeroTier. Создание урезанного опенсорсного продукта для рекламы коммерческого — это порочная практика и лично я такое не одобряю. </li> Не Wireguard По очевидным причинам. Блокировки по сигнатурам. </li> Упаковано в nixpkgs Тут ещё очевиднее. Сношала я VPN в nix паковать. </li> </ul> Подопытные</h1> EasyTier</h2> GitHub</a>, Official site</a> Это, наверное, самый простой способ создать p2p сеть. Настолько простой, что в nixpkgs даже нет модуля для его запуска. Из безопасности тут только строка с паролем в --network-secret</code>, которая и используется для шифрования трафика. Для работы сразу открывает TCP, UDP, WG, WS, WSS и черта лысого. Одно заблокировано, так через другое пробьётся. Фактически все ноды в сети одинаковы и можно указать несколько пиров для первоначальной установки связи. Можно использовать как публичные, которые можно посмотреть здесь</a>, так и указать одну из своих нод. Никакой дополнительной настройки оно не требует. К слову, имеет клиенты для Android, Windows и Mac OS, так что самое время доставать те старые игры, в которые недоиграли в детстве и устраивать LAN-пати с не сильно сведующими в технологиях друзьями. Главный недостаток — нельзя забиндить IP адреса к конкретным машинам. И да, это проект из Китая, может кому-то не понравится по идеологическим причинам, но лично я надеюсь, что оно создано энтузиастами специально для пробития Большого Китайского Фаерволла. Пример конфигурации</summary> { networking.firewall = { allowedTCPPorts = [ 11010 11011 11012 ]; allowedUDPPorts = [ 11010 11011 11012 ]; }; environment.systemPackages = [ pkgs.easytier ]; systemd.services."easytier" = { enable = true; script = "easytier-core -d --network-name sumeragi --network-secret changeme -p tcp://public.easytier.cn:11010 --dev-name et0 --multi-thread"; serviceConfig = { Restart = "always"; RestartMaxDelaySec = "1m"; RestartSec = "100ms"; RestartSteps = 9; User = "root"; }; wantedBy = [ "multi-user.target" ]; after = [ "network.target" ]; path = with pkgs; [ easytier iproute2 bash ]; }; } </code></pre> </details> Nebula</h2> GitHub</a>, Official site</a> Это уже более пафосное коммерческое решение от создателей Slack. Имеет шифрование на эллиптических кривых, предлагает использовать свой PKI и выглядит в целом надёжненько. Хотя перспектива раскидывать сертификаты на машины ручками меня не радует. Для своей работы требует "маяки", которые будут соединять все остальные ноды. Внутри всё работает вроде как на Noise Protocol</a>. Наружу торчит только одним UDP портом. Из приятных фишек есть фаерволл и зонирование, чтобы строить чуть более сложные сети, чем "все со всеми". А ещё интерфейс у Nebula максимально всратый. Вместо нормального cli, нужно настроить внутренний sshd и по ssh, соответственно, подключаться на локалхост. Может и безопаснее, но вообще отвратительно. Пример конфигурации</summary> let isLighthouse = if (config.networking.hostName == "lighthouse") then true else false; in { services.nebula.networks.sumeragi = { enable = true; ca = "/etc/nebula/ca.crt"; cert = "/etc/nebula/node.crt"; key = "/etc/nebula/node.key"; isLighthouse = isLighthouse; lighthouses = if (isLighthouse) then [] else [ "10.1.0.1" ]; listen = { host = "0.0.0.0"; port = 4242; }; staticHostMap = { "10.1.0.1" = [ "266.266.266.266:4242" ]; }; settings = if (isLighthouse) then { sshd = { enabled = true; listen = "127.0.0.1:2222"; host_key = "/etc/nebula/id_ed25519"; authorized_users = [ { user = "nommy"; keys = [ "ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" ]; } ]; }; } else { }; firewall = { outbound = [ { port = "any"; proto = "any"; host = "any"; } ]; inbound = [ { port = "any"; proto = "any"; host = "any"; } ]; }; }; networking.firewall.allowedUDPPorts = [ 4242 ]; } </code></pre> </details> Tinc</h2> GitHub</a>, Official site</a> Когда я нашла это чудо, первой мыслью было "Что это за херня?" Проекту больше 10 лет и он до сих пор находится в нестабильном состоянии. Текущая версия 1.1pre18</code>, вышла аж в 2021-м году. Последний коммит в 1.1</code> ветку был больше года назад. В Nix запакована как чёрт пойми что. Это вот как оно вообще? Но на самом деле Tinc способен очень даже сильно удивить. Под капотом использует свой собственный протокол поверх UDP, эллиптические кривые и тонну чёрной магии (к слову, нормально задокументированной), на которой это всё работает. Разумеется, всё ещё требует внешнюю ноду, через которую будет инициализировать все соединения, но в остальном сеть полностью одноранговая. Имеет относительно нормальный cli, умеет показывать граф всей сети, есть прочие вкусные штуки, но вот очень не хватает какого-то tui, или хотя бы ASCII-арта для отрисовки этого самого графа. Пример упоротой конфигурации</summary> По очевидным причинам конфигурация собрана дендрофекальным способом, очень советую не копировать as is, а всё же переписать самостоятельно. Да, конфигурация интерфейса и роутов делается через tinc-up</code> и tinc-down</code> скрипты. Это intended way</a> let hostName = config.networking.hostName; in { networking.firewall.allowedTCPPorts = [ 655 ]; networking.firewall.allowedUDPPorts = [ 655 ]; services.tinc = { networks = { sumeragi = { name = hostName; ed25519PrivateKeyFile = "/etc/tinc/sumeragi/ed25519_key.priv"; interfaceType = "tun"; debugLevel = 3; hostSettings = { lighthouse = { settings.Ed25519PublicKey = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; subnets = [ { address = "10.2.0.1/32"; } ]; addresses = [ { address = "266.266.266.266"; port = 655; } ]; }; laptop = { settings.Ed25519PublicKey = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; subnets = [ { address = "10.2.0.2/32"; } ]; }; rpi = { settings.Ed25519PublicKey = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; subnets = [ { address = "10.2.0.3/32"; } ]; }; }; }; }; }; environment.etc = { "tinc/sumeragi/tinc-up".source = pkgs.writeScript "tinc-up-sumeragi" '' #!${pkgs.stdenv.shell} ${pkgs.nettools}/bin/ifconfig $INTERFACE ${(builtins.elemAt config.services.tinc.networks.sumeragi.hostSettings."${hostName}".subnets 0).address} netmask 255.255.255.0 /run/current-system/sw/bin/ip r add 10.2.0.0/24 dev tinc.sumeragi ''; "tinc/sumeragi/tinc-down".source = pkgs.writeScript "tinc-down-sumeragi" '' #!${pkgs.stdenv.shell} ${pkgs.nettools}/bin/ifconfig $INTERFACE down /run/current-system/sw/bin/ip r del 10.2.0.0/24 dev tinc.sumeragi ''; }; } </code></pre> </details> Методология измерения</h1> Это вообще очень большая тема и по ней можно целую книгу написать, но самое главное — IPerf врёт. Разные версии IPerf показывают разные цифры, используют разные методики измерения по-умолчанию, имеют много вариантов тюнинга, которые влияют на результаты и порой их показания сильно отличаются от реальности. Так что вместе с двумя версиями iperf стоит добавить немного реальных кейсов использования сети. Скорость интернетов в обе стороны у всех нод примерно одинаковая, поэтому я буду брать цифры с первого попавшегося направления, ибо разница будет в пределах погрешности. Инфраструктура</h2> Для реалистичных измерений я буду использовать три машины: Домашний ноутбук (Laptop) в Испании</li> Промежуточный сервер с публичным IP (Lighthouse) в Финляндии</li> Raspberry Pi (RPi) за российским фаерволлом</li> </ul> При этом на Lighthouse размещены координаторы mesh-сетей, а скорость измеряется между Laptop и RPi. Ping</h2> ping -c 300 10.1.0.3</code> Отправляем ICMP пакетики, ждём пока прилетит ответ, меряем время за которое ответ был получен. Тут можно проверить latency, jittering и количество потерянных пакетов. Latency — это среднее время ответа на пинг. Jittering — это насколько сильно время ответа "гуляет" относительно среднего. Измеряется в ms. С количеством потерянных пакетов и так всё понятно. Для плюс-минус стабильных результатов 300 пакетов должно хватить. /dev/zero through SSH</h2> ssh 10.1.0.3 'dd if=/dev/zero bs=128M count=3 2>/dev/null' | dd of=/dev/null status=progress</code> Читаем три раза по 128 Mb нулей через SSH, потом смотрим на скорость чтения. В целом не самый плохой способ определить скорость передачи данных внутри SSH туннеля. Главная причина использования этого теста — через некоторые решения SSH работает настолько адски медленно, что между нажатием клавиши и появлением символа на экране может пройти больше секунды, а это никуда не годится. А иногда так вообще не работает. Wget</h2> wget 10.1.0.3:5201/testfile</code> В качестве тестового файла — всё те же 384 Mb нулей из /dev/null. В качестве сервера использую simple-http-server</a>, выставив количество потоков равное количеству ядер CPU (8). Разумеется, с выключенным сжатием, иначе мегабайты нулей рискуют превратиться в килобайт хедеров. iperf2 и iperf3</h1> Да, они показывают цены на апельсины в Африке. Чёрт его знает, как это тюнить. Поэтому просто запускаем с стандартной конфигурацией и потом нормализуем результаты из мегабитов в мегабайты. Референсные значения</h2> Измерить точные значения скорости, пинга и вот этого вот всего, от чего можно было бы отталкиваться немножечко невозможно, ибо обе машины находятся за NAT. Но так как в инфраструктуре имеется Lighthouse с публичным IP, можно сделать несколько тестов и нафантазировать какие-то результаты. </th> ICMP packet loss</th> ICMP Latency</th> ICMP Jittering</th> /dev/zero through SSH</th> Wget</th> iperf2</th> iperf3</th></tr></thead> Laptop -> Lighthouse</td> 0%</td> 71.879 ms</td> 1.422 ms</td> 25.5 MB/s</td> 23.3MB/s</td> 18 MB/s</td> 24.375 MB/s</td></tr> RPi -> Lighthouse</td> 0%</td> 51.872 ms</td> 1.011 ms</td> 9.0 MB/s</td> Timeout</td> 9.963 MB/s</td> 11.112 MB/s</td></tr> </tbody></table> А теперь можно начать фантазировать. Скорость между нодами не может быть больше минимального участка, поэтому в референсные значения тоже берём минимальную. Latency можно просто сложить. А вот что делать с jittering'ом — не до конца понятно. Вроде бы складывать такие значения нельзя, с нуля пересчитывать каждый пакет я не хочу, поэтому просто возьму максимальное значение. И настало время итоговых результатов Результаты</h1> Вся скорость нормализована в байтах. Для перевода в биты нужно умножить на 8. </th> ICMP packet loss</th> ICMP Latency</th> ICMP Jittering</th> /dev/zero through SSH</th> Wget</th> iperf2</th> iperf3</th></tr></thead> Reference</td> 0%</td> 123.751 ms</td> 1.422 ms</td> 9.0 MB/s</td> Timeout</td> 9.963 MB/s</td> 11.112 MB/s</td></tr> Wireguard + udp2raw</td> 49.6%</td> 108.806 ms</td> 3.724 ms</td> Timeout</td> Timeout</td> 3.175 KB/s</td> 0.00 B/s</td></tr> EasyTier</td> 0%</td> 153.163 ms</td> 36.290 ms</td> 2.7 MB/s</td> 8.09 MB/s</td> 6.15 KB/s</td> 0.00 B/s</td></tr> Nebula</td> 0%</td> 122.173 ms</td> 15.054 ms</td> 2.7 MB/s</td> 3.40 MB/s</td> 5.975 KB/s</td> 0.00 B/s</td></tr> Tinc</td> 2.3%</td> 115.065 ms</td> 3.393 ms</td> 14.7 MB/s</td> 5.16 MB/s</td> 6.488 MB/s</td> 4.175 MB/s</td></tr> </tbody></table> Египетская сила тех iperf'ов... Tinc, как уже говорила, очень способен удивить. EasyTier простительны такие оверхеды, он всё таки Ad-hoc и вообще "скажи спасибо, что связь в принципе есть". А вот Nebula меня откровенно разочаровала. Тут так и хочется ввернуть шуточку про клиент Слака на Электроне, но... Я ожидала лучшего, серьёзно. Так что если хочется заиметь что-то такое — Tinc лучший выбор в плане производительности. Я же себе оставлю все и сразу. Не люблю марсоход запускать без надобности. На этом у меня всё. А началось-то всё с того, что мама попросила починить робот-пылесос... Подключаем к Home Assistant Tasmota и странные нонейм девайсы 2025-03-12T00:00:00+00:00 Проблематика</h1> Однажды, один очень нехороший человек решил, что подключить весь дом (включая электроплиту) на один 2.5mm² кабель — это очень хорошая идея. Правила пожарной безопасности и автоматические предохранители же так не считали. Поэтому одновременное включение бойлера и духовки вызывает полный power outage в отдельно взятой квартире, что меня неистово фрустрирует, а каждый раз бегать включать-выключать бойлер из розетки — определённо не то, чем я хотела бы заниматься. Так что будем делать умный дом, чтобы рулить этим делом хотя бы со смартфона. Железяки</h1> Быстрый поиск по Амазону выдал мне SONOFF Zigbee Bridge 3.0 Gateway Hub, ,Soporte de Protocolo Dual,WiFi, Compatible con Dispositivos Zigbee Pro, Alexa & Google</code>, он же SONOFF ZBBridge-P</code> всего за 35€. Быстрогуглинг показал, что на неё есть какая-то опенсорсная прошивка. "Надо брать", — подумала я. Попутно в корзину отправились ZigBee Enchufe Inteligente Alexa 16A, 3680W Smart Plug con Monitor de Energía, Enchufe Temporizador con Control Remoto, Control por Voz y Funciones de Temporización, apoyo Alexa & Google Home</code> (4 штуки за 45€), позже оказавшиеся Tuya TS011F</code>. И ещё на сдачу была докинута Garza Smart - Bombilla LED Zigbee Estándar A60, 11W (equivale a 75W de incandescencia), E27, Requiere Puente/Bridge, RGB + CCT, Intensidad regulable, Programable, Control por voz y app, Alexa/Google</code>, которая зачем-то прикидывалась Tuya TZ3210</code>. Чем именно является эта TZ3210</code> установить так и не удалось, потому что в разных источниках пишут, что это либо выключатель, либо датчик влажности и температуры, либо всё таки RGB лампочка. Лечим бридж от облака</h1> Так как сливать данные умного дома на какое-то непонятное облако — это моветон, первым делом нужно прошить бридж. Я руководствовалась вот этой весьма подробной инструкцией How to flash Tasmota on Sonoff ZB Bridge Pro</a>. Единственное, что нормально не проговаривается — это пин GPIO00</code>. Он должен быть подтянут к GND</code> во время запуска железки, чтобы загнать её в режим прошивки через UART. У меня были трудности с этим, так что успешность операции можно отследить элегантным screen /dev/ttyACM0 115200</code> и посмотрев на логи запуска. Я не буду описывать полный процесс прошивки, ибо он отлично описан по ссылке выше, но... Рис 1. Как схватить инфаркт на ровном месте </figcaption> </figure> К счастью, этот баг уже давным-давно пофиксили в новой версии и кто-то просто долго не обновляла прошивку. Настраиваем секурный MQTT</h1> Несмотря на то, что ESP32 уже имеет реализацию Wireguard'а, Tasmota его всё ещё не поддерживает, так что придётся выставить MQTT наружу и настроить на нём SSL, чтобы рандомные вандереры не развлекались с моими розетками. Поэтому лёгким движением nixos-rebuild switch ...</code> поднимаем на внешнем сервере с статическим IP Mosquitto users.users.mosquitto.extraGroups = [ "nginx" ]; services.mosquitto = { enable = true; listeners = [ { address = "123.456.789.123"; port = 1883; users = { tasmota = { acl = [ "readwrite tasmota/#" ]; password = "changeme"; }; }; settings = { "allow_anonymous" = false; "require_certificate" = false; "cafile" = "/var/lib/acme/mqtt.example.com/fullchain.pem"; "certfile" = "/var/lib/acme/mqtt.example.com/cert.pem"; "keyfile" = "/var/lib/acme/mqtt.example.com/key.pem"; "tls_version" = "tlsv1.2"; }; } { address = "10.20.0.1"; port = 1883; users = { hass = { acl = [ "readwrite #" ]; password = "changeme"; }; }; } ]; }; </code></pre> Юзер mosquitto</code> отправляется в группу nginx</code> просто чтобы иметь возможность подтягивать Let's Encrypt сертификаты. Также я использую систему из двух листенеров. Один защищён SSL, ограничен по самые помидоры и смотрит наружу, а второй во внутренней VPN сети спокойно даёт подсосаться к нему при помощи бриджей, но об этом чуть позже Ещё стоит отметить строки "require_certificate" = false;</code> и "tls_version" = "tlsv1.2</code>. Первая отключает авторизацию через TLS, оставляя стандартный пароль, а вторая включает шифрование трафика. Без первой Tasmota не может подключться к MQTT, а без второй Mosquitto будет игнорировать все прописанные сертификаты и работать в незащищённом режиме. На стороне Home Assistant'а же я настроила бридж, который будет всасывать сообщения из промежуточного MQTT и засасывать в основной. Просто потому что у меня уже был настроен MQTT для локальных штук и я не хотела его трогать. services.mosquitto = { enable = true; listeners = [ ... ]; bridges = { "external2internal" = { addresses = [ { address = "10.20.0.1"; port = 1883; } ]; topics = [ "tasmota/# in" "tasmota/cmnd/# out" ]; settings = { remote_username = "hass"; remote_password = "changeme"; }; }; }; }; </code></pre> С такой настройкой топиков я не затягиваю внутрь ничего лишнего, а наружу могут попадать только непосредственные команды для Tasmota. Но это, разумеется, можно пропустить, если MQTT всего один. И НЕ ЗАБУДЬ ОТКРЫТЬ ПОРТ НА ФАЕРВОЛЛЕ! Подключаем бридж к секурному MQTT</h1> Тут и так всё очевидно и понятно, кроме пары моментов. Обязательно прожимаем чекбокс MQTT TLS</code>, чтобы оно вообще подключилось к нашему секурному Mosquitto. И в поле Full Topic</code> следует в начало дописать tasmota/</code>, чтобы все сообщения аккуратно сваливать в одну группу и не прописывать в ACL каждый бридж. После сопряжения устройств с бриджом (Просто нажми кнопку Zigbee Permit Join</code> и включай железяку) не лишним будет проверить, действительно ли всё работает как положено и сообщения от устройств попадают в MQTT. Подписываемся на tasmota/#</code> и ждём, пока туда что-нибудь не посыпется. Если не посыпалось, возвращаемся к началу и долго думаем, что же пошло не так. Повторять до полного удовлетворения. Изучаем устройства</h1> Рис. 2. SONOFF ZB Bridge-P </figcaption> </figure> Вот на этом этапе и начинается Адъ и Израиль. Дело в том, что Tasmota не умеет в auto discovery. Точнее умеет, но только для конечных устройств и через свой собственный плагин. А так как у нас бридж, то из этого следует два факта: Плагин нам не нужен, сырого MQTT более чем достаточно</li> Нам никто не поможет</li> </ol> Но для начала следует вооружиться консолью на самом бридже и посмотреть, что же там у нас имеется. Рис. 3. Зелёный и страшный </figcaption> </figure> Идём в Tools > Console</code> в веб интерфейсе бриджа и начинаем тыкать всё вокруг палочкой. Полный список команд лежит вот тут: Tasmota Commands</a>, но нам сейчас интересна исключительно часть про Zigbee</a>. А если быть точнее, то команды ZbInfo</code>, ZbName</code> и ZbSend</code>. ZbInfo</h3> Вбив в терминал ZbInfo</code> можно получить всю информацию о подключенных устройствах. Результатом обычно получается вот такая портянка 20:03:18.524 MQT: tasmota/tele/tasmota_6A65EC/7E20/SENSOR = {"ZbInfo":{"0x7E20":{"Device":"0x7E20","Name":"main_light_0","IEEEAddr":"0xA4C138E23EE90340","ModelId":"TS0505B","Manufacturer":"_TZ3210_4sku4dkz","Endpoints":[1,242],"Config":["O01","~01.1","L01"],"Power":1,"Dimmer":254,"Hue":0,"Sat":0,"X":24218,"Y":15601,"CT":499,"ColorMode":1,"RGB":"FFFFFF","RGBb":"FFFFFF","Reachable":true,"LastSeen":4,"LastSeenEpoch":1741806194,"LinkQuality":91}}} 20:03:18.536 MQT: tasmota/tele/tasmota_6A65EC/CD47/SENSOR = {"ZbInfo":{"0xCD47":{"Device":"0xCD47","Name":"aquarium_light","IEEEAddr":"0xA4C1382214F48A12","Endpoints":[1],"Config":["P01","O01"],"RMSVoltage":226,"ActivePower":10,"Power":1,"Reachable":true,"LastSeen":6,"LastSeenEpoch":1741806192,"LinkQuality":185}}} 20:03:18.548 MQT: tasmota/tele/tasmota_6A65EC/9AD4/SENSOR = {"ZbInfo":{"0x9AD4":{"Device":"0x9AD4","Name":"boiler_switch","IEEEAddr":"0xA4C13877C8106300","ModelId":"TS011F","Manufacturer":"_TZ3000_cehuw1lw","Endpoints":[1],"Config":["P01","O01"],"RMSVoltage":226,"ActivePower":0,"Power":0,"Reachable":true,"LastSeen":73,"LastSeenEpoch":1741806125,"LinkQuality":98}}} 20:03:18.563 MQT: tasmota/tele/tasmota_6A65EC/3B30/SENSOR = {"ZbInfo":{"0x3B30":{"Device":"0x3B30","Name":"main_light_1","IEEEAddr":"0xA4C1381A825F2ADE","ModelId":"TS0505B","Manufacturer":"_TZ3210_4sku4dkz","Endpoints":[1,242],"Config":["~01.1","O01","L01"],"Power":0,"Dimmer":254,"Hue":0,"Sat":254,"X":38449,"Y":21476,"CT":283,"ColorMode":2,"RGB":"FF0000","RGBb":"FF0000","Reachable":true,"LastSeen":136,"LastSeenEpoch":1741806062,"LinkQuality":163}}} 20:03:18.578 MQT: tasmota/tele/tasmota_6A65EC/898A/SENSOR = {"ZbInfo":{"0x898A":{"Device":"0x898A","Name":"studio_light","IEEEAddr":"0xA4C1389F99E433CE","ModelId":"TS0505B","Manufacturer":"_TZ3210_4sku4dkz","Endpoints":[1,242],"Config":["O01","~01.1","L01"],"Power":0,"Dimmer":42,"Hue":0,"Sat":254,"X":13578,"Y":14165,"CT":283,"ColorMode":2,"RGB":"FF0000","RGBb":"2A0000","Reachable":true,"LastSeen":150,"LastSeenEpoch":1741806048,"LinkQuality":65}}} </code></pre> Если посидеть, повтыкать внимательно, то можно обнаружить: Device</code> — Короткий адрес устройства (0xAAAA). Обычно используем его, чтобы обратиться к девайсу.</li> ModelId</code> и Manufacturer</code> — собственно, описание модели. Если посмотреть в начало статьи, то можно увидеть, что дешёвую китайскую Tuya можно встретить под разными пафосными брендами, но тут железяки палятся мгновенно.</li> Dimmer</code>, Hue</code>, Sat</code>, X</code>, Y</code> и все остальные железяко-специфичные параметры, которые эта самая железяка будет слать нам в MQTT.</li> </ul> Последнее нам особенно пригодится, но об этом чуть позже. ZbName</h3> Сейчас самое время дать всем устройствам читаемые имена, чтобы потом не запутаться что есть что. ZbName short_address,name</code> нам в этом поможет. Потом этот name будет ещё всплывать в каждом ивенте и можно будет с этим что-то делать, но главная цель — не запутаться. ZbSend</h3> А теперь мы можем потыкать палочкой в девайс уже активно, ибо ZbSend</code> позволяет отправить какое-нибудь сообщения и посмотреть на реакцию железки. Можно, например, потыкать палочкой в умную розетку. ZbSend {"device": "0x9AD4", "send": { "Power": "ON" }}</code> будет оную розетку включать, а ZbSend {"device": "0x9AD4", "send": { "Power": "OFF" }}</code>, соответственно, выключать. Как мы узнали, что нужно отправить именно { "Power": "ON" }</code> — это самый интересный вопрос. И ответом на него будет "Угадали", но это немного не так. Давайте посмотрим на JSON из вывода команды ZbInfo 0x9AD4</code> более пристально { "ZbInfo": { "0x9AD4": { "Device": "0x9AD4", "Name": "boiler_switch", "IEEEAddr": "0xA4C13877C8106300", "ModelId": "TS011F", "Manufacturer": "_TZ3000_cehuw1lw", "Endpoints": [ 1 ], "Config": [ "P01", "O01" ], "RMSVoltage": 226, "ActivePower": 0, "Power": 0, "Reachable": true, "LastSeen": 73, "LastSeenEpoch": 1741806125, "LinkQuality": 98 } } } </code></pre> Среди всего прочего тут можно увидеть поле Power</code> со значением 0</code>, тобишь "Выключено". А штуку с более читаемыми ON</code> и OFF</code> я просто в интернетах подсмотрела. Если смотреть на JSON от лампочки, там больше интересного { "ZbInfo": { "0x7E20": { "Device": "0x7E20", "Name": "main_light_0", "IEEEAddr": "0xA4C138E23EE90340", "ModelId": "TS0505B", "Manufacturer": "_TZ3210_4sku4dkz", "Endpoints": [ 1, 242 ], "Config": [ "O01", "~01.1", "L01" ], "Power": 1, "Dimmer": 254, "Hue": 0, "Sat": 0, "X": 24218, "Y": 15601, "CT": 499, "ColorMode": 1, "RGB": "FFFFFF", "RGBb": "FFFFFF", "Reachable": true, "LastSeen": 4, "LastSeenEpoch": 1741806194, "LinkQuality": 91 } } } </code></pre> Помимо Power</code> мы также имеем Dimmer</code>, Hue</code>, Sat</code>, X</code>, Y</code>, CT</code>, ColorMode</code>, RGB</code> и RGBb</code>. Спойлер: не всё из этого можно точно так же поменять, но общее направление для копания под девайс у нас имеется. Ещё один момент (Backlog)</h3> Ах, да. Тут стоить упомянуть ещё один момент. Несмотря на то, что мы можем сделать ZbSend {"device": "0x7E20", "send": { "Hue": "128" }}</code>, сделать ZbSend {"device": "0x7E20", "send": { "Hue": "128", "Sat": "254" }}</code> мы уже не сможем, так как за один запрос можно поменять только один параметр. Как быстрый воркараунд вокруг проблемы, можно использовать Backlog</a>, встроенный язык... Короче, в эту штуку можно просто несколько команд подряд передать, а потом они последовательно выполнятся. И в результате наша команда будет выглядеть примерно так: Backlog ZbSend {"device": "0x7E20", "send": { "Hue": "128" }}; ZbSend {"device": "0x7E20", "send": { "Sat": "254" }} </code></pre> Хорошо для быстрых хаков, но на практике получается так, что отправка двух команд — это не самый быстрый процесс и вместо этого иногда можно обнаружить "недокументированные" команды. В случае той же лампочки существует команда Color</code> которая позволяет одновременно установить значения X</code> и Y</code>, но об этом опять чуть позже. Home Assistant</h1> Рис. 4. Home Assistant </figcaption> </figure> Помните, я говорила, что Tasmota не умеет в автодискавери? Так вот. Сейчас будем писать коньфиги. Вручную. И да поможет нам Nix, и его возможность писать человеческие функции для автогенерации YAML'а. MQTT топики</h2> По-сути нам нужны только два топика: tasmota/tele/tasmota_${gw_addr}/SENSOR</code> для чтения и tasmota/cmnd/tasmota_${gw_addr}/ZbSend</code> для отправки команд. Возможно ещё третий tasmota/cmnd/tasmota_${gw_addr}/Backlog</code> для, собственно, Backlog команд. Да, любую из списка команд можно вызвать через MQTT, отправив в соответствующий топик, где последняя часть и является названием команды. Слать будем JSON'ы, парсить их тоже. Давайте к практике. Выключатели и сенсоры</h3> Рис 5. Выключатели с сенсорами </figcaption> </figure> Давайте вспомним наш JSON из розетки { "ZbInfo": { "0x9AD4": { "Device": "0x9AD4", "Name": "boiler_switch", "IEEEAddr": "0xA4C13877C8106300", "ModelId": "TS011F", "Manufacturer": "_TZ3000_cehuw1lw", "Endpoints": [ 1 ], "Config": [ "P01", "O01" ], "RMSVoltage": 226, "ActivePower": 0, "Power": 0, "Reachable": true, "LastSeen": 73, "LastSeenEpoch": 1741806125, "LinkQuality": 98 } } } </code></pre> Помимо Power</code>, который управляет включением\выключением розетки, у нас есть ещё: RMSVoltage</code> (меряет количество вольтов) и ActivePower</code> (меряет количество амперов). Поэтому начинаем писать конфиг: mqtt = { switch = [ { unique_id = "boiler_outlet_switch"; name = "Boiler Outlet Switch"; state_topic = "tasmota/tele/tasmota_6A65EC/SENSOR"; value_template = "{{ value_json.ZbReceived['0x9AD4'].Power }}"; command_topic = "tasmota/cmnd/tasmota_6A65EC/ZbSend"; payload_on = ''{"device":"0x9AD4","send":{"Power": "ON"}}''; payload_off = ''{"device":"0x9AD4","send":{"Power": "OFF"}}''; retain = true; device_class = "outlet"; device = { name = "Boiler Outlet"; model = "TS011F"; manufacturer = "Tuya"; identifiers = [ "0x9AD4" ]; }; } ]; }; </code></pre> Полное объяснение каждого параметра можно найти в соответствующей документации</a>, так что пробегусь по важному: state_topic</code> и command_topic</code> — те самые топики для чтения состояния и отправки команд. Обычно сразу после получения команды девайс кинет сообщение с изменённым состоянием, что позволяет не надеяться на "оптимистичную" стратегию Home Assistant и, пускай и с небольшой задержкой, но знать актуальное состояние железяки. value_template</code> — шаблон для вытаскивания значения параметра из JSON'а. Так как JSON'ы генерирует сам гетвей, можно смело копипастить шаблон из примера и только менять последнюю часть. Да, я тоже у кого-то это скопипастила. payload_on</code> и payload_off</code> — тут тоже всё понятно, однако чуть позже научимся их тоже шаблонизировать. Разумеется, для каждой розетки писать такую портянку будет неприятно, поэтому оборачиваем всё в функцию: ts011f_switch = id: name: short_addr: gw_addr: { unique_id = id; name = "${name} Switch"; state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; value_template = "{{ value_json.ZbReceived['${short_addr'].Power }}"; command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; payload_on = ''{"device":"${short_addr}","send":{"Power": "ON"}}''; payload_off = ''{"device":"${short_addr}","send":{"Power": "OFF"}}''; retain = true; device_class = "outlet"; device = { name = name; model = "TS011F"; manufacturer = "Tuya"; identifiers = [ short_addr ]; }; }; </code></pre> Но у нас же ещё сенсоры остались. Так что пишем ещё функцю для них: ts011f_sensors = id: name: short_addr: gw_addr: [ { unique_id = "${id}_power"; name = "${name} Power"; state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; value_template = "{{ value_json.ZbReceived['${short_addr}'].ActivePower }}"; unit_of_measurement = "W"; device = { identifiers = [ "${short_addr}" ]; }; } { unique_id = "${id}_voltage"; name = "${name} Voltage"; state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; value_template = "{{ value_json.ZbReceived['${short_addr}'].RMSVoltage }}"; unit_of_measurement = "V"; device = { identifiers = [ "${short_addr}" ]; }; } ]; </code></pre> В итоге наш непосредственный конфиг выглядит красивенько и можем добавлять столько розеток, сколько у нас имеется (а у меня их как раз четыре штуки): mqtt = { switch = [ (ts011f_switch "boiler_switch" "Boiler" "0x9AD4" "6A65EC") ]; sensor = (ts011f_sensors "boiler" "Boiler" "0x9AD4" "6A65EC") }; </code></pre> Лампочки</h2> Рис 6. Лампочка </figcaption> </figure> А теперь к самому сложному. Лампочки. Лампочки — это совершенно проклятые устройства. Они выглядят достаточно просто, но эта простота обманчива и заманивает несчастных на скалы безумия. Скалы безумия</h3> Давайте ещё раз на JSON посмотрим { "ZbInfo": { "0x7E20": { "Device": "0x7E20", "Name": "main_light_0", "IEEEAddr": "0xA4C138E23EE90340", "ModelId": "TS0505B", "Manufacturer": "_TZ3210_4sku4dkz", "Endpoints": [ 1, 242 ], "Config": [ "O01", "~01.1", "L01" ], "Power": 1, "Dimmer": 254, "Hue": 0, "Sat": 0, "X": 24218, "Y": 15601, "CT": 499, "ColorMode": 1, "RGB": "FFFFFF", "RGBb": "FFFFFF", "Reachable": true, "LastSeen": 4, "LastSeenEpoch": 1741806194, "LinkQuality": 91 } } } </code></pre> Конкретно эта лампочка умеет менять мощность, температуру свечения и свой цвет. На самом деле делает она это не одновременно, а переключаясь между режимами, которые можно достать из ColorMode</code>. Впрочем, эта информация нам нужна только для исследования и отладки. Первый режим — это яркое свечение во всю мощщу с переменной температурой. За это отвечают параметры Dimmer</code> и CT</code> (Color Temperature) соответственно. Второй и третий — это цветные. Отличаются они только способом выбора цвета: Hue\Sat или X\Y. Логично предположить, что мы хотим менять параметры Hue</code> и Sat</code> или X</code> и Y</code>, но тут всплывает не самый очевидный с первого раза вопрос. А какие именно значения может принимать этот параметр? С одной стороны, тут можно положиться на здравый смысл. Hue — это круг, значит диапазон значений должен быть 0..360. А координатная система XY использует значения 0.0..1.0. Но жизнь как всегда оказывается гораздо непредсказуемее, чем теория. И мы таки имеем дело с лампочкой, которая одновременно выключатель и датчик влажности. Так что единственный адекватный способ узнать настоящий диапазон значений — это тыкать палочкой и смотреть что получится. К примеру, Dimmer</code> имеет диапазон значений 0..254. Но при попытке выставить его в 255 лампочка начинает возвращать null, что весьма странно, ибо это ведь явно 8-битная переменная... Мои попытки подобрать значения Hue</code> и Sat</code> ни к чему конструктивному не привели, а вот X</code> и Y</code> при попытке запихнуть в них значение не в диапазоне 0..65279, просто отказываются воспринимать команду. Почему не 0..65535, как кто-то предложил в интернете, думая что это 16-битная переменная? Ну вот потому что! Собираем всё в Home Assistant</h3> В результате, собрав все полученные в процессе тыкания палочкой знания, мы готовы написать функцию tz3210_lamp = id: name: short_addr: gw_addr: { unique_id = id; name = name; command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; payload_on = ''{"device": "${short_addr}", "send": {"Power": "ON"}}''; payload_off = ''{"device": "${short_addr}", "send": {"Power": "OFF"}}''; brightness_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; brightness_command_template = ''{"device": "${short_addr}", "send": { "Dimmer": "{{ value - 1 }}" }}''; brightness_state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; brightness_value_template = "{{ value_json.ZbReceived['${short_addr}'].Dimmer }}"; xy_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; xy_command_template = ''{"Device": "${short_addr}", "send":{ "Color": "{{ x * 65279 }},{{ y * 65279 }}"}}''; xy_state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; xy_value_template = "{{ value_json.ZbReceived['${short_addr}'].X / 65279 }},{{ value_json.ZbReceived['${short_addr}'].Y / 65279 }}"; color_temp_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/ZbSend"; color_temp_command_template = ''{"device": "${short_addr}", "send": { "CT": "{{ value - 1 }}" }}''; color_temp_state_topic = "tasmota/tele/tasmota_${gw_addr}/SENSOR"; color_temp_value_template = "{{ value_json.ZbReceived['${short_addr}'].CT }}"; device = { name = "RGB Lamp"; model = "TZ3210"; manufacturer = "Tuya"; identifiers = [ short_addr ]; }; } </code></pre> Эта функция — просто сборник хаков, для того чтобы железка хоть как-то заработала. Давайте пойдём по-порядку Dimmer</code>, по мнению Home Assistant, должен принимать значения 0..255, но как мы уже знаем, максимальная циферка там 254, так что просто вычитаем единичку, всё равно оно в интерфейсе меньше чем в 3% не выставляется. То же самое для CT</code>. X</code> и Y</code>, по мнению того же Home Assistant, принимают значения от 0 до 1.0, поэтому преобразование туда\обратно делается элементарным умножением на максимально возможное значение Кроме того, в xy_command_template</code> тут используется функция Color</code>, которая позволяет передать значения X</code> и Y</code> за одну команду, случайно найденная уже не помню где в обсуждении уже не помню какого устройства. Если бы её не было, конфиг бы выглядел как-то так: xy_command_topic = "tasmota/cmnd/tasmota_${gw_addr}/Backlog"; xy_command_template = ''ZbSend {"Device": "${short_addr}", "send":{ "X": "{{ x * 65279 }}"}}; ZbSend {"Device": "${short_addr}", "send":{ "Y": "{{ y * 65279 }}"}}''; </code></pre> Это конец</h1> И на этой ноте мои приключения наконец-то закончились. Лампочки моргают, бойлер выключается и даже аквариум обзавёлся своим удалённым управлением. Мне категорически не понравилось умный дом делать, он какой-то слишком тупой оказался. А наебалово с ценами огорчило меня ещё больше. Пойду лучше на AliExpress железок докупать, там хотя бы модель явно пишут. Рис. 7. Бисексуальное освещение </figcaption> </figure>