- Подробности
- Категория: Обзоры
- Просмотров: 23206
Инфракрасное управление
Самый очевидный но ненадежный вариант с управлением по ИК я подробно рассматривать не буду. Низкая надежность и отсутствие обратной связи делают его целесообразным только если кондиционер уже куплен и висит.
Лучше озаботиться возможностью управления до покупки кондиционера.
Но если уже поздно - про BroadLink можно почитать здесь. При желании, ИК управление, также, реализуется на ESP8266, например, вот такой проект. Ну и, конечно, не обошлось без закрытых решений. Например, Sensibo.
Управление через облако производителя
Варианты, при которых управление происходит через внешнее облако, поддерживаемое поставщиком кондиционера, я, также, сразу отметаю. Как правило, это закрытые экосистемы, не дающие возможность интеграции. Даже если бы и давали - чужие облака - это слишком ненадежная опора, если рассматривать их хотя бы на период 10 лет, в течение которых очень не хотелось бы возвращаться к вопросу ремонта в доме.
Итак, что же остается:
Родные шлюзы производителей
Есть у производителей премиум-класса, например Daikin RTD-NET
Специализированные Premium устройства.
Типичный представитель - устройство CoolMaster - универсальный адаптер протоколов самых разнообразных VRF систем управления климатом с умными домами различных брендов. (Ну и в Modbus, заодно)
Прекрасно, но стоимость от 1500 Евро. Это может быть оправдано только если в здании развернута единая мультизональная система кондиционирования. Тогда можно будет обойтись одним шлюзом, докупив к нему необходимое количество лицензий.
Те, у кого нет дома VRF, а есть несколько разрозненных сплитов - могут найти подходящий вариант примерно по цене 500 Евро за сплит
Решения с открытым кодом
Ниже, я сделал подборку кондиционеров, протокол управления которых был исследован энтузиастами, реализован и доступен в исходных кодах
Для себя я делал выбор между продукцией Haier и Mitsubishi, так как в обоих случаях, реализован двухсторонний обмен через последовательный интерфейс UART, что, как мне кажется, является самым надежным вариантом и позволяет подключить модуль управления вместо опционального модуля WiFi
Именно этот вариант я использую в составе своего открытого решения Контроллер умного дома LightHub
Вариант, при котором как-то "обманывается" фирменный WiFi модуль - менее предпочтителен, так как нельзя гарантировать работу такой системы, например, после обновления прошивки
Итак, далее, перечень кондиционеров, которые имеют изученные протоколы взаимодействия.
И на закуску - управление кондиционерами нескольких китайских брендов через HomeBridge прямо с любимого Айфона
https://sprut.ai/client/blog/1474
- Подробности
- Категория: Обзоры
- Просмотров: 23701
Наступила осень. Время достаточно серое и унылое, но оптимизма и драйва добавило то, что удалось испробовать созданную летом Приточную установку.
Летом, в принципе, можно держать окна открытыми, если они, конечно, не выходят на автостраду а за окном не цветет какая нибудь береза, на которую у вас аллергия. Когда прилично холодает - это уже не вариант.
Установка сильно порадовала - субъективно, во всей квартире дышится легко, при этом температура не падает ниже 22-х градусов
Если, вдруг, такое происходит - кондиционер оперативно подогревает воздух на автомате, до 23-х градусов.
Но одновременно с этим, за неделю использования я обнаружил определенную проблему. И называется она - влажность.
Дело в том, что влажный, но холодный воздух с улицы, подогреваясь до комнатной температуры, теряет свою относительную влажность. Довольно скоро она понижается до 30%
Возможно, все замечали, что если плохо утепленная комната (щели в окнах) при этом сильно отапливается (а раньше, когда затраты на отопление никто не считал, такое было сплошь и рядом) - воздух становится ужасно сухим. Это приводит к першению в горле, носу, респираторным заболеваниям.
Эффективно работающая приточная установка, при отсутствии увлажнителя воздуха, по моим наблюдениям, тоже делает воздух излишне сухим.
Без притока, воздух в замкнутом пространстве увлажняется естественным путем (люди дышат, варят еду, принимают ванну). Оптимальная влажность - 45-60%, конечно, при этом не достигается, но совсем сухого воздуха тоже не получается. Зато, со временем, становится душно, так как повышается удельное количество углекислого газа в воздухе.
Приточный воздух вытесняет "отработаный", но более влажный воздух в вентканалы, заменяя более чистым, но более сухим. При этом, уровень CO2, конечно же, понижается, но при этом влажность понижается также.
Соответственно, следующая и уже не очень сложная задача, которую я себе поставил - найти баланс между влажностью и уровнем CO2 и поддерживать его автоматически.
При этом, естественно, мы еще и сэкономим электроэнергию, так как подогревать уличный воздух занятие достаточно энергоемкое.
Так как приточная установка уже полностью интегрирована в Умный Дом, управлять потоком воздуха с улицы - крайне просто. Значение от 0 до 100 просто записывается в соответствующий MQTT топик, далее, поступая в LightHub, оттуда по шине Modbus в частотный регулятор приточки. Рерулятор температуры после этого автоматически перенастраивает мощность нагревателя, чтобы обеспечить неизменную температуру воздуха на выходе.
Осталось чем-то выдать на MQTT шину значения влажности и CO2, например, в гостиной или спальне или взять худшую в доме величину каждого показателя
А далее, при помощи удачно найденного в NodeRed Пропорционального-Интегрально-Дифференциального (PID) регулятора поддерживать уровень CO2, скажем, на уровне до 1000 ppm
При этом, в помещение будет поступать минимально необходимое количество свежего уличного воздуха, что позволит его минимально увлажнять и экономить электроэнергию.
При этом, когда люди будут покидать дом, приточка, со временем, выключается. Ну или продолжает работать в минимальном режиме, обеспечивая воздухом собаку ))
В результате поисков, нашел совместимые со своим решением, недорогие датчики CO2/Влажности, которые могут передавать значения напрямую в MQTT шину. Откуда значение CO2 попадает на PID преобразователь Node Red, управляя скоростью вращения вентилятора при помощи Контроллера умного дома LightHub
Также, в последних версиях прошивки я научился работать с недорогими (хоть и капризными) датчиками CSS 811 (см Датчики качества воздуха)
Данное решение работает в продуктиве около года.
Еще ссылки на тему:
https://geektimes.ru/post/284994/
http://forum.ixbt.com/topic.cgi?id=47:11005:1720#1720
https://geektimes.ru/company/dadget/blog/276316/
http://izmerkon.ru/catalog/concentration/sensoryi-co2/s8.html
https://www.ebay.com/itm/Xiaomi-Mi-Home-PM2-5-Air-Detector-Quality-Tester-Monitor-OLED-Smart-Linkage-New/311799678572?epid=2152597783&hash=item4898b5866c:g:CzQAAOSwstJZVxAshttps://www.ebay.com/itm/Home-Smart-Wireless-Air-Quality-Detector-Sensor-Automation-System-Hot/253096751231?hash=item3aedbdf07f:g:hWEAAOSwpgNZkrUj
А, ну конечно, неплохая, хоть и не дешевая находка - Бризер с контролем CO2, температуры и влажности, мобильным приложением. Ничто не ново в этом мире.
Но к большому сожалению, по информации от Техподдержки - это опять "вещь в себе" без возможности интеграции в умный дом. Поэтому, идем своим путем.
Буду держать в курсе!
- Подробности
- Категория: Обзоры
- Просмотров: 28503
Спойлер - попробуйте NodeRed + LightHub в нашей Демо - Песочнице. Подробности в статье Как начать.
В предыдущих статьях, я рассказывал про управляемое освещение, вентиляцию, теплые полы и пр.
Это все можно назвать "руками" и "ногами" Умного дома.
Датчики температуры, влажности, CO2, движения, освещенности и даже выключатели на стенах - это все органы чувств - глаза и уши.
Шина MQTT или ZWave или любая другая - своеобразная "нервная система", передающая сигналы от датчиков и к исполнительным устройствам.
Собственно, роль контроллера LightHub - присоединить органы чувств и руки-ноги к нервной системе. Уже после этого Дом превращается в подобие "тела" которое уже может шевелиться и выполнять простейшие операции.
Но теперь, когда создано "тело" Умного дома, начинается самое интересное! Собственно, то, ради чего все и затевалось - вдыхаем в этого зомби разум.
У используемой мной системы Openhab есть, в принципе, возможность создавать, так называемые, правила (rules), позволяющие на довольно странном языке описать взаимосвязь событий - например: состояние датчика освещенности изменилось на "темно" - включаем свет. Но язык трудно назвать "дружелюбным".
Поиск привел меня к интересному Opensource проекту от компании IBM с названием NodeRed
Это среда графического создания правил, работающая на известном движке NodeJs, настраиваемое прямо в браузере, позволяющая собрать всю логику управления и взаимосвязи событий в доме, буквально, из сотен готовых кубиков.
Есть стандартные кубики: привязка к нашей шине MQTT, таймеры, узлы выбора и манипуляции с событиями. Есть - устанавливаемые из внешних репозиториев:
например - интеграция с Telegram или PID регулятор, который может точно поддерживать температуру или, скажем влажность в вашем доме
Возможности по программированию сценариев ограничены только вашим воображением. В принципе, для того, чтобы далее складывать логику работы вашего дома из кубиков, даже не требуется быть программистом. Достаточно понять общую идею.
В дальнейшем, я планирую выпустить ряд видеоуроков на эту тему, а пока, самое правильное - прочитать прекрасную статью на Хабре: https://geektimes.ru/post/279814/
Примеры того, что сейчас реализовано в моем доме при помощи NodeRed:
- Перекрытие подачи уличного воздуха в квартиру, если на улице слишком холодно
- Включение освещения при обнаружении движения, если на улице темно, выключение по таймеру.
- Уведомление на месседжер и голосом через GoogleHome о движении при установленном режиме охраны, снятии, постановке на охрану, неисправностях (датчики температуры, протечки)
- Контроль счетчиков воды и протечек с уведомлением на мессаджер
- Регулировка интенсивности приточной вентиляции в зависимости от уровня CO2 в помещении.
- Включение/выключение, настройка электрических Теплых полов в зависимости от времени суток (у меня трехтарифный электросчетчик и экономия существенна)
- Управление домом при помощи радиовыключателя (в тех местах, куда в свое время не дотянул провод)
Прошивку Контроллера умного дома LightHub я доработал таким образом, чтобы было максимально удобно управлять всем из Node Red.
Основные функции, облегчающие программирование сценариев из кубиков NodeRed:
- Группы каналов. Можно обьединять в группы, фактически, любые каналы и другие группы. Например создать группу "весь свет" или "все теплые полы"
- В дополнение к стандартным командам ON и OFF добавлены HALT (выключить) и REST (включить, но только если было выключено командой HALT) - это позволило легко реализовывать удобную автоматизацию
Например, когда на улице становится очень холодно - вентиляция перекрывается. Когда теплет - открывается обратно, но только при условии, что она была изначально открыта.
Ну и такие вещи как кнопка перед выходом из дома, которая выключает все но включает только то, что было выключено - это очень удобно - Также, реализованы команды XON (включить) и XOFF (выключить, но только если было включено командой XON) - Это сделано специально, чтобы свет, включенный вручную (ON) - не выключался по таймеру датчика движения
- Подробности
- Категория: Обзоры
- Просмотров: 17665
Пластиковые окна, во многом удобны - хорошая звуко-тепло изоляция, удобно мыть и пр. но по сравнению со старыми деревянными, у них есть существенный недостаток - они почти воздухонепроницаемы. Даже те, котоые, якобы, обеспечивают проветривание. Современные деревянные окна, также, вопреки мифам, почти непроницаемы для воздуха.
Раньше предполагалось, что воздух поступает в жилище через щели в окнах а покидает через вентиляционные каналы кухонь и санузлов. Установка современных стеклопакетов перекрывает данный путь воздуха, только если не держать окно приоткрытым. Но это некомфортно в зимнее время и при условии нахождения дома в шумном месте.
Поэтому, современный дом - это, в том числе, системы управления климатом и притоком свежего воздуха
СНИП определяет довольно серьезные нормы воздухообмена, на практике, трудновополнимые. Но даже если удовлетворить их на четверть - качество жизни повышается.
Различают приточные системы вентиляции и приточно-вытяжные. Приточно-вытяжные могут быть оборудованы системами рекуперации тепла. То есть теплый "отработанный" воздух перед покиданием жилища, подогревает холодный, поступающий с улицы. Это, конечно же, эффективно, но требует приличных начальных вложений в оборудование, а также, прокладывание массы воздуховодов, которые обеспечат поступление всего отработанного воздуха в установку для "отьема" тепла.
Приточная установка забирает воздух с улицы, подогревает его и подает в жилище. Отработанный просто вытесняется в вентканалы. Такая система радикально проще в инсталляции, но расходы на подогрев внешнего воздуха будут приличные.
Пример: сейчас на улице +6 градусов, установка нагревает воздух до +23 (на 17 градусов), при этом калорифер работает на 57% полной мощности (2,4 КВт*0,57) - примерно на 1300 Вт
Возможно сократить этот расход. Варианта два:
- Подавать свежий воздух только тогда, когда он реально нужен. Об этом в статье Автоматическое управление микроклиматом дома. CO2 против влажности
- Ну или если использовать приток свежего воздуха совместно с системой центрального кондиционирования. Как известно, если кондиционер нагревает воздух, то он делает это с КПД>100% (так как для кондиционера нагрев или охлаждение - это просто перенос тепла. С улицы в дом или из дома на улицу)
В моей системе, приточная установка нагнетает воздух в приемную камеру канального кондиционера. в принципе, даже если нагнетающий вентилятор выключен - кондиционер при работе подтягивает большое кол-во воздуха с улицы, подогревает и распределяет по комнатам
Обычно при плюсовых температурах на улице количество выработанного тепла превышает величину израсходованной энергии в 2-4 раза. Если мощность потребления составила 1 кВт, то мощность обогрева будет равняться примерно 2-4 кВт. Производитель указывает номинальную мощность потребления, которая может немного не совпадать с реальными значениями.
Но надо понимать, что в зимнее время и при температурах ниже -5, работать на обогрев могут только специально предназначенные для этого модели полупромышленных кондиционеров. Эффективность их при этом понижается.
Для своих экспериментов, я взял недорогую полупромышленную канальную модель кондиционера Haier, один блок которой легко справляется более чем со 100 кв.м площади и подогревает жилище аж до морозов в -18 градусов.
Есть, конечно, и недостатки - крайне сложная интеграция устройства в Умный дом. Поддержка так и не смогла предложить удовлетворительный вариант для этого, насчитав 60 тыс за несколько абсолютно мне не нужных устройств, в том числе, пульт управления Зданием, только для того, чтобы получить стандартный modbus интерфейс управления). Но вопрос управления, удалось решить самостоятельно, при помощи одного доп модуля и решения с открытым исходным кодом. Об этом в следующем обзоре.
Интеграция кондиционеров в умный дом
Вторая проблема - после года эксплуатации разбалансировался вентилятор внутреннего блока, что увеличило шум. Поддержка полгода назад обещала заменить ... Буду держать в курсе. Если устройство удастся приручить и оно проработает еще хотя бы пару лет - пожалуй, это будет самый экономичный вариант решения вопроса кондиционирования.
Но в целом, если есть возможность - лучше выбирать полупромышленные устройства таких брендов как DAIKIN, TOSHIBA, MITSUBISHI, PANASONIC
- Подробности
- Категория: Обзоры
- Просмотров: 31392
Что такое MQTT?
MQTT или Message Queue Telemetry Transport – это легкий открытый протокол обмена данными, работающий поверх TCP/IP, созданный для унификации обмена данных между устройствами M2M (Машинно-Машинное взаимодействие) и IIoT (Промышленный Интернет вещей).
Идеален для использования в контроллерах и датчиках где требуется небольшой размер кода и есть ограничения по пропускной способности канала.
Особенности протокола MQTT
Основные особенности протокола MQTT:
- Асинхронный протокол
- Компактные сообщения
- Работа в условиях нестабильной связи на линии передачи данных
- Поддержка нескольких уровней качества обслуживания (QoS)
- Легкая интеграция новых устройств
Протокол MQTT работает на прикладном уровне поверх TCP/IP и использует по умолчанию 1883 порт (8883 при подключении через SSL). Также, возможна работа через Winsocket
Обмен сообщениями в протоколе MQTT осуществляется между клиентом (client), который может быть издателем или подписчиком (publisher/subscriber) сообщений, и брокером (broker) сообщений (например, открытое ПО Mosquitto MQTT).
Издатель отправляет данные на MQTT брокер, указывая в сообщении определенную тему, топик (topic). Подписчики могут получать разные данные от множества издателей в зависимости от подписки на соответствующие топики.
Устройства MQTT используют определенные типы сообщений для взаимодействия с брокером, ниже представлены основные:
- Connect – установить соединение с брокером
- Disconnect – разорвать соединение с брокером
- Publish – опубликовать данные в топик на брокере
- Subscribe – подписаться на топик на брокере
- Unsubscribe – отписаться от топика
Топики представляют собой иерархическую структуру, похожую на путь в файловой системе. Например:
myhome/kitchen/temperature
myhome/kitchen/light
Все устройства, которые заинтересованы в получении обновлений информации по всему, например, что происходит на кухне, могут подписаться на топик myhome/kitchen/# (#-специальный символ, аналогичный "*" в файловых системах)
Датчик температуры публикует свои измерения в топик /myhome/kitchen/temperature
Выключатель - в топик /myhome/kitchen/light
Преимущества использования MQTT для устройств
- Является стандартом де-факто для современных облачных систем IoT (см обзор). Данный протокол поддерживается абсолютно всеми современными облачными и On Premises системами IoT
- Развитая экосистема opensource решений автоматизации и диспетчеризации, в том числе: HomeAssistant, OpenHab, Wiren Board, Node Red - (см. Обзор) - это позволяет оконечным устройствам легко использовать уже имеющееся ПО без необходимости разрабатывать Web- интерфейсы, мобильные приложения, Rule-engines и пр.
- ПО MQTT брокера, также, доступно в открытом исходном коде и портировано под основные ОС (https://mosquitto.org/)
- Поддержка данного протокола устройством позволяет использовать его совместно с большим кол-вом уже существующего ПО и легко интегрировать новые устройства
- Библиотеки для реализации клиентской части данного протокола, также, доступны в исходном коде и могут быть легко интегрированы в ваш проект
Недостатки и особенности реализации MQTT
Протокол хорошо специфицирует такие операции как подписка на информацию (топик) и публикацию информации в топик, но сам формат данных оставляет на усмотрение приложений IoT
Это привело к тому, что разные системы используют разные форматы данных и оказываются, на деле, несовместимы между собой
Например, популярные OpenSource системы управления УД: OpenHab, HomeAssistant и IOBroker поддерживают MQTT. Но при этом напрямую, не совместимы.
На мой взгляд, самая обширная и продуманная реализация MQTT из этих трех систем, у HomeAssistant. По крайней мере, она подразумевает разумную иерархию топиков. И поддерживает аж три формата взаимодействия, включая JSon. Также, описывает формат управления для типовых устройств Умного дома, таких как освещение, термостат и пр.
Отдельно стоит упомянуть MQTT Autodiscovery - механизм, при помощи которого HomeAssistant может одним кликом добавлять новые устройства, которые особым образом анонсируют себя на шине MQTT
Начиная с версии 2.4, OpenHab, также, анонсировал новый драйвер MQTT, в том числе, с поддержкой конвенции homie и AutoDiscovery
К сожалению, мои эксперименты с новым драйвером, проведенные некоторое время назад, показали, что он нестабилен. (если ситуация изменилась - обязательно отпишитесь в комментариях)
Старый драйвер стабилен, но достаточно примитивен. Подразумевает использование в качестве MQTT Payload простых команд: "ON", "OFF", цифровые значения датчиков, разделенные запятыми. Можно прикрутить JSon, но настройка этого крайне неудобна. Также, плоская как блин структура Item-ов OpenHab все еще крайне натянуто ложится на иерархическую структуру мира. Дальнейшие эксперименты я не проводил, так как постепенно перешел на HomeAssistant
IOBroker имеет более-менее продуманную структуру топиков, но вот беда, его авторам понадобилось зачем-то доработать сам брокер, отступив от стандарта.
Доработка заключается в том, что MQTT брокер, входящий в состав IOBroker-а не отправляет информацию обратно тому клиенту, который ее направил, даже если он в явном виде подписался на данный топик.
Сделано это, вероятно, для того, чтобы избежать закольцовывания сообщений между клиентом и брокером. Хотя разумная архитектура, а именно, разнесение командных топиков, через которые происходит управление устройствами, и статусных - это те, в которых устройства уведомляют брокер (и всех, кому это интересно) о смене своего состояния - решают данную проблему.
Можно спорить о том, полезная доработка или нет, но она уже привела к тому, что те устройства, которые делаются под IOBroker в принципе, не работают со стандарным Mosquitto, так как не заботятся о правильной архитектуре топиков, уповая на "костыль", внедренный в IOBroker. Любое отступление от стандартов - это всегда плохо.
MQTT в контроллере LightHub
В своем контроллере LightHub, я уже несколько раз усовершенствовал интерфейс, отвечающий за интерпретацию MQTT. Описание текущего интерфейса приведено здесь
Сейчас частично поддерживается конвенция homie, которая определяет рациональную и унифицированную иерархию MQTT топиков устройства, а также, публикует служебную информацию, при помощи которой, системы управления смогут автоматически настраиваться на те устройства, которыми управляет контроллер.
Также, контроллер может работать одновременно с системами OpenHab, HomeAssistant и IOBroker. Также, участники сообщества адаптировали контроллер под Domotics.
Данные особенности, тем не менее, не мешают использовать MQTT для межмашинного взаимодействия уже сегодня.
Конвертация форматов может производиться специально разработанным клиентом, подписывающимся на сообщения одного формата и публикующих их в другом формате в другие топики. У меня, например, ранее с такой конвертацией прекрасно справлялся NodeRed, не требуя ни строчки кода.
В статье использованы материалы из Wikipedia и IPC2u