В статье упоминается your_device_tracker_entity_id то есть подразумевается наличие device_tracker . Я, по вашей предыдущей статье, получаю координаты от livegpstracks . Но в последней версии вашей интеграции на GitHub создаётся только сенсор, а в device_tracker координаты приходится передавать автоматизацией, которая дёргает device_tracker.see каждый раз, когда меняется состояние сенсора.
device_tracker я привязал его к персоне, т.к. итоговой задачей является контроль зон.
Теперь у меня три сущности с одинаковыми координатами: sensor devise_tracker person и, по пока не усвоенной мною логике, на карте отображается то sensor, то person :(
В чём идея создания сенсора, а не сразу devise_tracker? Нет ли возможности отредактировать вашу интеграцию, чтобы она сразу создавала devise_tracker?
...и ещё sensor.car_gps_sensor не относится к домену device_tracker из-за чего эти координаты не получается передать "персоне". Пытаюсь разобраться, как сосдать device_tracker и передавать в него координаты из сенсора. Ну или как по другому настроить оповещения о нахождении трекера в настроенной в НА "зоне". Буду рад советам :)
Оказывается, в HA есть "зоны" и "Proximity" - почти готовые решения для моих целей. В начале статьи вы упоминали возможность отправки координат без описываемого посредника, при наличии внешнего IP у HA. У меня есть внешний IP, но не могу найти документации или примеров подобной "прямой" передачи координат. Не могли бы пнуть в нужную сторону ;) ?
Красивая идея, спасибо :) А не встречалась ли вам реализация каких-либо автоматизации, в которых триггером является приближение к произвольной координате на произвольное расстояние? А в идеале - контроль въезда в геозону произвольной формы?
Странно, что никто не пишет про «неполезность» повреждения текстолита. При любой механической обработке, вскрывающей волокна стеклоткани, получаем некое подобие губки, которое впитывает в себя всякое… Если, не дай бог, активный флюс туда попадёт, будет совсем не хорошо. Но и прочая «грязь» вполне потом вберёт в себя влагу, и обретёт некоторую электропроводность. Оно надо?
Мысль со статикой уловил — спасибо.
Моя задача — как раз организация резервного канала, т.к. нет никакого смысла складывать «100мбит» основного и «2мбит» резервного. Кроме того, мне нравится идея оповещения (e-mail, SMS или ещё как) о падении «основного» — так у меня раньше жил mwan3 под OpenWRT. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
До костыля с единым списком «всех DNS» я дотумкал самостоятельно, и как раз, понимая, что «это костыль» — хотел найти другое решение. Про «статические маршруты» — пока не осознал… Имеете ввиду прописать отдельно для LAN-WAN1 и LAN-WAN2?
Кстати, а не честнее ли будет сделать failover на скриптах? Не нашёл сравнения преимуществ/недостатков этих двух решений.
Спасибо!
Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?
В стандарте есть и поддерживается котлом «поддержание заданной температуры в контрольном помещении». Я этот температурный датчик установил на обратку. Сейчас я этот параметр («температуру в контрольном помещении») устанавливаю вручную, исходя из скорости протока в обратке. Т.е. мне нужно поставить температуру в обратке в зависимость от «скорости протока в обратке» (что косвенно говорит о количестве комнат, которые сейчас нужно греть). В обратке поставлен импульсный датчик. Все помещения греются через пол. Работает два котла «Термона» в каскаде.
Мне необходимо иметь возможность указывать котлу температуру «опорного помещения». Реально у меня это температура обратки, которую я хочу поставить в зависимость от количества «потребителей».
Приветствую! Долго я шёл до этой статьи :)… Планирую заменить неустраивающую автоматику, работающую как раз по OpenTherm. Если что — можно будет обратиться за помощью?
Пытаюсь идти проторенным вами путём - спасибо.
В статье упоминается
your_device_tracker_entity_idто есть подразумевается наличие device_tracker . Я, по вашей предыдущей статье, получаю координаты от livegpstracks . Но в последней версии вашей интеграции на GitHub создаётся только сенсор, а в device_tracker координаты приходится передавать автоматизацией, которая дёргает device_tracker.see каждый раз, когда меняется состояние сенсора.device_tracker я привязал его к персоне, т.к. итоговой задачей является контроль зон.
Теперь у меня три сущности с одинаковыми координатами:
sensor
devise_tracker
person
и, по пока не усвоенной мною логике, на карте отображается то sensor, то person :(
В чём идея создания сенсора, а не сразу devise_tracker? Нет ли возможности отредактировать вашу интеграцию, чтобы она сразу создавала devise_tracker?
...и ещё
sensor.car_gps_sensor не относится к домену device_tracker из-за чего эти координаты не получается передать "персоне".
Пытаюсь разобраться, как сосдать device_tracker и передавать в него координаты из сенсора.
Ну или как по другому настроить оповещения о нахождении трекера в настроенной в НА "зоне".
Буду рад советам :)
Попробовал пойти вашим путём :)
Вроде запустилось, увеличил частоту запросов для повышения точности
Хотелось бы заменить иконку на карте - не подскажете как присвоить уникальный идентификатор сенсору?
Оказывается, в HA есть "зоны" и "Proximity" - почти готовые решения для моих целей.
В начале статьи вы упоминали возможность отправки координат без описываемого посредника, при наличии внешнего IP у HA. У меня есть внешний IP, но не могу найти документации или примеров подобной "прямой" передачи координат. Не могли бы пнуть в нужную сторону ;) ?
Красивая идея, спасибо :)
А не встречалась ли вам реализация каких-либо автоматизации, в которых триггером является приближение к произвольной координате на произвольное расстояние? А в идеале - контроль въезда в геозону произвольной формы?
Так и я про то, что без скриптов оповещения не сделать. Может тогда имеет смысл всё на скриптах?
Моя задача — как раз организация резервного канала, т.к. нет никакого смысла складывать «100мбит» основного и «2мбит» резервного. Кроме того, мне нравится идея оповещения (e-mail, SMS или ещё как) о падении «основного» — так у меня раньше жил mwan3 под OpenWRT. Я правильно понимаю, что «оповещение» один фиг скриптами будет?
Кстати, а не честнее ли будет сделать failover на скриптах? Не нашёл сравнения преимуществ/недостатков этих двух решений.
А есть у микротика некий аналог «push» — что бы давать клиентам команды маршрутизации в сеть сервера?
А есть у микротика некий аналог «push» — что бы давать клиентам команды маршрутизации в сеть сервера?
Настроил failover с двумя провайдерами. А как быть с их DNS? Как сделать, что бы для каждого провайдера использовался «его» DNS?
И ещё, если не сложно: следующим этапом планирую прикручивать OpenVPN-туннель. Внешний IP даёт только основной провайдера, его доступность >95%. Потеря туннеля при работе через резерв не беспокоит. Но не возникнет ли проблем с доступом в подсеть за туннелем, из-за предложенных «хитростей» в роутах?