Предыстория: в качестве одного из хобби у меня случился «Умный дом». Хочется красивых устройств, но при этом ещё хочется свободы и приватности. Поэтому занимаюсь скрещиванием ужика Xiaomi с ёжиком Home Assistant.
Для поддержания комфортных условий нам нужно знать, а что вообще у нас дома происходит. Короче говоря, нужны сенсоры. Их у Xiaomi есть много разных, но больше всего мне понравился квадратный градусник на электронных чернилах. Вот только он совсем не умный, в том смысле, что не предоставляет вообще никаких интерфейсов, кроме графического – ни тебе WiFi, ни BLE, ни ZigBee. Зато батарейки CR2032 хватает на несколько лет. Есть ещё версия с блютусом, но она чуть менее изящная – эдакий толстый блинчик.
И вот в начале весны был анонсирован новый датчик температуры/влажности, на электронных чернилах, с BLE, да ещё и с часами. Часы мне не особенно-то и нужны, а вот всё остальное немедленно подавило все рациональные доводы и градусник был заказан на одном из популярных интернет-магазинов, по предзаказу. Ехало оно ехало, и наконец приехало.
В приложение MiHome датчик добавился без проблем (у меня англоязычный интерфейс везде, с русской версией MiHome, говорят, были трудности перевода). Показывает текущие значения и историю изменения показаний.
А вот с интеграцией в Home Assistant приключились сложности. Имеющийся компонент для датчика температуры ни в какую не хотел забирать данные с устройства и жаловался на неверный формат данных. Ну, делать нечего, достаём лопату и начинаем копать.
Первой мыслью было ознакомиться с устройством протокола BLE, но оценив размер документации, было принято решение переходить к методу народного тыка.
Для начала, открываем терминал на убунте и запускаем bluetoothctl. Видим следующее:
MJ_HT_V1 – это старый датчик температуры, LYWSD02 – новый. Разница в формате именования модели несколько настораживает.
Дальше надо как-то почитать, а какие данные вообще у нас могут быть получены. Открыл исходники библиотеки mitemp, которая используется в Home Assistant для получения данных со старого датчика. Там нашёл, что используется библиотека blewrap, которая, в свою очередь, является обёрткой над двумя питоновскими библиотеками для работы с BLE. Столько много слоёв мне ни к чему, будем использовать bluepy. Документация есть, её не много и не мало, читаем и пишем скрипт, который проходит по всем полям данных, которые есть на устройстве.
В целом, всё просто – BLE-устройство предоставляет набор сервисов, каждый из которых состоит из набора характеристик. Каждая характеристика может быть одного из 8 типов, для одной характеристики можно указать несколько типов одновременно. Сервисы и характеристики идентифицируются двумя способами – адресом в виде HEX-значения и UUID. С UUID мне работать как-то привычнее.
Итак я считал все характеристики для обоих датчиков, посмотрел на них и понял, что снова под маркой Xiaomi продаются устройства от совершенно разных производителей. Среди значений старого датчика было найдено «Cleargrass Inc», а в новом – «miaomiaoce.com». Структура сервисов и характеристик у этих двух датчиков также абсолютно разные, да и список характеристик у нового датчика длиннее в два раза. Тут стало понятно, что нужно писать свою собственную библиотеку для интеграции с датчиком (нет, я конечно сначала погуглил, может есть чего полезного по запросу LYWSD02, но ничего толкового гугл не выдал).
Среди имеющихся типов характеристик, кроме READ, есть ещё WRITE и NOTIFY. WRITE – для отправки данных на устройство, а NOTIFY – для получения данных. Есть ещё одновременно WRITE NOTIFY – устройство будет отправлять данные только после того, как на них подпишутся, отправив нужный байт командой WRITE.
Попытки сделать что-то руками не принесли никакого результата, был достигнут первый рубеж отчаяния, но в этот момент я обчитался статей про поделки на базе чипов от Nordic Semiconductors и поставил на смартфон программу nRF Connect. С её помощью я смог подписаться на все сервисы, которые предоставляло устройство, сохранил логи ответов и стал пытаться понять, что в них лежит.
Вот эти тройные стрелки активируют подписку.
Особенностью старого датчика было то, что данные о температуре и влажности приходили в виде UTF-строки, новый же всё отдавал в бинарном виде.
Чтобы получать данные с датчика, нужно отправить запрос на подписку. В библиотеке mitemp для этого отправлялись два байта на характеристику, но непонятно, откуда брать её Тут я посмотрел на то, как выглядит структура данных для старого датчика в nRF Connect и заметил, что нужный адрес указан для характеристики с данными, как некий дескриптор. Тогда я снова стал читать документацию к bluepy и понял, что адрес дескриптора легко можно получить из объекта характеристики. Осталось только написать класс с методом-колбеком, в который будут поступать данные из уведомления.
К счастью, только три характеристики были помечены как WRITE NOTIFY, при этом данные приходили с различной частотой и, эм..., визуальными особенностями.
Первый запрос присылал сразу большую портянку данных, а потом залипал. При этом первый байт представлял собой монотонно возрастающее число. Похоже, что это накопленная история средних значений.
Второй и третий присылались периодически, но приглядевшись, я увидел, что один из них не меняется, а в данных второго меняется только один байт. Ну, значит, это текущее время (напомню, в этом градуснике есть часы. В любом уважающем себя устройстве для умного дома должны быть часы).
Предположим, то третья характеристика – это полезные данные о температуре и влажности. Для подтверждения гипотезы был проведён физический эксперимент – подошёл к датчику и грубо надышал на него. На дисплее резко увеличились значения данных, а в терминале – поменялись байтики. Ура, данные где-то рядом.
Я обычно работаю с текстовыми данными (получи данные по HTTP в виде JSON/xml, положи их в файл или в базу), поэтому не очень понимал, как подступиться к задаче. Поэтому начал пытаться трансформировать данные разными способами, которые можно сделать из питона. Написал вот такую функцию-конвертилку и стал смотреть, как это соотносится с данными на экране датчика.
В консоль посыпались строчки разной степени непонятности, однако третий байт всегда был числом, и это число совпадало со значением влажности. Для верности я ещё раз подышал на датчик – и значения влажности на экране и в третьем байте изменились одинаково!
Тут я предположил, что в первых двух байтах хранится температура. Для того, чтобы данные менялись – перенёс датчик на полотенцесушитель в ванной. Но, сколько я ни пытался трансформировать результаты – нужных чисел не получалось.
В этот момент я ещё раз посмотрел на описание датчика и увидел, что внутри стоит датчик от Swiss Sensirion. Наверно, стоило с этого начинать, но это же не наш метод. На сайте Swiss Sensirion была найдена пачка датчиков, и даташиты к ним. В даташите, кроме всего прочего была найдена формула для конвертации байт, передаваемых по шине I2C в число.
Но… Получались очень странные значения. Что-то типа -34.66, а у меня было явно теплее. От грусти и печали я даже вскрыл датчик и проверил, а правда ли там сенсор от Swiss Sensirion. Выяснилось, что правда, но с индексом SHTC3, и для него нужна чуть-чуть другая формула.
Однако, всё равно данные после преобразования даже близко не были похожи на реальные. Тут я ещё больше загрустил, открыл исходники библиотеки для SHTC3 от Adafruit и стал пытаться адаптировать код трансформации из C++ в питон. Вывел всё в табличку – сырые данные, преобразованную сишную структуру и результат.
Получил что-то такое:
Да… как-то холодно… Но, стоп, подождите, а что это за 2604? Это же оно, 26.0 градусов на экране! Для подтверждения гипотезы снова унёс датчик на батарею, проверил – значения совпадают.
В итоге, получаем такой код преобразования данных:
На операции по подключению к датчику и поиски правильного алгоритма трансформации ушла пара вечеров. Несколько раз хотелось всё бросить, но одновременно с этим приходили новые идеи и я продолжал попытки.
Сейчас данные передаются в Home Assistant, дальше нужно допилить код интеграции и, возможно, переписать её с bluepy на bleak, поскольку bleak использует async/await и лучше подойдёт для Home Assistant, написанного aiohttp.
Для поддержания комфортных условий нам нужно знать, а что вообще у нас дома происходит. Короче говоря, нужны сенсоры. Их у Xiaomi есть много разных, но больше всего мне понравился квадратный градусник на электронных чернилах. Вот только он совсем не умный, в том смысле, что не предоставляет вообще никаких интерфейсов, кроме графического – ни тебе WiFi, ни BLE, ни ZigBee. Зато батарейки CR2032 хватает на несколько лет. Есть ещё версия с блютусом, но она чуть менее изящная – эдакий толстый блинчик.
И вот в начале весны был анонсирован новый датчик температуры/влажности, на электронных чернилах, с BLE, да ещё и с часами. Часы мне не особенно-то и нужны, а вот всё остальное немедленно подавило все рациональные доводы и градусник был заказан на одном из популярных интернет-магазинов, по предзаказу. Ехало оно ехало, и наконец приехало.
В приложение MiHome датчик добавился без проблем (у меня англоязычный интерфейс везде, с русской версией MiHome, говорят, были трудности перевода). Показывает текущие значения и историю изменения показаний.
А вот с интеграцией в Home Assistant приключились сложности. Имеющийся компонент для датчика температуры ни в какую не хотел забирать данные с устройства и жаловался на неверный формат данных. Ну, делать нечего, достаём лопату и начинаем копать.
Первой мыслью было ознакомиться с устройством протокола BLE, но оценив размер документации, было принято решение переходить к методу народного тыка.
Первый подход к снаряду
Для начала, открываем терминал на убунте и запускаем bluetoothctl. Видим следующее:
[NEW] Controller 00:1A:7D:DA:71:13 fett [default]
[NEW] Device 3F:59:C8:80:70:BE LYWSD02
[NEW] Device 4C:65:A8:DC:0D:AF MJ_HT_V1MJ_HT_V1 – это старый датчик температуры, LYWSD02 – новый. Разница в формате именования модели несколько настораживает.
Дальше надо как-то почитать, а какие данные вообще у нас могут быть получены. Открыл исходники библиотеки mitemp, которая используется в Home Assistant для получения данных со старого датчика. Там нашёл, что используется библиотека blewrap, которая, в свою очередь, является обёрткой над двумя питоновскими библиотеками для работы с BLE. Столько много слоёв мне ни к чему, будем использовать bluepy. Документация есть, её не много и не мало, читаем и пишем скрипт, который проходит по всем полям данных, которые есть на устройстве.
from bluepy import btle
mac = '3F:59:C8:80:70:BE'
p = btle.Peripheral(mac)
for s in p.getServices():
print('Service:', s.uuid)
for c in s.getCharacteristics():
print('\tCharacteristic:', c.uuid)
print('\t\t', c.propertiesToString())
if c.supportsRead():
print('\t\t', c.read())В целом, всё просто – BLE-устройство предоставляет набор сервисов, каждый из которых состоит из набора характеристик. Каждая характеристика может быть одного из 8 типов, для одной характеристики можно указать несколько типов одновременно. Сервисы и характеристики идентифицируются двумя способами – адресом в виде HEX-значения и UUID. С UUID мне работать как-то привычнее.
Итак я считал все характеристики для обоих датчиков, посмотрел на них и понял, что снова под маркой Xiaomi продаются устройства от совершенно разных производителей. Среди значений старого датчика было найдено «Cleargrass Inc», а в новом – «miaomiaoce.com». Структура сервисов и характеристик у этих двух датчиков также абсолютно разные, да и список характеристик у нового датчика длиннее в два раза. Тут стало понятно, что нужно писать свою собственную библиотеку для интеграции с датчиком (нет, я конечно сначала погуглил, может есть чего полезного по запросу LYWSD02, но ничего толкового гугл не выдал).
Как же всё-таки получить данные?
Среди имеющихся типов характеристик, кроме READ, есть ещё WRITE и NOTIFY. WRITE – для отправки данных на устройство, а NOTIFY – для получения данных. Есть ещё одновременно WRITE NOTIFY – устройство будет отправлять данные только после того, как на них подпишутся, отправив нужный байт командой WRITE.
Попытки сделать что-то руками не принесли никакого результата, был достигнут первый рубеж отчаяния, но в этот момент я обчитался статей про поделки на базе чипов от Nordic Semiconductors и поставил на смартфон программу nRF Connect. С её помощью я смог подписаться на все сервисы, которые предоставляло устройство, сохранил логи ответов и стал пытаться понять, что в них лежит.
Вот эти тройные стрелки активируют подписку.
Особенностью старого датчика было то, что данные о температуре и влажности приходили в виде UTF-строки, новый же всё отдавал в бинарном виде.
Подписка на уведомления
Чтобы получать данные с датчика, нужно отправить запрос на подписку. В библиотеке mitemp для этого отправлялись два байта на характеристику, но непонятно, откуда брать её Тут я посмотрел на то, как выглядит структура данных для старого датчика в nRF Connect и заметил, что нужный адрес указан для характеристики с данными, как некий дескриптор. Тогда я снова стал читать документацию к bluepy и понял, что адрес дескриптора легко можно получить из объекта характеристики. Осталось только написать класс с методом-колбеком, в который будут поступать данные из уведомления.
class MyDelegate(btle.DefaultDelegate):
def handleNotification(self, cHandle, data):
print(data)
mac_addr = '3F:59:C8:80:70:BE'
p = btle.Peripheral(mac_addr)
p.setDelegate(MyDelegate())
uuid = 'EBE0CCC1-7A0A-4B0C-8A1A-6FF2997DA3A6'
# Метод всегда возвращает список, потому что может работать с диапазоном адресов
ch = p.getCharacteristics(uuid=uuid)[0]
# Получаем дескрипторы для характеристики
desc = ch.getDescriptors(forUUID=0x2902)[0]
# Значение байта, который нужно отправить был найден методом научного тыка
desc.write(0x01.to_bytes(2, byteorder="little"), withResponse=True)
while True:
p.waitForNotifications(5.0)Отделяем зёрна от плевел
К счастью, только три характеристики были помечены как WRITE NOTIFY, при этом данные приходили с различной частотой и, эм..., визуальными особенностями.
Первый запрос присылал сразу большую портянку данных, а потом залипал. При этом первый байт представлял собой монотонно возрастающее число. Похоже, что это накопленная история средних значений.
Второй и третий присылались периодически, но приглядевшись, я увидел, что один из них не меняется, а в данных второго меняется только один байт. Ну, значит, это текущее время (напомню, в этом градуснике есть часы. В любом уважающем себя устройстве для умного дома должны быть часы).
Предположим, то третья характеристика – это полезные данные о температуре и влажности. Для подтверждения гипотезы был проведён физический эксперимент – подошёл к датчику и грубо надышал на него. На дисплее резко увеличились значения данных, а в терминале – поменялись байтики. Ура, данные где-то рядом.
Разбор данных
Я обычно работаю с текстовыми данными (получи данные по HTTP в виде JSON/xml, положи их в файл или в базу), поэтому не очень понимал, как подступиться к задаче. Поэтому начал пытаться трансформировать данные разными способами, которые можно сделать из питона. Написал вот такую функцию-конвертилку и стал смотреть, как это соотносится с данными на экране датчика.
def parse(v):
print([x for x in v])
print('{0:#x}'.format(int.from_bytes(data, byteorder='big')))
print('{0:#x}'.format(int.from_bytes(data, byteorder='little')))В консоль посыпались строчки разной степени непонятности, однако третий байт всегда был числом, и это число совпадало со значением влажности. Для верности я ещё раз подышал на датчик – и значения влажности на экране и в третьем байте изменились одинаково!
Тут я предположил, что в первых двух байтах хранится температура. Для того, чтобы данные менялись – перенёс датчик на полотенцесушитель в ванной. Но, сколько я ни пытался трансформировать результаты – нужных чисел не получалось.
На пути к успеху
В этот момент я ещё раз посмотрел на описание датчика и увидел, что внутри стоит датчик от Swiss Sensirion. Наверно, стоило с этого начинать, но это же не наш метод. На сайте Swiss Sensirion была найдена пачка датчиков, и даташиты к ним. В даташите, кроме всего прочего была найдена формула для конвертации байт, передаваемых по шине I2C в число.
![$T[°C] = -45 + 175\cdot\frac{S_T}{2^16-1}$](https://habrastorage.org/getpro/habr/formulas/d61/4f5/cee/d614f5cee279e5552426bdedb578751e.svg)
Но… Получались очень странные значения. Что-то типа -34.66, а у меня было явно теплее. От грусти и печали я даже вскрыл датчик и проверил, а правда ли там сенсор от Swiss Sensirion. Выяснилось, что правда, но с индексом SHTC3, и для него нужна чуть-чуть другая формула.
![$T[°C] = -45 + 175\cdot\frac{S_T}{2^16}$](https://habrastorage.org/getpro/habr/formulas/c60/a00/f24/c60a00f24ba45f997b731473c2a1635c.svg)
Однако, всё равно данные после преобразования даже близко не были похожи на реальные. Тут я ещё больше загрустил, открыл исходники библиотеки для SHTC3 от Adafruit и стал пытаться адаптировать код трансформации из C++ в питон. Вывел всё в табличку – сырые данные, преобразованную сишную структуру и результат.
def handleNotification(self, cHandle, data):
temp = data[:2]
humid = data[2]
unpacked = struct.unpack('H', temp)[0]
print(data, unpacked, -45 + 175 * unpacked / 2 ** 19, sep='\t')Получил что-то такое:
b',\n2' 2604 -44.130821228027344
b'-\n2' 2605 -44.1304874420166
b'+\n2' 2603 -44.131155014038086
b',\n2' 2604 -44.130821228027344Да… как-то холодно… Но, стоп, подождите, а что это за 2604? Это же оно, 26.0 градусов на экране! Для подтверждения гипотезы снова унёс датчик на батарею, проверил – значения совпадают.
В итоге, получаем такой код преобразования данных:
def handleNotification(self, cHandle, data):
humid_bytes = data[2]
temp_bytes = data[:2]
humidity = humid_bytes
temperature = struct.unpack('H', temp_bytes)[0] / 100
print(temperature, humidity)
Эпилог
На операции по подключению к датчику и поиски правильного алгоритма трансформации ушла пара вечеров. Несколько раз хотелось всё бросить, но одновременно с этим приходили новые идеи и я продолжал попытки.
Сейчас данные передаются в Home Assistant, дальше нужно допилить код интеграции и, возможно, переписать её с bluepy на bleak, поскольку bleak использует async/await и лучше подойдёт для Home Assistant, написанного aiohttp.
