По сути веб морда у меня для сервисных нужд (чтобы посмотреть статусы системы)потом отключу.

Про защиту, можно долго говорить и спорить (но все должно быть в адекватных рамках)

Представим что кто то задался целю взломать мой умный дом.
1.взлом wpa2
2.узнать айпи определеного модуля или айпи mqtt сервера
3.взломать пароль к mqtt серверу
4.подобрать идентификатор клиента mqtt сервера
5.Угадать топи, и команды mqtt

Телеграм, вариант не из легких но
1.Обойти защиту по админ id
2.Угадать команды

Взлом гугл акуанта, думаю тоже задача не из легких.
(я думаю они там в купертино штаны не просто так протирают)

И главный вопрос ДЛЯ ЧЕГО ЭТО ВСЕ КОМУ ТО?

ДЛЯ ЧЕГО ЭТО ВСЕ КОМУ ТО - это вопрос отдельный)) Сейчас в инете развелось много "радиолюбителей" ))


Это всё не проблема)) Достаточно знать как работает mqtt протокол. https://habr.com/ru/company/advantech/blog/452904/

Цитата: "Стандартный порт MQTT-брокера для входящих TCP-соединений — 1883. При использовании защищенного SSL-подключения используется порт 8883."
От себя: защищенный SSL вас не спасёт от атаки "человек посередине". ))

Узнать айпи и MAC адреса всех устройств в доме можно с помощью обычного анализатора трафика))
Телеграм ещё пока не взламывал... А всякие там аккаунты и ящики с паролями воруют... ещё и как))

Поэтому при проектировании умного дома надо быть готовым к тому что весь трафик в доме и за домом могут видеть все "радиолюбители"))

Далее...
Мне тут стало интересно как работает мой умный дом по VPN. Скачал оперу... В опере есть бесплатный встроенный VPN.
-Мой комп 192.168.0.101 установил защищённый канал связи с сервером VPN 77.111.244.26 по протоколу TLS версии 1.2.
-Оправляю пакеты... на IP сервер VPN 77.111.244.26
-сервера VPN 77.111.244.26 преобразует IP в 77.111.244.101 и отправляет моему дому W5500.
-мой дом W5500 определяет с какого IP пришёл запрос... проверяет корректность запроса (формат пакета, контрольные суммы, ключи шифрования и т.д.) и все эти данные возвращает серверу VPN 77.111.244.101
-сервер VPN 77.111.244.101 возвращает данные моему компу.

сервер VPN 77.111.244.26 находится где-то в Нидерландах))

Короче всё работает. ))
Только по VPN тормозит всё конкретно (скорость передачи пакетов меньше в 2...3 раза).
А ещё сервер VPN 77.111.244.26 фильтрует весь HTTP трафик. Просто TCP пакеты он не пропускает. Надо писать всё как положено (согласно HTTP протоколу).
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *\r\n
Content-Type: text/html\r\n\r\n
...
и т.д.
Но главное что всё работает. Буду в Нидерландах проверю))

Добавлено after 8 hours 19 minutes 20 seconds:

Подумаем))
В интернете нашёл прикольное видео)) Чувак сделал Ethernet модуль на... ATtiny85 !!!

https://www.youtube.com/watch?v=mwcvElQS-hM
https://www.youtube.com/watch?v=m4f4OzEyueg

Я тоже так хочу )) Повторим эксперимент. Будем передавать UDP пакеты по интернету))

Правда ATtiny85 у меня нет... возьмём Atmega8 )) И кварц 20 МГц. https://aliexpress.ru/item/32674069830. ... 81ca95a-12

Паяем по схеме.

Далее открываем AVR студию и пишем на... ассемблере)) Пипец... Не люблю ассемблер но по другому не получится))
Подробное описание Ethernet пакета лучше посмотреть тут - https://www.fpga4fun.com/10BASE-T2.html

Далее... чувак подробно рассказывает про стандарт 10BASE-T и "Манчестер-II"... Правда у чувака явные проблемы с математикой...

Но не важно.

Прошиваем Atmega8... подключаем к роутеру... и... нифига не работает)) Причина не понятна... нормального осциллографа нет.

Тогда делаем всё по стандарту 10BASE-T. Добавляем трансформатор )) https://aliexpress.ru/item/32742082279. ... d3ddcb5d-1

Заработало ! )) Сразу поднялся Link на роутере. Нажимаем на кнопку... побежали UDP пакетики))


*Резистор в схеме на всякий случай))

Пару слов про стандарт 10BASE-T. Проверим на практике стандарт 10BASE-T ))

"Манчестер-II" может иметь разную кодировку: так "1" > 10, "0" > 01 или так "1" > 01, "0" > 10.
Хотя роутер и работает с любой кодировкой, но второй вариант работает лучше (стабильней).


Байты передаются младшим битом вперёд (как в UART).

Контрольную сумму Ethernet пакета (CRC-32) может посчитать Atmega8.
А можно посчитать вручную, в онлайн-калькуляторе и забить в программу)) http://www.sunshine2k.de/coding/javascr ... rc_js.html

Только я не понял... зачем надо передавать CRC-32 начиная с младшего байта... B3 31 88 1B... но видимо так надо было)) Разработчикам Ethernet виднее))

Еще в стандарте 10BASE-T написано про Автосогласование - https://en.wikipedia.org/wiki/Autonegot ... al_signals
Если Atmega8 не передаёт пакеты, то она должна передавать импульсы соединения (NLP). И даже прописано требования к импульсам.
Сделаем по стандарту.))

Но как показала практика... роутеру пофигу эти стандарты)) Менял длительно (50...500 ns) и скважность (10...30 ms) и фазу импульсов... роутеру без разницы)) На самом деле роутер реагирует только на наличие или отсутствие импульсов, а не на их параметры)) Точнее роутер реагирует на любой сигнал (активность) на своём порту...
Можно вообще не передавать никаких импульсов (NLP), а сразу передавать пакеты.
-Если нет никаких импульсов, роутер отключает свой порт... и экономит электричество)).
-Как только появляются импульсы (или пакеты), роутер опять включает порт.
Одна проблема - время включения порта у роутера до 0,5 секунды. Поэтому если сразу передавать пакеты (пачками), то первые пакеты теряются. А в остальном всё нормально))

Короче... разобрали подробно Ethernet стандарт 10BASE-T. Сделали прикольный датчик)) Можно поставить куда-нибудь... Atmega8 может передавать UDP пакет прямо на мобильник... по интернету)) И никаких esp32 не надо))

Ещё порадовало низкое энергопотребление. Для сравнения (ток в режиме передачи):
-роутер 240...320 mA (зависит от количества активных портов).
-esp32 до примерно ~300 mA (точно не знаю).
-W5100 180mA
-W5500 80mA
-Atmega8 12mA (!).

Можно ещё добавить кнопок...
Теоретически можно добавить датчик температуры... напряжения и т.д.
Например тут собрали аналогичную схемку на ПЛИС - https://marsohod.org/projects/plata1/94-ether-send
Можно тоже самое сделать на Atmega8. Правда с Atmega8 придётся извратиться)) Atmega8 и так работает на пределе своих возможностей - тактовая частота 20 МГц, а максимальная ~25 МГц. ))

Ещё бы научить Atmega8 принимать пакеты...
Например тут собрали приёмник пакетов... https://marsohod.org/projects/marsohod2/263-rtl-recv
Но это для Atmega8 уже будет слишком сложно)) Тут нужен МК пошустрей... например како-нибудь STM32... с тактовой частой 72 МГц и т.д. и т.п.))

Короче... всё работает. Трансформатор не нужен. Просто провода покороче.

Или можно напрямую подключиться к микросхеме роутера. Всё работает.

Тут как раз проблема в ПОКОРОЧЕ.
Но это другая тема розговора, в которой я не особо компетентен.
Извените и не особо хочитса вникать.

Я успел поигратса с разными контролерами,
но после того как поработал пару месяцов с esp32
(других даже на термостат не ставлю)
Я не знаю в чем причина- но 32 работает мега быстро и стабильно.
(сотнями часов без единого резета и зависов и малейших тормозов)
И самое главное стоит 3 долара готовый модуль.
А програмирование в FL6.3-позволяет творить чудеса даже школьнику.
В режиме клиент потребляет 150-180ма (меня это вполне устраевает)
К стабильности питания не превеледлива.

Я просто констатирую факт, который проверен лично мной.
Если передумаете, пишите.

проблема в том что мне не надо ПОКОРОЧЕ
мне надо ПОПОДРОБНЕЙ

Что-то наш умный дом заглох... Тема требует продолжения ! ))
На чём мы остановились... ? На поиске оптимального варианта управления умным домом. ))

1. Сначала сделали управление умным домом на обычном браузере... по протоколу TCP(HTTP).

2. Потом поняли, что для управления умным домом браузер нам не подходит. Причин много...
-это не удобно... браузер не работает в режиме Сервера (не умеет принимать запросы).
-ограниченные возможности браузера... браузер не умеет работать с файловой системой компа.
-низкий уровень безопасности браузера... браузер предлагает сохранить пароли... браузера собирает данные активности клиентов и передаёт все данные на сервер Яндекса)) Причём по зашифрованному протоколу TLS... я даже не вижу что имено передаёт браузер)) Пипец... Всё это противоречит нашей политике безопасности Умного дома.

Поэтому написали приложение на Java... по протоколу UDP.

3. Чтобы сохранить возможность управления умным домом из браузера добавили в Java Socket... ServerSocket... InputStream... OutputStream... и т.д.
Теперь наше приложение на Java работает и как Сервер, и как Клиент, по протоколу UDP, TCP(HTTP).

Далее...
Две недели тестировали наш Сервер UDP, TCP(HTTP)... Подключались к нашему Серверу удалённо... по интернету... с компа... с телефона... и т.д. Всё работает))
Через две недели посмотрели журнал "посетителей" нашего сервера... и офигели)) Кто только не подключался к нашему Серверу по протоколу UDP, TCP(HTTP)... Больше всего подключений по протоколу TCP(HTTP)... Всякие боты... пару раз подключался сам Яндекс )) Оказывается в Яндекс есть служба, которая проверяет все сайты на предмет вредоносных программ... с последующим занесением в список безопасных сайтов. Наш сервер тоже попал в этот список))
Короче пипец... у нас не Сервер а проходной двор какой-то))
Всё это противоречит нашей политике безопасности Умного дома. Поэтому протокол TCP(HTTP) отключили.
Будем работать по UDP. ))

UDP имеет более высокую безопасность по сравнению с TCP.
UDP не устанавливает соединения (всякие SYN, FIN), а значит наш Сервер в интернете не виден)) Полная анонимность))

Немного подкрутили Java... ))

Далее...
Нас интересует как будет работать наш Сервер по протоколу UDP через NAT.
Наш Сервер находится дома за роутером. Роутер получает белый IP от провайдера. На роутере включён режим DMZ.
Ещё при отказе роутера (например роутер завис) наш Сервер может автоматом подключиться напрямую к провайдеру. Есть такая фишка)) Короче с подключением к Умному дому проблем нет. )) Умный дом всегда на связи))

Вопрос: Когда мы дома, мы работаем через тот же роутер по локальной сети дома. По проводам или по Wi-Fi.
А что делать когда мы не дома ? Как с нами будет связываться Умный дом ?
Ответ: Через публичные точки доступа Wi-Fi ! )) Как правило публичные точки доступа Wi-Fi - это обычные роутеры с NAT... Поэтому нам надо точно знать как работает NAT на роутерах... во всех подробностях))

Для проверки берём простой роутер и смотрим как там работает NAT (проброска портов отключена). Измерим все тайминги))

Схема такая: сервер (10.0.0.1) --- (WAN | роутер | LAN) --- сервер (192.168.0.1)

1. Из внешней сети (10.0.0.1) во внутреннюю (192.168.0.1) попасть невозможно так как порты на роутере закрыты.
2. Из внутренней сети (192.168.0.1) во внешнюю сеть (10.0.0.1) попасть можно.))
3. Допустим сервер (192.168.0.1) отправляет UDP пакет серверу (10.0.0.1).
4. Роутер делает запись в таблице NAT Table ("порт == IP" ).
5. После отправки UDP пакета роутер включает таймер примерно на 20 секунд.
6. Если по истечении 20 секунд ответ так и не пришёл, роутер удаляет из таблицы NAT Table запись о сокете. После этого из внешней сети (10.0.0.1) во внутреннюю (192.168.0.1) попасть невозможно.
7. Допустим ответ пришёл. Тогда роутер устанавливает таймер примерно на 30 секунд.

8. Далее идёт обмен данными между серверами... сервер (192.168.0.1) << >> сервер (10.0.0.1)...

9. При каждом новом пакете роутер автоматически устанавливает таймер примерно на 2...3 минуты.
10. Если пакетов больше нет, то через 2...3 минуты срабатывает тайм-аут и роутер удаляет из таблицы NAT Table запись о сокете. После этого из внешней сети (10.0.0.1) во внутреннюю (192.168.0.1) попасть невозможно.
11. При передачи пакетов порты (Source port и Destination port) роутер не меняет. Роутер меняет только IP (Source IP и Destination IP).
12. Вывод: Для поддержания связи по UDP надо непрерывно что-то передавать... например пустые пакеты... не реже чем каждые 2...3 минуты )) Чтоб не срабатывал тайм-аут и роутер удаляет из таблицы NAT Table запись о сокете.

Вообщем всё понятно)) Короче... Надо добавить в Java "режим удержания связи" через NAT))
На языке программистов это кажется называется "NAT дырокол"... или как-то так))

Такс... что у нас тут... Тесты продолжаются... ))

Продолжим...

Задача:
Сделать маленькие компактные датчики и исполнительные устройства с низким энергопотреблением для Умного Дома.
(реле, диммеры, выключатели, датчики температуры, протечки, умные счётчики... и т.д.)
Управление:
Через Java приложение (на телефоне, компьютере... и т.д.)

Для начала хочу сделать по такой схеме

Или по такой

Уходя из дома роутер можно отключить

Важный вопрос - безопасность. Всё должно быть зашифровано.

Согласен.

Так и сделаем.

Не согласен. Это не удобно.

Так и сделал.

Сейчас используется протокол шифрования ГОСТ 28147-89 https://ru.wikipedia.org/wiki/ГОСТ_28147-89
Только немного модифицированный.

Режим шифрования - Output Feedback (OFB) или Counter mode (CTR).
https://ru.wikipedia.org/wiki/Режим_шиф ... dback_(OFB)

1. Вектор инициализации состоит из трёх частей:
-заголовка - ID устройства. Так как все устройства в Доме имеют свой уникальный ID, то все устройства в Доме будут генерировать свою уникальную гамму. Это повышает криптостойкость всей системы в целом.
-генератора случайный чисел. Генератор случайных чисел делает непредсказуемым номер вектора инициализации. Это значительно повышает криптостойкость всей системы в целом.
В качестве генератора случайных чисел в Сервере Java используется встроенный генератор случайных чисел Java.
В качестве генератора случайных чисел в исполнительных устройствах используется шум квантования АЦП МК (ATmega8 или ATmega128).
-счётчика вектора инициализации. Счётчик вектор инициализации позволяет генерировать уникальные гаммы. Это значительно повышает криптостойкость всей системы в целом.
2. Вектор инициализации шифруется и передаётся вместе с зашифрованным пакетом.
3. Работа Генератора гаммы в особых пояснениях не нуждается. Стандартный режим сцепления блоков.
Единственное что - можно добавить опцию - "режим сцепления блоков с переменным шагом".
4. Имитовставки не используются. Вместо них используется хеш-функция. Сейчас обычный CRC.

На схеме зашифрованные пакеты выглядят так:

-с помощью хеш-функции (сейчас обычный CRC) Система Умный Дом проверяется целостность данных. При ошибках хеш-функции Система Умный Дом сообщает на все устройства (телефон, компьютер и т.д.), на которых запущен Сервер Java.
Далее Система Умный Дом переходит в режим "блокировки" или в другой режим (согласно настройкам).

-благодаря счётчику вектора инициализации все пакеты уникальны (никогда не повторяются).
Это позволяет легко защититься от так называемой "Атаки повторного воспроизведения".
https://ru.wikipedia.org/wiki/Атака_пов ... оизведения
Система Умный Дом автоматически обнаруживает все атаки "повторного воспроизведения" и сообщает на все устройства (телефон, компьютер и т.д.), на которых запущен Сервер Java.
Далее Система Умный Дом переходит в режим "блокировки" или в другой режим (согласно настройкам).


Ключи шифрования.
ГОСТ 28147-89 использует ключ 256-бит (32 байт).
45 23 67 96 85 74 38 69 47 01 49 82 05 74 93 06 04 82 84 95 48 72 74 95 61 74 95 83 47 69 04 93
Для повышения криптостойкости всей системы необходимо периодически менять Ключи шифрования.
Сейчас ключи шифрования передаются (по запросу) в одном пакете вместе с данными. Удобней передавать ключ по частям.
1. Это экономит место в пакете.
2. Повышает криптостойкость (трудней перехватить ключ по частям). К тому же не известно какая именно часть ключа передаётся. Это может быть один или несколько байт. Например так:
45 23 67 96 85 74 38 69 47 01 49 82 05 74 93 06 04 82 84 95 48 72 74 95 61 74 95 83 47 69 04 93
В дальнейшем надо сделать расписание ключей (автоматическая смена ключей по расписанию). Для повышения криптостойкости расписанием ключей может управлять например генератор случайных чисел.

Опции.
Система Умный Дом может "вбрасывать" так называемые "пустые" пакеты, которые не несут никакой информации, а служат для усложнения Криптоанализа.

Криптоанализ.
Насколько ГОСТ 28147-89 стойкий... я без понятия))
Но всегда есть так называемый "полный перебор". https://ru.wikipedia.org/wiki/Полный_перебор
Единственный способ защиты от атаки "полный перебор" - это одноразовый блокнот.
Как "взломать" одноразовый блокнот - наука пока не придумала...


Добавлено after 22 minutes 28 seconds:
P.S.
Протокол (ГОСТ 28147-89) для ATmega8 слишком тяжёлый... 8 битная ATmega8 (4 МГц) тормозит конкретно)) Но работает.

Вообще изначально я хотел AES-256.
Не знаю... если смысл переходить с ГОСТ 28147-89 на AES-256 ?

смысл есть.
AES-128/256 работает примерно в два быстрей ГОСТ 28147-89.
AES-128/256 блоки по 16 байт.
ГОСТ 28147-89 блоки по 8 байт.

ГОСТ 28147-89 и AES-256 по объёму занимаемой памяти примерно одинаковы.
оба спокойно помещаются в простой МК типа ATmega8.

ГОСТ 28147-89 и AES-128 и AES-256 по объёму занимаемой памяти примерно одинаковы.
все шифры спокойно помещаются в простой МК типа ATmega8.
разница только в скорости их работы...

Что-то мы давно не делали Умный дом...
Вот такой будем делать))

https://www.youtube.com/watch?v=7gOqqYq1QrA

после долгих проб и ошибок... пришли к классической схеме...

будем делать по классике - витуха с PoE по всему дому.
а вместо роутеров используем простые МК типа AVR

а полная схема будет примерно такая...

сейчас всё управление с ПК... через приложение... уже работает))

есть всякие автоматические всплывающие окна... и т.д.

ещё надо добавить мессенджеры...))

пока есть только самодельный Skype... уже работает))

обычный скайп)) передаёт аудио... видео... текст... по UDP... с шифрованием))
вверху разрешение экрана и IP ПК))
нажал кнопочку Test... сменил адрес на 172.0.0.1...
внизу вводим IP кому хотим позвонить... и нажимаем жёлтую кнопку вывоза...))
потом зелёную кнопочку)) говорим в микрофон... слушаем в наушниках...
вверху - видео TX_RGB (скриншот компа)... speed (частота кадров)... и т.д.
внизу вводим текст в нижнем окне и нажимаем "ввод"... в вернем окне появится чат))
плюс ещё есть куча настроек... по мелочи))
и т.д.

можно интегрировать Skype в приложение управления умным домом...
а можно использовать отдельно))

далее.. это всё надо допилить... до идеального состояния))
а вот какое оно должно быть... это идеальное состояние... пока до конца не ясно..))

вообще... изначально планировалась такая схема...

но у этой схемы высокое потребление...
80 mA - W5500
10 mA - ATmega128
300 mA - роутер

поэтому решили сделать свой протокол ))
принцип простой - используем прерывание и один таймер ATmega328.

-изначало все МК находятся в режиме SLEEP...
-при обнаружении пакета МК просыпается и переходит в режим приёма...
-при каждом изменении уровня вызывается прерывание, измеряется длительность между прерываниями и обнуляется таймер...
-по окончанию пакета вызывается прерывание таймера.


итого:
-получили скорость ~100 кБит/c.
-получили низкое потребление.

по моему проще уже не придумать))

забыли ИК пульт дорисовать))


на всякий случай))

продолжаем...


PoE:
добавим в Wi-Fi роутер PoE...

намотали самодельный трансформатор))
экспериментально определили - надо 10 витков (в два витка) на феррите 12х12 мм...


установили в роутер... подключили + 5V...

работает.


Добавлено after 2 minutes 14 seconds:
и антенны тоже сделаем самодельные... поменьше ))
экспериментально определили (по максимальному уровню сигнала) - надо 26 мм провода... что соответствует 1/4 волны для 2,4 GHz...

получили: роутер Wi-Fi (2 встроенные антенны) + Ethernet + PoE (5V, 2А).



ещё добавим POE в модуль W5500...

берём такой дроссель...

делам из него высокочастотный трансформатор...
мотаем 6+6 витков... с отводом...

паяем по такой схеме...

проверяем...


получился модуль W5500 с PoE (5V, 2А).

теперь схема такая

питание от стандартного БП (5V, 2А) или от стандартного USB (5V, 2А)...

уменьшили пакет до 32 байт...

стало работать чуть быстрей))

приложение на ПК...

-нажали кнопочку - ПК отправил пакет - включилась лампочка ))
-включилась лампочка - пришло подтверждение включения лампочки))


надо добавить в схему выключатель))


-включили/выключили выключатель - сработало прерывание МК (прерывание по изменению уровня).
-сработало прерывание - МК отправил пакет на ПК.
-если пакет с первого раза не прошёл... МК повторяет пакет... несколько раз...

получили UDP с гарантированной доставкой пакетов))
работает))

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

ИК пульт надо подключить))

берём такой приёмник...

подключаем к ATmega328/48...
смотрим протокол NEC...


включаем прерывание... таймер... записываем в буфер... собираем байты... передаём на ПК...

всё работает))

пульт от телика SAMSUNG...
https://radioparty.ru/manuals/encyclope ... -ircontrol
работает вот так...

единственное отличие - при повторе передается весь пакет целиком.
в остальном всё верно написано.

а в TV приставке повтор передаётся отдельными импульсами...

в остальном всё верно написано.

остальные пульты разбирать не будем... ))

теперь надо придумать куда это использовать...
Например можно пультом от телика управлять ПК... и т.д.
И наоборот... с ПК управлять теликом))
и т.д.

проверим разные пульты...

пульт от телика SAMSUNG...

44h - длина пакета (68 прерываний)
22h - длительность преамбулы.
23h - длительность стартового импульса.
07h - адрес устройства (SAMSUNG).
07h - адрес устройства (SAMSUNG).
68h - адрес команды (номер кнопки).
97h - инверсия адреса команды (номер кнопки).

а вот ещё один пульт от телика SAMSUNG...

всё тоже самое))

а вот пульт от TV приставки...

преамбула, адреса и команды уже другие...

и т.д. и т.п.

короче у нас получился анализатор ИК пультов на ПК ))



где это можно использовать в умном доме ?
нигде))
дело в том что пульт передаёт команды без шифрования...
а управлять умным домом без шифрования... запрещено ! ))
поэтому ИК пульт - это не более чем просто игрушка))
примерно так.

термореле надо подключить))

берём такой датчик...

подключаем к ATmega328/48...
смотрим протокол 1-Wire...

включаем термореле... запускается таймер... термореле автоматически (по таймеру) передаёт температуру на ПК...

когда температура превысит максимальный порог (MAX) термореле автоматом отключится... и сообщит на ПК...

когда температура упадёт ниже минимального порога (MIN) термореле автоматом включится... и сообщит на ПК...

Настройки:
-вкл/выкл термореле
-сообщать температуру каждые 5 сек - да/нет
-сообщать когда температура превысит максимальный порог - да/нет
-сообщать когда температура упадёт ниже минимального порога - да/нет
-сохранить настройки в EEPROM - да/нет
и т.д.
все настройки сохраняются в EEPROM термореле...
при повторном включении термореле продолжит свою работу в автоматическом режиме... но уже без участия ПК...

вот такое у нас получилось простенькое программируемое термореле... с управлением по Интернету))


Добавлено after 1 hour 9 minutes 7 seconds:
в ходе экспериментов выяснилось... что лучше чтобы ПК сам опрашивал все датчики в доме (включая термореле)...
а сами датчики будут сообщать ПК только в случае их срабатывания... т.е. по событию.
так система работает лучше - меньше нагрузка на локальную сеть...
можно и так... исправим)) это мелочи))
вообще такие подробности выясняются уже в процессе тестов))
там ещё много что надо подкрутить... и улучшить))


Добавлено after 1 hour 34 minutes 48 seconds:
раньше была такая схема...

энергопотребление:
роутер (2 шт) * 0,3 A + W5500 (5 шт) * 0,08 = 1 A * 5 V = 5 Ватт.

теперь такая схема...

энергопотребление:
роутер (1 шт) * 0,3 A + W5500 (1 шт) * 0,08 + AVR (2 шт) * 0,01 = 0,4 A * 5 V = 2 Ватт.

управлять умным домом без шифрования... запрещено ! ))
а управлять теликом по интернету... можно))

вот такое надо сделать... https://habr.com/ru/post/254761/
для начала надо считать все кнопки...

считали все кнопки... ))


Добавлено after 2 hours 4 minutes 49 seconds:
смотрим протокол SAMSUNG...

пишем простенькую программку для ATmega328... и закидываем в протеус...

берём ИК-светодиод... подключаем к ATmega328... открываем приложение...

нажимаем на кнопочки... управляем телевизором с ПК ))
всё работает.))

осталось нарисовать красивые кнопочки в приложении...

это мелочи))

в идеале надо вмонтировать ИК пульт в сам телевизор...
надо подумать))