lafaet
-
Публікації
44 -
Зареєстрований
-
Відвідування
Тип публікації
Профілі
Форум
Календар
Повідомлення, опубліковані користувачем lafaet
-
-
Поапдейтилcя MI home (android). Теперь при выборе WiFi extender, пишет "Shortcuts aren't supported on this device". Раньше просто показывал уровень сигнала. Сейчас показывает ничего. Я выбрал европейский сервер, с китайским неудобно.
В принципе не фатально, мне это устройство нужно именно в качестве WiFi extender, и устанавливал я MI home только для того, чтобы поднять устройство.
Надо бы как-то промониторить куда стучится этот зверек, и перерезать шлангочку путем firewall rules. Remote control server + закрытая архитектура - это похоже таки зло.
с таким не сталкивался,
только, что нашел следующее(как использовать датчики сяоми, без сяоми вообще):
sprut.ai/client/article/290
ru.aliexpress.com/af/zigbee-usb.html?SearchText=zigbee+usb&d=y&initiative_id=SB_20190301031732&origin=n&catId=0&isViewCP=y&jump=afs
интересная идея...может даже воспользуюсь
-
А вы уверены что тема всё еще об " Умный дом на базе Xiaomi MiHome?"
У меня впечатление что на ESP ни Orange PI3 к этому не имеют отношения.
Может стоит разделить ветку?
здравствуйте, вероятно да
а, где посмотреть, кто модератор раздела? что-то с ходу не нахожу (
За этим самым HA еще тянется неслабый шлейф приблуд, без которых оный не заработает. В принципе понятно python/Java разработчик стоит несравненно дешевле плюсовика, но побочный
эффект в том, что это получается не standalone приложение с библиотеками и файлами ресурсов, а целый зверинец инструментария/runtime.
в случае разворачивания с докер образа, вы на этот зверинец вообще можете не обращать внимания(при использовании докера будет не большая проблема в поднятии в lxc контейнере, но это изврат...на который мне пришлось пойти)
Frameworkа для разработки на самой платформе не нашел (или еще не разобрался), но gcc есть, так что проблем допилить что-либо не вижу.
вы сейчас в ХА или о ОПИ3?
Портов на плате - тьма тьмущая, есть USB3 HUB, наверное
все-таки такая плата больше бы подошла для какого-нибудь AV center, но у меня на нее немного другие планы.
Хотелось бы в дополнение к HA, нарисовать некое middleware, которое поможет мне выводить информацию с моих камер наблюдения на TV (HDMI).
в хассио, вроде, был отдельный модуль для камер
Присматриваюсь к Node Red, но пока что-то у меня туго с пониманием как эта штука заводится и
управляется.
мне не зашло, мне проще самому писать алгоритм, чем там рисовать
пы.сы.: наконецто добрался до форума
-
Образ и setup не проблема, спасибо. Я думаю что CentOS туда запихнуть смогу. Для собственного комфорта.
В общем конечно все равно - главное версия ядра, и инструментарий.
Может подскажете,- в какой dev среде это чудо кодится ?
gcc + makefile на самой платформе ?
Или Keil а потом шить образ ?
Цена ессно гораздо меньше.
С такими ресурсами, я смогу все свои камеры застримить на TV (HDMI). Ну и докинуть все то, что я не смог реализовать на ESP разных видов и мастей, помимо Home Assistant.
Что-то мне подсказывает, что рано или поздно моя alarm system на ESP32 тоже переедет на эту же платформу.
Закажу,- где-то через месяц создам новую ветку "малинка" и как ее усетапить.
кодить в каком смысле?
настраивать сам ХА? или устанавливать сам ХА?
-
Про интеграцию ламп. Если я правильно понял, то они не поддерживают MQTT.
Навел резкость на Raspberry Pi 3. Если заморачиваться с Home Assistant - думаю самое оно.
Под Windows эта конструкция заводится очень грустно, да и нет смысла держать включенной постоянно большую машину.
если делать Home Assistant и сяомовские лампы, то вообще ничем можно не заморачиваться. ставите ХА, включаете в лампах режим разработчика, перезагружаете ХА и он сам найдет лампы)
ну или руками прописать их в конфигах ХА(прописуется имя и адрес, больше ничего) потом с веб интерфейса управляете лампами
(www.home-assistant.io/components/light.yeelight/ - настройка ламп )
да, для ХА распберри более, чем хватит
я советую ставить hassio он распостраняется в образе dockera( + в нём уже установлены некоторые плагины) - при работе на малине минимум рукодвижений при установке
www.home-assistant.io/docs/installation/docker/
хм, оказывается есть даже готовый образ для флешки:
-
1
-
-
Пока видится интеграция путем MQTT. plain text/password, т.е. Home Assistant должен жить в локальной сети, ну или через какой-нибудь брокер.
я, видимо, не правильно понял о чем вы
вы про интеграцию ламп сяоми, или про самодельные модули умного дома?
-
Понятно. 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/
и очень много других модулей:
-
1
-
-
Ок, а как бы вы видели для себя сам процесс управления лампой ?
WEB страница подходит ?
Если есть несколько таких ламп, то какие могут быть сценарии ?
Типа разлить текущие параметры одной лампы по всем остальным ?
Или может какой-то более продвинутый вариант ?
всем рулит home assistant
сейчас для лампы у меня настроен следующий сценарий:
при открытии двери она включается
при движении она включается(в зависимости от времени суток на разную яркость, вот всё собираюсь припилить зависимость не от времени,а от яркости)
если в течении 2ух последних минут не было движения - она выключается
руками включается с планшета который установлен в роли панели управления
стоит переключения ручной/автоматический режим(можно переключить руками, сама переключается в ручной, если включилась не по датчику движения/не по открытию двери)
если за последние пол часа не было движения, а лампа в ручном режиме, то переходит в автоматический
ещё есть хотелка переключать лампу в ручной/автоматический режим голосом (например:home-smart-home.ru/raspberry-pi-pocketsphinx-offlajn-raspoznavanie-rechi-i-upravlenie-golosom/) )))
-
Все логично и правильно, но есть нюансы.
Самый главный нюанс, это формализация протокола обмена между устройствами. У оных
сущности в общем-то отличаются. Так, например, в случае диммируемой цветной лампочки,
я думаю имеет смысл передавать RGB + intensity. то есть лампочка должна отдавать
текущие параметры наружу, и принимать команды от других устройств и/или сервера.
Теперь вопрос: А кто должен инициировать обмен информацией, в случае модели клиент/сервер ?
Тут есть 2 варианта:
1. Клиент - который периодически (или по событию) стучится к серверу, отдает статус, и принимает команды
2. Сервер самостоятельно опрашивает/командует клиентами
Для сценария N1, чтобы все работало "гладко", нужно чтобы сервер имел возможность
коннектититься к устройству, и командовать, при наступлении некоего события.
У себя, я организовал сценарий N2. Это позволяет реализовать практически полную автономность,
типа сервер "живой" - командует. "неживой" - устройства работают в автономе, согласно заданным
программам. Сами устройства ессно имеют возможность взаимодействовать друг с другом,
даже при отсутствии WiFi точки доступа, благо ESP8266/ESP32 это позволяют.
Например одно устройство на выключателе света, второе на лампочке, или на любой другой нагрузке.
Пока есть питание, все будет работать безо всяческих проблем. Конфигурить правда придется
каждое устройство отдельно, подключаясь к встроенной точке доступа - это не очень удобно,
но все-таки лучше чем получить DOS как результат внешних, не зависящих от пользователя факторов.
Если уже начинать строить все по правильному - то тогда REST + XML. Это для взаимодействия
между сервером, и устройствами. Ролевой доступ (l/p) обязателен.
Сервер поднять проблема небольшая. Проблема в том, чтобы унифицировать зоопарк возможных
параметров, и правильно построить протоколы обмена, чтобы значит при добавлении нового устрорйства
с неизвестными на данный момент параметрами, не пришлось перешивать уже установленные
контроллеры.
Если "разливать" конфиги устройств с сервера, то обязательно нужно писать некий свой
логический анализатор. На эту швабру я уже наступил уже при 11 устройствах.
Прописал не тот канал на одном из устройств, и вместе со светом на кухне, выключался свет на 3м этаже
Это была знатная прогулка по швабрам, после которой я добавил в интерфейс каждого из
устройств опции, которые позволяют не слать команды другим устройствам или не принимать команды
от других устройств.
С клиентом под мобильный, ситуация аналогичная. Предположим что вы напишите своего клиента,
с красивым интерфейсом под текущую версию Android/IOS. А потом выйдет новая версия,
которая не заработает с вашим клиентом. И ? Фиксим и переписываем ?
А куда собсно должен "стучаться" мобильный клиент ? На оконечное устройство ? На сервер ?
"и туда, и туда" с возможностью выбора ?
В общем-то тоже проблем нет, кроме usability. Через год даже разработчик забудет все эту
хитроизвернутую логику.
А вообще, в принципе, какая стоит задача ? Управлять всем домом из единого графического интерфейса ?
Локально ? Или точечная автоматизация ?
ну так вы описали +/- тоже, что и я написал, только конкретнее)
задача? та на данный момент никакой конкретной нету, я работаю с home assistant, а случай падения основного сервера будет распбери на который сливается полный бекап раз в день. для моих задач, на данный момент, этого хватает более чем. всё висит на вифи
в будущем, скорее всего, буду максимально переходить на провод, или zigbee, или, что-то аналогичное. или буду использовать и то, и то.
типа - в котельню провод, т.к. более критическое оборудования, комнаты - вифи(температура/влажность), провод - движение и свет.
-
1
-
-
По такой цене - другого там просто быть не может, но кажется меня уже кто-то опередил:
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.
ыы, да))))
но это всё-же другая лампа(
-
Наскільки я розумію, радіатори повинні бути довжиною за стіну біля вікна, а може і ще більше, це можна порахувати. Я не розумію чому так мало людей мотають на другому поверсі теплу підлогу? Чи може тому, що другий поверх зазвичай покритий ламінатом, або тому, що двоспальне ліжко займає багато місця у спальні? Чому у Вас у спальні не намотана тепла підлога?
Доброго дня, можливо справа ще в тому, що люди бояться, що тепла водяна підлога може потекти. і якщо вона потече на першому поверсі, то проблем значно менше, ніж якщо вона потече на другому поверсі.
та ж причина, чому не ставлять теплі(саме водяні) поли в квартирах
-
Таки да. Подскажите пожалуйста
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но помещение) модуль который может работать автономно, когда сервер не доступен по какой-либо причине он всем управляет, а когда доступен, то настраиваться с сервера, графики рисовать на сервере
кстати, по большому счету, в случае автономных модулей в помещениях можно использовать и вифи. уже таких жестких требований к качеству сигнала не будет
-
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
-
-
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, а не других нет, иначе может выйти ситуация, что оборудование которое не работает на данных каналах будет периодечиски выпадать), так-же очень желательно, чтоб на всех точках доступа были включены одинаковые протоколы(опять-же, чтоб устройство не попало на точку в которой включен только протокол который не поддерживается данным устройство)
как-то так
-
1
-
-
У проблемы есть 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 стоит денег, поэтому вендоры, которые поддерживают работоспособность шлюзов, оплачивают затраты на электроэнергию, зарплату обслуживающему персоналу, ... пытаются монетизировать сервис, предоставляя какой-либо минимальный набор услуг (бесплатный), с возможностью платного расширения. Эксплуатационные расходы то есть.
Есть конечно вариант поднять локальный сервер, но это требует времени, квалификации, и по прежнему стоит денег - например за электроэнергию, которую потребит этот самый сервер.
с первым не всё так гладко, чтоб сделать бесшовный роуминг не достаточно, просто сделать одинаковый ссид - одинаковый ссид и пароль на точках доступах дает только, то что не нужно вводить пароль, но при этом процесс авторизации пользователя в сети остается такой-же(проверка пароля, запрос к роутеру за ип, выдача данного ип), для бесшовного роуминга нужен контроллер который отслеживает состояние устройств и помогает перекидывать клиентов, это не дешевая игрушка и дома она не нужна.
процесс авторизации у каждого оборудования происходит с разной скоростью, телефоны это делают относительно быстро, а таки устройства как сяоми лампы, есп и т.п. немного дольше(это, естественно, зависит не только от конечного оборудования, от роутера/точек доступа/повторителей тоже)
в остальном полностью согласен
но мы, кажеться, немного о разных вещах говорим - я говорю о том, что даже если покупать сяоми устройства, что действительно достаточно дешево, лучше не использовать ихнее облако, а поднимать свой сервер, который будет жить в локальной сети, и максимально ограничить доступ с него в интернет(особенно это касается действительно "умного" дома, где мы не просто лампочки и розетки с какой-то фигней щелкаем, а управляем дверями/шторами/вратами/бойлерами и много ещё)
ну, а вообще да - самый лучший вариант - отказаться от вифи для умного дома, и по возможности, использовать провод
если нельзя использовать провод, то есть хорошие беспроводные модули помимо вайфай, но по сравнению с тем-же сяоми они стоят гораздо дороже
-
Как чудесно,- контроль оборудования, которое в случае например частного дома находится в пределах максимум 6 - 10 соток, через сервер, который находится на другом континенте...
в случае с сяоми это не совсем так, но очень близко
с того, что я вычитал - когда настраиваешь, что-то с телефона - сначала телефон заливает настройки в китай - потом на туже лампу
если нужно при включении одной лампы - включить другую - через китай
если нужно включить лампу с телефона - по сути тоже через китай
шлюз с лампами работает на прямую. но после того как прешел на домотикз/ха всё равно стало гораздо меньше задержек, чем при контроле через шлюз. хотя кол-во работы, теоретически, выросло - датчик увидел движение - отправил шлюзу сигнал - шлюз отправил в домотикз/ха(или скорее сервер считал со шлюза), а они в свою очередь отправляют дальше(например той же лампе)
вообще - если делать умный дом с элементами по вифи, то тут есть 3и варианта:
1 - грамотно настроить вайфай(или настраивать бесшовный роуминг, или ставить 1 мощную точку доступа)
2 - грамотно настроить оборудование для подключения с вифи(лампы сяомовские, например, не настроить, там можно вбить только SSID и pass)
3 - не использовать оборудование на вайфай
проблема вифи может быть в следующем(у меня была ситуация с той же
лампой):
лампочка находится в коридоре, как раз посередине между повторителем и роутером, и время от времени она начала перепрыгивать с одной точки на другую, это происходило раз в минуту, иногда чаще, иногда реже(с чем связано - я так и не разобрался), на переключение с точки на точку у неё уходит какое-то кол-во времени, естественно она в этот момент команды сервера не принимает
-
И как ваш опыт с сяоми? Дополнили еще какими-то гаджетами? Или разочаровались?
Я очень люблю сяоми и постепенно дом наполняется этой техникой, в планах датчик газа и дыма, но пока изучаю вопрос.
я себе позаказывал немного сяомовских приблуд(датчики движения, температура, влажность, лампочки, розетки, удлиннители)
могу сказать, что если использовать всё, через сяоми, то оно подглючивает, и если сначала ты на это не обращаешь внимания, то потом это надоедает(приходится ждать по пару секунд пока включится свет, например). это скорее всего связано с тем, что так или иначе, но у MiHome используется китайкое облако, которое иногда глючит
после использования пары дней сценариев через MiHome поставил на raspberrypi domoticz(www.domoticz.com/), настроил его. работает гораздо лучше + можно использовать далеко не только сяоми(но не всё от сяоми работает)
пару месяцев назад попробовал HomeAssistant(www.home-assistant.io) понравилось больше, чем домотикз. теперь, когда есть немного времени/желания по немногу переезжаю туда
проблема, что домотикза, что ha - нужно хоть немного дружить с английским
и уметь уложить в голове четкий алгоритм работы системы
-
1
-
-
Все города, села и поселки ещё в 2013 году обязали актуализировать старые генпланы и по ним выдавать стройпаспорта частным застройщикам. Мне тоже дали отказ, написал жалобу в Минрегионбуд, там мне ответили в каком году и даже на какой сессии был актуализирован старый генплан моего города. Пошел с этим ответом к местному архитектору, та включила мороз, что не знала об этом и выдала стройпаспорт.
хмм, спасибо за совет, попробую так сделать
-
Здравствуйте, в прошлом году был куплен участок(для строительства частного дома) и были поданы документы на получения строительного паспорта, в архитектуре строй. паспорт не выдали по причине отсутствия ген. плана поселка(с.Креничи, Обуховский район), есть от них бумажка с отказом. Ходил в архитектуру, там сказали, что с моими документами(то, что я начертил по намерениям застройки) всё в порядке, но без ген плана они не могут выдать строй паспорт т.к. не могут проверить соответствует ли то, что я нарисовал градостроительной документации. Ген. плана действительно нету, сейчас разрабатывают, но сколько это ещё займет времени - никто сказать не может.
Есть ли шанс решить этот вопрос через суд?
Если да, то можете ли вы занятся подобным и сколько это будет стоить?
Спасибо за внимание
Хорошего вам дня
Расстояние между домами (хозпостройками) (противопожарные разрывы, ДБН)
в Юридична консультація. Земельне та будівельне право. Норми і правила.
Опубліковано:
Здравствуйте, подскажите, пожалуйста, читая информацию о разрывах наткнулся на следующее:
Означает ли это, что я в документах на стройпаспорт между "гостевым" домом и жилым домом могу указать расстояние 2см?(нужно для того, чтоб когда построится жилой дом объеденить его с жилым)
общий смысл в чем: постороить "гостевой дом", переехать в него, потом построить дом и объеденить их в одно сооружение, а часть гостевого превратить в гараж
Спасибо за внимание
Хорошего дня