Комментарии 62
Никто не запрещает mqtt в домашней сети поселить.
Я к тому, что это не фундаментальная проблема, для первых шагов вполне вариант.
Автор попробует и, быть может, сам придёт к выводу, что брокер MQTT лучше свой использовать. При этом не придётся переделывать всё, достаточно будет параметры соединения поменять.
Требования к умному дому читайте в первой статье.
Рассматривал. Под мои требования не подходят.
Профит зигби в том, что он не требует интернета. То есть если РКН забанит вас и все ваши wqtt,hodered,homebridge, А шлюз взорвется или упадет с 27 этажа на асфальт… то внезапно, большая часть функций будет работать. Так как в протоколе есть такое понятие как binding. это когда можно напрямую подключать устройства друг к другу, и они будут работать даже если координатор сети отвалится.
ZigBee менее понятный для фронт-разработчика. Я так и не нашел простого мануала как быстро запустить пример типа Hello World. Поэтому пишу такой мануал самостоятельно и в конце цикла его тоже опубликую. Но реально долго это делаю, т.к. Wi-Fi намного проще в понимании, чем ZigBee.
А можно вопрос не очень в тему?
Для чего вы говорите за всех "форнт-разработчиков"?
И для чего вы про себя говорите от лица всех "форнт-разработчиков"?
Это шаблоны и ярлыки в которых может затеряться личность.
BME280. Он и температуру и влажность и давление меряет, и очень точно.
Кроме того, подумайте о том, чтобы заменить ESP8266 на ESP32. Если нужно будет делать автономное питание то у 8266 есть архитектурные проблемы.
— Он не может долго спать. по-моему макс 40 минут.
— Нельзя запоминать некий стейт в RTC памяти
— нет ULP процессора.
— официальный SDK уже фактически не развивается. А в том что есть — там черт ногу сломит.
в ESP32
— можно спать сколь угодно времени до наступления события
— можно при просыпании по-быстрому обработать причину в ULP и решить нужно ли будить основное ядро.
— есть RTC память. которая не сбрасываетя в deep-sleep.
— есть bluetooth. То есть можно делать BLE маяки, которые будут сильно энергоэффективнее wifi.
— официальный SDK (ESP-IDF) очень активно развивается. есть много документации и примеров.
— 2 ядра на 240mhz!!! я как-то телеграм бота делал на esp32 который по https ходил. все работало довольно быстро.
— Продолжительность сна 8266 (если верить Тасмота) — 71 мин tasmota.github.io/docs/DeepSleep. Они обходят это ограничение кратковременным (0.3 сек) просыпанием и засыпанием снова. Т.е. некритично.
— Для ULP процессора нужно писать на Ассемблере, насколько я понял. Не каждый возьмется. А если ставить прошивки типа ESPEasy, ESPHome, Tasmota так наверное и не получится?
Согласен. Но не все сразу. Главное взлететь. А там разберемся)
Где тут умный дом то? Дом станет умным только при появлении сценариев взаимодействия, логики работы устроцств без вмешательства в эту систему. А так просто датчики в интернет данными срут.
сейчас у всех телефоны, они могут выступать не только в качестве монитора и органов управления, но и как раз устройством для формирования индивидуальных сценарив, таскер рулит, и без Алисы работает голосовое управление… и все работает и без внешнего интернета, хотя конечно с ним дальность действия весьма расширяется)) часть логики лежит на самих есп… по мне так это оптимально, mqtt брокер поднимается на роутере и больше ничего не требуется для работы, максимум голосовое управление всё же требует наличие интернета, чтоб Гугл разбирал сказанное и переводил в текстовый формат
а если хозяев несколько… да и основная автоматизация и логика выполнена на самих контроллерах, на которых присутствуют исполнительные устройства и датчики. просто сценарии которые необходимы пользователю и триггеры находятся на телефоне. да и ни кто не мешает пробросить порт на пример с шифрованием с того же Москито на внешку. суть в том что данные все же хранятся локально и все работает так же без инета. а устройство пользователя на пример отслеживает свое местоположение, или другие триггеры и отправляет команды в нужные топики, плюс на каждом устройстве можно реализовать свою логику и по выходным данным отправлять данные так сказать индивидуально то, что нужно пользователю именно этого устройства. на пример сработал ваш будильник и включилась кофеварка. будильник жены тоже что нить запускает своё. так же телефон может отслеживать свое нахождение, и на пример попадая в нужную геолокационную зону отправлять команды на включение того же кондиционера… а вот алгоритм запуска, отслеживания температуры, уже реализован локально самим контроллером.
Не вижу связи между "ушел на работу" и "УД выключился". Поясните, пожалуйста, свою мысль.
У меня тестовая система работает. Я уже много раз уходил, но она как работала так и продолжает работать. С чего ей вдруг ломаться?
Пробовал когда то строить на esp, но… беда в том что wifi не потерпит много клиентов, особенно если некоторые в подрозетниках, гле сигнал плохой :( выходит полунерабочая, тормозная поделка...
Поэтому я предложил гибридную сеть. Сервер, wi-fi до ESP, от ESP до датчиков и исполнительных устройство провода на 1-Wire и I2C. А потом, когда я допишу мануал по ZigBee, то будет еще лучше.
Мне это предложили профи в электронике. И не просто предложили, а обосновали и показали что I2C действительно работает на довольно больших расстояниях. И ничего не глючит.
А провода довольно надежный вариант. У меня всегда было куча проводов в квартире и ничего, все работало надежно. Так что не совсем понятно о какой надежности вы пишите.
датчик находится в полутра мерах от контроллера, подбирал подтягиваюшин резисторы. так вот стоит включить освещение в соседней комнате, такая дичь оттуда начинает сыпаться… единственное что уменьшило этот шум(но не исключило) это использование экранированных витых пар..
Очень заманчиво, чтобы не городить дома кучу WiFi точек доступа, чтобы обеспечить дохлым ESP нормальное покрытие.
Похожее/лучшее решение, по-моему (если важна энергоэффективность) будет на модулях JDY-40 или nRF24L01 — дистанция от 100 м до 1-2 км, более энергоэффективные, дешевле ЕСПэшки (даже 8266, не говоря о ESP32 NodeMCU). В этом варианте в дальних точках будут именно датчики с модулем передачи (а не роутер/ретранслятор) — и это все на батарейках (т.е. получается небольшой автономный модуль который легко переместить/закрепить).
Если важна простота — то да, пары-тройки ЕСП должно хватить на всю квартиру.
Кстати, некоторые модули идут со штатным штекером для внешней антенны, т.е вопрос охвата/силы сигнала можно решить и так (взять антенну на 2.4 от старого раутера или ноутбука).
Тоже думал в этом направлении, но… это требует постоянной работы ЕСПешэк (никакого сна, но в плюсе быстрая/мгновенная реакция на датчики, и наверное в чем-то проще в подключении/настройке). Еще минус — дистанция между точками ограничена (другие точки, помехи, стены).
ESP8266 и сон — как то не очень совмещаются.
Жрут много даже во сне, выход из сна через перезагрузку, а значит и переподключение к WiFi. В этом отношении лучше Zigbee я пока не видел ничего.
Похожее/лучшее решение, по-моему (если важна энергоэффективность) будет на модулях JDY-40 или nRF24L01 — дистанция от 100 м до 1-2 км
Ни разу не удалось получить на nRF24L01 хорошее покрытие. Мощность передатчика там меньше чем у WiFi и те же 2.4ГГц
NRF52 немного получше — у них радиотракт помощнее. Из них NRF52840 самые мощные.
Тут принцип работы, как и в Zigbee — самоорганизовывающая сеть, где любое устройство может стать роутером/ретранслятором
Zigbee, бесспорно хорош в энергоэффективности, но цена всего набора (хаб плюс пару-тройку датчиков, плюс реле) выходит высоковата (как по мне).
А вот о Вашем опыте с nRF был бы рад услышать, т.к. пока моя мысль движется именно в этом направлении (особенно интересна связка ESP32 на внутреннем Bluetooth modeme и nRF Bluetooth на датчике).
NRF c Bluetooth я не запускал. Не нашел примера реализации нормального.
А вот NRF24, NRF51, NRF52 c Mysensors использую уже несколько лет.
Пока самые интересные модули получаются E73 на NRF52832 при цене менее $2.5
ESP32 активно использую в коммерческих задачах. Там FreeRTOS — песня!
По моему пока статьи автора ещё очень сильно не дотягивает до уровня хабра. Понимание в теме, в выбираемой архитектуре решения, вопросы надежности, автономности работы и т.д. и т.п. отсутствуют.
Для начала замените "светодиод" на полноценную индуктивную нагрузку. Возможно после этого поймёте, что просто как front-end разработчику без паяльника, в теме умного дома Вам делать нечего.
А далее подумайте про автономность работы Дома (это не ups), на что косвенно и напрямую на протяжении двух статей обращают ваше внимание.
полноценную индуктивную нагрузку
Пока не планировал такую нагрузку ставить… Это же вроде как двигатели всякие. А у меня пока что только лампы и обогреватели.
Во-во. "вроде как двигатели всякие". Вы ещё мыслите на уровне светодиода. Реле под нагрузкой это нечто другое. Вот тут отдельные статьи можно писать — обычные реле, твердотельные, и т.п. Как вы собираетесь коммутировать нагрузку? Подключите лампу 220В, свой обогреватель. Реальную кнопку подвесте на ESP. Схему питания, приближенную к реали. Хоть лампу себе на рабочий стол запитайте. Активно попользуйтесь пару недель. Я тему ЭМИ после этого вспоминал, вспоминал RC цепи, про которые как программист давно забыл. Десяток вариантов переделал. И код перелопачивал для обеспечения восстановления работоспособности и большей стабильности.
Никто не утверждает, что на 8266 нельзя собрать адекватное управление. Ещё как можно, но с учётом большого количества "НО" и опыта. У меня работает несколько самоделок стабильнее, чем промышленные zigbee выключатели. Как раз на esp8266.
А в ваших статьях нет главного — понимания необходимости стабильной работы. Нет опыта. Вы молодец, что делаете, изучаете тему. С темы "светодиодов и датчиков температуры" начинал каждый, кто этим интересовался. Но сразу писать об этом серию статей…
Так же для себя выработал ряд правил, которые соблюдаю (возможно со мной будут не согласны):
- Хороший блок питания для ESP (как говорил начальник лаборатории в НИИ: «Правильный блок питаний 90% работоспособности изделия» ))).
- Подтягивать GPIO к шине питания резистором 10К.
- Электролит по питанию как можно ближе к ESP (где позволяют габариты) – спорная рекомендация, но привычка.
- Где необходимо использую RC-цепь (описание выше).
- Программно. Восстановление состояния устройства после рестарта/сбоя (без загрузки данных из сети. Вообще устройство должно работать без подключения к WiFi, облаку, MQTT и т.п.)
- Программно. Никогда сразу после отключения нагрузки (реле) не проводить сохранение данных во flash. Без RC-цепи в 50% случаях с реальными устройствами получал рестарт ESP. Рискую получить негатив, но это практическая наработка, которую не могу объяснить, т.к. в тестах не помогал ни блок питания, ни емкости, ни экранирование.
И последнее — при макетировании как можно ближе к реальной нагрузке, к реальной ситуации.
Наконец-то, свет в конце тоннеля))))
Вы невозможны!
Мне тут карму плинтуса опустили только за то, что я хочу строить сеть на одних ESP-шках)))
И кстати, сеть на ZigBee получается дороже, чем на ESP-модулях. Это правда пока первая прикидка, но уже модуль ESP стоит от 80 рублей, а ZigBee — от 300 рублей.
Основная проблема MQTT это отстутствие шифрования (а данные гуляют по воздуху).
Его можно поднять с сертификатами (сертификат в скетче — это изящно и удобно, да).
Второй момент — отстутствие нормальной (работающей) ОТА библиотеки.
У меня напрямую не вышло.
Только через загрузку скомпилированного бинарника по https с NodeRed.
А ведь потенциальный "мамкин хакер" может попросту долбить "дропами" WiFi (библиотеки на которой можно поднять mesh сеть и чтобы в ней работало все что описано выше я не нашел).
Короче дело было год назад и может что то и поменялось.
Мой умный дом на ESP8266, часть 2