В очередной раз я заболел.
В прошлый раз это был ковид: тогда я плохо понимал, что со мной происходит, и ситуация едва не закончилась совсем плохо. В этот раз всё выглядело банальнее — высокая температура, которая долго не сбивалась.
Обычный градусник показывал 38–39 °C. И вроде бы все мы понимаем: если температура высокая, долго держится и стандартные средства не помогают, это уже повод как минимум связываться с врачом. Но есть нюанс: чтобы принимать решения не на ощущениях, а на данных, температуру нужно измерять регулярно.
А вот тут начинается бытовая инженерия.
Проблема обычного градусника
На бумаге всё просто: взял градусник, измерил температуру, записал результат, повторил через час.
В реальности, особенно ночью, это выглядит иначе.
Если это стеклянный градусник, сначала его нужно сбросить. Потом засунуть под мышку, подождать около десяти минут, достать и попытаться в темноте рассмотреть показания. При этом надо не уронить его, не разбить и положить куда‑то так, чтобы он не укатился.
С электронным градусником чуть проще: он хотя бы не разбивается и умеет пищать. Но сценарий остаётся примерно тем же. Проснулся, засунул под мышку, дождался сигнала, ещё немного подождал, чтобы показания стабилизировались, потом в темноте ищешь телефон, включаешь фонарик, светишь на дисплей и пытаешься понять, что там написано.
А потом надо не забыть повторить всё это через час.
Когда у тебя температура под 39, это уже не очень удобный пользовательский интерфейс.
Техническое задание от человека с температурой 39
Мне хотелось сделать систему, которая:
сама регулярно измеряет температуру;
не требует включать свет ночью;
не заставляет читать мелкие цифры на дисплее;
умеет отправлять данные в систему умного дома;
может озвучить текущую температуру через колонку;
уведомляет, если температура достигает опасного порога;
позволяет вручную запросить текущее значение.
То есть задача была не просто «измерить температуру», а убрать из процесса больного человека как слабое звено.
Версия 0.1: киберпанк под мышкой
Первый прототип я решил собрать максимально быстро и из того, что уже было под рукой.
В качестве контроллера использовал миниатюрную плату на ESP32-C3. В качестве прошивки — ESPHome, потому что она отлично интегрируется с Home Assistant, позволяет быстро описать устройство YAML‑конфигурацией и не требует каждый раз писать прошивку вручную.
Для измерения температуры взял герметичный датчик DS18B20. Это цифровой температурный датчик, который часто используют в DIY‑проектах: он недорогой, простой, работает по 1-Wire и продаётся в герметичном исполнении на проводе.
Идея выглядела так:
На уровне идеи всё выглядело почти как медицинский wearables‑девайс.
На уровне реальности — как человек, подключённый проводом к плате разработки.
Ожидание и реальность
В голове это выглядело примерно так:
аккуратный маленький датчик, удобное крепление, ненавязчивый мониторинг температуры и голосовые уведомления.
А в реальности получилось немного иначе:
ESP32-C3, провод питания, провод датчика, датчик под мышкой, попытки удобно лечь и не выдернуть всё это во сне.
С эстетикой медицинского прибора было плохо. С инженерной точки зрения — уже гораздо лучше: температура действительно измерялась, данные попадали в Home Assistant, а автоматизации могли реагировать на значения.
Девайс выглядел примерно так:
Конфигурация ESPHome
Конфигурация ESPHome получилась довольно короткой. ESP32-C3 подключается к Wi‑Fi, поднимает API для Home Assistant, а DS18B20 опрашивается через GPIO по 1-Wire.
Пример конфигурации:
Скрытый текст
esphome: name: body-thermometer friendly_name: body-thermometer esp32: board: esp32-c3-devkitm-1 framework: type: esp-idf # Enable logging logger: # Enable Home Assistant API api: ota: - platform: esphome wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Body-Thermometer" password: "PoSMCx1mm" captive_portal: one_wire: - platform: gpio pin: GPIO4 sensor: - platform: dallas_temp name: "Body Temperature" id: body_temperature update_interval: 1min accuracy_decimals: 1 filters: - sliding_window_moving_average: window_size: 5 send_every: 1 - platform: wifi_signal name: "Thermometer WiFi Signal" update_interval: 60s binary_sensor: - platform: gpio name: "Thermometer Physical Button" id: measure_button pin: number: GPIO9 mode: INPUT_PULLUP inverted: true filters: - delayed_on: 30ms - delayed_off: 30ms on_press: then: - component.update: body_temperature button: - platform: template name: "Measure Body Temperature" id: measure_body_temperature on_press: then: - component.update: body_temperature
Я специально добавил сглаживание через sliding_window_moving_average, потому что при таком способе крепления датчика показания могут немного гулять. Особенно в первые минуты, пока датчик, провод и окружающая среда приходят к более‑менее стабильному состоянию.
Интервал измерения в примере — 30 секунд. Его можно увеличить, если питание от батареи важнее оперативности, или уменьшить, если хочется быстрее видеть динамику.
Автоматизация в Home Assistant
Дальше всё завязано на Home Assistant.
Нажал на устройстве кнопку. Команда улетелоа в HA. Там запустилась автоматизация:
Колонка говорит «Измеряю темературу»
Ждет 5 секунд (к этом моменту пользователь уже должен держать градусник правильно некоторое время достаточное для корректного его нагревания).
Сообщает результаты измерения
Код
Скрытый текст
alias: Озвучить температуру по нажатию кнопки description: При нажатии кнопки ждёт 5 секунд, читает температуру с датчика и произносит её triggers: - type: turned_on device_id: f1c5a51417eb27d4e3791a13d371391b entity_id: a87a16acb3ad54aa3b026a59a8ebbd15 domain: binary_sensor trigger: device actions: - action: tts.speak target: entity_id: tts.google_translate_en_com data: cache: true media_player_entity_id: media_player.yandex_station_u00pty100m5svc message: Измеряю температуру - delay: seconds: 5 - variables: temperature: >- {{ states('sensor.body_thermometer_body_temperature') | float | round(1) }} - action: tts.speak target: entity_id: tts.google_translate_en_com data: cache: true media_player_entity_id: media_player.yandex_station_u00pty100m5svc message: Температура сейчас {{ temperature }} градусов mode: single
Так же есть простая автоматизация: при изменении значения сенсора проверяем, что значение валидное, приводим его к числу и дальше смотрим на пороги.
Если температура выше 38 °C — колонка может озвучить текущее значение.
Если выше 39 °C — сообщение становится более настойчивым. Это уже не просто «температура такая‑то», а предупреждение, что значение перешло в опасную зону и пора принимать решение: будить близкого человека, связываться с врачом или вызывать скорую.
Скрытый текст
alias: Непрерывное измерение температуры description: Озвучить температуру и предупредить при превышении порога triggers: - trigger: state entity_id: sensor.body_thermometer_body_temperature not_to: - unknown - unavailable - none not_from: - unknown - unavailable - none conditions: - condition: template value_template: "{{ trigger.to_state.state | float(default=0) > 0 }}" actions: - variables: temperature: >- {{ states('sensor.body_thermometer_body_temperature') | float | round(1) }} - choose: - conditions: - condition: template value_template: "{{ temperature | float > 39 }}" sequence: - target: entity_id: tts.google_translate_en_com data: media_player_entity_id: media_player.yandex_station_u00pty100m5svc message: >- Внимание. Температура {{ temperature }} градусов. Температура выше тридцати девяти. action: tts.speak - conditions: - condition: template value_template: "{{ temperature | float > 38 }}" sequence: - target: entity_id: tts.google_translate_en_com data: media_player_entity_id: media_player.yandex_station_u00pty100m5svc message: Температура {{ temperature }} градусов. action: tts.speak default: [] mode: single
Почему это не медицинский прибор
Здесь важно сделать оговорку.
DS18B20 измеряет температуру самого датчика, а не «медицинскую температуру тела» в строгом смысле. На показания влияет контакт с кожей, положение датчика, теплоизоляция, время стабилизации и даже то, насколько плотно прижата рука.
Поэтому такой прототип нельзя считать медицинским прибором.
Это скорее домашний мониторинг тренда: температура растёт, падает, стабилизировалась или ушла в опасную зону.
Но даже в таком виде система уже решала главную бытовую проблему: мне не нужно было каждый раз просыпаться, включать свет, искать градусник и пытаться что‑то разглядеть в темноте.
Версия 0.2: нормальный градусник вместо провода под мышкой
Когда мне стало немного полегче, я решил перейти от «ESP32, провод и датчик под мышкой» к более аккуратному варианту.
Под рукой был медицинский Bluetooth‑градусник RELSIB WT50. Это не реклама, а просто устройство, которое оказалось у меня дома (друзья подарили, когда я занимался IOT платформой) и хорошо легло в задачу: нормальный медицинский термометр (производитель заявляет, что нет никаких отклонений при сравнении с ртутными градусниками в отличии от цифровых, продаваемых в аптеках), Bluetooth, приложение для телефона и возможность получать температуру не глазами с маленького дисплея, а в цифровом виде.
Изначально устройство рассчитано на работу со своим мобильным приложением. Но мне хотелось не просто смотреть температуру в отдельном приложении, та же самая волокита: возьми телефон, включи приложение (ночью выжги светом глаза), запусти, жди и прочее. Мне хотелось встроить градусник в уже существующую систему умного дома.
Идеальный сценарий был таким:
градусник измеряет температуру;
данные попадают в Home Assistant;
Home Assistant строит график и хранит историю;
колонка может озвучить текущую температуру;
при превышении порога срабатывает уведомление;
при необходимости можно запустить заранее подготовленную автоматизацию.
Немного BLE: что именно я начал изучать
Для начала я накидал небольшой Python‑инструмент с GUI, который искал BLE‑устройства рядом и показывал данные, которые удавалось получить от термометра.
Тут важно не перепутать термины.
В BLE есть широковещательные пакеты — advertising packets. Именно по ним устройство можно обнаружить при сканировании. В бытовом смысле это и есть «градусник вещает в эфир: я здесь».
Но сами показания температуры в нормальной BLE‑модели обычно живут не просто в «каких‑то широковещательных данных», а в структуре GATT: сервисы, характеристики, уведомления/индикации.
В случае медицинских термометров есть стандартный профиль Health Thermometer Profile. Он описывает взаимодействие между термометром и устройством‑сборщиком данных.
То есть хорошая новость была в том, что это не выглядело как полностью закрытый самописный протокол. По крайней мере базовый сценарий чтения температуры можно было попытаться реализовать через стандартные BLE‑механизмы.
Python GUI для разведки
Чтобы не писать сразу полноценную интеграцию, я начал с разведочного инструмента на Python.
Задачи у него были простые:
сканировать BLE‑устройства рядом;
находить градусник RELSIB WT50;
показывать advertising‑данные;
подключаться к устройству;
смотреть доступные GATT‑сервисы и характеристики;
получать температуру в итеративном режиме;
пробрасывать полученные значения дальше в Home Assistant.
Получился небольшой GUI‑инструмент для экспериментов: включаешь градусник, видишь его среди BLE‑устройств, подключаешься, смотришь, что приходит, и проверяешь, как эти данные можно превратить в нормальный сенсор Home Assistant.
Код пока не выкладываю — связался с производителем устройства, получил их локальный протокол не только Health Thermometer Profile, как только получу разрешение — добавлю ссылку на github.
На этом этапе мне было важно не «сразу сделать красиво», а понять главное:
как устройство называется в BLE‑сканировании;
какие сервисы и характеристики оно отдаёт;
нужно ли подключение;
приходят ли промежуточные значения температуры;
как часто обновляются данные;
можно ли стабильно прокидывать их в Home Assistant.
Прокидывание данных в Home Assistant через MQTT
Первые рабочие данные из Python‑приложения я прокидывал в Home Assistant через MQTT.
Мне не хотелось каждый раз вручную создавать сенсор в Home Assistant, прописывать configuration.yaml, перезапускать HA и потом проверять, правильно ли подтянулись значения. Поэтому я сделал self‑provisioning устройства: приложение само публиковало в MQTT не только значения температуры, но и конфигурацию для Home Assistant MQTT Discovery.
В итоге схема получилась такой:
То есть после запуска приложения Home Assistant сам видел новое устройство и создавал нужную сущность температуры.
Это оказалось очень удобно на этапе экспериментов: можно менять код, формат данных, имя устройства, топики и не тратить время на ручную настройку сенсоров.
В состояние можно отправлять не только температуру, но и дополнительные диагностические поля, которые полезны при отладке:
battery— если удаётся получить заряд;rssi— уровень сигнала BLE;updated_at— время последнего обновления;служебные признаки подключения или ошибки чтения.
Для Home Assistant главным полем была температура. Но при разработке интеграции дополнительные поля очень помогают понять, что именно сломалось: градусник далеко, BLE‑соединение отвалилось, приложение не получает данные или MQTT не доставляет сообщения.
Почему MQTT
MQTT оказался удобным по нескольким причинам.
Во‑первых, Home Assistant хорошо умеет работать с MQTT Discovery. Это позволяет не городить отдельную интеграцию на первом этапе.
Во‑вторых, MQTT хорошо ложится на модель «есть внешний сборщик данных, который периодически публикует состояние».
В‑третьих, это удобно отлаживать. Можно отдельно смотреть:
видит ли приложение градусник;
публикует ли оно сообщения;
доходят ли сообщения до брокера;
создаётся ли сущность в Home Assistant;
обновляется ли температура в интерфейсе.
Для первого рабочего прототипа это сильно быстрее, чем сразу писать полноценную HACS‑интеграцию.
Что дальше: HACS и Bluetooth Proxy
Дома у меня уже есть несколько Bluetooth‑устройств, а также ESPHome Bluetooth Proxy на базе ESP32. Поэтому следующий логичный шаг — уйти от Python‑скрипта на рабочей машине и сделать нормальную интеграцию для Home Assistant.
План такой:
выпустить нативную интеграцию через HACS;
добавить поддержку RELSIB WT50;
сделать набор готовых пресетов автоматизаций;
поддержать сценарии голосового оповещения;
добавить пороговые уведомления;
по возможности использовать существующие ESPHome Bluetooth Proxy в качестве BLE‑шлюзов.
Отдельно я веду переговоры с производителем градусника о возможности получить полную спецификацию протокола. Если получится договориться, интеграция может стать не просто «мы посмотрели, что летит по BLE», а полноценной поддержкой устройства с нормальным описанием всех сценариев работы.
Почему это не только мой больничный pet‑проект
Чем дальше я это делал, тем больше убеждался, что задача шире, чем «один человек заболел и решил поиграться с ESP32».
У многих дома уже есть голосовые ассистенты: Алиса, Салют, Маруся и другие устройства. Они умеют ставить таймеры, включать свет, рассказывать погоду и управлять розетками. Но при этом сценарий «у ребёнка или взрослого высокая температура, надо удобно и безопасно её контролировать ночью» до сих пор часто решается стеклянным градусником и фонариком телефона.
У моего друга за последний год дети разбили два ртутных градусника. После этого, конечно, жизнь чему‑то научила: они купили уже не ртутный, а аналоговый градусник с безопасным наполнением. Но сама проблема никуда не делась.
Любой стеклянный градусник — это всё ещё стеклянный градусник. Его можно разбить. Его нужно искать ночью. С него нужно считывать показания. Результат нужно запоминать или записывать. Измерение нужно повторять.
А если устройство умеет передавать температуру в экосистему умного дома, сценарий становится совсем другим:
Мне кажется, крупным компаниям, которые развивают экосистемы умного дома и голосовых помощников — Яндекс, Сбер, VK и другим — стоило бы посмотреть в эту сторону.
Это не «ещё один гаджет ради гаджета». Это вполне практичный сценарий, который решает проблемы аналоговых устройств:
не нужно включать свет ночью;
не нужно читать мелкий дисплей;
не нужно помнить, когда было последнее измерение;
можно строить график температуры;
можно получать голосовые уведомления;
можно заранее настроить критические пороги;
можно снизить риск историй с разбитыми стеклянными градусниками;
можно сделать устройство полезным для детей, пожилых людей и людей с ограничениями по зрению.
Да, это не отменяет врача. Да, это не превращает умный дом в медицинскую систему. Но как бытовой инструмент контроля состояния — это очень понятный и полезный сценарий.
Эх где все это было, когда мы повально болели ковидом и лично у меня в больнице температуру мерили бесконтактным градусом, который говорил что у меня 36, хотя электронный термометр показывал больше 38...
Что получилось
В итоге у меня получилось несколько уровней реализации.
Первый — совсем DIY:
ESP32-C3 + ESPHome + DS18B20 + Home Assistant
Он был быстрым, рабочим, но не очень удобным физически.
Второй — более правильный:
RELSIB WT50 + BLE + Python GUI + MQTT + Home Assistant
Он уже ближе к тому, как подобная система должна выглядеть для обычного пользователя.
И третий, пока планируемый:
RELSIB WT50 + Home Assistant HACS-интеграция + Bluetooth Proxy + автоматизации в HA
Вот это уже похоже на нормальный продуктовый сценарий.
Что я мог упустить
Я понимаю, что, возможно, уже существуют готовые решения, о которых я не знаю.
Возможно, кто‑то уже интегрировал подобные BLE‑градусники в Home Assistant. Возможно, есть более удобные устройства. Возможно, есть готовые медицинские термометры с открытым протоколом, нормальной интеграцией и поддержкой голосовых ассистентов. Возможно, я просто не нашёл их в момент, когда лежал с температурой и пытался соображать.
Поэтому буду рад комментариям.
Особенно интересно:
есть ли у вас опыт с подобными BLE‑градусниками;
какие устройства нормально интегрируются в Home Assistant;
есть ли открытые спецификации у медицинских термометров;
насколько вообще востребован сценарий голосового контроля температуры;
нужны ли готовые пресеты автоматизаций;
какие пороги и сценарии уведомлений вы бы считали разумными;
стоит ли делать отдельную HACS‑интеграцию или достаточно MQTT‑прокладки.
Важный дисклеймер
Всё описанное выше — не медицинская рекомендация и не замена врачу.
Автоматизация может помочь не забыть измерение, увидеть динамику и вовремя обратить внимание на опасный порог. Но решение о лечении, вызове врача или скорой помощи должно приниматься не Home Assistant, не ESP32 и не колонкой, а человеком с учётом медицинских рекомендаций.
Примечание об использовании ИИ
Черновик и редактура этой статьи частично готовились с использованием ИИ‑инструментов. Техническая реализация, факты, выводы, кодовые примеры и описанный опыт проверены автором.
