Подключение Xiaomi Mijia Bluetooth Thermometer в Home Assistant с помощью ESP32
В экосистеме компании Xiaomi есть датчик температуры и влажности Mijia Hygrothermograph с дисплеем, подключаемый по Bluetooth. Подключить этот датчик в приложение Mi Home можно непосредственно с телефона, либо через BLE шлюз. В качестве BLE шлюзов выступают ночные светильники Mijia Bed Side Lamp первого поколения, камера видеонаблюдения Mijia Smart Home Camera, умная колонка Yeelight Voice Assistant и другие устройства, но проблема в том, что эти шлюзы не позволяют пробрасывать подключенные устройства в альтернативные системы автоматизации.
Подключить такое устройство в Home Assistant возможно через Bluetooth компьютера, на котором установлена система автоматизации (в случае Raspberry Pi), или сделать BLE шлюз на основе платы ESP32 стоимостью
На всем известной китайской торговой площадке была заказана плата ESP32. Плата имеет Wi-Fi и Bluetooth интерфейсы, 4 мегабайта памяти, контроллер CP2102 и порт micro-ubs. Наличие контроллера CP2102 позволяет перепрашивать плату подключив ее к компьютеру кабелем micro-usb.
Метеостанция Xiaomi Mijia Thermometer 2 ► УМНЫЙ термометр-гигрометр СЯОМИ / Hygrothermograph 2
Прошивка платы ESP32
На плату будет залита прошивка, созданная в ESPHome, после чего она будет работать как полноценный BLE шлюз. Программная часть будет установлена на Raspberry Pi, а плата для первоначальной прошивки подключена к малинке кабелем micro-usb.
Для установки программной части подключаемся к Raspberry Pi по SSH. Устанавливаем Python3 т.к. поддержку Python2 обещают в скором времени вырезать.
Т.к. Raspberry Pi оснащена bluetooth модулем, запустим сканер для определения MAC адресов необходимых нам устройств:
После нахождения всех необходимых устройств прерываем работу сканера комбинацией клавиш:
Запускаем программное обеспечение ESPHome:
В браузере открываем страницу:
Создаем новый проект нажав + в правом нижнем углу. Последовательно заполняем необходимые поля:
- Node Name — Уникальное имя node. Имя вводится латиницей в нижнем регистре, допускаются цифры и символ подчеркивания
- Device Type — Тип устройства, для нашего проекта выбираем NodeMCU-32S
- WiFi Integration -> + . В списке находим ESPHome , заполняем IP адрес нашего BLE шлюза, порт по умолчанию 6053 , подтверждаем конфигурацию, в следующем окне вводим пароль, указанный в разделе api в конфигурационном файле устройства.
После подключения заходим в устройства Configuration -> Devices , находим подключенный BLE ESP32 шлюз.
Помимо сенсоров самой платы в списке отображаются сенсоры bluetooth термометра Mijia Hygrothermograph. Теперь их можно добавить на панель Lovelace .
Автоматизация
Следующая автоматизация будет управлять розеткой, к которой подключен увлажнитель воздуха. При падении влажности в помещении ниже 35% розетка будет включаться и при превышении 55% отключаться. В Configuration -> Automation или в automation.yaml добавляем:
Следующая автоматизация будет уведомлять о низком заряде батареи в устройстве.
Используя плату NodeMCU-32S и программное обеспечение проекта ESPHome, мы получили полноценный BLE шлюз, подключили к нему градусник Mijia Hygrothermograph, прокинули его в Home Assistant и задействовали его в домашних автоматизациях.
К минусам данного решения можно отнести только то, что при подключении нового Bluetooth устройства необходимо добавлять его в конфигурационный файл и заново прошивать устройство.
К плюсам относится, что плата может работать автономно, достаточно только питания 5V через micro-usb провод, последующие прошивки можно производить, не подключая устройство к компьютеру.
Xiaomi ClearGrass CGG1: датчик температуры и влажности с Bluetooth
В этом обзоре мы с вами рассмотрим беспроводной Bluetooth датчик температуры и влажности для экосистемы умного дома Xiaomi c экраном на электронных чернилах, от бренда ClearGrass. Я расскажу про возможности его применения в mihome, а также способе интеграции в Home Assistant.
Поставка
Поставляется устройство в коробке из белого картона с его фотографией на фронтальной стороне и параметрами сзади. Так как производитель не Xiaomi, принадлежность к экосистеме выдает надпись на коричневом треугольнике слева вверху. Она означает — продукт коммерческой платформы экосистемы Xiaomi. Справа — надпись о совместимости с умным домом mijia
Приступим к осмотру. Датчик в транспортировочном состоянии отключен от питания, экран инвертирован — белые символы на черном фоне.
В комплекте датчик и подставка для крепления на стене. Датчик с подставкой соединяются при помощи магнитов.
Подставка со стороны крепления к датчику имеет круглый выступ, который служит для его центрирования. На задней стороне — кусок двустороннего скотча, предназначенный для крепления, например, на стене.
Конструкция
Датчик имеет круглую форму, похож на своего Bluetooth тезку с LCD экраном. Большую часть фронтальной поверхности занимает круглый экран, внизу — отверстие для датчика влажности.
На задней стороне находятся — в верхней части выемка для установки на подставку, внутри нее — кнопка сопряжения и переключения режимов. Внизу откидывающаяся ножка, под которой находится батарейный отсек.
Эти слайды демонстрируют как датчик устанавливается на подставку. Это надо учитывать перед тем как наклеивать ее на стену, так как есть риск случайно прикрепить ее не той стороной, а скотч держит очень крепко.
Максимальный угол откидывания ножки — почти 90 градусов. Под ней на корпусе находится круглая поворотная крышка батарейного отсека
Элемент питания — CR2430, для его установки необходимо снять защитную ленту. Ставим батарейку на место и закрываем отсек крышкой, нужно убедится что она провернулась и держится надежно.
После подачи питания, экран переходит в рабочий режим — белый фон, черные символы. В самом верху — руна Bluetooth и уровень заряда, Верхняя половина экрана — температура, нижняя — влажность.
Если датчик не планируется клеить к стене — то он отлично стоит на своей ножке — подставке. Устойчив даже при таком небольшом угле.
Еще раз напомню про кнопку, которая находится сзади вверху и утоплена в паз
Короткое нажатие на нее переключает показания термометра датчика из градусов цельсия в фаренгейты и обратно.
Сравнение
Сравнительно с круглым датчиком с LCD экраном — герой обзора существенно больше. После того как показания датчиков устаканились — а оба датчика очень чуткие и моментально реагируют когда берешь их в руки, разница оказалась в две десятых по температуры и пол процента по влажности.
Вид с торца — CGG1 оказался примерно на 25% более тонким своего собрата по цеху. Чисто визуально он выглядит лучше, из-за большего по размерам и более контрастного экрана.
А это большой, прямоугольный климат датчик с часами, его экран тоже выполнен по технологии электронных чернил. По температуре оба датчика тоже гуляют в пределах пары десятых градуса, расхождение по влажности в пределах процента. Это кстати наиболее часто встречающийся показатель при сравнении любых датчиков экосистемы.
В этом сравнении мне больше нравится датчик с часами. Цена у них сопоставимая, причем герой обзора чаще дороже, экраны одинаково хороши по контрастности, но прямоугольная версия имеет часы и больший экран. Хотя из-за габаритов не везде сможет вписаться в интерьер.
Mihome
После подачи питания приложение обнаруживает новый датчик и предлагает его установить. Для перевода в режим синхронизации.
Далее нужно подождать пару минут, пока пройдет процесс синхронизации. Обмен данными происходит по Bluetooth, он должен быть включен
После этого датчик появляется в общем списке устройств. У него имеется собственный плагин, который показывает текущие значения температуры и влажности, в нижней части окна плагина — исторические данные в разделе дня, недели и месяца. Со временем они будут накапливать статистику и рисовать графики изменений этих параметров.
В настройках плагина ничего особенного нет, все стандартно — например можно вынести плагин сразу на рабочий стол, чтобы не запускать mihome, тут же имеется обновление прошивки.
Автоматизации
Датчик может участвовать в автоматизациях как условие. Можно задавать параметры на пересечение заданных границ температуры и влажности, как на увеличение так и на уменьшение от указанного значения.
Но для связи с другими устройствами системы, нужен Bluetooth шлюз. Этот датчик поддерживается всеми доступными мне для проверки шлюзами, это и люстры, и часы с поддержкой bluetooth mesh и, что очень удобно — увлажнитель smartmi, который можно применить в тандеме с этим датчиком и ничего дополнительно покупать не придется.
Например можно задать ряд условий, при которых увлажнитель будет включать более высокую скорость, а следовательно и испарять больше влаги, если относительная влажность в помещении будет падать.
Аналогично и наоборот, когда уровень влажности начнет подниматься, то увлажнитель будет уменьшать скорость, а при достижения нужного значения — переключаться на автоматический режим работы.
Home Assistant
Для работы в Home Assistant, напрямую с сервером — Raspberry, Orange, Khadas — главное наличие бортового, или USB адаптера Bluetooth, я использую кастомный компонент Xiaomi BLE monitor sensor platform. Он доступен в HACS или для отдельной установки, ссылка — https://github.com/custom-components/sensor.mitemp_bt
Для установки вручную — нужно переписать папку mitemp_bt из репозитория себе, в папку custom_components. В HACS — просто нажать установить.
На данный момент, компонент поддерживает пять типов блютуз устройств, включая и умные цветочные горшки, которые вообще мало где есть.
Для активации компоненты — не нужно прописывать каждый датчик по отдельности, это прописывается один раз. После этой записи, все обнаруженные датчики будут появляться автоматически.
Все добавленные сенсоры будут иметь шаблонное название, в домене sensor, все начинаются с mi, далее идет буква обозначающая параметр — например t для температуры и h для влажности, потом МАС адрес устройства. В атрибутах будет указана модель устройства, на этом слайде — герой обзора CGG1
Аналогичный сенсор — для круглого датчика с LCD экраном. Стоит добавить датчики могут появиться не сразу, особенно если находятся на удалении от сервера.
Для датчиков растений имеются еще параметры фертильности почвы и уровня освещения.
И что особенно радует — это поддержка умных цветочных горшков. Это довольно редкий гаджет, поэтому очень тяжело найти компонент, который будет с ними работать.
Видео версия обзора
Источник: shamrin.ru
Опять про BLE, температуру и датчики Xiaomi
Не так давно, удалось мне обзавестись известными датчиками температуры и влажности от Xiaomi. Эти датчики заслуженно приобрели широкую известность, так как при своей достаточно низкой цене, достаточно удобны в использовании, а также умеют передавать свои показания по протоколу BLE в тот же Mi Home. К тому же весь Интернет завален вариантами подключения этих сенсоров к Home Assistant, MajorDoMo и другим системам.
Но мне этого показалось мало и захотелось все сделать по-своему (не спрашивайте меня зачем и почему, просто захотелось). А именно, захотелось прочитать данные с датчиков, которые развешены по всему дому и как-нибудь интересно с ними поработать. Потому я покопался в своих электронных закромах и нашел там модуль ESP32.
Быстрое гугление показало: ESP32 — это то, что мне нужно. Он умеет Bluetooth и WiFi, программируется из Arduino IDE и позволит мне получить показания с датчика и отправить их по WiFi куда нужно (хоть на домашний сервер, хоть в облако). К тому же, очень быстро нашелся простой и понятный туториал, который как раз решал мою задачу. Но как выяснилось, не все так просто.
Первые проблемы
Как часто бывает с примерами из Интернета, код не заработал. А ведь так хотелось… Очевидно, что нужно разбираться с этим дальше.
Не смотря на то, что у меня в закромах лежат всякие ESP32, по основному роду деятельности я прикладной разработчик. Ковыряюсь с железками (как и многие, я полагаю) только в качестве хобби. Потому достаточно быстро пришло понимание того, что без закапывания в детали дальше продвинуться не получится. Потому пришлось изучить код, немного спецификацию BLE и понять как это устроено. По результатам разбирательств пришло некоторое понимание того, как оно работает, ну и сразу же захотелось этим с кем-нибудь поделиться.
Как оно работает
Обычно устройства BLE умеют работать в 2-х режимах. Назовем их широковещательный (discover mode) и подключенный (connection mode). В широковещательном режиме устройство может рассылать пакеты, позволяющие другим Bluetooth устройствам обнаружить его и установить соединение при необходимости. При дальнейшем установлении соединения устройства могут обмениваться данными и командами.
Некоторые устройства упаковывают какие-то данные о себе прямо в широковещательные пакеты. Это некоторым образом упрощает взамодействие с устройством, а также в числе прочих средств позволяет экономить энергию.
Сенсор Xiaomi умеет работать в двух режимах, и в Интернетах можно найти примеры работы как с широковещательными пакетами так и в режиме соединения. В найденном ранее руководстве используется вариант подслушивания широковещательных пакетов. Достаточно просто чтобы можно было быстро разобраться. Осталось только выяснить, что же не так.
Так что все-таки сломалось?
Код примера работает достаточно просто. При старте устройства инициализируется процесс сканирования устройств и устанавливается класс, функции которого будут вызываться при получении пакетов от устройств (advertising пакеты).
void initBluetooth() < BLEDevice::init(«»); pBLEScan = BLEDevice::getScan(); //create new scan pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks()); pBLEScan->setActiveScan(true); //active scan uses more power, but get results faster pBLEScan->setInterval(0x50); pBLEScan->setWindow(0x30); >
Пакеты от устройств обрабатываются в этой функции:
void onResult(BLEAdvertisedDevice advertisedDevice) < if (advertisedDevice.haveName() advertisedDevice.haveServiceData() !advertisedDevice.getName().compare(«MJ_HT_V1»)) < std::string strServiceData = advertisedDevice.getServiceData(); uint8_t cServiceData[100]; char charServiceData[100]; strServiceData.copy((char *)cServiceData, strServiceData.length(), 0); Serial.printf(«nnAdvertised Device: %sn», advertisedDevice.toString().c_str()); for (int i=0;istd::stringstream ss; ss ; switch (cServiceData[11]) < case 0x04: sprintf(charValue, «%02X%02X», cServiceData[15], cServiceData[14]); value = strtol(charValue, 0, 16); if(METRIC) < current_temperature = (float)value/10; >else < current_temperature = CelciusToFahrenheit((float)value/10); >displayTemperature(); break; case 0x06: sprintf(charValue, «%02X%02X», cServiceData[15], cServiceData[14]); value = strtol(charValue, 0, 16); current_humidity = (float)value/10; displayHumidity(); Serial.printf(«HUMIDITY_EVENT: %s, %dn», charValue, value); break; case 0x0A: sprintf(charValue, «%02X», cServiceData[14]); value = strtol(charValue, 0, 16); Serial.printf(«BATTERY_EVENT: %s, %dn», charValue, value); break; case 0x0D: sprintf(charValue, «%02X%02X», cServiceData[15], cServiceData[14]); value = strtol(charValue, 0, 16); if(METRIC) < current_temperature = (float)value/10; >else < current_temperature = CelciusToFahrenheit((float)value/10); >displayTemperature(); Serial.printf(«TEMPERATURE_EVENT: %s, %dn», charValue, value); sprintf(charValue, «%02X%02X», cServiceData[17], cServiceData[16]); value2 = strtol(charValue, 0, 16); current_humidity = (float)value2/10; displayHumidity(); Serial.printf(«HUMIDITY_EVENT: %s, %dn», charValue, value2); break; > > >
Очевидно, проблема где-то здесь.
Основное действие в этом коде происходит в конструкции switch, где проверяется значение 11го байта в service data массиве. Проблема только в том, что в моем случае массив данных был меньше 11 байт. Осталось выяснить почему.
Каждый advertising пакет помимо информации о возможности соединения с устройством может содержать пакет данных (payload). Этот пакет содержит расширенные данные об устройстве, также данные о сервисах, которые поддерживает устройство. В одном пакете может быть информация о нескольких сервисах. Типичный payload моих устройств выглядит так (это отдельные байты в шестнадцатиричной системе счисления):
020106121695fe5020aa01ab9f0231342d580a10014309094d4a5f48545f563105030f180a180916ffffc8b33f8a48db
Информация здесь кодируется достаточно просто. Первый байт (в примере 0x02) задает размер блока в байтах. За ним следует байт, который указыает назначение блока (подробно о типах блоков здесь). Затем следуют данные в зависимости от типа блока.
Ну и дальше все повторяется (опять появляется длина блока) пока не закончится пакет данных.
Нас больше всего интересют блоки с типом 0x16, которые отвеают за service data, т.е. за данные, описывающие отдельные функции устройства. В нашем примере таких блоков 2:
121695fe5020aa01ab9f0231342d580a100143 0916ffffc8b33f8a48db
Если присмотреться поближе, то можно заметить, что 11й байт в первом блоке очень похож, на тот, что ожидает наш switch (0x0A). А второй блок как раз похож на тот, слишком короткий блок, на который мы ссылались в начале. Похоже здесь и порылась собака. Похоже, что наш код ожидает видеть первый блок, а получает второй.
Почему так вышло?
Может у нас какие-то не такие устройства, а может у автора кода другие, но факт остается фактом, у нас оно так не работает. Самое время посмотреть в исходники библиотеки ESP32 для Arduino. Не будем вдаваться в подробности, но по этому коду видно, что getServiceData должен иметь параметр с индексом блока данных, который найден в пакете.
Т.е. в библиотеке предусмотрена возможность того, что payload может содержать несколько блоков service data. Однако, не все так просто. Оказывается, что эта ветка изменений на момент написания этой заметки еще не опубликована (текущая версия релиза 1.0.4). И просто так скачав в Arduino IDE все необходимое для ESP32 через Boards Manager будет получена более старая версия библиотеки.
И как раз в этой версии функция getServiceData() всегда возвращает последний блок service data. Это не очень приятно, но всегда можно использовать последнюю версию библиотеки. Главное, что мы смогли понять в чем была проблема.
Финальный код
С новой библиотекой решить проблему можно будет очень просто. Но не очень хочется создавать зависимость от новой версии библиотеки. Мы можем добавить простой код, который сделает то, что нужно нам нужно и так. Для этого нам нужен код, который в payload найдет нужный нам блок service data (в примере ниже функция findServiceData).
class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks < uint8_t* findServiceData(uint8_t* data, size_t length, uint8_t* foundBlockLength) < // пэйлоад у состоит из блоков [байт длины][тип блока][данные] // нам нужен блок с типом 0x16, следом за которым будет 0x95 0xfe // поэтому считываем длину, проверяем следующий байт и если что пропускаем // вернуть надо указатель на нужный блок и длину блока uint8_t* rightBorder = data + length; while (data < rightBorder) < uint8_t blockLength = *data; if (blockLength < 5) < // нам точно такие блоки не нужны data += (blockLength+1); continue; >uint8_t blockType = *(data+1); uint16_t serviceType = *(uint16_t*)(data + 2); if (blockType == 0x16 serviceType == 0xfe95) < // мы нашли что искали *foundBlockLength = blockLength-3; // вычитаем длину типа сервиса return data+4; // пропускаем длину и тип сервиса >data += (blockLength+1); > return nullptr; > void onResult(BLEAdvertisedDevice advertisedDevice) < if (!advertisedDevice.haveName() || advertisedDevice.getName().compare(«MJ_HT_V1»)) return; // нас интересуют только устройства, которые транслируют нужное нам имя uint8_t* payload = advertisedDevice.getPayload(); size_t payloadLength = advertisedDevice.getPayloadLength(); Serial.printf(«nnAdvertised Device: %sn», advertisedDevice.toString().c_str()); printBuffer(payload, payloadLength); uint8_t serviceDataLength=0; uint8_t* serviceData = findServiceData(payload, payloadLength, if (serviceData == nullptr) < return; // нам этот пакет больше не интересен >Serial.printf(«Found service data len: %dn», serviceDataLength); printBuffer(serviceData, serviceDataLength); // 11й байт в пакете означает тип события // 0x0D — температура и влажность // 0x0A — батарейка // 0x06 — влажность // 0x04 — температура switch (serviceData[11]) < case 0x0D: < float temp = *(uint16_t*)(serviceData + 11 + 3) / 10.0; float humidity = *(uint16_t*)(serviceData + 11 + 5) / 10.0; Serial.printf(«Temp: %f Humidity: %fn», temp, humidity); >break; case 0x04: < float temp = *(uint16_t*)(serviceData + 11 + 3) / 10.0; Serial.printf(«Temp: %fn», temp); >break; case 0x06: < float humidity = *(uint16_t*)(serviceData + 11 + 3) / 10.0; Serial.printf(«Humidity: %fn», humidity); >break; case 0x0A: < int battery = *(serviceData + 11 + 3); Serial.printf(«Battery: %dn», battery); >break; default: break; > > >;
Вывод
Вся проделанная работа в очередной раз показыает, что не всегда код из Интернета хорошо работает. Будь-то пример для ESP32 или кусок кода со StackOverflow, крайне желательно все же понимать как оно работает. Всегда могут появиться не самые стандартные случаи, которые заставят код развалиться. Хорошо, когда это происходит в хобби-проектах, но, очевидно, никому не хотелось бы наталкиваться на подобные случаи в боевом коде. Давайте будем осторожны с использованием чужого кода, ну или по крайней мере попытаемся в нем разбираться.
Как-то длинновато получилось, но надеюсь, что кому-то это будет полезно. Со своей же стороны, надеюсь, что этому эксперименту будет продолжение, и данные температуры все же будут отправлены дальше.
Полный код примера можно скачать здесь.
UPD: Продолжение экспериментов тут
Источник: habr.com
Подключение Xiaomi Mijia Bluetooth Thermometer в Home Assistant с помощью ESP32
В экосистеме компании Xiaomi есть датчик температуры и влажности Mijia Hygrothermograph с дисплеем, подключаемый по Bluetooth. Подключить этот датчик в приложение Mi Home можно непосредственно с телефона, либо через BLE шлюз. В качестве BLE шлюзов выступают ночные светильники Mijia Bed Side Lamp первого поколения, камера видеонаблюдения Mijia Smart Home Camera, умная колонка Yeelight Voice Assistant и другие устройства, но проблема в том, что эти шлюзы не позволяют пробрасывать подключенные устройства в альтернативные системы автоматизации.
Подключить такое устройство в Home Assistant возможно через Bluetooth компьютера, на котором установлена система автоматизации (в случае Raspberry Pi), или сделать BLE шлюз на основе платы ESP32 стоимостью ~4$.
На всем известной китайской торговой площадке была заказана плата ESP32. Плата имеет Wi-Fi и Bluetooth интерфейсы, 4 мегабайта памяти, контроллер CP2102 и порт micro-ubs. Наличие контроллера CP2102 позволяет перепрашивать плату подключив ее к компьютеру кабелем micro-usb.
Прошивка платы ESP32
На плату будет залита прошивка, созданная в ESPHome, после чего она будет работать как полноценный BLE шлюз. Программная часть будет установлена на Raspberry Pi, а плата для первоначальной прошивки подключена к малинке кабелем micro-usb.
Для установки программной части подключаемся к Raspberry Pi по SSH. Устанавливаем Python3 т.к. поддержку Python2 обещают в скором времени вырезать.
$ sudo apt install python3-pip $ sudo pip3 install setuptools $ sudo pip3 install esphome $ sudo pip3 install tornado esptool
Т.к. Raspberry Pi оснащена bluetooth модулем, запустим сканер для определения MAC адресов необходимых нам устройств:
$ sudo hcitool lescan LE Scan . 4C:65:A8:DA:02:B1 MJ_HT_V1
После нахождения всех необходимых устройств прерываем работу сканера комбинацией клавиш:
Ctrl+C
Запускаем программное обеспечение ESPHome:
$ esphome config/ dashboard
В браузере открываем страницу:
http://raspberry_ip_address:6052/
Создаем новый проект нажав + в правом нижнем углу. Последовательно заполняем необходимые поля:
- Node Name — Уникальное имя node. Имя вводится латиницей в нижнем регистре, допускаются цифры и символ подчеркивания
- Device Type — Тип устройства, для нашего проекта выбираем NodeMCU-32S
- WiFi Integration -> + . В списке находим ESPHome , заполняем IP адрес нашего BLE шлюза, порт по умолчанию 6053 , подтверждаем конфигурацию, в следующем окне вводим пароль, указанный в разделе api в конфигурационном файле устройства.
После подключения заходим в устройства Configuration -> Devices , находим подключенный BLE ESP32 шлюз.
Помимо сенсоров самой платы в списке отображаются сенсоры bluetooth термометра Mijia Hygrothermograph. Теперь их можно добавить на панель Lovelace .
Автоматизация
Следующая автоматизация будет управлять розеткой, к которой подключен увлажнитель воздуха. При падении влажности в помещении ниже 35% розетка будет включаться и при превышении 55% отключаться. В Configuration -> Automation или в automation.yaml добавляем:
— id: ‘room_humidity_below_35_percent’ alias: Room humidity below 35 percent trigger: — platform: numeric_state entity_id: sensor.mijia_bt_humidity below: ’35’ condition: [] action: — service: switch.turn_on entity_id: switch.xiaomi_socket_room_humidifier_switch data: <> mode: single — id: ‘room_humidity_above_55_percent’ alias: Room humidity above 55 percent trigger: — platform: numeric_state entity_id: sensor.mijia_bt_humidity above: ’55’ condition: [] action: — service: switch.turn_off entity_id: switch.xiaomi_socket_room_humidifier_switch data: <> mode: single
Следующая автоматизация будет уведомлять о низком заряде батареи в устройстве.
— id: ‘mijia_ble_term_low_batt’ alias: Mijia BLE termometr low battery trigger: — platform: numeric_state entity_id: sensor.mijia_bt_battery_level below: ’15’ condition: [] action: — service: notify.persistent_notification data: title: ⚠ — Battery low message: Mijia BLE termometr battery below 15 percent — service: telegram_bot.send_message data: message: Mijia BLE termometr battery below 15 percent mode: single
Итог
Используя плату NodeMCU-32S и программное обеспечение проекта ESPHome, мы получили полноценный BLE шлюз, подключили к нему градусник Mijia Hygrothermograph, прокинули его в Home Assistant и задействовали его в домашних автоматизациях.
К минусам данного решения можно отнести только то, что при подключении нового Bluetooth устройства необходимо добавлять его в конфигурационный файл и заново прошивать устройство.
К плюсам относится, что плата может работать автономно, достаточно только питания 5V через micro-usb провод, последующие прошивки можно производить, не подключая устройство к компьютеру.
Источник: stupidhouse.ru