Системный администратор
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
System Administration, DevOps
Senior
Git
PostgreSQL
Docker
MySQL
Nginx
High-loaded systems
Bash
CI/CD
Linux
Python
USB. У меня -- asus bt400, но там идея не в конкретном модуле, а в том чтобы унести BT модуль подальше от тушки одноплатника.
Выглядит прилично (разве что "dicsovering: no" смущает).
У меня после перехода на Pi 4 с бризером ничего не получалось до тех пор пока внешний модуль не поставил (и как я понял проблема довольно распространенная).
Еще рекомендую посмотреть на соседний проект https://github.com/dentra/esphome-tion
Красоты конфигов ради (а то со временем configuration.yaml имеет тенденцию превращаться в сложночитаемое нечто).
configuration.yaml
tree panel_iframe.d/
panel_iframe.d/portainer.yaml
Mosquito -- брокер сообщений (условно) в который приходят HomeAssisant и Zigbee2MQTT чтобы узнать/установить состояния устройств.
В HA есть родная Zigbee интеграция, которая не требует дополнительного брокера, но, как ни странно, родная интеграция и Z2M по разному поддерживают устройства.
Например, мои беспроводные двухклавишные выключатели Aqara (несколько лет назад), через Z2M работали нормально, а родная интеграция не видела двойные нажатия (если я сейчас правильно помню проблему).
Плюс если устройство новое, то в Z2M его относительно легко добавить самому.
А так да, вы абсолютно правы: без брокера и Z2M (иногда) можно обойтись.
Если рабочий с тряпкой эффективно очищает стекло камеры, то напрашивается способ используемый в камерах Формулы-1: по стеклу ездит проматываемая пленка. Пока пленка снаружи -- собирает грязь и пыль, как картинка стала плохой -- проматываем. На камеру приезжает чистый кусок пленки, а грязный или в утиль или, если пленка закольцована, проходит через щетки/тряпку.
А как из него выпилить "лишнее", вроде DNS, cast и всего того что мне не нужно, если хочется нормально пользоваться аддонами, и не тянуть все это?
Если вы наследуетесь от Entity, то статичные свойства лучше задавать приватными атрибутами (_attr_icon = ... ).
А хорошим способом делать update, в вашем случае, будет data update coordinator, ибо HA дергает update каждого сенсора (переключателя итд), а значит update из модуля дергается чаще, чем мог бы.
ps. Раз уж пиариться просят...
https://github.com/IATkachenko/HA-YandexWeather
https://github.com/IATkachenko/HA-SleepAsAndroid
https://github.com/TionAPI/HA-tion
А почему от поиска дороги с помощью машинного зрения отказались-то? Судя по картинке с маршрутом, в результате делается high-res фотография карьера, что называется "вид сверху". А дальше для машинного зрения задача, казалось бы простая: пройти "окном" по картинке, выделить на ней объект "дорога". И никакой тысячи не нужно: в зависимости от размера окна можно получить достаточно приличную базу относительно быстро, а сделав разметку в ручную на исходном кадре ("фломастером") легко и быстро получить исходную базу для обучения. Те опираться не на "найди дорогу в кадре", а на "где в этой части кадра дорога?".
С оценкой качества дороги, конечно, сложнее: окном нужно бежать по дороге и как-то научиться оценивать по шкале от нуля до 100. Но эта задача, судя по последней картинке, уже решена.
Откройте, пожалуйста, issue на гитхаб с home-assistnat.log с момента запуска и до появления сообщения с ошибкой -- посмотрим что происходит.
То как HA отображает данные от интеграции не зависит. Она только сами данные собиарет.
Это может быть стандартная карточка погоды, кастомная или вообще диспей в выключателе.
Шанс фэйла есть почти всегда.
Яндекс, кстати, в погодной сводке отдает текущий сезон :) Надо будет сенсор этого добавить и кэш на пару дней для значения...
Меня интересует общий комфорт: если и так жарко, то нет смысла греть пол.
У "наклеить" есть пара неочевидных проблем:
Датчик должен быть IP67
Датчик должен быть морозоустойчивым
Ну и отдавать данные прилично. Те это или жесткий DIY в силу требований по защищенности, или какие-то решения за деньги, которые тоже надо как-то интегрировать.
На водух в ванной смотреть тоже не правильно: температура воздуха в помещении в течении года меняется не сильно, а ощущения зависят от сезонности. Летом больше хочется прохлады, а зимой -- тепла.
Проще, но прогноз Яндекса для Москвы я считаю точнее. Для моих целей, конечно, хватает и примерных данных, но все ёж.
Там где за окном == улица датчик не высунуть, а там где балкон -- парник и с тем же успехом можно брать погоду на Марсе.
Температуру поверхности собирать можно, но тоже не очень интересно: когда жарко, то прохладный пол -- приятно. Плюс это сильно усложняет само управление нагревом: датчик контроллера на поверхность не положишь, а значит контроллер нужно дергать вопреки его алгоритмам, из HA.
Мне такие решения нравятся чуть меньше, чем сходить к профессиональным постащикам метео данных.
Чтобы:
Включать теплый пол за полчаса до будильника (за это отвечает интеграция с SleepAsAndroid в соседнем репозитории ;) )
Не делать этого когда на улице +25
В последней версии сервера добавил кэширование, чтобы бризер часто не дергать: у меня home assistant своими запросами его все же перенапрягает и за неделю стабильно бывает несколько раз, когда бризер не успевает ответить вовремя и сервер подвисает.
С другой стороны, друзья с окнами на Кутузовский, сказали что на 6ке наш бризер гудит не громче, чем Кутузовский с закрытыми окнами.
А касательно проблемы — в личку ответил, но и сюда продублирую: такая ошибка возникает (у меня) на первые несколько (~10) запросов, после долго бездействия сервера. Вероятно, алгоритм взаимодействия несколько сложнее, чем реализовано на python и бризеру нужно сказать что-то еще, прежде чем пытаться получать данные.
Нормальный воздухообмен на 5ке только достигается. Если вынуть HEPA, то на четверке. Но без HEPA можно только зимой, в силу аллергии.
Но даже при тройке спать не комфортно, хотя бризер на противоположной от кровати стене.
У нас еще вытяжная вентиляция в доме не очень хорошая — бризер ее не может нормально «продавить».