Comments 56
Вот такая штука есть в доме?
Срочно на Кикстартер!
Спасибо :-)
Сарказм оценил!
Да, это из раздела «сделай сам»
Сарказм оценил!
Да, это из раздела «сделай сам»
А если серьезно, то все, что в доме включается и выключается через bluetooth/интернет, должно по прежнему удобно включаться и выключаться обычными выключателями, просто рукой, без смартфонов и ноутбуков. И мозг «умного» дома должен уметь это обрабатывать и понимать текущее состояние. У вас с этим как, реализовано? А то пойдешь, извините, в туалет без смартфона, а смыв только через браузер работает… А если временно свет в доме выключили — вообще катастрофа…
Абсолютно согласен. Некоторые виртуальные элементы управления должны быть продублированы физическими. А физические могут опять же как отправлять команды на сервер, так и напрямую на устройство. Как я упомянул в статье я только собираюсь сделать такое дублирование.
Однако, эта технология позволяет создать нестандартные элементы управления.
Например — кубик размером с кружку. Положил на одну грань — включился свет, на другую — выключился. Повернул по часовой стрелке — ярче, обратно — тусклее. Внутри гироскоп (датчик наклона) и ESP01 с батарейкой.
Однако, эта технология позволяет создать нестандартные элементы управления.
Например — кубик размером с кружку. Положил на одну грань — включился свет, на другую — выключился. Повернул по часовой стрелке — ярче, обратно — тусклее. Внутри гироскоп (датчик наклона) и ESP01 с батарейкой.
Спасибо за статью. Лично мне не хватает знаний чтобы такое решение сделать. Выходит все слишком примитивно. Подскажите какую разметку делали на флешке?
C esp8266 гораздо удобнее общаться с помощью спец. протоколов, например MQTT или CoAP. Посмотрите например мой код.
У меня нет опыта чтобы сравнить удобство общения. PHP и JScript знакомы всем школьникам. И это работает
Ничего не мешает общаться через MQTT или CoAP на PHP и JS, тем более, что на стороне MCU lua.
Сейчас я использую простые GET запросы с ответами в формате json. Возможно мне стоит изучить преимущества этих протоколов. Чем упростит/улучшит обмен их использование?
Чтобы мониторить сигнал типа выключателя света, вам нужно будет использовать поллинг и посылать ваши GET запросы чаще, чем раз в 100мс, иначе задержка будет некомфортна для пользователя. Также эти запросы будут нагружать сеть, если у вас будет несколько десятков различных устройста. MQTT решает эту проблему, так как там поллинг не нужен — брокер сам рассылает сообщения всем подключившимся. В моем УД в результате задержка вообще не заметна…
Про какую систему Вы пишете? В моей системе поллинг еще изобретен не был.
Выключатель является датчиком. Датчики сами отправляют запросы на сервер, он передает его на исполняемое устройство (реле). Задержки в этом случае нет.
Я нажимаю на кнопку — get запрос через сервер (/control.php?slave=290&do=1) идет на wifi модуль с реле. Если планшет не тормозной задержки абсолютно не заметно. Обратно от модуля с реле возвращается ответ и отображается на состоянии кнопки (она подсвечивается). Никаких лишних запросов
Выключатель является датчиком. Датчики сами отправляют запросы на сервер, он передает его на исполняемое устройство (реле). Задержки в этом случае нет.
Я нажимаю на кнопку — get запрос через сервер (/control.php?slave=290&do=1) идет на wifi модуль с реле. Если планшет не тормозной задержки абсолютно не заметно. Обратно от модуля с реле возвращается ответ и отображается на состоянии кнопки (она подсвечивается). Никаких лишних запросов
О, да! Теперь понятно! Летают GET запросы туда сюда, только успевай отлаживать. Только теперь вопросы:
1. Как датчик узнает, куда слать свои запросы? То есть его нужно конфигурировать?
2. Если по какой-либо причине запрос не прошел, как сервер узнает, что датчик «отвалился». Через какое время? А как сам датчик об этом узнает? А как исполнительное устройство об этом узнает?
3. Теперь допустим у нас есть выключатель для управления светом и планшет/телефон для этой же цели. С обоих можно включить и выключить один и тот же свет в коридоре. Также сервер может это сделать по сценраию. Мы включили свет с выключателя. Как об этом узнает планшет? Сервер скажет? А откуда сервер узнает, кому надо слать статус света, а кому нет?
4. Если по какой либо причине сервер или датчик или исполнительное устройство теряли питание, как происходит восстановление синхронизации всех состояний всех устройств, после повторного включения?
Это как бы неполный список всех вопросов, которые сведут вашу попытку усовершенствования к еще большей неразберихе.
1. Как датчик узнает, куда слать свои запросы? То есть его нужно конфигурировать?
2. Если по какой-либо причине запрос не прошел, как сервер узнает, что датчик «отвалился». Через какое время? А как сам датчик об этом узнает? А как исполнительное устройство об этом узнает?
3. Теперь допустим у нас есть выключатель для управления светом и планшет/телефон для этой же цели. С обоих можно включить и выключить один и тот же свет в коридоре. Также сервер может это сделать по сценраию. Мы включили свет с выключателя. Как об этом узнает планшет? Сервер скажет? А откуда сервер узнает, кому надо слать статус света, а кому нет?
4. Если по какой либо причине сервер или датчик или исполнительное устройство теряли питание, как происходит восстановление синхронизации всех состояний всех устройств, после повторного включения?
Это как бы неполный список всех вопросов, которые сведут вашу попытку усовершенствования к еще большей неразберихе.
lingvo, вот это конкретный разговор!
1. Как я уже писал, все датчики имеют wifi модуль. Когда появляется питание на этом модуле он коннектится к точке доступа и там регистрируется! т.е. посылает get запрос со своим id. Сервер записывает в бд его IP (у меня последний октет IP). Там уже записаны id каждого реле. К каждой кнопке привязан id реле. Т.е. я, нажимая на кнопку посылаю запрос на сервер. Сервер, заглянув в бд, пересылает его по IP, где находится это реле. Простой прокси механизм.Т.е. вся конфигурация датчика состоит из параметров точки доступа.
2. Датчики посылают свои значения регулярно. Например, темп. и влажн. я отправляю раз в 3 минуты. Если сервер не получает данные с датчика более, скажем, 10 минут — тревожная запись в журнал (откровенно говоря, это еще не реализовано, но ясное представление как это сделать есть). Датчику знать ничего не надо. Сервер решает отправить смс, включить сирену или закрыть воду. Как я упоминал, вся логика на сервере. Исполняемые устройства с датчиками не связаны никак!
3. Это самое простое. Когда я открываю страницу в планшете (компьютере), для каждой кнопки отправляется запрос статуса реле (1 или 0) и отображается на странице. Если я включил свет с планшета, другой заходит с другого планшета и видит, что свет-то уже включен. Так работают все веб сервера. Сервер сообщает любому клиенту текущий статус и принимает команду от любого клиента.
4. Про модули с реле я уже писал, а датчикам вообще все равно, появилось питание, они подключаются к точке доступа и начинают слать свои регулярные запросы на известный всем адрес.
Эти усовершенствования уже были проведены до появления Ваших вопросов. Откуда неразбериха? Я же говорю, прототип рабочий. Логики ЕСЛИ-ТО на сервере пока не хватает. Реализацию этого этапа я бы обсудил более охотно.
1. Как я уже писал, все датчики имеют wifi модуль. Когда появляется питание на этом модуле он коннектится к точке доступа и там регистрируется! т.е. посылает get запрос со своим id. Сервер записывает в бд его IP (у меня последний октет IP). Там уже записаны id каждого реле. К каждой кнопке привязан id реле. Т.е. я, нажимая на кнопку посылаю запрос на сервер. Сервер, заглянув в бд, пересылает его по IP, где находится это реле. Простой прокси механизм.Т.е. вся конфигурация датчика состоит из параметров точки доступа.
2. Датчики посылают свои значения регулярно. Например, темп. и влажн. я отправляю раз в 3 минуты. Если сервер не получает данные с датчика более, скажем, 10 минут — тревожная запись в журнал (откровенно говоря, это еще не реализовано, но ясное представление как это сделать есть). Датчику знать ничего не надо. Сервер решает отправить смс, включить сирену или закрыть воду. Как я упоминал, вся логика на сервере. Исполняемые устройства с датчиками не связаны никак!
3. Это самое простое. Когда я открываю страницу в планшете (компьютере), для каждой кнопки отправляется запрос статуса реле (1 или 0) и отображается на странице. Если я включил свет с планшета, другой заходит с другого планшета и видит, что свет-то уже включен. Так работают все веб сервера. Сервер сообщает любому клиенту текущий статус и принимает команду от любого клиента.
4. Про модули с реле я уже писал, а датчикам вообще все равно, появилось питание, они подключаются к точке доступа и начинают слать свои регулярные запросы на известный всем адрес.
Эти усовершенствования уже были проведены до появления Ваших вопросов. Откуда неразбериха? Я же говорю, прототип рабочий. Логики ЕСЛИ-ТО на сервере пока не хватает. Реализацию этого этапа я бы обсудил более охотно.
Сорри, но добъем эту тему сначала:
По пункту 3 — а если страница в планшете уже открыта, и кто-то дернул выключатель уже после этого. Как она обновит статус реле? Это частое явление, когда планшет повешен на стену и постоянно отображает одну и ту же страницу статически, например с температурой за бортом, которая по идее меряется опять- же датчиком. Клацать F5 периодически не выход.
И по всем пунктам — вы понимаете, что, например, тот же MQTT полностью стандартизирует пункты выше, а также то, что вы еще только думаете сделать, а уже разработанные кем-то стеки уже реализуют, то, до чего у вас еще руки не дошли, и о чем еще не задумывались?
И вам достаточно прикрутить MQTT библиотеку, чтобы получить это все сразу, вместо придумывания каких-то своих вариантов регистрации по IP, прокси-адресов, форматов GET запросов и пр.
Это же мир IoT — стандартизация протокола связи, например, позволит вам подключать любые устройства, а не только с определенной прошивкой.
По пункту 3 — а если страница в планшете уже открыта, и кто-то дернул выключатель уже после этого. Как она обновит статус реле? Это частое явление, когда планшет повешен на стену и постоянно отображает одну и ту же страницу статически, например с температурой за бортом, которая по идее меряется опять- же датчиком. Клацать F5 периодически не выход.
И по всем пунктам — вы понимаете, что, например, тот же MQTT полностью стандартизирует пункты выше, а также то, что вы еще только думаете сделать, а уже разработанные кем-то стеки уже реализуют, то, до чего у вас еще руки не дошли, и о чем еще не задумывались?
И вам достаточно прикрутить MQTT библиотеку, чтобы получить это все сразу, вместо придумывания каких-то своих вариантов регистрации по IP, прокси-адресов, форматов GET запросов и пр.
Это же мир IoT — стандартизация протокола связи, например, позволит вам подключать любые устройства, а не только с определенной прошивкой.
А по моему скромному мнению это можно реализовать через WebSocket. Панель управления же у нас в виде WEB страницы, работа по HTTP происходит?
Так и есть
Я пробовал проекты УД на Websockets. Например тот же Web интерфейс OpenHAB сделан на этом, также как и его нативные клиенты.
Результат — отваливаются они. И на стандартных Firefoxах/IE и на iOS/Androidных браузерах. Под отваливается, я имею ввиду, что сервер перестает слать обновления и страничка превращается в стационарную. И так пока F5 не ткнешь.
Почему это происходило, я не исследовал, но автоматически соединение восстанавливалось через раз, поэтому я отказался от этого в своей установке УД, а сделал планшетный GUI на MQTT — вот он работает без проблем уже несколько месяцев и не отваливается. А если отваливается, реконнектится сам.
Результат — отваливаются они. И на стандартных Firefoxах/IE и на iOS/Androidных браузерах. Под отваливается, я имею ввиду, что сервер перестает слать обновления и страничка превращается в стационарную. И так пока F5 не ткнешь.
Почему это происходило, я не исследовал, но автоматически соединение восстанавливалось через раз, поэтому я отказался от этого в своей установке УД, а сделал планшетный GUI на MQTT — вот он работает без проблем уже несколько месяцев и не отваливается. А если отваливается, реконнектится сам.
Похоже, тут Вы правы. Пошел учить матчасть. Однако, почему-то уверен, что это не просто взять ключ на 13 и прикрутить MQTT библиотеку.
F5, по-моему, для этих целей никто не использует. JS (jquery и т.п.) умеет получать данные без этого.
F5, по-моему, для этих целей никто не использует. JS (jquery и т.п.) умеет получать данные без этого.
Да, это сильно упростит код и логику. Как минимум избавит от необходимости парсить HTTP заголовки.
Похоже, никому не верится, что это делается просто!
Отправляю get запрос (если надо json_encode) — в php получаю готовый объект одной командой json_decode;
С объектом делаю что хочу. Хочу отображаю пользователю, хочу исполняю условие в зависимости от параметров объекта
Зачем парсить заголовки?
Отправляю get запрос (если надо json_encode) — в php получаю готовый объект одной командой json_decode;
С объектом делаю что хочу. Хочу отображаю пользователю, хочу исполняю условие в зависимости от параметров объекта
Зачем парсить заголовки?
Так с помощью MQTT это делается еще проще
Сравните с
mqtt:on("message", function(conn, topic, data)
local object =cjson.decode(data)
Сравните с
conn:on("receive", function(client,request)
local buf = "";
local _, _, method, path, vars = string.find(request, "([A-Z]+) (.+)?(.+) HTTP");
if(method == nil)then
_, _, method, path = string.find(request, "([A-Z]+) (.+) HTTP");
end
local _GET = {}
if (vars ~= nil)then
for k, v in string.gmatch(vars, "(%w+)=(%w+)&*") do
_GET[k] = v
end
Смотрится впечатляюще! А что нужно уметь серверу на линукс, чтобы быть MQTT совместимым?
Можно поставить mqtt брокер, а можно использовать один из публичных типа test.mosquitto.org. Если серверные компоненты пишете на php то Вам вероятно сюда, а если на JS то сюда.
В контексте функции модуля, можно вообще не передавать параметры, а дёргать URL на подобие http://192.168.1.1/ON, http://192.168.1.1/OFF.
А можно просто делать реквест типа http://192.168.1.1/SWITH, при получении которого модуль просто переключает состояние и отправляет результат с текущим состоянием на сервер (который должен всем клиентам-панелям через websocket отправить информацию об изменении состояния модуля). А сервер уже должен делать контроль, дёргать URL или нет, проверяя состояние зафиксированное у себя и требуемое клиентом-панелью управления. Если панель даёт команду включить, а сервер имеет статус, что уже включено, то URL модуля не дёргает.
А можно просто делать реквест типа http://192.168.1.1/SWITH, при получении которого модуль просто переключает состояние и отправляет результат с текущим состоянием на сервер (который должен всем клиентам-панелям через websocket отправить информацию об изменении состояния модуля). А сервер уже должен делать контроль, дёргать URL или нет, проверяя состояние зафиксированное у себя и требуемое клиентом-панелью управления. Если панель даёт команду включить, а сервер имеет статус, что уже включено, то URL модуля не дёргает.
Это тогда Вам сюда.
Я хотел предложить REST, но он используется более широко. Данные там передаются всё равно в параметрах. Тут же данные вообще можно не передавать. Дёрнул url какой угодно, модуль состояние сменил вообще не читая параметры, т.к. они ни к чему. Тут главное чтобы модуль просто реквест событие получил, а что по нему прилетело — не важно.
Повторюсь, это касается только простых модулей типа ВКЛ/ВЫКЛ.
Повторюсь, это касается только простых модулей типа ВКЛ/ВЫКЛ.
Проблема в том, что роутер является слабым звеном. Надо либо всегда иметь такой же про запас в шкафу или делать кластер.
У меня есть немного иная идея. Так же есть два типа устройств: ввод (кнопки, сенсоры и т.д.) и вывод (реле, диммеры и т.д.). Устройства ввода просто отправляют своё состояние как широковещательное сообщение, а устройства вывода, которые «подписаны» на сообщение от устройств ввода выполняют заданную им функцию. Вот только вопрос как Wi-Fi сеть будет обрабатывать большое кол-во клиентов — читал, что роутер ляжет при 20 клиентах.
У меня есть немного иная идея. Так же есть два типа устройств: ввод (кнопки, сенсоры и т.д.) и вывод (реле, диммеры и т.д.). Устройства ввода просто отправляют своё состояние как широковещательное сообщение, а устройства вывода, которые «подписаны» на сообщение от устройств ввода выполняют заданную им функцию. Вот только вопрос как Wi-Fi сеть будет обрабатывать большое кол-во клиентов — читал, что роутер ляжет при 20 клиентах.
Интересная идея.
Согласен, есть недостатки в моей технологии. Однако, роутер здесь не для передачи команд (не только). На нем должна быть вся логика. все ЕСЛИ-ТО. Иначе придется логику прописывать в каждое устройство отдельно. А если условий несколько и в них участвуют несколько сенсоров, счетчиков, реле?
Эти устройства передают запросы из нескольких байт/кбайт. Причем раз в несколько минут. Таким трафиком сеть не положить.
Согласен, есть недостатки в моей технологии. Однако, роутер здесь не для передачи команд (не только). На нем должна быть вся логика. все ЕСЛИ-ТО. Иначе придется логику прописывать в каждое устройство отдельно. А если условий несколько и в них участвуют несколько сенсоров, счетчиков, реле?
Эти устройства передают запросы из нескольких байт/кбайт. Причем раз в несколько минут. Таким трафиком сеть не положить.
Так же есть два типа устройств: ввод (кнопки, сенсоры и т.д.) и вывод (реле, диммеры и т.д.). Устройства ввода просто отправляют своё состояние как широковещательное сообщение, а устройства вывода, которые «подписаны» на сообщение от устройств ввода выполняют заданную им функцию.
Такой вариант реализован в том же протоколе KNX. Да, это увеличивает надежность, но сложность настройки системы значительно возрастает и уже при паре десятков устройств у вас будут значительные проблемы с поддержкой (а обновлять одновременно 20 прошивок из-за какой-то простой функции вы не пробовали? Увлекательное занятие)
Поэтому централизованная система в этом плане гораздо проще.
Как я уже упомянул, сервер стоит полторы тыр. В рабочем режиме необходимо иметь один сконфигурированный прозапас. Файлы и бд лежат на usb диске. Замена неисправного сведется к перетыканию Ethernet кабелей и флешки из одного в другой.
Можно сделать кластер, scsi хранилище, только если играться очень серьезно.
Можно сделать кластер, scsi хранилище, только если играться очень серьезно.
Вау, изобретение очередного колеса и обучение на своих ошибках.
Я не понимаю, как народ до того, как потратить свое время на такие вещи не может нормально погуглить.
Ну возьмите вы тот же RPi и поставьте на него OpenHAB, Domoticz или любой другой сервер УД и получите все то же самое, но уже отлаженное многими пользователями в сотнях инсталляциях, с поддержкой. И вдобавок ко всему этому кучу других возможностей, до которых автору статьи еще программировать и программировать.
Зачем?
Я не понимаю, как народ до того, как потратить свое время на такие вещи не может нормально погуглить.
Ну возьмите вы тот же RPi и поставьте на него OpenHAB, Domoticz или любой другой сервер УД и получите все то же самое, но уже отлаженное многими пользователями в сотнях инсталляциях, с поддержкой. И вдобавок ко всему этому кучу других возможностей, до которых автору статьи еще программировать и программировать.
Зачем?
Обидеть художника может каждый :-)
Действительно, зачем изобретать андроид, если есть виндоус и что-то там еще.
Это не изобретение, а применение простых (уровня продвинутого пользователя) уже изобретенных технологий в проекте «сделай сам». Спасибо за подсказки систем. Однако почему нет одной — лучшей — реализации умного дома? Потому же, почему не может быть одного универсального типа автомобиля. Много факторов, которые влияют на выбор системы.
Есть подобные отлаженные и даже промышленные системы. Raspberry Pi with Cayenne, Samsung Smartthings, и т.п. — сами знаете где искать.
Зачем статья? Автор показал пример, как школьник, увлеченный веб програмированием, за деньги на порядок меньше упомянутых систем, может сделать это для себя. Роутер в статье дешевле RPi, но в нем уже есть ОС, БД и тд. Устройства с датчиками, реле и т.д. стоят тоже таких денег, что не жалко развлекаться.
Вы верно заметили, что понадобится много человеко-часов программирования. Поэтому автор и опубликовал статью про этот прототип. Форум — место где люди испытывают свои идеи и находят других, которым эти идеи не кажутся зряшными. Крауд сорсинг удивительно эффективный метод разработки.
Действительно, зачем изобретать андроид, если есть виндоус и что-то там еще.
Это не изобретение, а применение простых (уровня продвинутого пользователя) уже изобретенных технологий в проекте «сделай сам». Спасибо за подсказки систем. Однако почему нет одной — лучшей — реализации умного дома? Потому же, почему не может быть одного универсального типа автомобиля. Много факторов, которые влияют на выбор системы.
Есть подобные отлаженные и даже промышленные системы. Raspberry Pi with Cayenne, Samsung Smartthings, и т.п. — сами знаете где искать.
Зачем статья? Автор показал пример, как школьник, увлеченный веб програмированием, за деньги на порядок меньше упомянутых систем, может сделать это для себя. Роутер в статье дешевле RPi, но в нем уже есть ОС, БД и тд. Устройства с датчиками, реле и т.д. стоят тоже таких денег, что не жалко развлекаться.
Вы верно заметили, что понадобится много человеко-часов программирования. Поэтому автор и опубликовал статью про этот прототип. Форум — место где люди испытывают свои идеи и находят других, которым эти идеи не кажутся зряшными. Крауд сорсинг удивительно эффективный метод разработки.
А Open Source еще лучше. Замечу, что OpenHAB и прочие — бесплатны. Так что там далеко не порядок по деньгам.
Согласен про простые датчики, которые сами ничего без команды не делают.
Свой велосипед это хорошо для образования, но с практической точки зрения со временем начинает доставлять неудобства.
Сейчас переписываю на Home assistant + mysensors + ардуины с езернетом и mqtt.
Вам правильно указывают на недостатки самописного протокола, ничем хорошим это не закончится, а поддержка mqtt есть во многих контроллерах умных домов.
Свой велосипед это хорошо для образования, но с практической точки зрения со временем начинает доставлять неудобства.
Сейчас переписываю на Home assistant + mysensors + ардуины с езернетом и mqtt.
Вам правильно указывают на недостатки самописного протокола, ничем хорошим это не закончится, а поддержка mqtt есть во многих контроллерах умных домов.
Не переживайте, у каждого решения найдётся свой пользователь.
Я, например, не считаю ваше решение плохим. MQTT это всего лишь протокол, как и HTTP. Да, он более подходит для IoT, но и для разработки порог вхождения выше, да и подключить его в виде готовых библиотек, я полагаю, не во всех языках можно. А для HTTP инфраструктура на всех языках развита, так что для легковесных задач вполне подойдёт и ваша реализация.
Я, например, не считаю ваше решение плохим. MQTT это всего лишь протокол, как и HTTP. Да, он более подходит для IoT, но и для разработки порог вхождения выше, да и подключить его в виде готовых библиотек, я полагаю, не во всех языках можно. А для HTTP инфраструктура на всех языках развита, так что для легковесных задач вполне подойдёт и ваша реализация.
А что за софт на планшете? Интересна технология панели управления. Планшет же всегда включен?
А можно названия компонентов, которые вы для датчиков используете?
Ссылки на другие компоненты указаны в оригинальной статье: http://www.instructables.com/id/Wireless-Home-Cloud-for-the-Crowd/
Не рассматривали готовые сервера умного дома? OpenHAB или MajorDoMo, например.
Если интересно, мой опыт применения MajorDoMo
Если интересно, мой опыт применения MajorDoMo
ИМХО, опыт применения MajorDoMo очень интересен! Но если если посмотреть список доступного оборудования http://majordomo.smartliving.ru/Main/HardAndSoft и главное его стоимость — то посещает печалька ( Любое внешнее устройство это десятки баксов $$$. Всего лишь 1 датчик температуры 50 уе… Если вопрос денег не стоит, то текущее состояние проекта MajorDoMo реально впечатляет!
В этом проекте принципиальное отличие в концепции: Все находится на сервере — информация, обработка и реакции. «На местах» только простые и недорогие контроллеры которые сами ничего не решают. В этом проекте, датчик температуры будет стоить 5 уе :-) Мне кажется идея единого датацентра эта та самая изюминка этого проекта которую стоит развивать.
В этом проекте принципиальное отличие в концепции: Все находится на сервере — информация, обработка и реакции. «На местах» только простые и недорогие контроллеры которые сами ничего не решают. В этом проекте, датчик температуры будет стоить 5 уе :-) Мне кажется идея единого датацентра эта та самая изюминка этого проекта которую стоит развивать.
Вам в помощь https://www.mysensors.org/
Мы можем построить обучаемую систему, которая сможет приспосабливаться к нашим привычкам, сообщать нам о происшествиях
Вот постройте и расскажите. А то лампочкой мигнуть легко. Я не критикую, удачи Вам конечно, в велосипедостроении, но… Как только система обрастет десятками датчиков/реле и пр., Вы дешевым роутером и Javascript'ом на коленке не разрулите всё это. И в итоге получите такого же монстра, как и готовые решения.
Все классно, вот только не очень понятно — где тут облако?
Если у вас все на ESP8266 может просто вынести сервер в интернет и избавиться от лишней коробочки? Задублировать канал провайдера на всякий случай.
Я так вынес… И когда хостинг с сервером упал, я мог включить свет только специальным запросом на локальный ip выключателя.
Веб-интерфейс с кнопочками тоже с этого хостинга загружался. Даже приложение для pebble, в котором были прописаны все локальные ip, перед работой считывало текущие статусы устройств с этого хостинга.
Теперь сервер в локалке, так оказалось немного надежнее.
Веб-интерфейс с кнопочками тоже с этого хостинга загружался. Даже приложение для pebble, в котором были прописаны все локальные ip, перед работой считывало текущие статусы устройств с этого хостинга.
Теперь сервер в локалке, так оказалось немного надежнее.
Sign up to leave a comment.
Беспроводное домашнее облако для вещей интернета