Пару лет как использую такие реле. Брал их часто по ~100 на али, в рубрике купи 3 вещи по 100р. У меня накопилось несколько вариантов плат и распиновок к ним. Надо было раньше вас статью писать) Так вот раньше я просто менял стоковые модули на esp. Потом в esphome завезли cb2s и прочие bk (а я использую esphome), стал писать напрямую их. А потом все чаще и чаще стали попадаться реле с распаянными прямо на основную плату мк. И по началу это решалось прошивкой (uart там тоже конечно же есть) и чуть более сложным вычислением распиновки, но потом там все чаще и чаще стали попадаться совсем неподдерживаемые esphome мк. Эти "непрошиваемые" реле у меня остались, но сейчас нет возможности посмотреть что там за мк. Короче, хотел сказать что будьте осторожны, могут попасться такие реле, а отличить их почти невозможно (ну наверное как то можно) без вскрытия.
Это не наш метод - проверим в бою. Вроде поднялось, в конверторе тоже поменял на свой TZ3000bzt33cyu. Не понял насчет второй прошивки. Надо делать? И если делать, то как? Править local_ota_index.json под новый идентификатор?
Прошивка не хотела обновляться, пока в local_ota_index.json не поменял на свой TZ3000bzt33cyu Пока шьется, посмотрим что будет. В принципе если окажется что "не та ревизия" и датчик окирпичится, не расстроюсь. Пол года работал нормально, еще пол года - постоянные отвалы и батарейка то 0, то 100.
Для ipv6 дополню. Допустим у нас ipv6 и его тоже надо обходить (единственное что, у меня для обхода ipv6 отдельный интерфейс, но я думаю направления хватит):
Создаем лист для ipv6 адресов (firewall)
config ipset
option name 'proxy_list'
option match 'dst_net'
option family 'ipv6'
Маркируем пакеты (firewall)
config rule
option name 'Mark-Proxy-for-LAN'
option src 'lan'
option dest '*'
option proto 'all'
option ipset 'proxy_list'
option set_mark '0x2'
option target 'MARK'
option family 'ipv6'
Добавляем маршрут для трафика 0x2 (network)
config rule6
option priority '100'
option lookup 'proxy'
option mark '0x2'
Добавляем маршрут для таблицы (network)
config route6
option interface 'proxy'
option target '::/0'
option table 'proxy'
Добавляем правила для доменов (dnsmasq) nftset=/chatgpt.com/6#inet#fw4#proxy_list
Хоть и решение завернуть wg в vless может показаться странным на первый взгляд, на это есть свои причины... По итогу удалось сделать следующим образом: Взял проект https://github.com/rfc1036/udptunnel. Скопмилировал бинарники для сервера и роутера. Может показаться что, зачем? Есть ведь есть socat (очень сильно режется скорость, буквально до кбит), есть udptunnel в официальных репозиториях openwrt (это не то, хоть и имеет такое же название. Более того, udptunnel из репозиториев openwrt у меня не заработал и судя по форуму openwrt, не только у меня).
На сервере: [tcp который будем слушать] [ip и udp куда нам надо переадресовать] udptunnel -S --server -v 0.0.0.0:12345 127.0.0.1:51820
На клиенте: [udp в который будем ломиться] [адрес сервера с tcp портом] udptunnel -S -v 0.0.0.0:12345 example.com:12345
По итогу такая связка заработала. Wireguard кстати на openwrt капризный, если указывать в endpoint - localhost, wg отказывается у меня запускаться. 127.0.0.1 работает. Скорость получилась 50/20 мбит против эталонных - 110/200, что мало конечно, но лично меня устраивает.
Столкнулся с проблемой. Предыстория - дачный роутер перестал подключаться по Wireguard к городу. Решил завернуть трафик WG в VLESS. Поставил sing-box на роутер, поднял VLESS - тут ок, никаких проблем. Пытаюсь поднять WG через tun от sing-box, все по мануалам выше. Коннекта нет. Почему то tun ни в какую не пропускает udp. Решения не нашел.
Я тоже заметил что некоторые устройства, например друзей приходящих в гости, отображают хоть и подменный, но постоянный мак адрес. Хотя глубоко в вопросе не разбирался. Спасибо что поделились наблюдениями)
Так можно сделать, но проблема в том что невозможно именно сделать template device_tracker, просто в HomeAssistant нет такого типа template. А именно device_tracker нужен был мне для красивого отображения в интерфейсе, и привязки к аккаунта пользователя, к которому тоже невозможно привязать что либо кроме device_tracker.
Zigbee у меня только дома и на даче. На даче через Zigstar LAN. При этом это только потолочный свет. Что касается отопления - дом в целом теплый, есть печка, зимой почти никогда не ездим. На весну/осень установлены электрические конвекторы в каждой комнате. В конвекторы встроены (своими руками) esp8266+релюшки на 16А. Данные температуры берутся с перешитых bluetooth датчиков - LYWSD03MMC. Собирает это все дело с них, esp32 с esphome (настроенно как platform: atc_mithermometer). На случай отвала интернета на роутере поднят mqtt сервер, куда esp32 дублирует показания с датчиков. От туда же esp8266 конвектора читает температуру в своей комнате и воображает себя термостатом. Получается в случае отвала интернета пропадает только контроль потолочного света, но в ручную то все работает и zigbee сеть не разваливается. Ну а конвекторы вообще получается никак от интернета не зависят, ну только задать температуру... Но для этого у меня предусмотрена физическая кнопка на конвекторе позволяющая тупо включать реле.
Ну это только пример. Если ничего в доме нет, то и ping как бинарный сенсор сойдет на посмотреть. Телевизором будет управлять на сколько позволит ваш телевизор. В дефолте обычно вкл/выкл, громкость, пауза стоп. Можно сделать простейшую автоматизацию - если ваш смартфон пингуется - включить телевизор. Конечно, это не имеет никакой полезной нагрузки, но повторюсь - на посмотреть сойдет.
Создать виртуальное устройство. Например бинарный сенсор ping. До роутера. Будет показывать пингуется или нет. Можно подключить погоду, например с яндекса, тоже сенсоры появятся. А можно хорошенько осмотреть дом на предмет чего-то отдаленно умного, например многие телеки сразу автоматом прокидываются.
Пару лет как использую такие реле. Брал их часто по ~100 на али, в рубрике купи 3 вещи по 100р. У меня накопилось несколько вариантов плат и распиновок к ним. Надо было раньше вас статью писать) Так вот раньше я просто менял стоковые модули на esp. Потом в esphome завезли cb2s и прочие bk (а я использую esphome), стал писать напрямую их. А потом все чаще и чаще стали попадаться реле с распаянными прямо на основную плату мк. И по началу это решалось прошивкой (uart там тоже конечно же есть) и чуть более сложным вычислением распиновки, но потом там все чаще и чаще стали попадаться совсем неподдерживаемые esphome мк. Эти "непрошиваемые" реле у меня остались, но сейчас нет возможности посмотреть что там за мк. Короче, хотел сказать что будьте осторожны, могут попасться такие реле, а отличить их почти невозможно (ну наверное как то можно) без вскрытия.
Эх, сейчас бы снова XIP пересобирать.
Просто совет для тех кому в конфиг sing-box сложно. Бейте секции на отдельные json и делайте merge в один.
Пользуюсь случаем, хочу сказать какая-же отстойная у sing-box документация
Спасибо, вторая пошла шиться. Добавьте тогда bzt33cyu что ли в список поддерживаемых.
Это не наш метод - проверим в бою. Вроде поднялось, в конверторе тоже поменял на свой TZ3000bzt33cyu.
Не понял насчет второй прошивки. Надо делать? И если делать, то как? Править local_ota_index.json под новый идентификатор?
Прошивка не хотела обновляться, пока в local_ota_index.json не поменял на свой TZ3000bzt33cyu
Пока шьется, посмотрим что будет. В принципе если окажется что "не та ревизия" и датчик окирпичится, не расстроюсь. Пол года работал нормально, еще пол года - постоянные отвалы и батарейка то 0, то 100.
Интересно, а батарейку начнет адекватно показывать наконец?
Для ipv6 дополню. Допустим у нас ipv6 и его тоже надо обходить (единственное что, у меня для обхода ipv6 отдельный интерфейс, но я думаю направления хватит):
Создаем лист для ipv6 адресов (firewall)
config ipset
option name 'proxy_list'
option match 'dst_net'
option family 'ipv6'
Маркируем пакеты (firewall)
config rule
option name 'Mark-Proxy-for-LAN'
option src 'lan'
option dest '*'
option proto 'all'
option ipset 'proxy_list'
option set_mark '0x2'
option target 'MARK'
option family 'ipv6'
Добавляем маршрут для трафика 0x2 (network)
config rule6
option priority '100'
option lookup 'proxy'
option mark '0x2'
Добавляем маршрут для таблицы (network)
config route6
option interface 'proxy'
option target '::/0'
option table 'proxy'
Добавляем правила для доменов (dnsmasq)
nftset=/chatgpt.com/6#inet#fw4#proxy_list
Хоть и решение завернуть wg в vless может показаться странным на первый взгляд, на это есть свои причины... По итогу удалось сделать следующим образом:
Взял проект https://github.com/rfc1036/udptunnel. Скопмилировал бинарники для сервера и роутера.
Может показаться что, зачем? Есть ведь есть socat (очень сильно режется скорость, буквально до кбит), есть udptunnel в официальных репозиториях openwrt (это не то, хоть и имеет такое же название. Более того, udptunnel из репозиториев openwrt у меня не заработал и судя по форуму openwrt, не только у меня).
На сервере: [tcp который будем слушать] [ip и udp куда нам надо переадресовать]
udptunnel -S --server -v 0.0.0.0:12345 127.0.0.1:51820
На клиенте: [udp в который будем ломиться] [адрес сервера с tcp портом]
udptunnel -S -v 0.0.0.0:12345 example.com:12345
По итогу такая связка заработала. Wireguard кстати на openwrt капризный, если указывать в endpoint - localhost, wg отказывается у меня запускаться. 127.0.0.1 работает.
Скорость получилась 50/20 мбит против эталонных - 110/200, что мало конечно, но лично меня устраивает.
Столкнулся с проблемой. Предыстория - дачный роутер перестал подключаться по Wireguard к городу. Решил завернуть трафик WG в VLESS. Поставил sing-box на роутер, поднял VLESS - тут ок, никаких проблем. Пытаюсь поднять WG через tun от sing-box, все по мануалам выше. Коннекта нет. Почему то tun ни в какую не пропускает udp. Решения не нашел.
Я тоже заметил что некоторые устройства, например друзей приходящих в гости, отображают хоть и подменный, но постоянный мак адрес. Хотя глубоко в вопросе не разбирался. Спасибо что поделились наблюдениями)
Да, просто отключаю для домашних сетей.
Так можно сделать, но проблема в том что невозможно именно сделать template device_tracker, просто в HomeAssistant нет такого типа template. А именно device_tracker нужен был мне для красивого отображения в интерфейсе, и привязки к аккаунта пользователя, к которому тоже невозможно привязать что либо кроме device_tracker.
Zigbee у меня только дома и на даче. На даче через Zigstar LAN. При этом это только потолочный свет. Что касается отопления - дом в целом теплый, есть печка, зимой почти никогда не ездим. На весну/осень установлены электрические конвекторы в каждой комнате. В конвекторы встроены (своими руками) esp8266+релюшки на 16А. Данные температуры берутся с перешитых bluetooth датчиков - LYWSD03MMC. Собирает это все дело с них, esp32 с esphome (настроенно как platform: atc_mithermometer). На случай отвала интернета на роутере поднят mqtt сервер, куда esp32 дублирует показания с датчиков. От туда же esp8266 конвектора читает температуру в своей комнате и воображает себя термостатом.
Получается в случае отвала интернета пропадает только контроль потолочного света, но в ручную то все работает и zigbee сеть не разваливается. Ну а конвекторы вообще получается никак от интернета не зависят, ну только задать температуру... Но для этого у меня предусмотрена физическая кнопка на конвекторе позволяющая тупо включать реле.
https://habr.com/ru/articles/785868/
Я как раз пишу об этом следующую статью)
Ну это только пример. Если ничего в доме нет, то и ping как бинарный сенсор сойдет на посмотреть.
Телевизором будет управлять на сколько позволит ваш телевизор. В дефолте обычно вкл/выкл, громкость, пауза стоп.
Можно сделать простейшую автоматизацию - если ваш смартфон пингуется - включить телевизор.
Конечно, это не имеет никакой полезной нагрузки, но повторюсь - на посмотреть сойдет.
Создать виртуальное устройство. Например бинарный сенсор ping. До роутера. Будет показывать пингуется или нет. Можно подключить погоду, например с яндекса, тоже сенсоры появятся. А можно хорошенько осмотреть дом на предмет чего-то отдаленно умного, например многие телеки сразу автоматом прокидываются.
Не надо стеснятся, ставьте сразу HomeAssistant. Много ресурсов он не отожрет.