d
СОбака без привязи по нашему двору шатается по ночам иногда.
Size: a a a
2020 December 10
RO
У меня в этом месте только пешком пройти можно. Но я думаю среагирует. Это такой же датчик, как на дверях в супермаркетах. Он реагирует на изменение поля - микроволновый радар. Бъет через радиопрозрачные препятствия - у меня это деревянная стена. Котов не видит, а собаку соседскую регулярно фотографирует.
А дальность какая максимально рабочая?
d
Порядка трёх метров (у меня)
d
SM
А автоматизации в ямле? У меня просто много похожих по духу вещей реализованы в appdaemon, там можно хранить такие вещи или в конфигурационном файле со списком приложений или просто в коде
нет, пока python_scripts. я вообще не хочу ямлы использовать, очень сложно отлаживать, переиспользовать.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
d
нет, пока python_scripts. я вообще не хочу ямлы использовать, очень сложно отлаживать, переиспользовать.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
А node red не нравится? ИМХО для таких дел быстро и наглядно.
IB
Я сейчас для себя выделил 3 фазы дня, при которых устройства у меня должны работать по разному:
1. утро (когда я проснулся и вышел из спальни)
2. вечер (подготовка ко сну)
3. сон
Каждая фаза меняет параметры устройств в комнатах. Например, я не вижу смысла часто включать увлажнитель в спальне днем, потому что я там не нахожусь. Но вот в зале, где я провожу основную часть дня охото чтобы было повлажнее. Поэтому при срабатывании фазы "утро", в спальне параметры увлажнения уменьшаются, а в зале - увеличиваются.
Вечером охото наоборот, чтобы перед сном комната была максимально подготовлена ко сну, поэтому часа за 3 устройства в комнате начинают пытаться достичь идеального состояния, чтобы ко времени сна выключиться (и не шуметь пока засыпаю) и периодически включаться ночью, чтобы поддерживать состояние. А в зале наоборот, можно сахару устраивать 🙂 Вот сделаю автоматически открывающиеся окна, еще перед сном проветривать буду 🙂
Эти фазы я храню в input_select и хочу менять или по времени или, как сон, по кнопке. Также время когда фазы может зависеть от дня (например, хочу, чтобы в выходной день утро и сон начинались позже, потому что я скорее всего лягу спать и проснусь позже чем в рабочий день). При смене состояния устройства меняют свои настройки или отрабатывают определенные действия. Сделал это для того, чтобы не копировать логику проверки триггеров смены фаз из устройства в устройство и иметь возможность усложнять её при необходимости в одном месте.
Скорее всего, со временем мне захочется сделать еще какие-то глобальные состояния квартиры, которые могут возникать с достаточно сложной логикой и охото сразу на простом примере проработать подход. Но пока я не могу ничего такого сходу придумать для примера.
1. утро (когда я проснулся и вышел из спальни)
2. вечер (подготовка ко сну)
3. сон
Каждая фаза меняет параметры устройств в комнатах. Например, я не вижу смысла часто включать увлажнитель в спальне днем, потому что я там не нахожусь. Но вот в зале, где я провожу основную часть дня охото чтобы было повлажнее. Поэтому при срабатывании фазы "утро", в спальне параметры увлажнения уменьшаются, а в зале - увеличиваются.
Вечером охото наоборот, чтобы перед сном комната была максимально подготовлена ко сну, поэтому часа за 3 устройства в комнате начинают пытаться достичь идеального состояния, чтобы ко времени сна выключиться (и не шуметь пока засыпаю) и периодически включаться ночью, чтобы поддерживать состояние. А в зале наоборот, можно сахару устраивать 🙂 Вот сделаю автоматически открывающиеся окна, еще перед сном проветривать буду 🙂
Эти фазы я храню в input_select и хочу менять или по времени или, как сон, по кнопке. Также время когда фазы может зависеть от дня (например, хочу, чтобы в выходной день утро и сон начинались позже, потому что я скорее всего лягу спать и проснусь позже чем в рабочий день). При смене состояния устройства меняют свои настройки или отрабатывают определенные действия. Сделал это для того, чтобы не копировать логику проверки триггеров смены фаз из устройства в устройство и иметь возможность усложнять её при необходимости в одном месте.
Скорее всего, со временем мне захочется сделать еще какие-то глобальные состояния квартиры, которые могут возникать с достаточно сложной логикой и охото сразу на простом примере проработать подход. Но пока я не могу ничего такого сходу придумать для примера.
Звучит все очень разумно. В воскресенье будет конференция Home Assistant и там будет доклад "Create the ultimate mornings routine" — вот мне кажется что я его уже прослусал в твоем исполнении =)
Но я не понял где ты тут хочешь использовать переменные вынесенные в конфиг. У тебя есть input_select значение которое динамически меняется (утро/вечер/сон) — его в конфиг под переменную не уберешь.
Но я не понял где ты тут хочешь использовать переменные вынесенные в конфиг. У тебя есть input_select значение которое динамически меняется (утро/вечер/сон) — его в конфиг под переменную не уберешь.
AX
нет, пока python_scripts. я вообще не хочу ямлы использовать, очень сложно отлаживать, переиспользовать.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
2020 December 11
IB
нет, пока python_scripts. я вообще не хочу ямлы использовать, очень сложно отлаживать, переиспользовать.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
Я, конечно, за yaml-ы (хотя очень и не люблю этот формат). Может тебе сразу писать кастомный компонент на питоне, если так хочется использовать именно настоящий язык программирования
AP
нет, пока python_scripts. я вообще не хочу ямлы использовать, очень сложно отлаживать, переиспользовать.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
А pyscript не смотрели? Он совсем недавно появился, но очень динамично развивается. В отличие от AppDaemon это не аддон, а интеграция. Я все хочу поиграться, но все не нахожу времени. Но в целом, за исключением некоторых небольших, моментов меня AppDaemon устраивает и по возможностям и по скорости и по надежности.
AP
нет, пока python_scripts. я вообще не хочу ямлы использовать, очень сложно отлаживать, переиспользовать.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
appdaemon не хочу, потому что как-то не сильно хочется для автоматизаций использовать отдельный сервис, который с HA взаимодействует по web. Мне проще написать компонент выполняющий сложную штуку, который будет напрямую с api python HA работать.
Хранить переменные в коде - вот это как раз то, чего делать не хочется 🙂
На самом деле, python_scripts был бы норм, если бы там был небезопасный режим, который бы отключал их ограничения по использованию отдельных методов и давал бы доступ к конфигу.
А что касается переменных в коде, то тут сильно зависит от контекста. Всякие относительно константные вещи (например, при какой температуре за окном можно автоматически включать кондей) проще константами в коде держать. Вероятность того, что я буду их менять очень небольшая, а, если и буду, то скорее всего и что-то другое в автоматизации поменяю.
SM
Звучит все очень разумно. В воскресенье будет конференция Home Assistant и там будет доклад "Create the ultimate mornings routine" — вот мне кажется что я его уже прослусал в твоем исполнении =)
Но я не понял где ты тут хочешь использовать переменные вынесенные в конфиг. У тебя есть input_select значение которое динамически меняется (утро/вечер/сон) — его в конфиг под переменную не уберешь.
Но я не понял где ты тут хочешь использовать переменные вынесенные в конфиг. У тебя есть input_select значение которое динамически меняется (утро/вечер/сон) — его в конфиг под переменную не уберешь.
утро/вечер/сон - это как раз состояние сенсора, значение которого меняется на основе других параметров, которые я и выношу в конфиг
в коде это вглядит типа такого
Но это я просто накидал, как концпецию, чтобы просто что-то заработало. Но формат точно поменяю, чтобы не покомпонентно было, а компоненты сгруппированы по фазам дням и лежало это в одном месте, а не перемешано в разных сенсорах в их атрибутах.
в коде это вглядит типа такого
config = {
"phases": {
"sleeping": "00:00:00",
"work": "09:00:00",
# "weekend": "11:00:00",
"evening": "21:50:00",
}
"humidity_badroom": {
"work": {
"min": 40,
"max": 45
},
"evening": {
"min": 50,
"max": 55,
},
"sleeping": {
"min": 50,
"max": 55,
}
},
"humidity_hall": {
# ...
}
}Но это я просто накидал, как концпецию, чтобы просто что-то заработало. Но формат точно поменяю, чтобы не покомпонентно было, а компоненты сгруппированы по фазам дням и лежало это в одном месте, а не перемешано в разных сенсорах в их атрибутах.
SM
Как раз недавно видел в твоем канале, но не добрался посмотреть в чем отличия. Но, если там полноценный питон с полным доступом к api ha, беру неглядя 🙂
AX
Как раз недавно видел в твоем канале, но не добрался посмотреть в чем отличия. Но, если там полноценный питон с полным доступом к api ha, беру неглядя 🙂
Да там одна страничка ридми о всём рассказывает на примерах
SM
Я, конечно, за yaml-ы (хотя очень и не люблю этот формат). Может тебе сразу писать кастомный компонент на питоне, если так хочется использовать именно настоящий язык программирования
У компонентнов достаточно сложное апи, для того, чтобы на каждый чих его создавать, например для такой задачи, чтобы по параметрам сделать какой-то триггер или выполнить базовое действие. потому ищу способ более простой.
Но, я, написал свой первый компонент (возможно велосипед), который из ямл конфига умеет инициализировать компоненты с data flow уже не умеющие или криво работающие с ямл конфигом. Правда протестировал только с компонентом погоды.
Но, я, написал свой первый компонент (возможно велосипед), который из ямл конфига умеет инициализировать компоненты с data flow уже не умеющие или криво работающие с ямл конфигом. Правда протестировал только с компонентом погоды.
AX
Вообще для обычной логики ветвлений проще использовать Node-RED
SM
А pyscript не смотрели? Он совсем недавно появился, но очень динамично развивается. В отличие от AppDaemon это не аддон, а интеграция. Я все хочу поиграться, но все не нахожу времени. Но в целом, за исключением некоторых небольших, моментов меня AppDaemon устраивает и по возможностям и по скорости и по надежности.
посмотрел, очень не зашло то что это какой-то полупитон. вот вроде всё могу что в питоне, но и не могу что в питоне. как-то я питон-то не знаю (на других языках всю жизнь писал) и не большой его любитель, так еще в голове держать кучу нюансов что в питоне это норм, а в pyscript работает не так..
Вот у меня и было 2 стороны одной медали appdaemon - полноценный питон, но внешним сервисом и pyscript - недопитон, но зато встроенный. решил отказаться от обоих 🙂
Вот у меня и было 2 стороны одной медали appdaemon - полноценный питон, но внешним сервисом и pyscript - недопитон, но зато встроенный. решил отказаться от обоих 🙂
SM
А что касается переменных в коде, то тут сильно зависит от контекста. Всякие относительно константные вещи (например, при какой температуре за окном можно автоматически включать кондей) проще константами в коде держать. Вероятность того, что я буду их менять очень небольшая, а, если и буду, то скорее всего и что-то другое в автоматизации поменяю.
ну, простите, тут моя профдеформация 🙂 Опыт подсказывает, что поддержка такого кода хоть и лучше чем без констант, но всё равно экспоненциально увеличивается со временем 🙂