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

И, как и многое другое в Дивном Новом Мире Большого Брата, практически бесплатно мы получаем термостат с интеллектом кофеварки и кофеварку с интеллектом умственно отсталого муравья. С простецкой ценой в одну смертную душу в виде ваших данных. Всё это пришло вместе с лицензионными соглашениями, которые можно только посылать в филиал ада по соглашениям с Бессмертными Душами, сопроводив запиской: «Учитесь, парни…» (© Терри Праттчет, Нил Гейман — Благие Знамения.)

Не раз мы слышали новости о том, что какая-то нерадивая Алекса позвонила куда-то не туда или Алиса с Сири сливают данные одновременно товарищу майору и мистеру Смиту. Но мы не лыком шиты. У нас есть альтернативы, и с ними мы и познакомимся.

Мир IoT удивительно разнообразен. Системы разнообразны. Нужно сидеть и выбирать, будете ли вы следовать по пути Amazon, Apple, Google, Logitech или Samsung. Сами устройства разнообразны. У вас есть большое количество производителей, каждый из которых предоставляет разные протоколы и стандарты.

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

Можно решить вопрос консолидацией всего на одной из платформ Больших Братьев, а можно взять Ардуину и построить свой умный дом с куртизанками и преферансом. Руки у нас растут из нужного места. Писать на скриптах и питоне умеет каждый. Да и кто из нас, хабровчан, откажется от сомнительного удовольствия провести выходные, настраивая подключение кото-кормушки к камере с сенсорами (так как вы уже давно подозреваете, что ваш кот давным-давно не является единственным котом в доме)?

Итак, что делать, если вы ещё не начали писать программное обеспечение для своего дома сами?

Для начала нам нужно будет разобраться с одной достаточно простой технологией.

MQTT — Message Queuing Telemetry Transport. Протокол передачи сообщений телеметрии. В мире умных вещей на этом языке говорят достаточно многие.

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

В 2010 году протокол был переиздан в свободной форме, а в 2016 стал ISO стандартом.

Идея протокола достаточно проста. Всё работает по TCP/IP на порту 1883. Туда-сюда кидаются бинарные сообщения. Клиент подключается к установленному в сети брокеру, регистрируется на этом брокере и скидывает на него данные.

MQTT не создавался как протокол для настройки и работы с умным домом. Это протокол для автоматизации чего угодно. Но мы можем воспользоваться правилом пятисот дрелей и использовать MQTT как основной подлежащий протокол для всех наших умных замков, розеток и поливалок для цветов (сами устройства ищутся на различных маркетах путём добавления “MQTT” к названию устройства). Не все устройства одинаково хорошо поддерживают этот протокол. Например, если вам не повезло стать владельцем Алексы, то она вообще дружит с MQTT только после конкретной обработки напильником.

Но и не только на MQTT живёт мир. Все устройства с Амазона работают на своём протоколе. Цветные лампочки от Филипса работают на своём. Куда ни ткни — везде свой протокол. Для программирования своего дома вам придётся создавать примерно следующую архитектуру:

  1. Сеть. Самое простое — Wi-Fi. Для продвинутых пользователей шапочек из фольги можно заморочиться и найти Ethernet варианты практически любых IoT гаджетов
  2. Система-брокер. Raspberry PI или любой другой компьютер для обработки сообщений MQTT и других протоколов.
  3. Система хранения данных. Любой достаточно ёмкий диск. Объём ограничивается только вашей фантазией.
  4. Если вы собираетесь управлять своим домом с мобильного телефона — внешний IP-адрес с доменом и Let's Encrypt.

Но не бойтесь, на самом деле с нуля писать это не придётся. У нас есть большое количество уже существующих open-source проектов, которые позволяют вам просто подключать все эти устройства.

Вот три самых известных системы, на которые следует обратить внимание:

  1. OpenHab, github.com/openhab
  2. Home Assistant, github.com/home-assistant
  3. Homebridge, github.com/homebridge

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

А вот ещё куча систем, которые существуют, но до вышеописанных трёх не дотягивают.

  1. www.openmotics.com
  2. www.jeedom.com/site/en/index.html
  3. www.iobroker.net
  4. www.agocontrol.com
  5. www.domoticz.com
  6. calaos.fr/en
  7. pimatic.org
  8. www.smarthomatic.org
  9. www.mycontroller.org
  10. docs.pidome.org

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

Отдельно в этом списке идут два проекта:

  • fhem.de/fhem.html — с лицензией GNU, написанный на Perl. Этот сервер подойдёт заядлым любителям антилоп. Он упорно развивается и поддерживает множество устройств, но интерфейс оставляет желать лучшего. Плюс я не помню, когда я видел коммит на перле в последний раз.
  • www.eventghost.net — заточен для работы с Windows. Один из тех сайтов-динозавров, который по дефолту не поддерживает HTTPS. Можно просто поставить на флешку. Абсолютно бесполезен для конечного продукта, но может подойти для тестового стенда. Имеет поддержку игрового контроллера Xbox, благодаря чему можно сделать пару отличных штук с детворой.

Идея будет достаточно простой. Берём Raspberry Pi, устанавливаем на неё один из вышеописанных клиентов и начинаем разработку. Если под рукой нет малинки, то систему можно поставить на любой сервер. А если и этого нет в достаточном количестве, то ставить можно будет на обычный компьютер с докером.

Тут надо учесть вот что. Умный дом должен сам менять температуру, включать кофеварки и управлять лампочками, когда надо. Для того чтобы это «когда надо» определить, нам потребуется куча сенсоров и датчиков. А для этого нам нужно будет постоянно быть онлайн, чтобы эти датчики считывать.

Если ваши компоненты не включают в себя такие вещи, как Alexa и тому подобные гаджеты, которые требуют постоянного подключения к интернету, ваш умный дом можно будет строить на air-gapped сети.

Данные никогда не покинут вашего дома и будут храниться на вашем сервере. Но для большинства людей это сомнительное удовольствие. Полный отказ от всех интернет-зависимых сервисов вредит юзабилити.

Например, если вы решили подключить системы стриминга музыки к своему дому. OpenHab позволяет работать со Spotify, который, наконец-то, запустили в России. Более того, тот же OpenHab приучили дружить с Алисой.

Если вы хотите, чтобы ваш умный дом был доступен на смартфоне, то тут ничего не поделаешь. Всё надо будет либо подключать через интернет, либо оснащать сервер двумя сетевыми картами и выводить админку во внешний мир. Более того, вам потребуется либо выделенный адрес, либо какой-нибудь сервис для выведения этого адреса вовне.

Опять же, всё это необязательно, OpenHab может жить в пещере внутренней сети. Но если вы выводите систему вовне, то вам нужно будет учитывать два фактора:

  • Вы не должны пропускать никаких инструкций по безопасности. В мануалах большинства из вышеописанных систем есть данные про безопасность соединения. Вам нужно будет прочитать, вникнуть и не упускать из внимания эти инструкции.
  • Вы должны позаботиться о стабильности системы. Если вам припёрло установить датчик наличия кота на опрыскиватель для цветов, чтобы отпугивать усатое чудо от поедания кактусов, то это одно дело. В худшем случае вы либо получите съеденный кактус, либо постоянно мокрого кота. Если вы подключите умный замок к камере внешнего наблюдения, чтобы удалённо открывать двери детям, то это абсолютно другое дело.

Стабильный сервер с хорошим соединением позволит вашим чадам избежать стояния в холодном подъезде по 3 часа, потому что единственный физический ключ есть только у папы, а сервер решил кордампнуть по причине падения IDE жёсткого диска-пенсионера.

Итак, устанавливаем и настраиваем OpenHab. Всё просто, всё на сайте, всё по инструкции.

Что дальше?

А вот тут начинается самое интересное. Быстро читаем мануалы (мы же не те самые нерадивые админы, про которых недавно писал Григорий Остер). После чего понимаем, что попало нам в руки.

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

И вот как раз тут-то у нас начинается самая веселуха. OpenHab поддерживает из коробки NodeRed и Jython. Свой дом можно превращать в цифровую крепость на визуальном Node.js или питоне. Идея достаточно проста — у нас есть данные о состоянии датчиков. Обрабатываем эти данные скриптом и запускаем различные устройства в ответ на найденные состояния. Естественно, встроенная система создания интерфейсов в OpenHab позволяет вам нарисовать нужные кнопки и переключатели, которые имеют биндинги к уже существующим данным в базе.

Более того, если ваше устройство поддерживается из коробки, вам даже не нужно будет делать ничего особого. Просто берёте, рисуете переключатель и привязываете состояние лампочки к этому переключателю. И вот — вы можете выключать свет с вашего телефона.

Но это дико неинтересно. Это сегодня может сделать любая лампочка из коробки.

Вы же можете написать скрипт, который будет отслеживать координаты вашего телефона и в зависимости от времени суток выставлять правильную степень яркости ваших лампочек. Или, например, создать систему «следования» в музыкальном проигрывателе, которая автоматически переключает вашу музыку на колонки в той комнате, в которой вы находитесь.

Загвоздка заключается в том, что после написания пяти различных скриптов для пяти различных девайсов, я устал. И решил на всё забить. Если уже и писать систему, так делать её универсальной.

В принципе всё, что нам было нужно — это создать точку привязки, которая позволит нашему хабу общаться с другими устройствами по UDP без всяких скриптов-посредников.

Открываем openhab.cfg и создаём биндинг:

udp:port=4115

udp:buffersize=110

udp:itemsharedconnections=true

udp:bindingsharedconnections=true

udp:directionssharedconnections=false

udp:addressmask=false

udp:preamble=

udp:postamble=/r/n

udp:blocking=false

udp:updatewithresponse=false

udp:refreshinterval=250

udp:charset=UTF-8


После этого описываем устройство:

String Relay_InputString "Relay Input String [%s]" {udp="<[device_ip:source_port:’REGEX((.*))’]"}

String Relay_decString "decoded Input String [%s]"

И добавляем обработчик события:

rule:

`import org.openhab.core.library.types.*

rule "parse_Relay_InputString"

when

Item Relay_InputString received update

then

if (Relay_InputString.state instanceof StringType) {

var value = Relay_InputString.state as StringType

var valueLength = value.toString.length() as Integer

val byte[] bytes = value.toString.getBytes("UTF-8")

postUpdate(Relay_decString, bytes.toString())

}

end

И таким образом мы получаем данные из устройства. И попутно сидим и молимся о том, что в данном случае кодировка UTF-8 сработает (спойлер, на одном устройстве она сработала). Если кодировка не работает и на входе вы получаете мусор, то тут можно разбираться до конца времён. Но те, кто работал с Java, знают как в этом разобраться.

Для тех, кому это делать лень — можно пойти другим, намного более извращённым путём, который будет транслировать сообщения из TCP или UPD в JSON. Этот способ прост, если у вас есть много устройств, на которые надо отправлять команды, но из которых необязательно получать ответы. Берём любимый язык программирования и пишем свой сервер, который принимает команды на одном конце и выдаёт последовательности бит на другом. Это займёт больше времени, но если у вас есть большое количество китайских несговорчивых устройств, это может сэкономить некоторые телодвижения.

Я, например, решил эту проблему созданием сервера, в сердце которого лежало 60 строк на C#:

	public static class Executor

	{

    	public static Byte[] Say(string What, CommandType Type, string Address, int Port)

    	{

        	Byte[] bt = Type switch

        	{

            	CommandType.AsciiString => System.Text.Encoding.ASCII.GetBytes(What),

            	CommandType.UtfString => System.Text.Encoding.UTF8.GetBytes(What),

            	CommandType.Binary => ProcessBinary(What, 8),

            	CommandType.ByteArray => ProcessBytes(What),

            	_ => Array.Empty<byte>()

        	};

        	using TcpClient t = new TcpClient(Address, Port);

        	var s = t.GetStream();

        	s.Write(bt, 0, bt.Length);

        	return bt;

    	}

    	static Byte[] ProcessBytes(string What)

    	{

        	if (What.Length % 2 == 1) What += "0"; //If user sent us uneven byte count

        	List<Byte> ret = new(What.Length/2);

        	foreach (String ch in What.SplitInParts(2))

        	{

            	var d1 = Convert.ToByte(ch[0].ToString(), 16);

            	var d2 = Convert.ToByte(ch[1].ToString(), 16);

            	d1 *= 0x10;

            	d1 += d2;

            	ret.Add(d1);

        	}

        	return ret.ToArray();

    	}

    	static Byte[] ProcessBinary(string What, int WordLength)

    	{

        	List<Byte> ret = new(What.Length);

        	foreach (var ch in What.SplitInParts(WordLength))

        	{

            	ret.Add(Convert.ToByte(ch, 2));

        	}

        	return ret.ToArray();

    	}

	}

	static class StringExtensions

	{

    	public static IEnumerable<String> SplitInParts(this String s, Int32 partLength)

    	{

        	if (s == null)

            	throw new ArgumentNullException(nameof(s));

        	if (partLength <= 0)

            	throw new ArgumentException("Part length has to be positive.", nameof(partLength));

        	for (var i = 0; i < s.Length; i += partLength)

            	yield return s.Substring(i, Math.Min(partLength, s.Length - i));

    	}

	}


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

С такой заглушкой можно было быстро подключить кучу разношёрстных разноязычных устройств к openHab и продолжать конфигурировать систему.

Собственно говоря, тут уже можно делать что только душе угодно.

Более того, если вам удалось отхватить какое-то автоматическое реле за 100 рублей на “Алибаба” три года назад и оно всё ещё пылится без дела, то вы можете подключить это реле в OpenHab. Большинство дешёвых китайских подделок работают по каким-то только им известным бинарным или полутекстовым протоколам. При помощи Jyton вы сможете подключиться к несчастному реле руками через сеть и написать функции, необходимые для включения и выключения этого реле. После чего эти функции можно смело импортировать в сам OpenHab и использовать для построения своего дома.

При всём при этом, как вы видите, входной порог достаточно низок. Для того чтобы начать играться с этими системами автоматизации, вам не нужны никакие подписки. Все open-source. Wi-Fi реле можно найти меньше чем за 1000 рублей.

Для успешной работы с системами вам нужно будет выучить либо питон, либо визуальный Node.js. Если вы будете серьёзно программировать устройства, то вам потребуется понимание протоколов передачи данных, таких как MQTT. Но всё это необходимо, если вы будете серьёзно экономить на устройствах. Если же вы пойдёте путём покупки брендового оборудования, то можно обойтись программированием по методу щёлканья мышкой.

Но какой же умный дом, без того, чтобы можно было зайти и сказать: “Милая, я вернулся!”, ожидая, что ваша теперь уже напичканная электроникой квартира ответит что-то в стиле: “Сию секунду делаю кофе!”

Не стоит думать, что Алекса, Сири, Алиса и Кортана единственные на рынке (и Гугл, у них тоже что-то есть, но оно абсолютно безликое).

Один из самых больших проектов на github с открытым кодом голосового помощника называется Leon. Система сделана французом, и этот проект собрал 5.4 тысячи звёзд на платформе. Расширяемый и переписываемый помощник, который можно подключить к вашему умному дому.

После, у нас есть JARVIS из Железного Человека. Он зиждется в этом репозитории. github.com/sukeesh/Jarvis. По умолчанию этот помощник умеет работать с базовыми действиями из командной строки. После небольшой конфигурации ему можно включить голос, и писать скрипты для обработки более сложных команд.

Далее можно будет подключить SAPI модуль для обработки вашего голоса и можно запускать скрипты, которые будут дёргать ваши команды через API в OpenHab. Это позволит вам создавать вашу собственную Сири в пределах отдельно взятой сети.

Оба вышеописанных проекта написаны по лицензии MIT.

Чуть более популярная чем Jarvis, но уступающая Леону — система Mycroft. Лицензия в данном случае — Apache, и сама компания заточена на продажу собственных гаджетов в виде умных колонок и дисплеев. Хотя система и запускается в докере, но она очень просится в интернет, особенно если вы прикупите себе Mycroft гаджетов.

Существуют и другие, менее успешные open-source системы распознавания голоса. Их можно нагуглить, но они более узко специализированы и их удобнее использовать как API для ваших приложений, нежели как самостоятельные проекты.
Предупреждаю только вот о чём:

Устанавливать систему распознавания голоса надо на более продвинутое железо. Тут одна малинка не прокатит. Для того чтобы хостить собственную модель для распознавания речи, вам потребуется что-то, как минимум, с восемью свободными гигами оперативки. И желательно с приличным процессором, особенно если вы захотите как следует натаскать её на ваш голос. Так что внезапно простая затея с умным домом превращается в настройку сервера в стойке и перерастает в многолетний проект. Так что будьте осторожны.
Ну вот и всё.

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

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

Мир open-source избушки на курьих ножках достаточно прост и доступен. Дерзайте.


НЛО прилетело и оставило здесь промокоды для читателей нашего блога:

15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.

20% на выделенные серверы AMD Ryzen и Intel Core HABRFIRSTDEDIC.

Доступно до 31 декабря 2021 г.

Комментарии (11)


  1. Crazy_Pit
    13.12.2021 11:43
    +3

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


  1. ptr128
    13.12.2021 12:01
    +2

    Иметь поддержку TCP/IP + MQTT на выключателе или простейшем датчике, на мой взгляд, и избыточно и дорого. Причем "дорого" не столько поддержка TCP (ESP-01 стоит не дорого), сколько его питание. Поэтому простейшие устройства выгодней делать на mesh сети из nRF24L01+ в паре с ultra-low-power МК. Если это только датчик на двери или окне, то от литиевой CR2032 он способен проработь год или даже более. Или несколько месяцев от LIR2032. Причем напрямую, без DC-DC преобразователя или, тем более AC-DC блока питания!

    А уже гейтом MQTT - nRF24L01+ на той же малинке можно получать к этой сети доступ.


  1. ptr128
    13.12.2021 12:54
    +1

    Если вы хотите, чтобы ваш умный дом был доступен на смартфоне, то тут ничего не поделаешь. Всё надо будет либо подключать через интернет, либо оснащать сервер двумя сетевыми картами и выводить админку во внешний мир. Более того, вам потребуется либо выделенный адрес, либо какой-нибудь сервис для выведения этого адреса вовне.

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

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

    Что же касается "админка во внешний мир" - то только с pre-shared ключами. Например, SSH туннель на внутренний proxy, не отказываясь при этом от HTTPS.

    Стабильный сервер с хорошим соединением позволит вашим чадам избежать стояния в холодном подъезде по 3 часа, потому что единственный физический ключ есть только у папы, а сервер решил кордампнуть по причине падения IDE жёсткого диска-пенсионера.

    Я бы расшифровал это так:

    1. Соединение с интернет должно быть резервировано, например через LTE (или LTE с симкой другого оператора, если основной канал и так LTE). Причем, желательно, не на том же самом роутере, который обеспечивает основной канал, так как роутер тоже может зависнуть.

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

    3. И не забываем о резервном питании. Причем не только роутеров и серверов IoT, но и датчиков охранной сигнализации.


  1. putnik
    13.12.2021 13:59
    +6

    Статья читается так, будто у нас тут в open source большой выбор отличных готовых легко настраиваемых решений, так что выбирайте понравившееся и начинайте использовать. К сожалению, в реальности всё даже близко не так, и даже самые популярные системы часто сводятся наборам костылей и далеко не самой простой настройке с поиском ответов в чатах и в issue на гитхабе. Это не так плохо, но всё же очень сильно отличается от опыта настройки одной кнопкой, который стараются предоставить закрытые коммерческие экосистемы.

    Ну и более конкретно прокомментирую часть про голосовых ассистентов, так как я этим сейчас активно занимаюсь:

    Один из самых больших проектов на github с открытым кодом голосового помощника называется Leon. Система сделана французом…

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

    После, у нас есть JARVIS из Железного Человека. <…> Это позволит вам создавать вашу собственную Сири в пределах отдельно взятой сети.

    Интересно, получилось ли у автора создать собственную Сири, или всё же самостоятельная настройка споттера, распознавания голоса и озвучки текста на отдельно взятой малинке всё же сильно выходят за рамки «небольшой конфигурации». Ну, и если ничего не поменялось, то у него была проблема с поддержкой даже не русского, а вообще какой-либо локализации. Так что, вероятно, вам придётся делать форк и переводить все сообщения.

    Чуть более популярная чем Jarvis, но уступающая Леону — система Mycroft.

    Про эту знаю несколько больше, так как выбрал её и сейчас занимаюсь локализацией. И хорошо, если хотя бы к новому году смогу получить сколько-нибудь работающее решение.

    Ядро небольшое, почти всё вынесено в плагины и навыки. Есть какое-никакое сообщество, которое эти навыки пишет и поддерживает. Хотя встречается довольно много говна и палок не самых лучших архитектурных решений. Ядро в интернет ломится за настройками навыков, которые хранятся на сервере, сами навыки за данными. По умному дому более-менее нормальная интеграция есть только с Home Assistant, остальное вам придётся писать с нуля. По музыке есть интеграция со Spotify (если вас не смущает необходимость хранить пароль в открытом виде на чужих серверах).

    Хотя система и запускается в докере, но она очень просится в интернет, особенно если вы прикупите себе Mycroft гаджетов.

    Только вы их не прикупите, потому что первой версии колонки давно нет в продаже, а со второй компания встряла, и всё висит в статусе «почти готово». Когда они смогут найти производителя, никто толком не знает. Ну а после этого вам придётся дождаться отгрузки всем тем, кто перечислял на неё через краудфандинг в 2018-м. Если всё же смогут выпустить, то есть надежда на взрывной рост сообщества.

    В общем, в моём случае история «а настрою-ка я себе голосового ассистента, который будет работать локально и не будет сливать никому данные» подбирается уже к окончанию второго месяца, и он пока умеет только погоду сообщать, да и в интернет при этом поглядывает регулярно.


    1. Nurked
      13.12.2021 17:24

      Хороший обзор.

      Да, лично я эту проблему решил переходом га английский. Но это не вариант для всех. Можете поделиться наработками в Микрофте?


      1. putnik
        13.12.2021 20:22
        +1

        Наработки можете посмотреть в репозитории, но в целом всё, что я делаю, и так постепенно попадает в основные ветки репозиториев ядра и навыков. Ну, разве что выбор и настройка TTS и SST — это головная боль (пока остановился на RHVoice и Vosk, но буду продолжать пробовать варианты), и там нужно было дописывать и искать плагины, на которые нет ссылок на официальном сайте.

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

        Если надумаете попробовать раньше настроить, приходите в чат в Mattermost, там жизни практически нет, но я туда стараюсь кидать информацию, которую нахожу.


        1. janvarev
          13.12.2021 21:35

          О, спасибо, интересный у вас репозиторий.


    1. janvarev
      13.12.2021 18:14
      +2

      О, а я как раз делаю голосового ассистента на русском, работающего оффлайн, и планирую выложить на Хабр в каком-нибудь будущем. Python + плагинная архитектура. Уже работает, используем с женой. Голос оффлайн, таймер (оффлайн), мультики (оффлайн), погода (онлайн), электрички (онлайн), управление плейером MPC-HC (оффлайн), получается пока вполне интересно и работоспособно. Если интересно, стучитесь в личку.

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


      1. putnik
        13.12.2021 20:25

        Подскажите, вы что используете для Text-to-Speech и Speech-to-Text?


        1. janvarev
          13.12.2021 21:17

          TTS — виндовский pyttsx3 (UPD: под linux вроде тоже заводится, но не проверял)
          STT — vosk

          Впрочем, при необходимости они заменяемы. STT заменяется раннером ядра — например, есть раннер для командной строки для отладки текстом вместо голоса, 20 строк кода, глянул только что. TTS пока через одну заменяемую функцию работает, подключить другие не проблема.

          (Если что, у меня своя CMS для сайтов, которой уже 17 лет, до сих пор с актуальными проектами. Так что кое-как в архитектуру умею ;))


  1. third112
    14.12.2021 03:13

    Примерно в 1960х, м.б. в журнале "Радио", была схема аналогового выключателя на многих транзисторах, который включал лампочку по хлопку ладоней. В конце 1980х мой приятель раскопал этот журнал и собрал устройство. Когда пришел к нему, он хлопал несколько раз — включилось. Он сказал, что поработает с настройкой. Следущий раз он включил свет обычным выключателем — сказал, что все ладони отбил пока настраивал, а сейчас его сосед ремонт затеял и когда электродрелью стенку сверлит, то электроника включается среди дня.


    Мне вспомнилась эта история по прочтении статьи.


    Лет 5 назад купил часы, повесил на кухне. Стоит ударить ложкой по тарелке — они на полминуты подсветку включают. ИМХО можно придумать много ненужных функций.