Другими словами, ты должен поддерживать огромные библиотеки спецификаций и кодов. И необходимо больше времени для того чтобы справиться со всеми своими устройствами. Определенно, некоторые более организованы, чем я, но, наверняка, большинство в борьбе с энтропией добились незначительных успехов. Без обид.
Что делать, чтобы обуздать нашествие роботов на свой дом (а это в любом случае неизбежно)?.. Все просто. Вещи проще. Облако умнее.
Концепция
- Устройства как можно проще: стандартный модуль связи с частным облаком. Состоит из беспроводного модуля и скриптов инициализации (как в модуле, так и на сервере). Если модуль выходит из строя, выбрасываем его и меняем на новый стандартный модуль.
- Вся логика и интеллект располагается на сервере. Простом роутере на линукс.
Вещи проще. Облако умнее
Крохотный сервер принимает данные с датчиков, хранит их и посылает команды исполнительным устройствам. Теперь ваши устройства не толпа мыслящих вещей. Они лишь синапсы мозга сервера. Это просто и естественно.
В моей сети два типа устройств:
- Датчики и элементы управления (входные) и
- Реле, клапаны и т.п. (выходные)
Все они общаются с сервером посредством модулей wifi (ESP8266 из известного китайского магазина). Входы отправляют данные о своем состоянии на сервер базы данных. Выходы принимают и исполняют команды от сервера. Как я уже упомянул, никакого разума у устройств нет.
Цель — сделать вещи как можно более простыми.
Вся логика остается на сервере. На сервере все алгоритмы, триггеры и т.п. Например, сервер принимает решение включить отопление, если температура в определенных помещениях опускается ниже определенного уровня на определенное количество времени. Сервер принимает решение открыть электромагнитный клапан полива в теплице, если влажность почвы упала до определенного уровня в определенное время суток. Естественно, человек может всегда вмешаться и взять управление в свои руки или изменить логику. Сервер также уведомляет владельца о критических событиях по СМС. Он может принимать команды с определенных телефонов.
Ядро умного облака
Я использовал маленький беспроводный роутер с OpenWRT и расширенной памятью, способный содержать веб сервер и сервер баз данных — Gl-iNet 6416A не дороже 25 USD.
Удивительно крохотное устройство дает нам:
- Веб сервер lighttpd для размещения страниц интерфейса (предустановлен)
- php, чтобы они были интерактивными (предустановлен)
- Сервер баз данных MySQL для хранения данных (устанавливается). Кое-кто использует SQlite, но он не способен обрабатывать одновременные запросы, в топку
Это мое частное облако. Оно создает свою собственную подсеть сеть (192.168.8.1), свою собственную сеть wifi, доступную только моим вещам. У него также есть внешний интерфейс (WAN), подключенный к моему обычному домашнему роутеру (с назначенным адресом 192.168.1.100). Он нужен для доступа к панели управления из моей домашней wifi сети.
Прикладное программное обеспечение, использованное в проекте:
- WinSCP — графический FTP клиент для доступа к файлам
- HeidiSQL — графический SQL клиент для доступа к базе данных
- PuTTy — клиент SSH для передачи команд операционной системе OpenWRT
Текущая конфигурация хранится на GitHub.
И да, виноват, я использовал флешку как файловое хранилище, хотя по-взрослому не стоит использовать память NAND (требование mySQL).
Стандартный модуль
Модуль wifi (ESP8266) заправленный стандартным скетчем. Вкратце, он считывает параметры последнего доступа к точке доступа, пытается к ней подключиться, если ему не удается, он запускает свою точку доступа и страницу с формой для новых параметров доступа. А если ему удается подключиться, он загружает с сервера предназначенные этому модулю скрипты и запускает их. Модули различаются по MAC адресам.
В моем облаке для каждого MAC адреса есть выделенная папочка с рабочими скриптами по адресу 192.168.8.1:86
Итак, изначально у модуля всего три скрипта:
AP_config — две строки: SSID и пароль.
init.lua — подключение к точке доступа с сохраненными параметрами из AP_config. При неудаче — запуск do(«ap_request.lua»). При удаче — загрузка рабочих скриптов и запуск их.
ap_request.lua — запрос новых параметров доступа к точке доступа, запись их в файл AP_config (в случае, если подключение с предустановленными не удалось).
Скрипты модуля
Управляемые устройства
Цель — сделать периферийный устройства как можно более простыми. Например модуль с двумя реле (выключатели света) состоит из:
- Блока питания AC-DC
- Стабилизатора питания на 3,3В
- ESP8266 (в данном случае ESP-01 с двумя управляемыми пинами)
- модули реле
- корпус
Всё про всё — 7 USD.
Датчики (входы)
Устройство с датчиком состоит из:
- Блока питания
- Стабилизатора питания
- Модуля wifi (опять ESP01)
- Цифрового датчика температуры и влажности DHT11
Всё не более 5 USD.
Он измеряет показания температуры и влажности и каждые 3 минуты отправляет на сервер, где они сохраняются в базу данных mySQL.
Управление
Всё веселье на сервере!
Самое интересное это то, что у меня нет обычных панелей управления. Все интерфейсы виртуальные. Кнопки, выключатели, движки виртуальны. Конечно, можно сделать их реальными и некоторые из них я сделаю.
С помощью этого сайта мы можем наблюдать историю датчиков и текущие значения, можем управлять лампами, клапанами и т.п.
Вы всегда можете добавить новые устройства к панели при помощи простых навыков HTML и Javascript кодирования.
Я использовал карты ссылок с изображениями построенными в простой программе SweetHome 3D для организации навигации по дому.
Включите свое воображение
Гораздо больше людей знают как кодировать для веба (PHP, Javascript, HTML), чем для контроллеров (C++, Lua). При помощи этой структуры мы можем получать, запрашивать, отправлять данные и команды простыми php или js скриптами. Мы можем построить обучаемую систему, которая сможет приспосабливаться к нашим привычкам, сообщать нам о происшествиях.
Комментарии (55)
dimitriy16
09.08.2016 11:58Спасибо за статью. Лично мне не хватает знаний чтобы такое решение сделать. Выходит все слишком примитивно. Подскажите какую разметку делали на флешке?
Alex--T
09.08.2016 12:43Мне тоже не хватает знаний по некоторым вопросам. флешка просто в ntfs с одним разделом. Автоматически монтируется в /mnt/sda1. Там уже в папках iot — веб сервер, в mysql — база данных
past
09.08.2016 12:20C esp8266 гораздо удобнее общаться с помощью спец. протоколов, например MQTT или CoAP. Посмотрите например мой код.
Alex--T
09.08.2016 12:46У меня нет опыта чтобы сравнить удобство общения. PHP и JScript знакомы всем школьникам. И это работает
past
09.08.2016 13:21Ничего не мешает общаться через MQTT или CoAP на PHP и JS, тем более, что на стороне MCU lua.
Alex--T
09.08.2016 14:16Сейчас я использую простые GET запросы с ответами в формате json. Возможно мне стоит изучить преимущества этих протоколов. Чем упростит/улучшит обмен их использование?
lingvo
09.08.2016 15:01+1Чтобы мониторить сигнал типа выключателя света, вам нужно будет использовать поллинг и посылать ваши GET запросы чаще, чем раз в 100мс, иначе задержка будет некомфортна для пользователя. Также эти запросы будут нагружать сеть, если у вас будет несколько десятков различных устройста. MQTT решает эту проблему, так как там поллинг не нужен — брокер сам рассылает сообщения всем подключившимся. В моем УД в результате задержка вообще не заметна…
Alex--T
09.08.2016 15:31Про какую систему Вы пишете? В моей системе поллинг еще изобретен не был.
Выключатель является датчиком. Датчики сами отправляют запросы на сервер, он передает его на исполняемое устройство (реле). Задержки в этом случае нет.
Я нажимаю на кнопку — get запрос через сервер (/control.php?slave=290&do=1) идет на wifi модуль с реле. Если планшет не тормозной задержки абсолютно не заметно. Обратно от модуля с реле возвращается ответ и отображается на состоянии кнопки (она подсвечивается). Никаких лишних запросовlingvo
09.08.2016 16:02О, да! Теперь понятно! Летают GET запросы туда сюда, только успевай отлаживать. Только теперь вопросы:
1. Как датчик узнает, куда слать свои запросы? То есть его нужно конфигурировать?
2. Если по какой-либо причине запрос не прошел, как сервер узнает, что датчик «отвалился». Через какое время? А как сам датчик об этом узнает? А как исполнительное устройство об этом узнает?
3. Теперь допустим у нас есть выключатель для управления светом и планшет/телефон для этой же цели. С обоих можно включить и выключить один и тот же свет в коридоре. Также сервер может это сделать по сценраию. Мы включили свет с выключателя. Как об этом узнает планшет? Сервер скажет? А откуда сервер узнает, кому надо слать статус света, а кому нет?
4. Если по какой либо причине сервер или датчик или исполнительное устройство теряли питание, как происходит восстановление синхронизации всех состояний всех устройств, после повторного включения?
Это как бы неполный список всех вопросов, которые сведут вашу попытку усовершенствования к еще большей неразберихе.Alex--T
09.08.2016 16:37lingvo, вот это конкретный разговор!
1. Как я уже писал, все датчики имеют wifi модуль. Когда появляется питание на этом модуле он коннектится к точке доступа и там регистрируется! т.е. посылает get запрос со своим id. Сервер записывает в бд его IP (у меня последний октет IP). Там уже записаны id каждого реле. К каждой кнопке привязан id реле. Т.е. я, нажимая на кнопку посылаю запрос на сервер. Сервер, заглянув в бд, пересылает его по IP, где находится это реле. Простой прокси механизм.Т.е. вся конфигурация датчика состоит из параметров точки доступа.
2. Датчики посылают свои значения регулярно. Например, темп. и влажн. я отправляю раз в 3 минуты. Если сервер не получает данные с датчика более, скажем, 10 минут — тревожная запись в журнал (откровенно говоря, это еще не реализовано, но ясное представление как это сделать есть). Датчику знать ничего не надо. Сервер решает отправить смс, включить сирену или закрыть воду. Как я упоминал, вся логика на сервере. Исполняемые устройства с датчиками не связаны никак!
3. Это самое простое. Когда я открываю страницу в планшете (компьютере), для каждой кнопки отправляется запрос статуса реле (1 или 0) и отображается на странице. Если я включил свет с планшета, другой заходит с другого планшета и видит, что свет-то уже включен. Так работают все веб сервера. Сервер сообщает любому клиенту текущий статус и принимает команду от любого клиента.
4. Про модули с реле я уже писал, а датчикам вообще все равно, появилось питание, они подключаются к точке доступа и начинают слать свои регулярные запросы на известный всем адрес.
Эти усовершенствования уже были проведены до появления Ваших вопросов. Откуда неразбериха? Я же говорю, прототип рабочий. Логики ЕСЛИ-ТО на сервере пока не хватает. Реализацию этого этапа я бы обсудил более охотно.lingvo
09.08.2016 17:51Сорри, но добъем эту тему сначала:
По пункту 3 — а если страница в планшете уже открыта, и кто-то дернул выключатель уже после этого. Как она обновит статус реле? Это частое явление, когда планшет повешен на стену и постоянно отображает одну и ту же страницу статически, например с температурой за бортом, которая по идее меряется опять- же датчиком. Клацать F5 периодически не выход.
И по всем пунктам — вы понимаете, что, например, тот же MQTT полностью стандартизирует пункты выше, а также то, что вы еще только думаете сделать, а уже разработанные кем-то стеки уже реализуют, то, до чего у вас еще руки не дошли, и о чем еще не задумывались?
И вам достаточно прикрутить MQTT библиотеку, чтобы получить это все сразу, вместо придумывания каких-то своих вариантов регистрации по IP, прокси-адресов, форматов GET запросов и пр.
Это же мир IoT — стандартизация протокола связи, например, позволит вам подключать любые устройства, а не только с определенной прошивкой.
bankir1980
10.08.2016 16:08А по моему скромному мнению это можно реализовать через WebSocket. Панель управления же у нас в виде WEB страницы, работа по HTTP происходит?
lingvo
11.08.2016 10:32Я пробовал проекты УД на Websockets. Например тот же Web интерфейс OpenHAB сделан на этом, также как и его нативные клиенты.
Результат — отваливаются они. И на стандартных Firefoxах/IE и на iOS/Androidных браузерах. Под отваливается, я имею ввиду, что сервер перестает слать обновления и страничка превращается в стационарную. И так пока F5 не ткнешь.
Почему это происходило, я не исследовал, но автоматически соединение восстанавливалось через раз, поэтому я отказался от этого в своей установке УД, а сделал планшетный GUI на MQTT — вот он работает без проблем уже несколько месяцев и не отваливается. А если отваливается, реконнектится сам.
Alex--T
11.08.2016 08:04Похоже, тут Вы правы. Пошел учить матчасть. Однако, почему-то уверен, что это не просто взять ключ на 13 и прикрутить MQTT библиотеку.
F5, по-моему, для этих целей никто не использует. JS (jquery и т.п.) умеет получать данные без этого.
past
09.08.2016 15:02+1Да, это сильно упростит код и логику. Как минимум избавит от необходимости парсить HTTP заголовки.
Alex--T
09.08.2016 15:37Похоже, никому не верится, что это делается просто!
Отправляю get запрос (если надо json_encode) — в php получаю готовый объект одной командой json_decode;
С объектом делаю что хочу. Хочу отображаю пользователю, хочу исполняю условие в зависимости от параметров объекта
Зачем парсить заголовки?past
09.08.2016 15:47Так с помощью 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 endAlex--T
09.08.2016 16:39Смотрится впечатляюще! А что нужно уметь серверу на линукс, чтобы быть MQTT совместимым?
past
09.08.2016 17:27Можно поставить mqtt брокер, а можно использовать один из публичных типа test.mosquitto.org. Если серверные компоненты пишете на php то Вам вероятно сюда, а если на JS то сюда.
bankir1980
10.08.2016 16:14В контексте функции модуля, можно вообще не передавать параметры, а дёргать URL на подобие http://192.168.1.1/ON, http://192.168.1.1/OFF.
А можно просто делать реквест типа http://192.168.1.1/SWITH, при получении которого модуль просто переключает состояние и отправляет результат с текущим состоянием на сервер (который должен всем клиентам-панелям через websocket отправить информацию об изменении состояния модуля). А сервер уже должен делать контроль, дёргать URL или нет, проверяя состояние зафиксированное у себя и требуемое клиентом-панелью управления. Если панель даёт команду включить, а сервер имеет статус, что уже включено, то URL модуля не дёргает.past
10.08.2016 16:26Это тогда Вам сюда.
bankir1980
10.08.2016 16:31Я хотел предложить REST, но он используется более широко. Данные там передаются всё равно в параметрах. Тут же данные вообще можно не передавать. Дёрнул url какой угодно, модуль состояние сменил вообще не читая параметры, т.к. они ни к чему. Тут главное чтобы модуль просто реквест событие получил, а что по нему прилетело — не важно.
Повторюсь, это касается только простых модулей типа ВКЛ/ВЫКЛ.
BurlakovSG
09.08.2016 12:27Проблема в том, что роутер является слабым звеном. Надо либо всегда иметь такой же про запас в шкафу или делать кластер.
У меня есть немного иная идея. Так же есть два типа устройств: ввод (кнопки, сенсоры и т.д.) и вывод (реле, диммеры и т.д.). Устройства ввода просто отправляют своё состояние как широковещательное сообщение, а устройства вывода, которые «подписаны» на сообщение от устройств ввода выполняют заданную им функцию. Вот только вопрос как Wi-Fi сеть будет обрабатывать большое кол-во клиентов — читал, что роутер ляжет при 20 клиентах.Alex--T
09.08.2016 12:51Интересная идея.
Согласен, есть недостатки в моей технологии. Однако, роутер здесь не для передачи команд (не только). На нем должна быть вся логика. все ЕСЛИ-ТО. Иначе придется логику прописывать в каждое устройство отдельно. А если условий несколько и в них участвуют несколько сенсоров, счетчиков, реле?
Эти устройства передают запросы из нескольких байт/кбайт. Причем раз в несколько минут. Таким трафиком сеть не положить.BurlakovSG
09.08.2016 13:14Со сложными условиями не получится, если нужно учитывать несколько разных устройств ввода.
lingvo
09.08.2016 13:21Так же есть два типа устройств: ввод (кнопки, сенсоры и т.д.) и вывод (реле, диммеры и т.д.). Устройства ввода просто отправляют своё состояние как широковещательное сообщение, а устройства вывода, которые «подписаны» на сообщение от устройств ввода выполняют заданную им функцию.
Такой вариант реализован в том же протоколе KNX. Да, это увеличивает надежность, но сложность настройки системы значительно возрастает и уже при паре десятков устройств у вас будут значительные проблемы с поддержкой (а обновлять одновременно 20 прошивок из-за какой-то простой функции вы не пробовали? Увлекательное занятие)
Поэтому централизованная система в этом плане гораздо проще.
Alex--T
09.08.2016 14:21Как я уже упомянул, сервер стоит полторы тыр. В рабочем режиме необходимо иметь один сконфигурированный прозапас. Файлы и бд лежат на usb диске. Замена неисправного сведется к перетыканию Ethernet кабелей и флешки из одного в другой.
Можно сделать кластер, scsi хранилище, только если играться очень серьезно.
lingvo
09.08.2016 12:50+2Вау, изобретение очередного колеса и обучение на своих ошибках.
Я не понимаю, как народ до того, как потратить свое время на такие вещи не может нормально погуглить.
Ну возьмите вы тот же RPi и поставьте на него OpenHAB, Domoticz или любой другой сервер УД и получите все то же самое, но уже отлаженное многими пользователями в сотнях инсталляциях, с поддержкой. И вдобавок ко всему этому кучу других возможностей, до которых автору статьи еще программировать и программировать.
Зачем?Alex--T
09.08.2016 13:59Обидеть художника может каждый :-)
Действительно, зачем изобретать андроид, если есть виндоус и что-то там еще.
Это не изобретение, а применение простых (уровня продвинутого пользователя) уже изобретенных технологий в проекте «сделай сам». Спасибо за подсказки систем. Однако почему нет одной — лучшей — реализации умного дома? Потому же, почему не может быть одного универсального типа автомобиля. Много факторов, которые влияют на выбор системы.
Есть подобные отлаженные и даже промышленные системы. Raspberry Pi with Cayenne, Samsung Smartthings, и т.п. — сами знаете где искать.
Зачем статья? Автор показал пример, как школьник, увлеченный веб програмированием, за деньги на порядок меньше упомянутых систем, может сделать это для себя. Роутер в статье дешевле RPi, но в нем уже есть ОС, БД и тд. Устройства с датчиками, реле и т.д. стоят тоже таких денег, что не жалко развлекаться.
Вы верно заметили, что понадобится много человеко-часов программирования. Поэтому автор и опубликовал статью про этот прототип. Форум — место где люди испытывают свои идеи и находят других, которым эти идеи не кажутся зряшными. Крауд сорсинг удивительно эффективный метод разработки.lingvo
09.08.2016 15:37А Open Source еще лучше. Замечу, что OpenHAB и прочие — бесплатны. Так что там далеко не порядок по деньгам.
bazis13
10.08.2016 02:04Согласен про простые датчики, которые сами ничего без команды не делают.
Свой велосипед это хорошо для образования, но с практической точки зрения со временем начинает доставлять неудобства.
Сейчас переписываю на Home assistant + mysensors + ардуины с езернетом и mqtt.
Вам правильно указывают на недостатки самописного протокола, ничем хорошим это не закончится, а поддержка mqtt есть во многих контроллерах умных домов.
bankir1980
10.08.2016 16:27Не переживайте, у каждого решения найдётся свой пользователь.
Я, например, не считаю ваше решение плохим. MQTT это всего лишь протокол, как и HTTP. Да, он более подходит для IoT, но и для разработки порог вхождения выше, да и подключить его в виде готовых библиотек, я полагаю, не во всех языках можно. А для HTTP инфраструктура на всех языках развита, так что для легковесных задач вполне подойдёт и ваша реализация.Alex--T
11.08.2016 07:56Глупо игнорировать MQTT, когда многие указывают на его удобство. Я упустил этот момент и благодарен всем, кто конструктивно меня попинал.
de1m
09.08.2016 13:45А можно названия компонентов, которые вы для датчиков используете?
Alex--T
09.08.2016 14:27Ссылки на другие компоненты указаны в оригинальной статье: http://www.instructables.com/id/Wireless-Home-Cloud-for-the-Crowd/
ElectricFromUfa
09.08.2016 14:55Не рассматривали готовые сервера умного дома? OpenHAB или MajorDoMo, например.
Если интересно, мой опыт применения MajorDoMoAlex--T
09.08.2016 16:18Конечно, интересно. В плане применения модулей и организации взаимодействия с пользователем.
Возможно, знающие люди убедят меня в бесперспективности собственной разработки. То тогда и в плане внедрения конкретных проектов. Всегда восхищался людьми которые доводили дело до законченного решения.
Pavel_R1
09.08.2016 17:02ИМХО, опыт применения MajorDoMo очень интересен! Но если если посмотреть список доступного оборудования http://majordomo.smartliving.ru/Main/HardAndSoft и главное его стоимость — то посещает печалька ( Любое внешнее устройство это десятки баксов $$$. Всего лишь 1 датчик температуры 50 уе… Если вопрос денег не стоит, то текущее состояние проекта MajorDoMo реально впечатляет!
В этом проекте принципиальное отличие в концепции: Все находится на сервере — информация, обработка и реакции. «На местах» только простые и недорогие контроллеры которые сами ничего не решают. В этом проекте, датчик температуры будет стоить 5 уе :-) Мне кажется идея единого датацентра эта та самая изюминка этого проекта которую стоит развивать.Kostyanych
09.08.2016 18:38Вам в помощь https://www.mysensors.org/
zeblong
10.08.2016 10:41А у вас есть опыт скрещивания mysensors с какими нибудь готовыми решениями типа MajorDoMo?
я пробовал OpenHab и Domoticz в обоих случаях выходит не стабильно.
И еще надо обновлять страницу что бы получить состояния
savostin
10.08.2016 11:09Мы можем построить обучаемую систему, которая сможет приспосабливаться к нашим привычкам, сообщать нам о происшествиях
Вот постройте и расскажите. А то лампочкой мигнуть легко. Я не критикую, удачи Вам конечно, в велосипедостроении, но… Как только система обрастет десятками датчиков/реле и пр., Вы дешевым роутером и Javascript'ом на коленке не разрулите всё это. И в итоге получите такого же монстра, как и готовые решения.
ncix
13.08.2016 22:03Если у вас все на ESP8266 может просто вынести сервер в интернет и избавиться от лишней коробочки? Задублировать канал провайдера на всякий случай.
rstepanov
Вот такая штука есть в доме?
past
Срочно на Кикстартер!
Alex--T
Спасибо :-)
Сарказм оценил!
Да, это из раздела «сделай сам»
rstepanov
А если серьезно, то все, что в доме включается и выключается через bluetooth/интернет, должно по прежнему удобно включаться и выключаться обычными выключателями, просто рукой, без смартфонов и ноутбуков. И мозг «умного» дома должен уметь это обрабатывать и понимать текущее состояние. У вас с этим как, реализовано? А то пойдешь, извините, в туалет без смартфона, а смыв только через браузер работает… А если временно свет в доме выключили — вообще катастрофа…
Alex--T
Абсолютно согласен. Некоторые виртуальные элементы управления должны быть продублированы физическими. А физические могут опять же как отправлять команды на сервер, так и напрямую на устройство. Как я упомянул в статье я только собираюсь сделать такое дублирование.
Однако, эта технология позволяет создать нестандартные элементы управления.
Например — кубик размером с кружку. Положил на одну грань — включился свет, на другую — выключился. Повернул по часовой стрелке — ярче, обратно — тусклее. Внутри гироскоп (датчик наклона) и ESP01 с батарейкой.