Majordomo

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

Если теорию знаете, можно перейти к моей истории поисков идеального решения.

NB! Так же для удобства, жирным курсивом подсветил названия технологий и платформ. А просто жирным - важные наблюдения или выявленные глобальные засады.

Ну, а теперь по порядку, немного теории

Умным домом принято называть что угодно, от 2 лампочек, управляемых по таймеру до сложной системы, реагирующей на множество факторов и делающей жизнь владельца комфортной.

• В любом случае речь про управление устройствами, кратко их можно собрать в группы:

• Бытовая техника (пылесосы, телевизоры, чайники, кондиционеры)

• Реле/выключатели (вкл/выкл)

• Лампочки/ленты (меняют цвет и яркость)

• Датчики (мощность, напряжение, температура, влажность, концентрация газов)

• Диммеры (пропорциональный выходной сигнал)

• Исполнительные устройства (регуляторы температуры, привод штор)

• Шлюзы (пульты, универсальные передатчики команд)

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

• Умный дом Яндекс - нет логики, только команды, много совместимых устройств

• Xiaomi (Aquara) простые скрипты

• Google Home простые скрипты, много совместимых устройств

• Domoticz ограничен набор устройств, развитая логика

• IFTTT - ограничен набор устройств, развитая логика

• HomeAssistant - ограничен набор устройств, развитая логика, настройка интерфейса плагинами

• Majordomo (php) - развитая логика, открытый проект, активно развивается, требует умения программировать.

Нужно заметить, что платформы от именитых производителей умеют работать друг с другом. То есть их экосистемы можно объединять, что существенно расширяет перечень подключаемых устройств. Кстати, о подключениях тут есть 2 аспекта: как подключаться физически и как общаться с концентратором умного дома.

Физически можно связываться через локальную компьютерную сеть (проводную или беспроводную), сеть малого радиуса (Bluetooth, ZigBee) или просто по радио или инфракрасному каналу (последнее обычно только в одну сторону работает).

Что же касается языка на котором общаются устройства, то тут вариантов много, но можно разделить на открытые (общедоступные) типа mqtt (сервис коротких сообщений через центральный сервер) или web-hook (обычные прямые ссылки на веб-сервер на борту устройства) и закрытые типа протокола Xioami/Redmond и прочих, которые известны только производителям.

Устройства это хорошо, но что же ими управляет? Центральное устройство/ центр управления. Кстати, хабы типа Aqara это нифига не центральный модуль, а всего лишь концентратор сети ZigBee или какой иной, понравившейся производителю логика остается в самих устройствах или на телефоне пользователя или в облаке.

Насколько я понял, большинство облачных сервисов не поддерживают логику. То есть в Яндекс доме можно узнать температуру и включить обогреватель. Но заставить Яндекс следить за температурой и держать в комфортном диапазоне нет!

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

Как ни странно, дешевые микро ПК на ARM процессорах, например OrangePi, Nano Pi и прочие фруктовые Пи вполне тянут систему с базой данных, брокером сообщений и веб-интерфейсом. Не говорю уже про Raspberry это вообще, как заговоренные.

Из программных серверов умного дома можно выделить популярные: Blynk (есть вариант облака и локальный), IFTTT (чисто облако, но с мобильным приложением), Home Assistant, Domotics, Majordomo.

История рождения моего умного дома

На момент начала моей автоматизации, у меня были штук 6 устройств SonOff (у них родное приложение и облако eWeLink), управлял розетками на даче. И поставил камеры Xiaomi Dafang (камеры не понимали русский, но это PTZ, FullHD, да еще и стоили всего 2 тысячи рублей каждая). Камеры принесли на дачу постоянный интернет (мобильный), роутер. А также облако Xiaomi. Итого, 2 облака Xiaomi + eWeLink. Надо было собирать в единую панель управления. Первым был установлен HomeAssistant, даже игрался с камерами (хотел на датчик движения у камер прикрутить и сохранять в системе). Но дальше скриншотов, и то не всегда, дело не пошло. С SonOff вообще не смог подружить. Решив, что логика для розеток все-таки важнее, начал играться с MajorDomo, который имел для этих устройств коннектор, а также более-менее понятный интерфейс настроек (субъективно, да, php+html, объектно-ориентированная модель).

Первый тревожный звоночек пришел от Роскомнадзора в попытке убить телеграмм (безуспешной) они прибили доступ ко многим облакам, в том числи и Xiaomi. В середине зимы было очень неприятно оказаться без видеонаблюдения за дачей, расположенной в 100 км от дома..

Итог камеры перепрошиты на Dafang Hack (прошивка делающая локальный RTSP сервер потокового видео) и первая моя Raspberry c MotionEyeOS (локальный видео сервер), а также белый IP дома и VPN между домом и дачей (на роутерах Mikrotik). Локальный сервер держит архив на 500Гб (пара месяцев с двух камер), питается от аккумулятора (до 3 дней без света).

Для логики нужно не только управлять, но и контролировать, для этого купил SonOff POW R2 это фактически, счетчик электроэнергии с выключателем на 16А (стоимость по 750 рублей). Это позволило при включении посудомоечной машины, бойлера для воды (суммарно 4 кВт) блокировать розетку с чайником. Сейчас это модно называется DemandResponse. А так же стало возможно контролировать работоспособность насосов водоснабжения и канализации (по графику дренаж включается и на графике мощности есть пики, по которым можно понять, много ли воды и вообще, не завис ли поплавок!) - дистанционная диагностика оборудования. Так же для управления низковольтными устройствами (включение дизельного отопителя, насоса аэрации воды для очистки, отключения зарядника от аккумулятора, когда нет напряжения в сети СНТ) был куплен клон SonOff G4 четырехканального реле с радиопультом (еще 1100 рублей).

Второй звоночек пришел от eWeLink с выходом в массы устройства контроля напряжения SonOff POW R2 поток через их сервер, видимо, стал превышать их возможности (ток, напряжение, мощность активная, мощность реактивная, мощность полная, коэффициент мощности и все это 5 раз в секунду с каждого такого устройства) и они решили, что датчики будут телеметрию слать один раз в минуту. То есть у вас уже минуту мощность за разумными рамками или напряжение просело до Америки (113 вольт реально было летом), а умный дом живет в розовых мечтах, что все хорошо.

Итог модуль MojorDomo для локального режима SonOff и окончательный переход на MajorDomo на Orange Pi (стоила около 1000 рублей всего, пришлось осваивать Linux, а точнее Armbian и по инструкциям ставить MajorDomo). Но недолго музыка играла SonOff почувствовали что-то неладное и очередная прошивка на их сервере отрубила локальный режим, то есть только через облако, только раз в минуту..

Полная локализация

Так как умный дом к этому моменту управлял в том числе зарядкой аккумулятора и переключением на инвертор в случае аварии, зависеть от облака на вражеских серверах, а так же наличия связи с интернет показалось не очень разумной идеей.

Очередной шаг перепрошивка всех устройств на Tasmota, отказ от протокола eWeLink и уход на MQTT. Это, кстати, открыло путь в полный лоукост прошивка легко настраивается, а плата Wemos из Китая стоит всего 120 рублей, при этом на борту 12 линий для подключения периферии, АЦП, WiFi. Так число устройств в умном доме увеличилось раза в 3 выключатели, датчики напряжения на АКБ, датчики температуры и влажности (кстати, оказалось, что лучший AM2301 это AM2320! Программно совместим с AM2301, который еще называют DHT21, но при этом стабилен, не глючит и не зависает).

Тут Остапа понесло и в умном доме появились солнечные панели, 2 контроллера (один PWM, второй - MPPT), датчики тока от солнечных панелей в систему и на АКБ (просто по напряжению на клеммах степень заряда не измерить). От АКБ, кстати, на этот момент питаются 3 камеры, 2 микросервера, 2 роутера, общее потребление примерно 40Вт постоянно.

После примерно полугода, когда все было настроено и отлажено пришла беда умерла карта памяти. Свежего бэкапа не оказалось все ждал идеального состояния, не дождался. Изучил, какие карты бывают узнал про MicroSD A2 это карты с контроллером, как у SSD дисков - то есть много и часто писать/читать мелкие файлы им не страшно. Настроил, по памяти восстановил логику и оформление, сделал бэкап. Через месяца три началось неладное зависания, тормоза при открытии графиков за месяц. Анализ (я почти стал спецом по Linux) показал, что база данных тупит из-за очень большого числа накопленных данных. Пришлось делать удаление старых данных, оставляя только по 2 отсчета за минуту для данных старше месяца. Помогло, но не сильно. Надежда была на плату с большим объемом памяти Orange Pi One Plus (700 рублей), но не судьба. В итоге куплена Raspberry Pi4 c 2Гб памяти на борту, а для этой палаты есть оптимизированный образ MajorDomo и о чудо, там все отлично БД крутится полностью в памяти, раз в час сбрасывается на карту бэкап, в случае незапланированного падения, при загрузке восстанавливается состояние на начало часа.

Все это было отлично, управляется с компьютера, с телефона (экран на картинке там 2 таких сцены, одна для управления и климата, вторая для телеметрии).

Но вот беда чтобы включить свет надо все равно тянуться за телефоном и тыкать мелкие кнопки. А на даче еще и родители бывают, а для них много кнопок на экране слишком сложно.

Появление голосового управления

И вот тут я задумался, что пора подключать голосовой помощник. Сначала думал про Google Assistant/Home, но увидав, что они творят со своим президентом, да еще к новому году отключили поддержку русского на колонках (оставив только на телефонах), решил, что вполне реально повторение с отключенными облаками Xiaomi и eWeLink. В итоге, Алиса от Яндекса. Каково же было мое удивление, когда увидел, что есть стандартный коннектор (навык Алисы) к MajorDomo! Яндекс станция мини отлично подошла по функциям и размеру, более того, нашел и обратный коннектор из MajorDomo можно выдавать команды на устройства, подключенные к Алисе пультам кондиционеров, телевизиров и даже роботу-пылесосу. И это не считая проговаривания статусов типа внимание, работаем от аккумуляторов!. Соединение с Алисой можно сделать двумя способами через платный сервис Connect (2 тысячи рублей в год, бонусом облачные бэкапы) или через Яндекс.Диалоги для этого надо SSL сертификат на сайт, белый IP, и выставленный в интернет сайт с MajorDomo, то есть свет или отопление сможет отключить случайный прохожий. В общем, 2к в год не большая цена за сохранение комфорта, да и SSL покупать не надо.

Естественно, управление через Яндекс это чисто функция комфорта, основная логика реализована на локальном уровне.

Итак, затраты:

Количество физических устройств не соответствует числу управляемых каналов одно 8 канальное реле это датчик тока и 8 выключателей! Так что общее число устройств в системе 68 (и это не считая Яндекс.Станции и устройства не на даче, только то, что управляется локально!).

Внимание, мошенники!

Кстати, про Яндекс.Станции. С рук покупать очень не советую оказалось, что есть станции по подписке продается конкретному человеку и 3 года он должен платить по 400 рублей в месяц. Никому такую передавать нельзя она залочена на учетку того, кому ее Яндекс отдал. То есть они не для продажи. Ни на коробке, ни на станции, ни при включении она ничем не отличается от обычной (только, кажется, глуховатые, кстати). Но через 10 минут работы говорит оплатите подписку и вообще не работает никак. Поддержка Яндекса может проверить по номеру, но отвечают через день явно долго для проверки при покупке.

Итак, мой умный дом готов, слушается голоса, управляет климатом, зарядкой аккумулятора на даче.

Более того, умные устройства стоят теперь как на даче, так и дома, в городе. Причем из-за особенностей совместимости экосистем с Яндексом часть устройств дома (RGB ленты) управляются через сервер на Majordomo (дача).

И вот тут возникает ряд логичных вопросов:

где должен стоять сервер дома или на даче?

Потерей управления какими устройствами жертвовать при обрыве связи между домом и дачей?

Как не грузить GSM канал до дачи передачей графиков в HTML верстке сайта?

Легко догадаться, что ответом является резервирование:

1. Серверы должны быть и там и там

2. Серверы должны уметь управлять всеми устройствами

3. Серверы должны иметь полный набор данных

Так как датчики общаются с сервером в основном через протокол MQTT, MQTT брокер так же становится точкой отказа.

Резервирование сервера

Начнем с MQTT брокера. Если не считать таких сообщений, как LWT (последняя воля устройства) и Retain (хранимых на сервере), большинство сообщений передаются одномоментно и только тем, кто в данный момент подключен к брокеру. То есть "отправил - забыл".

К счастью, в последних версиях mosquitto сервера есть режим бриджа вы просто задаете адрес второго брокера и топики, которые нужно дублировать, направления дублирования. В моем случае вполне пригодился вариант копировать все в обе стороны. Вот как это делается в raspbian/armbian добавляем в /etc/mosquito/mosquito.conf:

#connection bridge-01connection bridge-01address mqtt.mydomain.ru:1883topic # out 0topic # in 0

Вуаля, оба брокера содержат одни и те же данные, локальные устройства могут общаться с локальным брокером в локальной сети (без задержек и прочей чепухи ненадежных каналов).

Дальше, сами серверы Majordomo. Я сделал второй сервер на базе Orange pi one plus (1Gb RAM) стоит в 2 раза дешевле Raspberry Pi4, для вспомогательного сервера - то, что надо. Но серверы должны уметь делать одно и то же, но не делать этого одновременно (в большинстве случаев это не страшно, ну поступит 2 команды на включение зарядника не страшно, но некоторые вещи лучше дважды не делать, например, не поворачивать солнечные панели по часам).

Так как для корректной работы с датчиками и исполнительными устройствами я использую MQTT, логично отслеживать работоспособность удаленного сервера через тот же MQTT. Для этого я создал отдельный класс, в котором есть 2 статуса (для отображения) и 2 времени для локального сервера и для удаленного, а также адрес активного брокера и собственный адрес сервера. Раз в 10 секунд выполняется проверка системного цикла MQTT время последнего запуска (ThisComputer.cycle_mqttRun). Это время сравнивается с текущим (time()). Если прошло больше 10 секунд паникуем, то есть понимаем, что локальный сервер не дружит с MQTT брокером и показываем это в интерфейсе. Так же сравниваем время последнего запуска MQTT цикла на удаленном сервере (приходит через MQTT). Если прошло больше 20 секунд, а локальный цикл в порядке понимаем, что удаленный сервер больше не управляет устройствами. Проверяем еще один параметр, передаваемый через MQTT имя активного брокера. Если это не локальный, то надо переключать на себя:

$val=getGlobal("ThisComputer.cycle_mqttRun");$locval=time()-$val;$this->setProperty("LocValue",$val);$this->setProperty("LocDeltaT",$locval);if($locval>10)$locstate=1;else$locstate=0;$tmp=$this->getProperty("Status");if(is_null($tmp))$tmp=10;if($tmp!=$locstate)$this->setProperty("Status",$locstate);$remval=time()-$this->getProperty("RemValue");$newstate=($remval<20)?0:1;$this->setProperty("RemStatus",$newstate);$ot = $this->object_title;$currBroker=$this->getProperty("MQTT_broker");$sA=$this->getProperty("selfAddress");if($sA!=$currBroker)$this->setProperty("isController",0);setTimeOut($ot . "_checkCycle",'callMethod("'.$ot.'.checkCycle");',10);if((!$locstate&&($newstate||($this->getProperty("LinkedRoom")=="Energoblok")))&&($sA!=$currBroker))// remote failed local good or local is good and is not local server{debMes('Switch to '.$this->getProperty("selfAddress"),0);$cnt=0;for($i=40;$i<90;$i++){if(ping('192.168.3.'.number_format($i,0)))    {getURL('http://192.168.3.'.number_format($i,0).'/cm?cmnd=MqttHost%20'.$this->getProperty("selfAddress"));debMEs('http://192.168.3.'.number_format($i,0).' is online',0);$cnt++;$this->setProperty("LocValue",time());}}if($cnt>10){$this->setProperty("MQTT_broker",$this->getProperty("selfAddress"));$this->setProperty("isController",1);}}

У меня Tasmota устройства (IP в диапазоне c 192.168.3.40 по 192.168.3.90), им можно передать обычным URL запросом новый адрес MQTT сервера. Вот только запросы надо посылать синхронные, а главное не забывать между ними обновлять MQTT свойство для удаленного сервера. Иначе получится замкнутый цикл начали переключаться, больше 10 секунд не сообщаем удаленному серверу, что мы живы. Тот начинает переключение на себя и тоже замирает. Не делайте так :)

Повышаем надежность самого сервера

Операционная система и БД хранятся на карте памяти. Есть карты класса А1 и даже А2, но через год постоянной нагрузки такая карта с большой вероятностью загнется. Кроме того, штатный код пишет в базу кучу ненужного, а каждое чтение/запись свойства любого объекта это обращение к БД. У меня было порядка 1200 обращений к БД в секунду.

Карту можно спасти, если базу держать в оперативной памяти. К счастью, разработчики Majordomo сделали прошивку для Raspberry сразу с опцией БД в памяти, а для прочих платформ есть скрипт для переноса БД в память (но памяти должно быть не менее 1Гб, на orange pi zero c 512Мб у меня не взлетело - база весит порядка 300Мб и столько же надо дополнительно для дампов бэкапов). Да, теперь в любой момент просто так перезагружать систему нельзя, нужно выполнить скриптик, иначе данные за последние полчаса потеряются (но база всегда бэкапится в рабочем состоянии!). Зато скорость работы БД и долговечность карты памяти просто великолепны.

Остался последний штрих снизить нагрузку на БД, убрав лишние запросы. Решение простое:

• Обновиться до последней версии (буквально пару недель назад обновили интерфейс, убрав лишние обращения к БД и переписав на java скрипты)

• Обращаться к локальным или глобальным свойствам только один раз и использовать переменные в памяти (смотрите на пример кода цикла проверки getProperty\setProperty там использованы только по одному разу).

Еще пример оптимизации скриптов чтобы и обращений лишних не было, и чтобы срабатывала автоматическая зависимость от переменной, например:

if((($temp2Floor=getGlobal("sTemp2Floor.value"))<'21')&&gg("remote_mqtt_updated.isController")) // if remote failed{if ($temp2Floor < '21' && !getGlobal("rConserveSW.status") && timeBetween('2:00', '8:00')) { if (!getGlobal("rDieselHome.status")) { callMethod("rDieselHome.turnOn"); }} else if ($temp2Floor > '23') { if (getGlobal("rDieselHome.status")) { callMethod("rDieselHome.turnOff"); }}}

Обратите внимание, что в первом условии есть ветка проверки, этот ли сервер управляет устройствами в настоящий момент (gg("remote_mqtt_updated.isController")). remote_mqtt_updated это объект контроля работы серверов.

Теперь у меня число обращений к БД порядка 380 в секунду, что гораздо лучше по сравнению с начальным значением в 1200.

Итог

Вот так, добавив сервер за 2500 рублей, получил полное резервирование брокера сообщений, сервера управления устройствами (логики) и можно получать графики с актуальными данными с домашнего сервера, не нагружая сервер, работающий через GSM модем.

В связи с переходом на частично удаленную работу у меня появилась потребность дистанционного включения рабочего (домашнего) компьютера с программой удаленного управления, из-за пределов локальной сети.
Реализацию осуществил двумя способами: первый с помощью SIP сервера FreeSWITCH, посредством телефонного соединения через IVR меню; второй способ с помощью системы домашней автоматизации ("Умный Дом") MajorDoMo.
Устройство, выполняющее отправку магического пакета - мини компьютер Rasberry Pi Model 3B, в первом случаю выполняет роль IP АТС, во втором сервер Умного Дома.
Первоначальная идея была создание возможности удаленного управления элементами "Умного Дома" при отсутствии (блокировки, нестабильной связи и т.д.) сети Internet или отдельных сервисов. Однако для написания статьи я выбрал наиболее актуальное (для меня) применение. Итак, основная задача: набрав с телефона номер своего Умного дома и введя подтверждение, дистанционно включить свой ПК.

Wake-On-LAN (иногда сокращенно WoL) является стандартным протоколом для пробуждения компьютеров дистанционно. ПК должен быть подключен физически и к электричеству и к роутеру с помощью проводного (иногда Wi-Fi) соединения. Включение Wake-On-LAN зависит от двух вещей: материнской платы и сетевой карты. Материнская плата должна быть подключена к ATX-совместимому блоку питания, на данный момент среди ПК таких большинство. Сетевая карта или беспроводная карта также должны поддерживать эту функцию.
Технология WoL позволяет удалённо включить компьютер посредством отправки через локальную сетьспециальной последовательности байтов пакета данных(так называемогоmagic packet волшебного пакета).

Подготовительная часть:

Настраиваем свой ПК для работы с magic packet: в БИОСе и настройках сетевой карты. Настройку я подробно описывать не буду, довольно много статей и инструкций есть в сети на эту тему, к тому же наименование функции меняются в зависимости от производителя материнской платы. Если коротко, то в BIOS включение функции обычно находится в Power Management Setup, или ACPI Configuration. Требуется активировать опцию Wake-Up by PCI devices (или Wake-on-LAN, Power on by Ethernet Card, Power by PCI и т.д.) для встроенной в материнскую плату сетевой карты.

В настройках Windows включение требуется активировать в двух местах: Диспетчер Устройств Сетевые адаптеры Свойства:

Управление электропитанием: опция Разрешить этому устройству пробуждать компьютер и опцию пробуждения ПК с помощью магического пакета и дополнительно (у меня), включение по локальной сети после отключения;

Узнаем MAC адрес ПК. В случае с ОС Windows. В командной строке набираем ipconfig/all и ищем физический адрес сетевого адаптера.

У меня: Физический адрес. . . . . . . . . : 38-05-47-78-3B-35
Проверим включение через локальную сеть. Подключаемся к Raspberry Pi с помощью SSH клиента.

Для того, что бы наш Raspberry Pi мог отправлять магический пакет по сети устанавливаем пакет etherwake:

sudo apt-get install etherwake

Если БИОС и ОС настроены правильно, то после установки пакета Etherwake, удаленно включить ПК можно задав следующую команду на RPi :

sudo etherwake 38:05:47:78:3B:35

Где 38:05:47:78:3B:35MAC адрес удаленного ПК, который мы недавно узнали, для каждого компьютера он будет свой. Утилита Etherwake работает только от пользователя sudo. Создадим скрипт сделаем его исполняемым и проверим отработку включения ПК этим скриптом:

nano /home/pi/wakeup.shsudo chmod +x /home/pi/wakeup.shsudo /home/pi/wakeup.sh

#! /bin/bashsudo etherwake 38:05:47:78:3B:35

Способ 1. Удаленное включение ПК через телефонную сеть

В этой части установим, произведём минимальную первоначальную настройку SIP сервера FreesWITCH на Raspberry Pi и дистанционное включение ПК (возможность управления элементами Умного Дома) через телефонные сети.

В качестве устройства подключения к телефонным сетям я использовал VoIP-GSM шлюзс поддержкой 1 GSM линии Yeastar TG100.

Установка Freeswitch:

Устанавливаем freeswitch из пакетов на официальном сайте есть рабочая инструкция поустановке для Raspberry Pi :
Приведу свои действия:
Входим под пользователем sudo и выполняем следующие команды:

sudo -iapt-get update && apt-get install -y gnupg2 wget lsb-releasewget -O - https://files.freeswitch.org/repo/deb/rpi/debian-release/freeswitch_archive_g0.pub | apt-key add -echo "deb http://files.freeswitch.org/repo/deb/rpi/debian-release/ `lsb_release -sc` main" > /etc/apt/sources.list.d/freeswitch.listecho "deb-src http://files.freeswitch.org/repo/deb/rpi/debian-release/ `lsb_release -sc` main" >> /etc/apt/sources.list.d/freeswitch.listapt-get update && apt-get install -y freeswitch-meta-all

Установка длится около получаса. По окончании перегрузим малинку. Для проверки работоспособности можем войти в консоль freeswitch (выход из консоли quit или же CTRL+D):

sudo fs_cli

Первоначальная настройка FreeSWITCH

После установки FreeSWITCH почти готов к работе, в нём по умолчанию есть 20 абонентов с номерами 1000-1019. Пароль по умолчанию для абонентов VoIP указан в файле /usr/local/freeswitch/conf/vars.xml и равен 1234.
В директории /usr/local/freeswitch/conf/derectory/default находятся 20 xml файлов, каждый из которых отвечает за абонента с соответствующим номером. Можем добавлять абонентов копированием файлов с подстановкой данных.

Из коробки freeswitch частично работоспособен, имеет довольно обширный диалплан.

Зарегистрировав VoIP телефон (софтфон) можем попробовать произвести несколько тестовых звонков: набрав номер 500 попадаем в демо IVR меню Freeswitch на английском языке. Позвонив на номер 779 используется расширение eavesdrop: после набора номера идёт автоматический ответ на SIP сервере и посылка звонящему звуковых тональных сигналов. Эти два направления и будем использовать в дальнейшем.Небольшое замечание при полностью дефолтном пароле при наборе номера идёт задержка 10 секунд.
Отредактируем файлы конфигурации: сменим дефолтный пароль, изменим язык голосовых сообщений на русский, так же поменяем профиль с external на internal.

 sudo nano /etc/freeswitch/vars.xml

<X-PRE-PROCESS cmd="set" data="default_password=1111"/><X-PRE-PROCESS cmd="set" data="sound_prefix=$${sounds_dir}/ru/RU/vika"/><X-PRE-PROCESS cmd="set" data="use_profile=internal"/><X-PRE-PROCESS cmd="set" data="default_country=RU"/>

Так же исправим одну строчку с указанием неправильной директории звуковых файлов в файле: etc/freeswitch/lang/ru/ru.xml приводя строку к виду

<language name="ru" sound-prefix="$${sounds_dir}/ru/RU/vika" tts-engine="cepstral" tts-voice="elena">

Перегружаем сип сервер (можно в консоли fs_cli набрать reloadxml), снова подключаемся sip клиентом, изменив пароль. Набираем номер 500 и уже слышим приветствие FreeSWITCH в IVR меню уже на русском языке. Можно собрать из существующих при установке звуковых файлов FreeSWITCH нужную вам фразу, можно использовать заранее записанный *.wav файл, указав полный путь, в файле /etc/freeswitch/ivr_menus/demo_ivr.xml.

Перейдём к диалплану (номерной план, dialplan) формальное описание схемы маршрутизации и обработки телефонных звонков. Номерной план подробно описывает, что система должна делать со входящими и исходящими звонками: передавать их дальше, сохранять, отвечать на них самостоятельно и так далее. Основные настройки по умолчанию находятся в файле /etc/freeswitch/dialplan/default.xml

Отредактируем его, найдём строчку с номером 779 и добавляем всего одну строчку в секции eavesdrop с номером 779.<action application="system" data="/home/pi/wakeup.sh "/>, которая и запустит ранее сделанный скрипт с посылкой магического пакета.
Номер (направление) я тоже решил поменять на 7777, можно указать любой, в качестве своего ПИН-кода. В итоге секция у меня приняла такой вид:

<extension name="eavesdrop">      <condition field="destination_number" expression="^7777$"><action application="answer"/><action application="system" data="/home/pi/wakeup.sh "/><action application="set" data="eavesdrop_indicate_failed=tone_stream://%(500, 0, 320)"/><action application="set" data="eavesdrop_indicate_new=tone_stream://%(500, 0, 620)"/><action application="set" data="eavesdrop_indicate_idle=tone_stream://%(250, 0, 920)"/><action application="eavesdrop" data="all"/>      </condition>    </extension>

Сейчас при наборе номера 7777 идёт автоматический ответ, запуск скрипта, и посылка тоновых сигналов.

Небольшое примечание: как вы помните утилита etherwake запускается с правами суперпользователя. При установке SIP сервера у нас создается новый простой пользователь freeswitch, не имеющий пароля. Нужно разрешить ему запускать скрипт от Sudo, с посылкой магического пакета. Есть два варианта: первый разрешаем ему выполнять любые действия без ввода пароля от sudo, второй вариант в sudoers разрешаем запускать без пароля только определённые программы (в данном случае скрипта).

Я применил первый вариант, для этого создаем группу для пользователей, которые будут использовать sudo без ввода пароля, добавляем пользователя freeswitch к этой группе:

sudo groupadd sudosudo usermod -a -G sudo freeswitchsudo nano /etc/sudoers.d/freeswitch-nopasswd

Создаём ещё один файл. Содержимое файла всего одна строчка:

freeswitch ALL=(ALL) NOPASSWD: ALL

Изменим немного демонстрационное голосовое меню (IVR), установленное по умолчанию:

sudo nano /etc/freeswitch/ivr_menus/demo_ivr.xml

Добавим всего одну строку с регулярным выражением, после строки с трансфером добавочного номера (цифры номерного плана 1000-1019) в XML features передадим набранный номер 7777, с командой на выполнение скрипта, в дефолтное направление:

<entry action="menu-exec-app" digits="/^(10[01][0-9])$/" param="transfer $1 XML features"/> <entry action="menu-exec-app" digits="/^(7777)$/" param="transfer 7777 XML default"/>

Сейчас, в локальной сети, набрав номер 5000 попадаем в IVR меню и далее набрав наш номер 7777 (ПИН-код), отрабатывает скрипт и в качестве ответа слышим тоновые посылки.

Настроим выход SIP сервера во внешнюю сеть. Для этого перейдем к небольшой настройке VoIP шлюза. Зайдя в интерфейс GSM шлюза (по умолчанию: адрес 192.168.5.150 логин admin и паролем password). Изменим IP адрес, можем поменять имя пользователя и пароль на подключение к шлюзу.

По умолчанию у нас имеется 2 Sip аккаунта. Для примера буду использовать один из них с именем 20001 и паролем на подключение pincode20001.

Перейдём опять к настройке FreesWITCH. Отредактируем профиль internal, в файле /etc/freeswitch/sip_profiles/internal.xml. В секции gateways добавим возможность чтения xml файлов из директории internal и принудительно выставим параметры ext-rtp-ip и ext-sip-ip указав в них IP адрес нашего SIP сервера (малинки). Без этих указания этих параметров профиль internal у меня подымался на некорректном IP адресе и соответственно не работал.

sudo nano /etc/freeswitch/sip_profiles/internal.xml

<gateways><X-PRE-PROCESS cmd="include" data="internal/*.xml"/>  </gateways>...   <param name="ext-rtp-ip" value="192.168.1.101"/>    <param name="ext-sip-ip" value="192.168.1.101"/>

Создадим директорию для xml файлов шлюза и файл с настройками подключения к GSM шлюзу:

sudo -u freeswitch mkdir /etc/freeswitch/sip_profiles/internalfreeswitch nano /etc/freeswitch/sip_profiles/internal/GSM.xml

<include> <gateway name="GSM"><param name="username" value="20001" /><param name="password" value="pincode20002" /><param name="proxy" value="192.168.1.101" /><param name="from-domain" value="192.168.1.101"/> <param name="ignore_early_media" value="true"/> <param name="expire-seconds" value="600" /> <param name="register" value="true" /> <param name="register-transport" value="udp" /><param name="retry-seconds" value="60" /> <param name="context" value="default" /><param  name="caller-id-in-from" value="true"/>        </gateway> </include>

Перегружаем freeswitch: sudo systemctl restart freeswitch.service. Заходим в консоль freeswitch и проверяем состояние профилей FS, задав команду sofia status

Как видим появился дополнительный профиль GSM, с состоянием REGED (зарегистрирован), профили internal и internal.gsm подняты на правильном интерфейсе, профиль external на неверном, можем отредактировать его в соответствующем файле.

Создадим файл, который отвечают за входящую GSM шлюза с freeswitch сервером. В файле from_GSM.xml все входящие звонки, поступающие от 20001 запускают IVR меню. Набрав свой ПИН-код запускается скрипт, в котором мы ранее прописали запуск ПК. Ну а далее, помощью программы удаленyого доступа можно соединится с компьютером с любого места.

sudo -u freeswitch nano /etc/freeswitch/dialplan/default/from_GSM.xml

<include><extension name="call from GSM"><condition field="destination_number" expression="^20001$"> <action application="answer"/> <action application="sleep" data="800"/><action application="set" data="transfer_ringback=$${ru-ring}"/> <action application="ivr" data="demo_ivr"/> <action application="hangup"/>    </condition></extension></include>

Перегружаем сервер IP телефонии и проверяем уже через сеть мобильного оператора. Если всё сделано правильно, то можно включать ПК из любого места набрав номер GSM шлюза.
Так же можно и продублировать любую команду управления "Умным домом", не зависимо от наличия интернета или удаленного доступа к системе домашней автоматизации.

Способ второй, удаленное включение ПК с помощью системы домашней автоматизации MajorDoMo

Этот способ гораздо проще, рассмотрим его на примере Raspberry Pi с установленной системой УД MajorDoMo с базового образа. Первым делом после установки обновляем систему MajorDoMo.

Переходим в Панель Управления - Система - Маркет дополнений. В разделе Оборудование находим модуль WoL и добавляем его в нашу систему домашней автоматизации.

В пункте Меню - Устройства, добавился Раздел WakeOnLan, перейдём к нему и запустим сканер обнаружения:

В помощи к модулю есть примеры вызова этого модуля из сценария.

Дальше создаём вначале сценарий, затем элемент управления.
В поле код я прописал следующее:

include_once(DIR_MODULES . 'wol/wol.class.php');$wake = new wol();$wake->WakeOnLan('192.168.1.255','38:D5:47:78:3B:35');

В меню Объекты панели управления добавляем новый раздел, используя недавно созданный сценарий:

В итоге в меню Сервис на главной странице нашей домашней системы автоматизации получаем новый элемент (кнопку) WoL PC, нажав которую запускаем включение ПК.

Организовать доступ к своей системе домашней автоматизации MajorDoMo можно разными способами. Наиболее быстрый и простой - использование сервиса CONNECT и мобильного приложения MajorDroid от создателей системы MajorDoMo.

Можно использовать или первый или второй способ, а можно и продублировать выполнение любой команды системы домашней автоматизации MajorDoMo через SIP сервер FreeSWITCH.