Создание переключателя Home Assistant для управления правилом фаервола Mikrotik

Потребовалось тут выключать\включать правило в ip/firewall/filter в микротике. На данный момент нашел три компонента для работы с микротиком. Стандартная, которая ничего не умеет, кроме как обнаружить есть ли микротик в сети. Простенький компонент, но без документации. Серьезный компонент, работающий по winbox api. 

Но мне хотелось более простого варианта. Чтобы не грузить лишние компоненты в Home Assistant (HA). И такой вариант есть - это работа через ssh.

Подключаем SSH Public Key Authentication

С паролем работать из HA с ssh непросто,  по-крайней мере я нашел кучу тем без ответа как это делать и сразу перешекл к рабочему и более правильному варианту - авторизация по публичному ключу. Там все стандартно, создем пару ключей на клиенте (HA), закидываем публичный на микротик:

ha_user@ha:~$ ssh-keygen -t rsa
ha_user@ha:~$ scp ~/.ssh/id_rsa.pub admin@192.168.1.1:mykey.pub

Далее импортируем файл публичного ключа в пользователя:

Тестируем, что можем зайти в mikrotik без пароля ssh admin@192.168.1.1 "/system resource print".

Настраиваем Switch в Home Assistant.

прописываем в configuration.yaml:

switch:
  - platform: command_line
    switches:
      rule_1:
        command_on: "ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no admin@192.168.1.1 '/ip firewall filter disable 1'"
        command_off: "ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no admin@192.168.1.1 '/ip firewall filter enable 1'"
        command_state: "ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no admin@192.168.1.1 '/put [ip firewall filter get number=1 disabled]'"
        value_template: '{{ value == "true" }}'
        friendly_name: Rule 1 

value_template - параметр который работает с ответом от command_state. Так как command_state нам возвращает "true"\"false" а не "0" как трубет command_state, то используем его. Конечно, лучше завести нового пользователя в микротике, с ограничением прав только на данные операции. Выключатель готов:

Подключение выключателя Sonoff T4EU1C к Home Assistant

Выключатели Xiaomi довольно дорогие, и не входят в стандартный российский подрозетник. Поэтому было решено купить выключатель Sonoff TXT4EU1C, который в два раза дешевле. Он работает поверх сети wifi. Никаких ZigBee. Это выключатель работает в разрыв фазы, дополнительно надо установить Antiflicker Module, параллельно лампе, который и будет замыкать цепь и питать наш выключатель.

Подключаем Sonoff T4EU1C к Home Assistant
Буквально на днях наши соотечественники выпустили перспектинвую библиотеку SonoffLAN для испозования Sonoff устройств в Home Assistant. Ну что же, попробуем.
Для начала устанавливаем приложение ewelink для регистрации устройства в профиле. Именного из профиля SonoffLAN будет брать всю информацию об устройствах Sonoff. Хотя вы можете прописать всю информацию врчуную, но в этом случае, я так понимаю, все равно нужно приложения, для подключния Sonoff устройства к вашей wifi сети.
Качаем библиотеку

#wget https://github.com/AlexxIT/SonoffLAN/archive/master.zip

Распаковываем библиотеку в директорию Home Assistant:

/config/custom_components/sonoff/

Прописываем логин пароль от eWeLink в /config/configuration.yaml:

sonoff:
  username: mymail@gmail.com
  password: mypassword

Перезапускаем сервер Home Assistant из web приложения. И получаем выключатель в Home Assistant

На удивление просто, и писать больше собственоо нечего. :)

Подключение Xiaomi Gateway (Aqara) к Home Assistant

Установка home assistant
Я выбрал вариант для докера (установил docker и portainer (очень удобный веб интерфейс для управления контейнерами). Установка home-assistant описана тут: https://www.home-assistant.io/docs/installation/docker/ .

Режим разработчика или DIY Xiaomi Gateway (Aqara)
Устанавливаем приложение Mi Home на телефон IOS или Android, добавляем шлюз средствами программы. Активируем режим разработчика (внимание, на данный момент поддерживаются только хабы Aqara версии v2, в дригух пока такого режима нет. В версии 3 можно использовать через Apple Home, гуглите).
Заходим в хаб, нажимаем Сведения (About) в меню, нажимаем пять раз на версию приложения пока не появятся дополнительные меню на английском (нам нужно меню wireless communication protocol, в нем вы увидите пароль для хаба).

Привязываем хаб Xiaomi Gateway (Aqara) к home assistant
Для привязки одного хаба пишем в configuration.yaml:

#yum install sysbench
# You can leave MAC empty if you only have one gateway.
xiaomi_aqara:
  discovery_retry: 5
  gateways:
    - key: xxxxxxxxxxxxxxxx

Хаб найдется через мультикаст запрос, можно прописать ip хаба. Для привязки нескольких configuration.yaml:

#yum install sysbench
# 12 characters MAC can be obtained from the gateway.
xiaomi_aqara:
  gateways:
    - mac: xxxxxxxxxxxx
      key: xxxxxxxxxxxxxxxx
    - mac: xxxxxxxxxxxx
      key: xxxxxxxxxxxxxxxx

Перезапускаем сервер из веб приложения home assistant (настройки - сервер - перезапустить). И получаем.. ничего :) Ошибка:

Проверяем порт Xiaomi Gateway (Aqara)
Что бы HA подключился к хабу, нужны открытые UDP порты 4321/9898 на хабе. Говорят, в последних партиях хабов эти порты закрыты по умолчанию (Новые ревизии шлюзов (надпись около вилки идёт по кругу) поставляются с последней прошивкой). Узнаем ip адрес хаба в приложении MI Home (About -> Hub info). Тестируем порты:

#  nmap -sU 192.168.1.109 -p 5353,9898,4321
PORT     STATE         SERVICE
4321/udp open|filtered rwhois
5353/udp open|filtered zeroconf
9898/udp open          monkeycom

Если у вас порты закрыты - прочитайте статью.
У меня была определенная проблема в том что, сеть докера была в bridge mode и multicast дискаверинг не срабатывал. Переключаем докер в host mode. Открываем порт 8123 на файерволе, а так же прохождение мультикаст пакетов (на хосте с докером), если необходимо. Получаем результат:

Нагрузочное тестирование CPU в CentOS 8 (stress test)

EPEL
EPEL (Extra Packages for Enterprise Linux) — репозиторий с дополнительными пакетами для Enterprise Linux, предоставляемый командой Fedora, которые не включены в установку по умолчанию в некоторых дистрибутиве CentOS.
Устанавливаем с помощью пакета epel-release и проверяем, что все работает:

# yum install epel-release
# yum repolist | grep -i "epel\|repo id"
repo id           repo name                                               status
*epel             Extra Packages for Enterprise Linux 8 - x86_64          4,979

Sysbench
Устанавливаем и запускаем тест (cpu - этот тест проверит производительность процессоров, используя вычисления с 64-разрядными числами.):

#yum install sysbench
#sysbench cpu --threads=4 --cpu-max-prime=10000000 run

где
--num-threads=4 - это количество потоков, у меня двухъядерный четырёхпотоковый Intel® Core™ i3 (мобильная U версия), поэтому 4;
--cpu-max-prime=10000000 - это максимальное количество выполненных операций. Вы можете увеличть это число, если надо тестировать дольше.
Вот так загружается процессор при выполнении:

Отслеживание температуры
Смысл нагрузки процессора, в моем случае, был не только в проверке в проверке скорости работы процессора, но и в проверки температуры процессора в безвентиляторной системе. Поэтом во время нагрузочного теста, неплохо бы и отслеживать температуру.
Устанавливаем sensors.

#yum install lm_sensors

Запускаем программу обнаружения датчиков. Для простоты жмите Enter, когда задаются вопросы.

#sensors-detect 

Добавим 0 в --cpu-max-prime=100000000 (чтобы тест пошел больше, чем 1 минуту) и запускаем sysbench. В отдельной консоли отслеживаем температуру:

#watch -n 1 -d sensors

Моя температура до запуска:

Тест длился 570 секунд, температура на пике:

Достаточно низкая температура, попробуем другую утилиту.

Mersenne prime (mprime 95)
Качаем Mersenne prime и запускаем.
В моем случае:

#mkdir mprime && cd mprime
#wget http://www.mersenne.org/ftp_root/gimps/p95v298b6.linux64.tar.gz
#tar -zxvf p95v298b6.linux64.tar.gz
#./mprime -m

Нажмите N, если не хотите выполнять задания с сервера и перейти к тесту torture (пытка :) ). Выберем количество потоков. Дальше выбираем:

Choose a type of torture test to run.
  1 = Smallest FFTs (tests L1/L2 caches, high power/heat/CPU stress).
  2 = Small FFTs (tests L1/L2/L3 caches, maximum power/heat/CPU stress).
  3 = Large FFTs (stresses memory controller and RAM).
  4 = Blend (tests all of the above).

Я выбрал 2, так как пока не хочу нагружать память, возможно в следующий раз. Остальные опции по умолчанию. Пошел тест:

Загрузка в top те же 400%, но с температурой уже поинтереснее:

Двухчасовое тестирование выдало максимальную температуру 60 градусов (в первый час 58). Максимальная температура PCH (южного моста Skylake) 54 градус (первый час 52). Считаю отличный результат для без вентиляторной системы (а для мобильной платформы шикарный), а mprime лучшей утилитой для подобного стресс теста. Sysbench, я думаю, лучше использовать просто, как подсчет попугаев.

ps. нормальный показатель температуры диода PCH ноутбуков составляет 45-70°C. Кратковременные поднятия до более высоких температур тоже. Так же и с мобильным процессором, до 70 градусов - абсолютная норма.

Видеонаблюдение

Продолжим. Ну какой умный дом без видео наблюдения?

В связи с тем, что умный дом у нас DIY, соответственно бюджетный, мы будем делать видео наблюдение на основе регистратора и аналоговых камер. Качество сносное, лучший вариант - все таки ip камеры. С другой стороны аналоговые камеры - гораздо меньше размером и существуют, например, в виде глазка.

Тем не менее, я выбрал аналоговый вариант с регистратором. Что такое регистратор - по-простому это коробочка для подключения аналоговых камер и микрофонов, с линуксом внутри, что обычно подразумевает возможность подключить sata диск и записывать на него, а также подразумевает наличие ethernet порта, с различными сетевыми возможностями - записью на ftp, samba сервер или даже облако (китайское), возможность просмотра камер с доступом через определенный порт (rtsp) и т.д. Возможностей обычно много - например тот же ntp клиент, dynDns и прочее.

У меня выбор пал на следующий регистратор. Сложно понять, что это за фирма и модель, тем не менее присутствие 960H подкупило. Хотя вот кстати его шильдик:

К сожалению, я не нашел возможность конфигурирования через веб-интерфейс (только просмотр с activex плагином). Конфигурировать возможно только непосредственно подключив мышь и монитор к регистратору или используя программу CMS (только под Windows), идущую на диске с регистратором (что говорит нам о том, что api управления есть - есть и конфигурация порта управления в настройках).

Дальнейшее разбирательство привело к следующим данным. Регистратор на основе hi3520d с такой начинкой:

[root@registrator custom]$ cat ProductDefinition
{
   "Vendor" : "General",
   "Hardware" : "MBD6704T-E",
   "PackSize" : 17408,
   "PreRecSize" : 2048,
   "LogoArea" : {"Begin": "0xe80000", "End": "0xec0000"}
}

[root@registrator custom]$ cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 1318.91
Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : hi3520d
Revision        : 0000
Serial          : 0000000000000000

Пароль для доступа через telnet к устройствам с таким контроллером xc3511. В принципе, там делать особо нечего, если не требуется каких-то сугубо специфических действий. Конфигурирование через telnet уж тем более на ваш страх и риск - не стоит там что либо править, если вы не уверены в своих действиях.

Это место в посты было переписано три раза :) Один раз кусок стер блогспот, второй раз я стер сам часто про то как я делал из rtsp jpeg. Провозившись три недели я все таки пришел к общему знаменателю вывода rtsp в веб для показа видео. И это связка - ffmpeg, nginx и nginx-rtmp. Для html5 в данный момент надо поддерживать целый зоопарк различно закодированных потоков. Это накладно для простых файлов, а для живого вещания вообще кошмар.

Как установить рассказывать не буду - вот хотя бы пример. Могу добавить, что для использования модуля надо пересобирать весь nginx целиком. Плюс добавлю, что после компиляции я создаю пакет и ставлю его:

/usr/src/nginx/nginx-1.5.9# checkinstall -D --install=no
/usr/src/nginx/nginx-1.5.9# dpkg -i nginx_1.5.9-1_amd64.deb

Дальше идем на https://github.com/arut/nginx-rtmp-module/ и читаем документацию. Пишем конфигурацию примерно такого содержания:

rtmp {

    max_connections 50;

    server {
 notify_method get;
        listen 1935;
        application cams {
            live on;
            allow publish 127.0.0.1;
            allow publish 192.168.0.0/24;
     deny publish all;
     exec_static ffmpeg -i "rtsp://ipregistrator:554/user=myuser&password=mypasswd&channel=1&stream=1.sdp" -c:v copy -profile:v baseline -c:a copy -f flv rtmp://localhost/cams/stream;
     exec_static ffmpeg -i "rtsp://ipregistrator:554/user=myuser&password=mypasswd&channel=2&stream=1.sdp" -c:v copy -profile:v baseline -c:a copy -f flv rtmp://localhost/cams/stream2;
 }

    }
}

Замечу, что exec_static выполняется при запуске nginx (ffmpeg забирает rtsp поток с регистратора и конвертирует в flv без перекодирования) , что очень удобно, не надо писать никаких дополнительных скриптов для запуска клиента.

Далее настраиваем flash плеер (uppod, flowplayer или др.) на html странице с адресом вида rtmp://server/cams/stream . В openhab с добавил Webview sitemap и в итоге у нас вышло нечто вроде:



Повесил китайский планшет на стену - openhab теперь используется в виде видеоглазка. Регистратор записывает видео при обнаружении движения (настройка довольно таки не тривиальная, но можно поиcкать инструкцию к программе cms на русском, такая существует.

В будущем планирую видео записывать в облако mail.ru, благо там получен 1 террабайт.

Управление и оповещение через jabber в openHAB

Отлично, у нас есть показания открытой двери и замка. Теперь было бы неплохо, получать какие-нибудь оповещения о событиях. Например, для начала, о том что замок закрылся или открылся.

Я решил оповещения сделать на основе jabber, тем более, что данный вариант позволяет даже управлять openHABом из jabber. Создаем учетную запись (xmpp или jabber). Ищем секцию xmpp в openhab.cfg. Прописываем сервер, логин, пароль.
Отправляем команду help:

(15:22:48) I: help
(15:22:49) my****@jabber.org: Usage: 
update ⟨item⟩ ⟨state⟩ - sends a status update for an item
send ⟨item⟩ ⟨command⟩ - sends a command for an item
status ⟨item⟩ - shows the current status of an item
items [⟨pattern⟩] - lists names and types of all items matching the pattern
say ⟨sentence to say⟩ - Says a message through TTS on the host machine
⟩ ⟨script to execute⟩ - Executes a script

Теперь разберемся, как нам послать сообщение о смене статуса открытого замка. Для этого просто создадим новое правило в home.rules:

rule "Door Check Lock Send"
when
        Item Main_Door_Lock changed
then
        if(Main_Door_Lock.state==1)
        {
            sendXMPP("jabber@jabber.org", "Замок двери открыт!")
        }
        else if(Main_Door_Lock.state==0)
        {
            sendXMPP("jabber@jabber.org", "Замок двери закрыт!")
        }
        else{
            sendXMPP("jabber@jabber.org", "Неполадки с датчиком замка двери!")
        }
end

Очень помогает в написании правил функция авто-дополнения в дизайнере (Ctrl+Space), ибо документация по этому поводу хромает.

Поэкспериментировав понимаем, что время отклика оставляет желать лучшего. Смотрим лог owfs - датчик опрашивается openHAB'ом раз в минуту - это как раз настройка в openHAB. К сожалению на данный момент время обновления едино для всех датчиков 1-wire в openHAB. Поэтому ничего не остается, как сменить частоту обновления хотя бы на раз в 10 секунд.

Кеш owfs для датчиков по умолчанию 15 секунд. Поэтому, чтобы получать свежие значения, надо изменить его на 10 секунд. Пропишем в owfs.conf:

timeout_volatile = 10
#error_print = 1
error_print = 3
error_level = 2

error_print = 3 обозначает подавление логов - при опросе раз в 10 секунд из слишком много.

Протестировав я понял, что и 10 секунд слишком много. Но дальше увеличивать частоту опросов всех датчиков накладно. И вообще неплохо бы использовать unchached значения из owfs для датчиков, а кеш использовать только для датчиков, данные которых не критичны в времени опроса - например, датчики температуры. Но в openHAB пока с этим проблемы. Поэтому будем использовать небольшой хак. Для датчиков мы будем использовать exec binding и получать данные с файловой системы. Формат запроса:

in:  exec:"<[<commandline execute="" to="">:<refreshintervalinmilliseconds>:<transformationrule>]"

items:

Number Main_Door_Lock "Замок в двери C: [MAP(ru.map):%s]"<door>(Doors) { exec="<[/bin/cat /mnt/1wire/uncached/12.A214B2000000/sensed.A:5000:REGEX((.*?))]" }

В принципе, тут можно использовать и Contact.
Результат срабатывания правила:

Последний штрих - теперь нам надо настроить запуск приложения файловой системы owfs, потому что мы с него получаем данные. (Проверьте, что у вас запускается при старте в директориях rc.d).

# update-rc.d owfs defaults 30

Не забудьте выставить очередь запуска после owserver (у меня, как видно 30, а у owserver 20)!

Датчик открытого замка\двери\окна на 1-wire и openHAB

После небольшого перерыва на софт вновь перейду к железной стороне. Следующим устройством в сети мне надо сделать датчик открытого замка. Если вы помните, мы использовали электронную метку ds2401 для определения наличия датчика в сети. Как мы убедились, а умные люди нам подсказали - это работает слишком медленно. Поэтому мы будем использовать не определение датчика в сети, а сигналы от датчика-ключа ds2406p (такую микросехму я нашел, можно использовать и другие). Заодно мы сделаем и датчик открытой двери, ибо в таком исполнении у микросхемы два канала.

DS2406P универсальный элемент стандарта 1-Wire-net. Она содержит два независимых транзисторных ключа, с током потребления до 50 мА на предельном коммутируемом напряжении +13 В (для канала А) и до 8 мА на предельном коммутируемом напряжении +6 В (для канала B). DS2406P может быть использована также для контроля двух независимых датчиков дискретных сигналов типа "сухой контакт". (с).

Изучаем схему с сайта http://www.benuks.ru/

Схема аналогична этой. Только тут используется более "продвинутая" микросхема.

Освоим технологию создания плат (типа продинутый ЛУТ), мне понравилось вот это видео (пришлось даже ламинатор купить):

Единственно, я заменил самоклейку на фотобумагу. Но с ней у меня ничего не вышло, в итоге я взял лист от тонкого глянцевого журнала. Процесс травления не показан, ну можно поискать, или вот он:

Качаем архив со схемами в формате layout4. Находим там схему и печатаем на листе  тонкого глянцевого журнала, прогоняем результат с ламинатором.

То, что получилось у меня после печати и прогона в ламинаторе (160 градусов Цельсия):

Травим, получаем (снизу артефакты от первой печати с фотобумагой, сверху - плохой журнальный лист - тонер отскочил от него - подкрасил маркером):

Моем (бензин или ацетон) и сверлим отверстия (я собрал мини дрель - держатель в сборе в радио магазине, двигатель от детской машины).

Для покупки-сбора инструмента, освоение технологий, ушло пару-тройку рабочих недель. Цанговый патрон брал в местном радио-магазине, сверла здесь. Отличные сверла, рекомендую. Лудим, паяем плату.

Обратите внимание - в схеме надо делать перемычку для подачи 5 вольт на ds2406. Далее, я подпаял разъем rj11 и подключил к нашей сети 1wire . Заходим в директорию /mnt/1wire и смотрим - у нас должен появиться новый датчик. Подключив геркон к выводу "земля" и А (или B), а магнит приклеив к замку - получаем датчик закрытого\открытого замка:

root@truck:/mnt/1wire/12.***4B2000000# cat sensed.A
0
root@truck:/mnt/1wire/12.***4B2000000# cat sensed.B
1

B - можно использовать тут же, например, для датчика закрытой двери.

Стабилизатор с 18 на 12 вольт я впаивать не стал - в данном случае нам 12 вольт не нужно.

OpenHAB

Теперь нам надо показания датчиков открытия отобразить в OpenHAB. Я пытался использовать стандартный Contact item. Но по-видимому он еще не работает с 1wire. Поэтому пришлось прописать показания открытого замка как Number.

/* Active Group */
Group:Number:SUM        Doors   "Двери [открыто: %d]"     (All)

/* Contacts */

Number  Main_Door      "Входная дверь: [MAP(ru.map):%s]"       <door>  (Doors) { onewire="12.A234B4000000#sensed.B" }
Number  Main_Door_Lock "Замок в двери: [MAP(ru.map):%s]"        <door>  (Doors) { onewire="12.A234B4000000#sensed.A" }

1 - открытая дверь/замок, 0 - закрытая. Группа Doors (привет поклонникам Джима :) ) - показывает суммарное значение показаний item в группе - соответственно, количество открытых дверей.
ru.map пишем по аналогу en.map. В sitemap выводим просто группу.

Так как doors у нас через number, а иконка door завязана на Contact с показаниями open\close, то картинку door-open.png копируем в door-1.png, а door-close.png копируем в door-0.png.

Результат:

ps. Только я спросил про патч, сразу товарищи разработчики его наложили. Так что можете пробовать Contact item в ночном билде (я думаю это исправление войдет в версию 1.4, которая выйдет 9-го февраля 2014 года). Я пробовать не буду, так как меня пока устраивает на основе Numbers.