home assistant очистить историю
Большой брат следит за… собой или карта с историей перемещений в HomeAssistant
Вступление
Разведка
Собственно, чтобы отобразить маршрут нужно иметь набор точек с координатами, поэтому первым шагом было выяснить где HomeAssistant хранит нужные данные (если вообще хранит) и как их оттуда достать. Недолгое изучение первоисточника сразу привело к решению: необходим включенный модуль recorder для записи состояний нужных датчиков в БД в различные моменты времени, а также модуль history, который позволяет получать данные из БД в красивом виде. У модуля history есть хорошо документированный REST API. То, что нужно!
Далее необходимо полученные данные как-то отобразить на карте. Существует множество различных сервисов, позволяющих отображать историю перемещений. Я наверняка перепробовал далеко не все из них, однако позволю себе пару слов о проверенных мною:
А. yandex и google. Собственно для моих нужд там есть все и даже больше, однако в силу платности сервисов и сильных ограничений бесплатных версий, они мне сразу не подошли. Yandex, например, разрешает бесплатное использование только для открытых проектов (то есть любой человек должен иметь возможность в любое время открыть твой ресурс и воспользоваться его возможностями), не говоря уже о других ограничениях в количестве запросов. Про изменения в политике Google по отношению к api не писал только ленивый. На текущий момент, насколько я понял, каждый запрос к maps api или directions api оплачивается, чем больше запросов — тем дешевле. Однако каждому пользователю с подключенной к аккаунту банковской картой дается бесплатный лимит на 200$ в месяц. Все что сверху сразу оплачивается с вашей карты. Привязка карты к аккаунту — это не наш путь.
Поправьте, если я ошибся где то по поводу google и/или yandex.
Б. Связка OpenRouteService и OpenRouteService maps. В принципе по возможностям мало чем отличается от google или yandex (во всяком случае я не заметил). Полностью бесплатен (есть ограничения по количеству запросов в день и в минуту при превышении которых советуют обратиться в поддержку… описания каких-либо платных тарифов нет вообще). Однако использование ресурса OpenRouteService maps оказалось неудобным (долгая загрузка приложения и назойливое широкое меню слева, открывающееся по умолчанию и не отключаемое средствами API, к тому же сервис не совсем корректно открывается с мобильных устройств). Справедливости ради, OpenRouteService maps можно поставить на свой сервер и вполне возможно, что там позволено сконфигурировать все под себя.
В. Mapbbcode. Наткнулся на хабре на интересную реализацию карт в простом формате. В принципе для моей задачи проект абсолютно подходит, однако из этой статьи я узнал о Leaflet и решил обратиться к первоисточнику. На ней в итоге и остановился…
Г. Leaflet. Очень хорошая open-source js библиотека для карт, простая в освоении и хорошо документированная. Из фишек: позволяет использовать тайлы от многих сервисов (openstreetmaps, yandex, google, mapbox, microsoft и тд и тп). Дополнительно я использовал плагин leaflet.polylineDecorator для указания направления движения на карте.
Стоит упомянуть, что последние два рассматриваемых ресурса не поддерживают «маршруты», то есть не умеют соединять точки вдоль существующих дорог и/или тротуаров, а просто соединяют точки прямой линией. Лично для меня это не проблема, а осознанный шаг. Если нужна именно навигация по дорогам, то нужно смотреть в сторону платных google, yandex или бесплатного openrouteservice.
Реализация
Запрос к модулю history через REST-API довольно прост (здесь и далее код будет на языке HomeAssistant, т.е. python) и позволяет получить ответ в виде простого для понимания JSON:
здесь self._haddr — это адрес вашего HA такой же, как указан в настройках frontend, self._myid — это ид устройства device_tracker, чей маршрут мы будем строить, dayBegin – это начало периода для отображения маршрута, я по умолчанию выбрал начало текущего дня, self._token – это long-life токен для доступа к апи, который можно получить в интерфейсе HomeAssistant.
Когда объект, чью историю мы пытаемся отобразить на карте, долгое время находится неподвижно или передвигается крайне медленно, мы получим кучу точек, близко расположенных и забивающих карту. Для исправления ситуации пропустим полученный массив координат через фильтр: если расстояние между предыдущей точкой и следующей менее 100 метров, то не отображать точку на карте. Для расчета расстояний между двумя соседними точками используем упрощенную формулу с равноугольным приближением. Приближение применимо, когда расстояние между соседними точками не превышает нескольких км:
Здесь dst расстояние в км.
Описывать API Leaflet здесь не вижу смысла. За этим — на официальный сайт. Модуль работает следующим образом: Каждые n секунд (у меня настроено на 300) делается запрос к сегодняшней истории интересующего меня объекта. Полученный массив координат прогоняется через фильтр расстояний, уменьшая количество точек. Далее в папке с конфигурацией HomeAssistant в папке www формируются 2 файла: index.html и route.html. В файле route.html прописана вся логика по созданию карты. А файл index.html — это лайфхак по предупреждению кэширования страницы. По умолчанию HomeAssistant кэширует все, что только можно, и только сброс кэша помогал актуализировать данные на карте, что, конечно, неприемлемо. В файле index.html происходит вызов содержимого route.html однако с рендомным динамически формируемым параметром, что позволяет всегда запрашивать с сервера актуальную версию файла route.html:
Немного о безопасности
HomeAssistant устроен так, что все файлы внутри директории www являются публичными, то есть любой файл внутри директории www можно открыть в любом браузере безо всякой авторизации, зная прямую ссылку. В случае с моим модулем эта ссылка такая: your_address_homeassistant/local/route/index.html. Если для вас это не критично, то можете пропускать данный раздел. Я же пошел немного дальше и прикрутил таки авторизацию к странице с маршрутами. Для этого я использовал nginx (вы можете выбрать другой веб сервер с поддержкой реверсивного прокси) в качестве прокси сервера. На сайте HomeAssistant есть официальная инструкция по настройке данной конфигурации. После настройки прокси и проверки работы в конфигурацию nginx нужно добавить авторизацию для нужных страниц:
Затем создать файл «/etc/nginx/.htpasswd», и в консоли выполнить последовательно команды:
admin – заменить на желаемый логин.
После этого перезапускаем nginx и проверяем: при попытке открыть страницу с маршрутом браузер должен запрашивать логин и пароль. Замечу, что это отдельная авторизация, никак не связанная с авторизацией самого HomeAssistant.
Заключение
Пожалуй и все, что можно рассказать о данном модуле.
Кого заинтересовало, вот ссылка на модуль. Файл расположить по пути: config_folder_homeassistant/custom_components/route/sensor.py, не забывайте про права.
Если не существует, то создать папку config_folder_homeassistant/www и выдать на нее соответствующие права.
В конфигурационном файле configuration.yaml прописать следующие строки:
здесь your_device_tracker_entity_id – это ID вашего устройства device_tracker, your_address_homeassistant – внешний адрес вашего HomeAssistant, your_long_life_token – предварительно полученный во фронтенде HomeAssistant токен доступа для использования REST API.
После этого перезапустить HomeAssistant и наслаждаться. Карта будет доступна по прямой ссылке: your_address_homeassistant/local/route/index.html. При желании вы можете добавить ее в меню HA с помощью panel_iframe или в любое окно HA через lovelace card “iframe”.
На этом все, спасибо за внимание.
UPD:
Добавил ссылку на GitHub. Доработал некоторые места (убрал из конфигурации haddr, автоматом получаю config_dir, добавил возможность установки своего часового пояса)
History
The history integration will track everything that is going on within Home Assistant and allows the user to browse through it. It depends on the recorder integration for storing the data and uses the same database setting. If any entities are excluded from being recorded, no history will be available for these entities.
This integration is by default enabled, unless you’ve disabled or removed the default_config: line from your configuration. If that is the case, the following example shows you how to enable this integration manually:
Configuration Variables
Configure which integrations should not be displayed.
The list of entity ids to be excluded from the history.
Include all entities matching a listed pattern when creating logbook entries (e.g., sensor.weather_* ).
The list of domains to be excluded from the history.
Configure which integrations should be displayed.
The list of entity ids to be included in the history.
Include all entities matching a listed pattern when creating logbook entries (e.g., sensor.weather_* ).
The list of domains to be included in the history.
Define domains and entities to exclude (aka. blocklist). This is convenient when you are basically happy with the information displayed, but just want to remove some entities or domains. Usually these are entities/domains which do not change or rarely change (like updater or automation ).
Use the include list to define the domains/entities to display, and exclude some of them within the exclude list. This makes sense if you, for instance, include the sensor domain, but want to exclude some specific sensors. Instead of adding every sensor entity to the include entities list just include the sensor domain and exclude the sensor entities you are not interested in. Note that the order of any include entities will be displayed as listed in the configuration, otherwise, the display order is arbitrary.
If you’d like the order of display of the sensors to follow the way they are listed in the included entity list, you can set the flag use_include_order to true.
Filters are applied as follows:
The following characters can be used in entity globs:
Implementation details
The history is stored in a SQLite database home-assistant_v2.db within your configuration directory unless the recorder integration is set up differently.
When the history integration queries the states table it only selects states where the state has changed: WHERE last_changed=last_updated
On dates
SQLite databases do not support native dates. That’s why all the dates are saved in seconds since the UNIX epoch. Convert them manually using this site or in Python:
The history information is also available through the RESTful API.
Purge history after X days #1337
Comments
justyns commented Feb 19, 2016
I ran into an issue recently where it would take minutes to restart home-assistant on a raspberry pi 2. Eventually I tracked it down to the size of the sqlite db being used for history in
/.homeassistant/homeassistant.db. It was only around 2gb, but that’s on an sd card and sqlite so I wouldn’t expect it to be very performant anyway.
I’d propose adding a ‘purge_after’ or some option to the history component where it could be set to delete the history after 7 days or whatever you set it to. With other history backends(graphite, influxdb, etc) being supported now, it doesn’t seem too useful to keep a local copy of the history for very long.
Caveat: While old data is being purged from the db, I think it will block anything new being written to it. A limit could be added to the purge query so that it only deletes X records at a time. That’d make it safer to run every hour or so.
The text was updated successfully, but these errors were encountered:
balloob commented Feb 20, 2016
The recorder works with a queue so it wouldn’t block normal processing
while cleaning up
On Fri, Feb 19, 2016, 14:49 Justyn Shull notifications@github.com wrote:
I ran into an issue recently where it would take minutes to restart
home-assistant on a raspberry pi 2. Eventually I tracked it down to the
size of the sqlite db being used for history in
/.homeassistant/homeassistant.db. It was only around 2gb, but that’s on an
sd card and sqlite so I wouldn’t expect it to be very performant anyway.
I’d propose adding a ‘purge_after’ or some option to the history component
where it could be set to delete the history after 7 days or whatever you
set it to. With other history backends(graphite, influxdb, etc) being
supported now, it doesn’t seem too useful to keep a local copy of the
history for very long.
Caveat: While old data is being purged from the db, I think it will block
anything new being written to it. A limit could be added to the purge query
so that it only deletes X records at a time. That’d make it safer to run
every hour or so.
—
Reply to this email directly or view it on GitHub
#1337.
thunfischbrot commented Feb 23, 2016
This is a good idea. Limiting either by number of days or total db file size could be good for now. Later different policies for different data could be implemented, e.g. to keep aggregated temperature and humidity data for a longer time, but throwing out presence and window/door state data. That second step though might be an additional module or even outside the scope of home assistant.
justyns commented Feb 23, 2016
Thanks, I didn’t realize there was a queue for the recorder already, I’ll look into it more.
Good idea on possibly using different policies for different data. Would that need to be defined per sensor/etc in the config? Or would it be a new section in the recorder config? Aggregation seems outside the scope of HA imo, since it’d be better handled by an external history source already.
Would this look okay?
The first two listed sensors would be purged after 1 day, the two weather sensors would be kept for 90 days, and everything else would only be kept 7 days.
If that looks okay, is there a preference over using keep_days: 7 vs purge_after: 7d where 1h, 1d, 1m, etc could be used? I’m not sure how difficult parsing the latter would be.
balloob commented Feb 24, 2016
Let’s not get ahead of ourselves. I do not want to start updating old data
for aggregation etc. Our history stream should be immutable with purging
after a certain date.
For the initial version I would suggest just an option to delete data older
than X days at startup.
On Tue, Feb 23, 2016 at 9:17 AM, Justyn Shull notifications@github.com
wrote:
Thanks, I didn’t realize there was a queue for the recorder already, I’ll
look into it more.
Good idea on possibly using different policies for different data. Would
that need to be defined per sensor/etc in the config? Or would it be a new
section in the recorder config? Aggregation seems outside the scope of HA
imo, since it’d be better handled by an external history source already.
Would this look okay?
history:
keep_days: 7
override:
sensor.aeon_labs_home_energy_meter_energy_2: 1
sensor.aeon_labs_home_energy_meter_power_2: 1
sensor.weather_temperature: 90
sensor.weather_humidity: 90
The first two listed sensors would be purged after 1 day, the two weather
sensors would be kept for 90 days, and everything else would only be kept 7
days.
If that looks okay, is there a preference over using keep_days: 7 vs purge_after:
7d where 1h, 1d, 1m, etc could be used? I’m not sure how difficult
parsing the latter would be.
—
Reply to this email directly or view it on GitHub
#1337 (comment)
.
Clear up storage
Reaching your storage limit, this page will help you when that happens.
There are several things you can do to free up some space:
Clean the database
The Home Assistant database can get huge!
Luckily there is a tool you can use to purge the contents of the database
You can filter what you send to the database, and even change how long it stores the data with the purge_keep_days setting
Delete old backups
Open the Home Assistant UI and go to “Supervisor” in the sidebar, and then to the “Backups” tab, here you will see all your backups, these can be downloaded and placed somewhere safe. When you have done that, you can delete them in the UI and it will free up some space for you.
Uninstall unused add-ons
Add-ons can take a lot of space, not just the add-on itself but also their data.
Open the Home Assistant UI and go to “Supervisor” in the sidebar, you will be on the “Dashboard” tab when you click on the “Supervisor”, here you will see all your installed add-ons, maybe you have some that you no longer use, if you do those can be uninstalled to free up some space.
Last resort
If all else fails, you need to expand your storage.
If you are running Home Assistant as a VM, look at the documentation for your hypervisor on how to expand disks for virtual machines. Home Assistant will auto-expand to use the newly added space.
If you are not running a VM, you need to replace your storage medium (typically, this will be an SD card). You can use backups to quickly restore your Home Assistant installation on a new storage medium.
Home Assistant + база SQL MariaDB оптимизация
Все чаще у многих пользователей Home Assistant возникает вопрос о выросшем файле базы данных. При большом количестве датчиков и автоматизаций, базы за месяц не помещаются на карту памяти. Встроенная база SQLite при больших нагрузках работает медленно.
Сейчас мы исправим эту ситуацию установим и настроим SQL сервер MariaDB.
Установка и настройка
Нажимаем INSTALL.
Теперь необходимо правильно настроить конфигурацию, для этого переходим ниже и вносим следующие данные
Имя, название базы можно оставить по умолчанию придумайте надежный пароль.
Теперь необходимо открыть порт для доступа к базе данных из внешнего приложения, переходим ниже на следующую вкладку, вписываем порт 3306 и нажимаем SAVE
Перезапускаем сервер коммандой RESTART
Опускаемся вниз и обновляем лог коммандой REFRESH, если все заполнено правильно ошибок не будет. Видим открытый порт 3306 для внешнего управления базой.
Теперь необходимо добавить в configuration.yaml запись которая укажет непосредственный путь к нашей новой базе.
Открываем и добавляем следующий код:
Проверяем логи на наличие ошибок.
Внешнее управление
Теперь можем установить на свой компьютер одну из программ для работы с внешней базой. Я пользуюсь Navicat for MySQL, так же можно использовать MySQL Workbench
Скачиваем устанавливаем. Для настройки открываем вкладку Connection и вносим следующие данные:
Где IP адрес вашего сервера, имя пользователя и пароль, которое заполняли выше и сохраняем.
Нажимаем двойным кликом на новое подключение и попадаем в нашу базу.