Умный дом на базе Xiaomi MiHome?

А кто что скажет о системе устройств серии Xiaomi MiHome?

Можно купить Home Multifunctional Gateway и к нему периферию Xiaomi:

1) вай-фай розетки

2) светильники

3) камера

4) ТВ и приставки

5) датчики: движения, открытия, температуры и влажности

6) раутер

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

Что скажут профессионалы и любители? ))

Мне больше понравилась система KERUI-W1

ru.aliexpress.com/store/product/KERUI-W1-WiFi-PSTN-Home-Burglar-Alarm-System-More-Convenient-Portable-home-alarm-system-great-design/115772_32686353850.html

Больше возможностей расширения как мне показалось.

А кто что скажет о системе устройств серии Xiaomi MiHome?

Можно купить Home Multifunctional Gateway и к нему периферию Xiaomi:

1) вай-фай розетки

2) светильники

3) камера

4) ТВ и приставки

5) датчики: движения, открытия, температуры и влажности

6) раутер

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

 

Что скажут профессионалы и любители? ))

Это пластмассовые поделки для поиграться с телефона, ничего общего с умным домом оно не имеет

В частном случае ценность представляют розетки и свет

Но если смотреть комплексно, то свет никакой против Philipps HUE

Датчики никакие против даже простой системы сигнализации

Камера ничто против системы видеонаблюдения

И главное - не умеет управлять системой отопления и кондиционирования

Суть какова, хочешь умный дом - это не к сяоми, это или к дорогим комплексным системам или к солянке разных систем, которые завязанны на системы управления, что умеют обьеденить разные стандарты и протоколы в единое с возможность написаний правил и граффиков

ЗЫ. Сяоми - это для любителей беленьких пластиковых гаджетов, поклацать недельку, показать куму и положить в тумбочку навсегда

Добавлено через 2 минуты

Мне больше понравилась система KERUI-W1

ru.aliexpress.com/store/product/KERUI-W1-WiFi-PSTN-Home-Burglar-Alarm-System-More-Convenient-Portable-home-alarm-system-great-design/115772_32686353850.html

 

Больше возможностей расширения как мне показалось.

Шикарная система сигнализации на брелке 433мГц, который читается с эфира даже школьником...

Приехали розетки, датчик температуры и гейтвей чтобы все это собрать докупы. Пока что проводятся полевые испытания - законнектил все устройства и поставил тестовый сценарий для отопления на отсутствие людей в доме - розетка (будет управлять насосом теплого пола на 1 этаже) включается если температура падает менее 10 градусов и выключается когда температура становится 15 градусов. Проверку проводил, поместив датчик температуры в холодильник - все сработало )))). Розетки поддерживают как дистанционное вкл-выкл, так и режим таймера + разнообразные сценарии.

Через гейтвей можно проигрывать китайское радио, включать и изменять цвет подсветки (баловство), самое главное - подключать кучу другой периферии (при желании).

Есть приложение под Андроид и iOS.

Поставлю все в доме - отпишусь по результатам.

Да, кстати о ценах: розетка стоит на алиэкспрессе 10 долларов, температурный датчик столько же, гейт в районе 30. Можно найти в Украине, цены ненамного дороже.

И как ваш опыт с сяоми? Дополнили еще какими-то гаджетами? Или разочаровались?

Я очень люблю сяоми и постепенно дом наполняется этой техникой, в планах датчик газа и дыма, но пока изучаю вопрос.

И как ваш опыт с сяоми? Дополнили еще какими-то гаджетами? Или разочаровались?

 

Я очень люблю сяоми и постепенно дом наполняется этой техникой, в планах датчик газа и дыма, но пока изучаю вопрос.

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

могу сказать, что если использовать всё, через сяоми, то оно подглючивает, и если сначала ты на это не обращаешь внимания, то потом это надоедает(приходится ждать по пару секунд пока включится свет, например). это скорее всего связано с тем, что так или иначе, но у MiHome используется китайкое облако, которое иногда глючит

после использования пары дней сценариев через MiHome поставил на raspberrypi domoticz(www.domoticz.com/), настроил его. работает гораздо лучше + можно использовать далеко не только сяоми(но не всё от сяоми работает)

пару месяцев назад попробовал HomeAssistant(www.home-assistant.io) понравилось больше, чем домотикз. теперь, когда есть немного времени/желания по немногу переезжаю туда

проблема, что домотикза, что ha - нужно хоть немного дружить с английским

и уметь уложить в голове четкий алгоритм работы системы

Как чудесно,- контроль оборудования, которое в случае например частного дома находится в пределах максимум 6 - 10 соток, через сервер, который находится на другом континенте...

в случае с сяоми это не совсем так, но очень близко

с того, что я вычитал - когда настраиваешь, что-то с телефона - сначала телефон заливает настройки в китай - потом на туже лампу

если нужно при включении одной лампы - включить другую - через китай

если нужно включить лампу с телефона - по сути тоже через китай

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

вообще - если делать умный дом с элементами по вифи, то тут есть 3и варианта:

1 - грамотно настроить вайфай(или настраивать бесшовный роуминг, или ставить 1 мощную точку доступа)

2 - грамотно настроить оборудование для подключения с вифи(лампы сяомовские, например, не настроить, там можно вбить только SSID и pass)

3 - не использовать оборудование на вайфай

проблема вифи может быть в следующем(у меня была ситуация с той же

лампой):

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

У проблемы есть 2 стороны:

1. Локальные проблемы, связанные с видимостью WiFi маршрутизатора/маршрутизаторов, с которыми соединяются оконечные устройства

2. "Глобальные проблемы", связанные с тем, что пакеты из вашей внутренней сети, уходят во внешний мир. Иногда достаточно далеко - в Китай например.

Если проблема номер раз может быть решена относительно просто (бесшовный WiFi), или по простому, можно задать то-же имя (SSID) для каждого из маршрутизаторов - и проблем нет. В этом случае BSSID будут различаться, но имена (SSID) останутся такими-же. В списке доступных сетей просто появятся несколько WiFi точек доступа с одинаковыми именами. Можно кстати и с разными. Можно так же использовать WiFi "удлинители". То есть эта проблема решается достаточно просто.

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

В общем неплохая идея, но в этом случае очень уместно "дорогая, подожди заходить в туалет, нужно перезагрузить WiFi точку доступа - и тогда появится свет".

В этом случае мы зависим от:

1. WiFi access point

2. Доступность локального интернет-провайдера

3. Доступность транспортной сети от местного провайдера до сервера (шлюза)

4. Доступность самого шлюза

Немного абсурдно: Оборудование установлено у вас. Все внутренние коммуникации, включая WiFi, который в общем-то не сильно зависит от внешних ресурсов (кроме некоторых моментов) по прежнему работают как часики, и тут локальный провайдер решает перезагрузить скажем свой BGP router. Минут 10 минимум. Занавес.

Все это время, устройства, которые по сути своей обладают достаточной автономностью для непрерывной самостоятельной работы, превращаются в набор деталей, плат и корпусов. И такими останутся, потеряв свою ценность до 0, если по какой-либо причине vendor не сможет поднять свой шлюз, или примет решение о прекращении предоставления сервиса.

Или по каким-либо причинам, в стране будет принята (не дай Бог конечно) какая-либо политика ограничения доступа к ресурсам внешнего мира, в рамки которой, по нелепой случайности, могут попасть подсети адресов, на которых развернуты шлюзы и их зеркала/реплики.

К сожалению, в нашей стране, понятие SLA в применении к локальному провайдеру интернет - пустой звук. Дырка от бублика то есть. Если отключат инет на скажем час,- ессно будут возмущенные звонки в support, но это пожалуй и все.

Коммерческая модель предоставления сервисов с SLA стоит денег, поэтому вендоры, которые поддерживают работоспособность шлюзов, оплачивают затраты на электроэнергию, зарплату обслуживающему персоналу, ... пытаются монетизировать сервис, предоставляя какой-либо минимальный набор услуг (бесплатный), с возможностью платного расширения. Эксплуатационные расходы то есть.

Есть конечно вариант поднять локальный сервер, но это требует времени, квалификации, и по прежнему стоит денег - например за электроэнергию, которую потребит этот самый сервер.

У проблемы есть 2 стороны:

 

1. Локальные проблемы, связанные с видимостью WiFi маршрутизатора/маршрутизаторов, с которыми соединяются оконечные устройства

2. "Глобальные проблемы", связанные с тем, что пакеты из вашей внутренней сети, уходят во внешний мир. Иногда достаточно далеко - в Китай например.

 

Если проблема номер раз может быть решена относительно просто (бесшовный WiFi), или по простому, можно задать то-же имя (SSID) для каждого из маршрутизаторов - и проблем нет. В этом случае BSSID будут различаться, но имена (SSID) останутся такими-же. В списке доступных сетей просто появятся несколько WiFi точек доступа с одинаковыми именами. Можно кстати и с разными. Можно так же использовать WiFi "удлинители". То есть эта проблема решается достаточно просто.

 

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

В общем неплохая идея, но в этом случае очень уместно "дорогая, подожди заходить в туалет, нужно перезагрузить WiFi точку доступа - и тогда появится свет".

 

В этом случае мы зависим от:

 

1. WiFi access point

2. Доступность локального интернет-провайдера

3. Доступность транспортной сети от местного провайдера до сервера (шлюза)

4. Доступность самого шлюза

 

Немного абсурдно: Оборудование установлено у вас. Все внутренние коммуникации, включая WiFi, который в общем-то не сильно зависит от внешних ресурсов (кроме некоторых моментов) по прежнему работают как часики, и тут локальный провайдер решает перезагрузить скажем свой BGP router. Минут 10 минимум. Занавес.

Все это время, устройства, которые по сути своей обладают достаточной автономностью для непрерывной самостоятельной работы, превращаются в набор деталей, плат и корпусов. И такими останутся, потеряв свою ценность до 0, если по какой-либо причине vendor не сможет поднять свой шлюз, или примет решение о прекращении предоставления сервиса.

Или по каким-либо причинам, в стране будет принята (не дай Бог конечно) какая-либо политика ограничения доступа к ресурсам внешнего мира, в рамки которой, по нелепой случайности, могут попасть подсети адресов, на которых развернуты шлюзы и их зеркала/реплики.

 

К сожалению, в нашей стране, понятие SLA в применении к локальному провайдеру интернет - пустой звук. Дырка от бублика то есть. Если отключат инет на скажем час,- ессно будут возмущенные звонки в support, но это пожалуй и все.

 

Коммерческая модель предоставления сервисов с SLA стоит денег, поэтому вендоры, которые поддерживают работоспособность шлюзов, оплачивают затраты на электроэнергию, зарплату обслуживающему персоналу, ... пытаются монетизировать сервис, предоставляя какой-либо минимальный набор услуг (бесплатный), с возможностью платного расширения. Эксплуатационные расходы то есть.

 

Есть конечно вариант поднять локальный сервер, но это требует времени, квалификации, и по прежнему стоит денег - например за электроэнергию, которую потребит этот самый сервер.

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

процесс авторизации у каждого оборудования происходит с разной скоростью, телефоны это делают относительно быстро, а таки устройства как сяоми лампы, есп и т.п. немного дольше(это, естественно, зависит не только от конечного оборудования, от роутера/точек доступа/повторителей тоже)

в остальном полностью согласен

но мы, кажеться, немного о разных вещах говорим - я говорю о том, что даже если покупать сяоми устройства, что действительно достаточно дешево, лучше не использовать ихнее облако, а поднимать свой сервер, который будет жить в локальной сети, и максимально ограничить доступ с него в интернет(особенно это касается действительно "умного" дома, где мы не просто лампочки и розетки с какой-то фигней щелкаем, а управляем дверями/шторами/вратами/бойлерами и много ещё)

ну, а вообще да - самый лучший вариант - отказаться от вифи для умного дома, и по возможности, использовать провод

если нельзя использовать провод, то есть хорошие беспроводные модули помимо вайфай, но по сравнению с тем-же сяоми они стоят гораздо дороже

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

процесс авторизации у каждого оборудования происходит с разной скоростью, телефоны это делают относительно быстро, а таки устройства как сяоми лампы, есп и т.п. немного дольше(это, естественно, зависит не только от конечного оборудования, от роутера/точек доступа/повторителей тоже)

 

в остальном полностью согласен

 

но мы, кажеться, немного о разных вещах говорим - я говорю о том, что даже если покупать сяоми устройства, что действительно достаточно дешево, лучше не использовать ихнее облако, а поднимать свой сервер, который будет жить в локальной сети, и максимально ограничить доступ с него в интернет(особенно это касается действительно "умного" дома, где мы не просто лампочки и розетки с какой-то фигней щелкаем, а управляем дверями/шторами/вратами/бойлерами и много ещё)

 

ну, а вообще да - самый лучший вариант - отказаться от вифи для умного дома, и по возможности, использовать провод

если нельзя использовать провод, то есть хорошие беспроводные модули помимо вайфай, но по сравнению с тем-же сяоми они стоят гораздо дороже

1. local.com.ua: Кажется около 2000грн. Это не самая большая проблема.

2. Как вы себе представляете бесшовный роуминг имени WiFi ? Это ведь не GSM, в котором терминал защелкивает 5 БСок, и теоретически может переключаться между ними, без разрыва связи. Есть набор подчастот (канал в терминах WiFi), есть возможность перенегошиэйтить канал, есть b/g/n, есть уровень сигнала, устройства каждые ~100ms отправляют beacons, ... Переключение с одной точки доступа к другой, полюбэ потянет за собой повторную авторизацию. Это в общем больше от клиента зависит.

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

Что касается самого WiFi, мне кажется вы как-то его "не так" рассматриваете. Это такой себе транспортный протокол (на самом деле набор 10+ стандартов), который достаточно хорошо описан и стандартизирован, и в который можно инкапсулировать IP, который в общем то тоже описан до мелочей.

В любом случае, WiFi никак не участвует в цепочке "от провайдера до шлюза", и никак не влияет на доступность шлюза. IP протокол в общем можно построить поверх любого транспортного,- хоть например через LORA, несмотря на 300 бод скорость. Не суть.

1. local.com.ua: Кажется около 2000грн. Это не самая большая проблема.

2. Как вы себе представляете бесшовный роуминг имени WiFi ? Это ведь не GSM, в котором терминал защелкивает 5 БСок, и теоретически может переключаться между ними, без разрыва связи. Есть набор подчастот (канал в терминах WiFi), есть возможность перенегошиэйтить канал, есть b/g/n, есть уровень сигнала, устройства каждые ~100ms отправляют beacons, ... Переключение с одной точки доступа к другой, полюбэ потянет за собой повторную авторизацию. Это в общем больше от клиента зависит.

 

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

 

Что касается самого WiFi, мне кажется вы как-то его "не так" рассматриваете. Это такой себе транспортный протокол (на самом деле набор 10+ стандартов), который достаточно хорошо описан и стандартизирован, и в который можно инкапсулировать IP, который в общем то тоже описан до мелочей.

В любом случае, WiFi никак не участвует в цепочке "от провайдера до шлюза", и никак не влияет на доступность шлюза. IP протокол в общем можно построить поверх любого транспортного,- хоть например через LORA, несмотря на 300 бод скорость. Не суть.

так, а при чем тут шлюз? я говорю о работе устройства внутри локальной сети

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

как раз таки при безшовном роуминге авторизация и dhcp запросы каждый раз не происходят, более того переключаться клиенту между точками или нет - решает контроллер точек доступа, а не клиент. в бесшовном роуминге при обычном пинге вы не увидите потерь пакетов(ну или 1ин пакет потеряется),

а вот как раз каналы не обязаны совпадать(в пределах разумного: тоесть очень не желательно, чтоб на одних точках были разрешены каналы выше 11, а не других нет, иначе может выйти ситуация, что оборудование которое не работает на данных каналах будет периодечиски выпадать), так-же очень желательно, чтоб на всех точках доступа были включены одинаковые протоколы(опять-же, чтоб устройство не попало на точку в которой включен только протокол который не поддерживается данным устройство)

как-то так

так, а при чем тут шлюз? я говорю о работе устройства внутри локальной сети

 

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

 

как раз таки при безшовном роуминге авторизация и dhcp запросы каждый раз не происходят, более того переключаться клиенту между точками или нет - решает контроллер точек доступа, а не клиент. в бесшовном роуминге при обычном пинге вы не увидите потерь пакетов(ну или 1ин пакет потеряется),

а вот как раз каналы не обязаны совпадать(в пределах разумного: тоесть очень не желательно, чтоб на одних точках были разрешены каналы выше 11, а не других нет, иначе может выйти ситуация, что оборудование которое не работает на данных каналах будет периодечиски выпадать), так-же очень желательно, чтоб на всех точках доступа были включены одинаковые протоколы(опять-же, чтоб устройство не попало на точку в которой включен только протокол который не поддерживается данным устройство)

 

как-то так

dhcp это отдельный вопрос. Обращаться будет полюбэ, и получит новый (или тот-же) адрес по окончанию lease time.

dhcp кстати broadcasts шлет вне зависимости от того, хочет этого клиент или нет.

ping - это другой тип запроса: icmp (en.wikipedia.org/wiki/Ping_(networking_utility). Кажется type 13. Его можно использовать как индикатор, но отнюдь не как критерий прошли пакеты или нет.

Что касается бесшовного роуминга, то на самом деле можно использовать обычные точки доступа, подключенные к специальному коммутатору. Например такое решение: local.com.ua/forum/topic/69151-%D0%BF%D1%80%D0%BE%D0%B4%D0%B0%D0%BC-%D1%82%D0%BE%D1%87%D0%BA%D1%83-%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B0-motorola-ap650-dual-ext-mesh-%D0%B1%D0%B5%D1%81%D1%88%D0%BE%D0%B2%D0%BD%D1%8B%D0%B9-%D1%80%D0%BE%D1%83%D0%BC%D0%B8%D0%BD%D0%B3/?tab=comments#comment-715088

Скорость соединения (а именно авторизации, например WPA2), зависит от TX/RX кристалла, и расстоянием до WiFi access point. dhcp - это уже другой протокольный уровень.

При этом абсолютно пофиг будет это одна точка доступа или несколько. Главное выбрать ту, которая принимается лучше. Это все можно определить еще на этапе connectа, т.к. access point передает все эти параметры в широковещательных пакетах (не IP) .

WiFi client может "на ходу" передоговариваться об использовании той или иной полосы частот (каналов). В разных странах, часть каналов может быть запрещена для использования, например от 13 и выше. Иногда есть еще ограничения на TX access point. Как правило из интерфейса не конфигурится (то, что не разрешено), но через cli (если есть) - с легкостью.

Все это можно увидеть своими глазами, установив на компьютере соотв. утилиту, например WireShark, и поставить нужный фильтр.

Это то, что касается уровня протокола, не транспорта (ARP запросы увидите).

Если хочется посмотреть "в живую" на детали обмена протоколом на уровне транспорта WiFi, то можно использовать например ESP8266, или ESP32. Это из доступных и дешевых. В качестве мониторилки пакетов WiFi.

Основная проблема,- это если оконечное устройство упрямо пытается "вцепиться" в access point, к которому оно было подключено раньше, вне зависимости от качества сигнала, и наличия других точек доступа, которые принимаются лучше. Это вопрос к firmware устройства.

dhcp это отдельный вопрос. Обращаться будет полюбэ,

нет, в бесшовном роуменге при переходе с точки на точку запроса нету(можете посмотреть тем-же WireShark/tcpdump)

и получит новый (или тот-же) адрес по окончанию lease time.

dhcp кстати broadcasts шлет вне зависимости от того, хочет этого клиент или нет.

это всё понятно

но при, чем в данном случае lease time? Мы говорим про переход от точке к точке в случае бесшовного роуминга

ping - это другой тип запроса: icmp (en.wikipedia.org/wiki/Ping_(networking_utility). Кажется type 13. Его можно использовать как индикатор, но отнюдь не как критерий прошли пакеты или нет.

+\-

но опять-же — в данном случае с помощью пинга вы можете наглядно увидеть потери при роуминге и обычном переходе от точке к точке

Что касается бесшовного роуминга, то на самом деле можно использовать обычные точки доступа, подключенные к специальному коммутатору. Например такое решение: local.com.ua/forum/topic/69151-%D0%BF%D1%80%D0%BE%D0%B4%D0%B0%D0%BC-%D1%82%D0%BE%D1%87%D0%BA%D1%83-%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B0-motorola-ap650-dual-ext-mesh-%D0%B1%D0%B5%D1%81%D1%88%D0%BE%D0%B2%D0%BD%D1%8B%D0%B9-%D1%80%D0%BE%D1%83%D0%BC%D0%B8%D0%BD%D0%B3/?tab=comments#comment-715088

вам не кажеться, что это не «обычная»\ не совсем домашняя точка доступа(в понимании рядового пользователя)?

В характеристиках данной точки написано, что она умеет роуминг

специльным комутатором(выше я называл его контроллером) — выступает отдельная железяка(Ruckus\UniFi\Motorola)\сервер(как, например, возможно у UniFi)\ одна из точек этой же конторы(точно знаю умеют некоторые модели Ruckus)

конкретную модель моторолы не изучал, но судя по тому, что ниже спрашивали есть ли простенький контроллер, то эта работает через него(он тоже денег стоит — я не смотрел сколько)

(на саму точку доступа цена очень вкусная(особенно ни ибее)) ), даже без использования роуминга. не знал, что есть такие цены на подобные железяки)

Скорость соединения (а именно авторизации, например WPA2), зависит от TX/RX кристалла, и расстоянием до WiFi access point. dhcp - это уже другой протокольный уровень.

изначально шел разговор о подключении не до момента — ой, а я с вайфаем, а до момента — работает сеть

опять-же в случае с домашней сетью большинство настраивается с помощью dhcp

поэтому dhcp в данном контексте разговора влияет на скорость соединения(если вам угодно — читайте подключения)

зависимостей к скорости соединения больше, в том числе и со стороны клиента(шифрование\ширина канала\кол-во других точек рядом)

Скорость соединения (а именно авторизации, например WPA2), зависит от TX/RX кристалла, и расстоянием до WiFi access point. dhcp - это уже другой протокольный уровень.

При этом абсолютно пофиг будет это одна точка доступа или несколько. Главное выбрать ту, которая принимается лучше. Это все можно определить еще на этапе connectа, т.к. access point передает все эти параметры в широковещательных пакетах (не IP) .

при первом подключении — всё абсолютно верно, при переключении от точки к точке — нет(в том числе по вами же озвученой причине о глюках железяки)

ну и вайфай это только широковещательные пакеты, устройство само забирает назначеные ему пакеты с ефира

WiFi client может "на ходу" передоговариваться об использовании той или иной полосы частот (каналов). В разных странах, часть каналов может быть запрещена для использования, например от 13 и выше. Иногда есть еще ограничения на TX access point. Как правило из интерфейса не конфигурится (то, что не разрешено), но через cli (если есть) - с легкостью.

абсолютно верно

Все это можно увидеть своими глазами, установив на компьютере соотв. утилиту, например WireShark, и поставить нужный фильтр.

Это то, что касается уровня протокола, не транспорта (ARP запросы увидите).

видел

Если хочется посмотреть "в живую" на детали обмена протоколом на уровне транспорта WiFi, то можно использовать например ESP8266, или ESP32. Это из доступных и дешевых. В качестве мониторилки пакетов WiFi.

 

 

Основная проблема,- это если оконечное устройство упрямо пытается "вцепиться" в access point, к которому оно было подключено раньше, вне зависимости от качества сигнала, и наличия других точек доступа, которые принимаются лучше. Это вопрос к firmware устройства.

бесшовный роуминг решает последнюю проблему

пы.сы.: вам не кажеться, что мы ушли от темы?)

...

пы.сы.: вам не кажеться, что мы ушли от темы?)

Таки да. Подскажите пожалуйста

1. Ссылку на ali на лампочку имени Xiaomi

2. Она цветная/диммируемая ?

Я подозреваю что внутри таки 8266, а значит можно перезалить свою прошивку.

Даже если что-либо другое, думаю можно будет побороть.

Самое ценное в этой лампочке - это корпус. Этого я, к сожалению, повторить не смогу.

Все остальное проблем не представляет. Мой концепт - отсутствие централизованного сервера.

От слова совсем. Только тонкий клиент (browser).

Если заморачиваться с мобильным клиентом, то его придется сопровождать. Лениво.

Таки да. Подскажите пожалуйста

 

1. Ссылку на ali на лампочку имени Xiaomi

2. Она цветная/диммируемая ?

 

Я подозреваю что внутри таки 8266, а значит можно перезалить свою прошивку.

Даже если что-либо другое, думаю можно будет побороть.

 

Самое ценное в этой лампочке - это корпус. Этого я, к сожалению, повторить не смогу.

 

Все остальное проблем не представляет. Мой концепт - отсутствие централизованного сервера.

От слова совсем. Только тонкий клиент (browser).

 

Если заморачиваться с мобильным клиентом, то его придется сопровождать. Лениво.

ru.aliexpress.com/item/XiaoMi-Colorful-APP-WIFI-Remote-Control-Smart-LED-Light-RGB-Colorful-temperature-Romantic-lamp-Yeelight-XiaoMi/32676143973.html?spm=a2g0v.search0104.3.10.62225bc8AdW9yu&ws_ab_test=searchweb0_0,searchweb201602_1_10065_5736111_10068_5736011_319_10059_10884_317_10887_10696_100031_321_322_10084_453_454_10083_10103_10618_431_10307_537_536,searchweb201603_50,ppcSwitch_0&algo_expid=d6e41ba6-fbe8-4624-93e7-fa9ccb792abe-1&algo_pvid=d6e41ba6-fbe8-4624-93e7-fa9ccb792abe&transAbTest=ae803_3

цветная у меня такая, да - она диммерная

мне на 13 кв комнату 1ой такой, и просто белой хватает с головой

большинство времени они у меня включены на 25%

в коридоре, наверное, около 15кв. вполне хватает просто белой сяомовской лампы

есть сомнения, что там 8266, но всё может быть )

если вам нужен корпус, то я думаю на али можно и корпуса попробовать поискать))

Мой концепт - отсутствие централизованного сервера.

От слова совсем. Только тонкий клиент (browser).

вы просто не хотите, что на этот сервер может попасть злоумышленник и всё поломать?

или, что если выйдет одна железяка из строя, то всё сломается?

я бы не отказывался всё таки от сервера, это очень удобно. другое дело, что можно сделать(например 1ин в 1но помещение) модуль который может работать автономно, когда сервер не доступен по какой-либо причине он всем управляет, а когда доступен, то настраиваться с сервера, графики рисовать на сервере

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

По такой цене - другого там просто быть не может, но кажется меня уже кто-то опередил:

github.com/fvollmer/open-desk-lamp-firmware

Еще фокус не наводил, но в общем проблем не вижу.

Что касается сервера,- то нужна логика обмена, протокол. tcp connections в общем удовольствие недешевое для realtime system.

В плане времянок.

По такой цене - другого там просто быть не может, но кажется меня уже кто-то опередил:

 

github.com/fvollmer/open-desk-lamp-firmware

 

Еще фокус не наводил, но в общем проблем не вижу.

 

Что касается сервера,- то нужна логика обмена, протокол. tcp connections в общем удовольствие недешевое для realtime system.

В плане времянок.

пока не вникал в автономность, но всё уже придумано за нас))

MQTT можно попробовать использовать

самое простое, на мой взгляд(именно простое, не бросайте тапками;) ), это по хттп/хттпс обмениматься post и get запросами

пример:

датчик температуры меряет температуру, пока ничего не меняется он с сервером не связывается, температура поменялась на больше, чем н"градусов он включил/выключил, что либо, и отправил запрос на сервер, что он что-то сделал и, что температура изменилась (естественно нужно ещё добавлять проверки)

+ сервер сам ещё может опрашивать модули о их состоянии

вы поменяли на сервере параметры, он отправил запрос на модуль о том, что такие-то параметры нужно изменить

если делать такую систему на вифи, то мне кажеться, что при создании отдельной сети вифи для сервера и модулей она имеет право на существование

но опять-же - я в вопрос не вникал и это только догадки/набросок

Добавлено через 1 час 17 минут

По такой цене - другого там просто быть не может, но кажется меня уже кто-то опередил:

 

github.com/fvollmer/open-desk-lamp-firmware

 

Еще фокус не наводил, но в общем проблем не вижу.

 

Что касается сервера,- то нужна логика обмена, протокол. tcp connections в общем удовольствие недешевое для realtime system.

В плане времянок.

The Xiaomi desk lamp is a modern IoT device, that uses the ESP8266 microcontroller.

ыы, да))))

но это всё-же другая лампа(

Все логично и правильно, но есть нюансы.

Самый главный нюанс, это формализация протокола обмена между устройствами. У оных

сущности в общем-то отличаются. Так, например, в случае диммируемой цветной лампочки,

я думаю имеет смысл передавать RGB + intensity. то есть лампочка должна отдавать

текущие параметры наружу, и принимать команды от других устройств и/или сервера.

Теперь вопрос: А кто должен инициировать обмен информацией, в случае модели клиент/сервер ?

Тут есть 2 варианта:

1. Клиент - который периодически (или по событию) стучится к серверу, отдает статус, и принимает команды

2. Сервер самостоятельно опрашивает/командует клиентами

Для сценария N1, чтобы все работало "гладко", нужно чтобы сервер имел возможность

коннектититься к устройству, и командовать, при наступлении некоего события.

У себя, я организовал сценарий N2. Это позволяет реализовать практически полную автономность,

типа сервер "живой" - командует. "неживой" - устройства работают в автономе, согласно заданным

программам. Сами устройства ессно имеют возможность взаимодействовать друг с другом,

даже при отсутствии WiFi точки доступа, благо ESP8266/ESP32 это позволяют.

Например одно устройство на выключателе света, второе на лампочке, или на любой другой нагрузке.

Пока есть питание, все будет работать безо всяческих проблем. Конфигурить правда придется

каждое устройство отдельно, подключаясь к встроенной точке доступа - это не очень удобно,

но все-таки лучше чем получить DOS как результат внешних, не зависящих от пользователя факторов.

Если уже начинать строить все по правильному - то тогда REST + XML. Это для взаимодействия

между сервером, и устройствами. Ролевой доступ (l/p) обязателен.

Сервер поднять проблема небольшая. Проблема в том, чтобы унифицировать зоопарк возможных

параметров, и правильно построить протоколы обмена, чтобы значит при добавлении нового устрорйства

с неизвестными на данный момент параметрами, не пришлось перешивать уже установленные

контроллеры.

Если "разливать" конфиги устройств с сервера, то обязательно нужно писать некий свой

логический анализатор. На эту швабру я уже наступил уже при 11 устройствах.

Прописал не тот канал на одном из устройств, и вместе со светом на кухне, выключался свет на 3м этаже

Это была знатная прогулка по швабрам, после которой я добавил в интерфейс каждого из

устройств опции, которые позволяют не слать команды другим устройствам или не принимать команды

от других устройств.

С клиентом под мобильный, ситуация аналогичная. Предположим что вы напишите своего клиента,

с красивым интерфейсом под текущую версию Android/IOS. А потом выйдет новая версия,

которая не заработает с вашим клиентом. И ? Фиксим и переписываем ?

А куда собсно должен "стучаться" мобильный клиент ? На оконечное устройство ? На сервер ?

"и туда, и туда" с возможностью выбора ?

В общем-то тоже проблем нет, кроме usability. Через год даже разработчик забудет все эту

хитроизвернутую логику.

А вообще, в принципе, какая стоит задача ? Управлять всем домом из единого графического интерфейса ?

Локально ? Или точечная автоматизация ?

Все логично и правильно, но есть нюансы.

 

Самый главный нюанс, это формализация протокола обмена между устройствами. У оных

сущности в общем-то отличаются. Так, например, в случае диммируемой цветной лампочки,

я думаю имеет смысл передавать RGB + intensity. то есть лампочка должна отдавать

текущие параметры наружу, и принимать команды от других устройств и/или сервера.

 

Теперь вопрос: А кто должен инициировать обмен информацией, в случае модели клиент/сервер ?

Тут есть 2 варианта:

 

1. Клиент - который периодически (или по событию) стучится к серверу, отдает статус, и принимает команды

2. Сервер самостоятельно опрашивает/командует клиентами

 

Для сценария N1, чтобы все работало "гладко", нужно чтобы сервер имел возможность

коннектититься к устройству, и командовать, при наступлении некоего события.

 

У себя, я организовал сценарий N2. Это позволяет реализовать практически полную автономность,

типа сервер "живой" - командует. "неживой" - устройства работают в автономе, согласно заданным

программам. Сами устройства ессно имеют возможность взаимодействовать друг с другом,

даже при отсутствии WiFi точки доступа, благо ESP8266/ESP32 это позволяют.

Например одно устройство на выключателе света, второе на лампочке, или на любой другой нагрузке.

Пока есть питание, все будет работать безо всяческих проблем. Конфигурить правда придется

каждое устройство отдельно, подключаясь к встроенной точке доступа - это не очень удобно,

но все-таки лучше чем получить DOS как результат внешних, не зависящих от пользователя факторов.

 

Если уже начинать строить все по правильному - то тогда REST + XML. Это для взаимодействия

между сервером, и устройствами. Ролевой доступ (l/p) обязателен.

 

Сервер поднять проблема небольшая. Проблема в том, чтобы унифицировать зоопарк возможных

параметров, и правильно построить протоколы обмена, чтобы значит при добавлении нового устрорйства

с неизвестными на данный момент параметрами, не пришлось перешивать уже установленные

контроллеры.

 

Если "разливать" конфиги устройств с сервера, то обязательно нужно писать некий свой

логический анализатор. На эту швабру я уже наступил уже при 11 устройствах.

Прописал не тот канал на одном из устройств, и вместе со светом на кухне, выключался свет на 3м этаже

Это была знатная прогулка по швабрам, после которой я добавил в интерфейс каждого из

устройств опции, которые позволяют не слать команды другим устройствам или не принимать команды

от других устройств.

 

С клиентом под мобильный, ситуация аналогичная. Предположим что вы напишите своего клиента,

с красивым интерфейсом под текущую версию Android/IOS. А потом выйдет новая версия,

которая не заработает с вашим клиентом. И ? Фиксим и переписываем ?

А куда собсно должен "стучаться" мобильный клиент ? На оконечное устройство ? На сервер ?

"и туда, и туда" с возможностью выбора ?

В общем-то тоже проблем нет, кроме usability. Через год даже разработчик забудет все эту

хитроизвернутую логику.

 

А вообще, в принципе, какая стоит задача ? Управлять всем домом из единого графического интерфейса ?

Локально ? Или точечная автоматизация ?

ну так вы описали +/- тоже, что и я написал, только конкретнее)

задача? та на данный момент никакой конкретной нету, я работаю с home assistant, а случай падения основного сервера будет распбери на который сливается полный бекап раз в день. для моих задач, на данный момент, этого хватает более чем. всё висит на вифи

в будущем, скорее всего, буду максимально переходить на провод, или zigbee, или, что-то аналогичное. или буду использовать и то, и то.

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

ну так вы описали +/- тоже, что и я написал, только конкретнее)

 

задача? та на данный момент никакой конкретной нету, я работаю с home assistant, а случай падения основного сервера будет распбери на который сливается полный бекап раз в день. для моих задач, на данный момент, этого хватает более чем. всё висит на вифи

 

в будущем, скорее всего, буду максимально переходить на провод, или zigbee, или, что-то аналогичное. или буду использовать и то, и то.

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

Ок, а как бы вы видели для себя сам процесс управления лампой ?

WEB страница подходит ?

Если есть несколько таких ламп, то какие могут быть сценарии ?

Типа разлить текущие параметры одной лампы по всем остальным ?

Или может какой-то более продвинутый вариант ?

Ок, а как бы вы видели для себя сам процесс управления лампой ?

WEB страница подходит ?

Если есть несколько таких ламп, то какие могут быть сценарии ?

Типа разлить текущие параметры одной лампы по всем остальным ?

Или может какой-то более продвинутый вариант ?

всем рулит home assistant

сейчас для лампы у меня настроен следующий сценарий:

при открытии двери она включается

при движении она включается(в зависимости от времени суток на разную яркость, вот всё собираюсь припилить зависимость не от времени,а от яркости)

если в течении 2ух последних минут не было движения - она выключается

руками включается с планшета который установлен в роли панели управления

стоит переключения ручной/автоматический режим(можно переключить руками, сама переключается в ручной, если включилась не по датчику движения/не по открытию двери)

если за последние пол часа не было движения, а лампа в ручном режиме, то переходит в автоматический

ещё есть хотелка переключать лампу в ручной/автоматический режим голосом (например:home-smart-home.ru/raspberry-pi-pocketsphinx-offlajn-raspoznavanie-rechi-i-upravlenie-golosom/) )))

всем рулит home assistant

 

сейчас для лампы у меня настроен следующий сценарий:

при открытии двери она включается

при движении она включается(в зависимости от времени суток на разную яркость, вот всё собираюсь припилить зависимость не от времени,а от яркости)

если в течении 2ух последних минут не было движения - она выключается

руками включается с планшета который установлен в роли панели управления

стоит переключения ручной/автоматический режим(можно переключить руками, сама переключается в ручной, если включилась не по датчику движения/не по открытию двери)

если за последние пол часа не было движения, а лампа в ручном режиме, то переходит в автоматический

 

 

ещё есть хотелка переключать лампу в ручной/автоматический режим голосом (например:home-smart-home.ru/raspberry-pi-pocketsphinx-offlajn-raspoznavanie-rechi-i-upravlenie-golosom/) )))

Понятно. lafaet - можно я позадаю ''чайниковские" вопросы ?

Технически задача не сложная, но все-таки хочется использовать уже имеющиеся модели управления, а не изобретать велосипед. Насколько я вижу, есть разные frameworks и конструкторы, которые взаимодействуют с конечным устройством путем полноценного 2х стороннего MQQT. То есть понятное дело, что рисовать свой конструктор в пределах каждого из кристаллов - не самая лучшая идея, равно как и пытаться запихнуть в кристалл с RAM ~80kb логику распознавания голоса. Это значит что в каждый из кристаллов нужно добавить поддержку MQQT, в той или иной реализации. Поскольку практического опыта именно с Xiaomi home assistant у меня нет, то мне нужно понимать что требуется от кристалла, что нужно параметризировать в WEB config кристалла, т.е. какие параметры нужно менять, какие отдавать наружу, и в каком виде принимать команды.

Например POST/GET /mqqt/relay1/control ON, параметры цветовой температуры и интенсивности лампы. Судя по всему, вы этот этап уже прошли, и "остановились" на том, что прошивка самого кристалла на лампе, не позволяет реализовать все "хотелки" должным образом.

Понятно. lafaet - можно я позадаю ''чайниковские" вопросы ?

Технически задача не сложная, но все-таки хочется использовать уже имеющиеся модели управления, а не изобретать велосипед. Насколько я вижу, есть разные frameworks и конструкторы, которые взаимодействуют с конечным устройством путем полноценного 2х стороннего MQQT. То есть понятное дело, что рисовать свой конструктор в пределах каждого из кристаллов - не самая лучшая идея, равно как и пытаться запихнуть в кристалл с RAM ~80kb логику распознавания голоса. Это значит что в каждый из кристаллов нужно добавить поддержку MQQT, в той или иной реализации. Поскольку практического опыта именно с Xiaomi home assistant у меня нет, то мне нужно понимать что требуется от кристалла, что нужно параметризировать в WEB config кристалла, т.е. какие параметры нужно менять, какие отдавать наружу, и в каком виде принимать команды.

Например POST/GET /mqqt/relay1/control ON, параметры цветовой температуры и интенсивности лампы. Судя по всему, вы этот этап уже прошли, и "остановились" на том, что прошивка самого кристалла на лампе, не позволяет реализовать все "хотелки" должным образом.

прошивка лампы меня полностью устраивает, меня не устраивает управление "умного" дома с Xiaomi MiHome, я прошивку лампы вообще не трогал(только включил developer mode, чтоб можно было управлять с посторонних приложений) и не собираюсь

я управляю лампой не с приложения Xiaomi, а с движка умного дома Home Assistant, там есть готовые модули для управления некоторыми устройствами Xiaomi:

www.home-assistant.io/components/#search/Xiaomi

www.home-assistant.io/components/#search/yeewww.home-assistant.io/components/camera.yi/

и очень много других модулей:

www.home-assistant.io/components/#all

прошивка лампы меня полностью устраивает, меня не устраивает управление "умного" дома с Xiaomi MiHome, я прошивку лампы вообще не трогал(только включил developer mode, чтоб можно было управлять с посторонних приложений) и не собираюсь

я управляю лампой не с приложения Xiaomi, а с движка умного дома Home Assistant, там есть готовые модули для управления некоторыми устройствами Xiaomi:

www.home-assistant.io/components/#search/Xiaomi

www.home-assistant.io/components/#search/yeewww.home-assistant.io/components/camera.yi/

 

 

и очень много других модулей:

www.home-assistant.io/components/#all

Пока видится интеграция путем MQTT. plain text/password, т.е. Home Assistant должен жить в локальной сети, ну или через какой-нибудь брокер.