В конце сентября прошла наша первая встреча для hardware-разработчиков — Яндекс.Железо. Это важный шаг на новом для нас рынке производителей устройств. Участники (около 150 человек) послушали доклады, пообщались и провели много времени на стендах, где можно было заглянуть внутрь беспилотного автомобиля, обезвредить «бомбу», перерезав нужные провода, разобрать Яндекс.Станцию (рекорд — 6 минут 23 секунды), а также протестировать бортовой компьютер Яндекс.Авто и умный дом.
Как раз о платформе умного дома и поговорим сегодня. Весной мы запустили её для всех разработчиков, а на Яндекс.Железе руководитель разработки платформы Марат Мавлютов подвёл первые итоги и показал, как наладить управление устройствами. Из доклада можно узнать о терминах голосового API, способах описания и взаимодействия с девайсом пользователя.
— Давайте поговорим про умный дом. Как сделать ваш дом чуточку умнее, чтобы ни один котик не остался голодным и все ворота в Екатеринбурге открывались?
Зачем вообще мы туда полезли и что мы хотим получить? Мы очень хотим сделать так, чтобы наш голосовой помощник был именно помощником, чтобы он мог не только включить музыку или видео, а помогал в самых естественных, бытовых вещах.
Также мы понимаем, что не можем написать вообще весь код в мире и интегрироваться со всеми устройствами. Именно поэтому мы хотим этот голосовой интерфейс предоставить разработчикам, компаниям, людям, которые уже умеют делать устройства и делают их классными. Компания Ericsson говорит, что к 2021 году по всему миру будет 28 млрд подключенных устройств умного дома. Это значит, на минуточку, что если представить весь земной шар интернетизированным, то у каждого человека будет в среднем по четыре устройства.
Перед самым запуском мы провели исследования, чтобы понять, как люди пользуются умным домом, что они хотят увидеть, чем они хотят управлять. Мы выбрали три самых топовых направления:
— управление телевизорами, AV-ресиверами, медиаустройствами и т. д.,
— управление светом и осветительными приборами,
— управление температурой — кондиционером, термостатом, батареей, бойлером и т. д.
На следующем слайде есть статистика. Например, мы запустились всего четыре месяца назад, в мае, и сейчас видим, что среднее количество устройств в нашей платформе у каждого пользователя — 3,8. Я вчера смотрел, было 3,93. А два месяца назад эта цифра была 3,2. Значит, люди не только пользуются умным домом, но и докупают устройства, им нравится. Следующей цифрой мы гордимся: 96% пользователей управляют своим умным домом с помощью голоса, хотя у всех них есть приложение, через которое тоже можно управлять этими умными устройствами.
И мы понимаем ограничения текущего API, там действительно пока очень мало того, что можно подключить или описать. Но производители, энтузиасты или разработчики смогли интегрироваться с нашей платформой так, что мы в ней сейчас видим более 800 различных моделей устройств. Это именно модели устройств: всевозможные чайники, кондиционеры, телевизоры и т. д.
Повторюсь, мы в продакшене всего четыре месяца, но такие большие распределенные компании уже смогли итегрироваться с нашей платформой, и я считаю, что это очень большая заслуга команды. Это говорит о том, что наше API достаточно простое, такое, что люди смогли за четыре месяца интегрироваться с Яндексом.
Со стороны инди-разработчиков и энтузиастов мы видим, что люди пишут навыки типа умного дома. Тем самым они интегрируют нашу платформу с другими системами: openHAB, Homebridge, Home Assistant, — например, чтобы девайсы, заточенные под экосистему Apple, тоже могли работать с Алисой. Тут немножко кейсов применения от наших партнеров. Мы думали, что умный дом от Яндекса будет нацелен на тех энтузиастов, которые только начинают двигать этот рынок вперед. Но люди из совсем других индустрий практически без участия Яндекса пришли к нам и рассказали, что они хотят делать инсталляции с умным домом.
Например, есть известный случай с застройщиком «ПИК» и компанией Rubetek. В качестве одного из топовых предложений отделки квартир они представляют умный дом на платформе Яндекса. В таких квартирах, в таких уже существующих шоу-румах, пользователь может прийти и попросить Алису сварить кофе, открыть шторы или управлять светом. Также мы прямо сейчас работаем с застройщиками офисов. Они хотят, например, встроить Алису в свои переговорки так, чтобы можно было забукать переговорку, позвонить в другой город или управлять, опять же, какими-нибудь световыми приборами. И еще мы запускаем некоторые эксперименты с отелями. Можно будет попросить завтрак в номер, поменять вам подушку на потеплее или включить какой-нибудь платный канал.
Давайте теперь немножко опустимся к техническим деталям. Схема работы с умным домом довольно простая. Есть очень много производителей умных устройств, и всеми этими устройствами можно управлять через мобильный телефон. Это значит, что у всех этих производителей есть какой-то API, с помощью которого пользователь кликает в мобильном телефоне, мобильный телефон отправляет какие-то запросы в облако, соответственно, этого производителя, и устройство включается, выключается, изменяется яркость, какие-то параметры.
Соответственно, именно в эту сторону мы и хотим встроиться. Мы же можем сказать, что пользователь не в телефоне тыкает, а голосом, например, говорит. И посылать точно такой же запрос в облако этого производителя. Это называется cloud-to-cloud взаимодействие. На следующем слайде оно подробно описано.
То есть человек управляет или с помощью мобильного телефона, или голосом. Дальше сервера Яндекса идут с облака соответствующего производителя, и устройство включается.
Как Яндекс узнает об устройстве, которое есть у пользователя? Для этого мы используем стандартную процедуру. Она называется Oauth2 account linking. Пользователю достаточно зайти в приложение Яндекса, связать, что называется, аккаунты. Грубо говоря, на пальцах, это работает так.
Когда мы хотим связать свой аккаунт с Philips, пользователь вводит свой логин, пароль, или сообщает нам специальный токен, и мы с этим токеном ходим якобы от имени пользователя в Philips.
Вторая большая часть, из которой состоит протокол умного дома, — голосовые интенты. Первый и самый главный — Discovery. Мы с токеном пользователя идем в облако соответствующего производителя, и производитель нам говорит: у пользователя есть такие устройства. А дальше все просто. Query, Action. Яндекс идет с запросом к Query, чтобы узнать, в каком статусе находится сейчас устройство — утюг выключен, включен, или какая температура сейчас на кондиционере. А Action, это значит, что текущий статус нужно поменять. Unlink происходит, когда пользователь решил разорвать связку аккаунтов, чтобы Яндекс полностью забыл обо всех устройствах, которые есть.
Давайте спустимся еще поглубже, и посмотрим, как работают все эти интенты. Первое, самое главное, это типы устройства — device type. Типы устройства влияют только на представления устройств в интерфейсе. Это специальные лейауты в мобильном приложении. Плюс, самое важное, наверное, что типы устройств обобщают некое голосовое представление, некие голосовые команды. То есть неважно, как пользователь назвал свою лампу, она все равно должна реагировать на слово «свет», например. Или совсем не должно быть важно, пользователь говорит «включи кондиционер» или «кондей». Причем этот кондиционер может называться как угодно.
И второе, это чтобы понять, как управлять устройством, нам нужно знать, что это устройство умеет. Мы называем эти штуки capabilities. То есть это как building block, которые рассказывают о том, что устройство умеет.
Чуть подробнее про device type. На самом старте у нас их было, по-моему, шесть. Сейчас мы выросли до такого количества. Например, две недели назад выпустили openable, и ребята смогли открыть свои ворота. Они могут теперь говорит: «Алиса, открой ворота», а не «Алиса, включи ворота», например.
Давайте теперь поговорим о capabilities, о том, какие capabilities бывают и как сделать так, чтобы Алиса поняла, как вашим устройством управлять.
Первое, самое главное и простое — on_off. Это capability есть практически у каждого устройства. Чтобы рассказать Алисе, что устройство умеет включаться, выключаться, достаточно добавить вот эти пару строчек Jason и определить флажок retrievable. Этот флажок означает, что можно у текущего устройства узнать, включен он или не включен.
Простой пример с телевизором. У всех вас есть дома телевизор вероятно, и, смотря на пульт от телевизора, невозможно понять, включен телевизор или выключен, конечно же, если этот пульт инфракрасный.
Следующий тип capability, который описывает световые приборы, это color_setting. У него также есть флажок retrievable. Но самое главное, вот эти два параметра — color_model. С помощью этого параметра производитель говорит нам о том, что он умеет управлять цветом. Этот цвет может быть в hsv-или rbg-режиме.
И второе — градация белого. То есть можно сказать, что моя лампочка умеет холодный белый цвет, теплый желтый цвет и так далее, чтобы пользователь мог говорить: «сделай, пожалуйста, свет потеплее».
Дальше у нас пойдут capabilities, обобщающие некие режимы. Очень хорошая аналогия с интерфейсом, это Radio buttons, когда вам нужно выбрать какой-то из нескольких режимов. Или вспомните стиральную машину с крутилочкой, где точно есть режим «хлопковое белье», «деликатная стирка» и т. д.
Здесь нам важно узнать, какой именно instance этого режима стоит. Текущие instance, там уже штук шесть их. Но именно те, которые мы реализовали на самом первом этапе, это instance работы кондиционера — автоматический режим, охлаждение, и т. д. Или, например, есть instance, режим работы вентилятора — самый медленный, средний или, опять же, автоматический.
И применительно к mode можно сказать: «Включи, пожалуйста, следующий режим». И это очень удобно для кондиционеров или для той же стиральной машины.
Еще одним capability является range. Применительно также с аналогией интерфейсов, это какой-то ползунок от минимального до максимального значения может что-то регулировать. У этого ползунка тоже есть instance. Например, это температура, громкость, яркость и так далее, практически любой range, который можно описать. Это unit, потому что некоторые люди, как оказалось, чтобы проверить кондиционеры, говорят значение температуры в фаренгейтах. И это, соответственно, совсем разные температуры. Когда человек просит включить в Фаренгейтах или в Цельсиях, и это тоже надо понимать.
Флажок random access, наверное, вам хорошо известен, это когда мы можем точную цифру, на которой в этом range нужно поставить значение. Довольно простой пример, опять же, с телевизорами. Громкостью можно управлять только вверх и вниз. А температуру на кондиционерах можно указать точную.
И само описание range, когда мы знаем какое-то минимальное значение, максимальное значение, и шажочек, с которым это значение можем изменять. На кондиционерах, опять же, оно может быть какое-то целое, или по долям десятков.
Последний capability аналогичен интерфейсу, это какая-то галочка. Помните, в старых компьютерах был такой турборежим — нажимаешь, и компьютер быстрее работает? Здесь ты говоришь: «Алиса, выключи звук», мы нажимаем кнопочку mute и звук исчезает. Можно сказать, наверное, что это какой-то бинарный режим.
И комбинация всех вот этих capabilities, всех умений. Мы можем описать всевозможные устройства, которые на данный момент представлены на рынке.
Например, умная лампочка. Она умеет включаться, выключаться. Она умеет регулировать цвет, и она умеет регулировать яркость. Но если с лампочкой все просто, давайте попробуем все вместе описать какое-нибудь другое устройство. Например, чайник.
Как вы считаете, что должен уметь умный чайник? Я дал вам подсказку, скриншот из интерфейса приложения Яндекс. Как бы вы описали чайник? Температура. Еще? Да, и включи-выключи. Чайник довольно простое устройство. Он умеет включаться, выключаться, и, например, мой любимый зеленый чай, я хочу его делать на 85 градусах. Есть ли в нем вода? Да, хорошее замечание. Тут мы ждем информацию от производителя.
Я хотел бы вам рассказать и про другие устройства. Одно из самых сложных устройств, которые сейчас есть, это кондиционер. Как вы считаете, что должен уметь кондиционер? Греть или охлаждать. Регулировать температуру. Режим со шторками. Скорость вентилятора. Все правильно. И кондиционер, который сейчас можно описать в нашем capability, умеет все это. Он умеет включаться, выключаться, выбирать режим охлаждения, регулировать температуру и скорость вентилятора, с которым дует или холодный, или горячий воздух. Может быть и простой воздух в режиме без кондиционера.
Давайте спустимся еще ниже и посмотрим, какие же ответы от производителей мы ждем при описании устройств. Это интент discovery. Здесь немножко YAML, но он довольно просто читается.
В тот момент, когда пользователь связывает аккаунты, мы спрашиваем у производителя, что же у этого пользователя есть, какие устройства — просто чтобы понимать, как ими управлять.
Первое, и самое главное: мы ждем user_id этого пользователя и список устройств.
Здесь описано только одно устройство: у пользователя есть лампочка, devices.types.light. Это может быть, кстати, не только лампочка. Это может быть какая-то РГБ-лента или газонокосилка с подсветкой. Нам это вообще неважно. Главное, чтобы она реагировала на слово «свет» и чтобы в интерфейсе мы смогли нарисовать capability, которое отвечает именно за свет.
Наша газонокосилка, похоже, умеет включаться, выключаться. Она умеет менять яркость. И она умеет регулировать цвет. Причем не только цвет — еще у этого осветительного прибора есть регулировка цветовой температуры.
Предположим, пользователь спрашивает: «Алиса, в каком состоянии сейчас моя лампочка?» или «Алиса, моя лампочка включена?» Тогда мы отправляем такой вопрос провайдеру, говорим, что у такого-то девайса нужно спросить, в каком сейчас цветовом режиме он находится и включено ли само устройство.
Если пользователь хочет изменить этот режим, он может, например, сказать: «Алиса, выключи свет». Есть лампочка с айдишником abc-123, «Пожалуйста, выключи», value false.
Ждем, что производитель устройства на той стороне облака нам ответит: окей, лампочка abc-123, action_result, status DONE. Значит, лампочка выключилась.
Еще немного про сценарии. Мы понимаем, что пользователи хотят не только управлять своими устройствами по отдельности, но и объединять их в группы. Например, просыпаясь, они говорят: «Алиса, доброе утро», и хотят, чтобы выполнилась некая комбинация действий.
Соответственно, в приложении Яндекса можно так сказать, и Алиса включит какую-то музыку, выключит ночник, чайник начнет работать, кипятить воду, чтобы сделать ваш любимый кофе.
О планах. Мы понимаем, что работа в текущем виде хотя и позволяет описать огромное количество устройств, но, например, не позволяет получать информацию от датчиков. Мы не сможем настроить в сценариях какой-то event так, чтобы по датчику протечки, дыма или открытия двери понять, что что-то случилось. Мы целимся это сделать. Также мы понимаем, что в данный момент не умеем управлять mediastream. Самый простой пример — курьер пришел к вам домой с горячей пиццей, и вам на телефон приходит пуш с фотографией этого человека. Это же супер! Сейчас с текущими capabilities это сделать невозможно — скорее всего, появятся capabilities, описывающие камеры.
Про датчики я затрону скользкую тему — IFTTT. C IFTTT мы хотим сценарий запускать не только голосом, как сделано сейчас. Мы хотим запускать их по разным events: по таймеру, расписаниям, восходу или заходу солнца и другим событиям. И мы очень хотим, чтобы умный дом был не только для гиков, которые понимают, зачем нужно передать свой пароль от Wi-Fi лампочке. Мы хотим сделать так, чтобы люди, абсолютно не связанные с умным домом, или не понимающие, как он работает, просто покупали какой-то чайник, стиральную машину, лампочку, неважно. И Алиса говорила: «Похоже, у вас в доме есть какое-то новое для меня устройство. Хотите его подключить?» И все, чтобы работало сразу.
В заключение хочу сказать: чтобы воспользоваться этой технологией, умным домом, вам нужно лишь прочитать документацию и правильно описать ваше устройство, используя device types и существующие сейчас capabilities. Спасибо.
Как раз о платформе умного дома и поговорим сегодня. Весной мы запустили её для всех разработчиков, а на Яндекс.Железе руководитель разработки платформы Марат Мавлютов подвёл первые итоги и показал, как наладить управление устройствами. Из доклада можно узнать о терминах голосового API, способах описания и взаимодействия с девайсом пользователя.
— Давайте поговорим про умный дом. Как сделать ваш дом чуточку умнее, чтобы ни один котик не остался голодным и все ворота в Екатеринбурге открывались?
Зачем вообще мы туда полезли и что мы хотим получить? Мы очень хотим сделать так, чтобы наш голосовой помощник был именно помощником, чтобы он мог не только включить музыку или видео, а помогал в самых естественных, бытовых вещах.
Также мы понимаем, что не можем написать вообще весь код в мире и интегрироваться со всеми устройствами. Именно поэтому мы хотим этот голосовой интерфейс предоставить разработчикам, компаниям, людям, которые уже умеют делать устройства и делают их классными. Компания Ericsson говорит, что к 2021 году по всему миру будет 28 млрд подключенных устройств умного дома. Это значит, на минуточку, что если представить весь земной шар интернетизированным, то у каждого человека будет в среднем по четыре устройства.
Перед самым запуском мы провели исследования, чтобы понять, как люди пользуются умным домом, что они хотят увидеть, чем они хотят управлять. Мы выбрали три самых топовых направления:
— управление телевизорами, AV-ресиверами, медиаустройствами и т. д.,
— управление светом и осветительными приборами,
— управление температурой — кондиционером, термостатом, батареей, бойлером и т. д.
На следующем слайде есть статистика. Например, мы запустились всего четыре месяца назад, в мае, и сейчас видим, что среднее количество устройств в нашей платформе у каждого пользователя — 3,8. Я вчера смотрел, было 3,93. А два месяца назад эта цифра была 3,2. Значит, люди не только пользуются умным домом, но и докупают устройства, им нравится. Следующей цифрой мы гордимся: 96% пользователей управляют своим умным домом с помощью голоса, хотя у всех них есть приложение, через которое тоже можно управлять этими умными устройствами.
И мы понимаем ограничения текущего API, там действительно пока очень мало того, что можно подключить или описать. Но производители, энтузиасты или разработчики смогли интегрироваться с нашей платформой так, что мы в ней сейчас видим более 800 различных моделей устройств. Это именно модели устройств: всевозможные чайники, кондиционеры, телевизоры и т. д.
Повторюсь, мы в продакшене всего четыре месяца, но такие большие распределенные компании уже смогли итегрироваться с нашей платформой, и я считаю, что это очень большая заслуга команды. Это говорит о том, что наше API достаточно простое, такое, что люди смогли за четыре месяца интегрироваться с Яндексом.
Со стороны инди-разработчиков и энтузиастов мы видим, что люди пишут навыки типа умного дома. Тем самым они интегрируют нашу платформу с другими системами: openHAB, Homebridge, Home Assistant, — например, чтобы девайсы, заточенные под экосистему Apple, тоже могли работать с Алисой. Тут немножко кейсов применения от наших партнеров. Мы думали, что умный дом от Яндекса будет нацелен на тех энтузиастов, которые только начинают двигать этот рынок вперед. Но люди из совсем других индустрий практически без участия Яндекса пришли к нам и рассказали, что они хотят делать инсталляции с умным домом.
Например, есть известный случай с застройщиком «ПИК» и компанией Rubetek. В качестве одного из топовых предложений отделки квартир они представляют умный дом на платформе Яндекса. В таких квартирах, в таких уже существующих шоу-румах, пользователь может прийти и попросить Алису сварить кофе, открыть шторы или управлять светом. Также мы прямо сейчас работаем с застройщиками офисов. Они хотят, например, встроить Алису в свои переговорки так, чтобы можно было забукать переговорку, позвонить в другой город или управлять, опять же, какими-нибудь световыми приборами. И еще мы запускаем некоторые эксперименты с отелями. Можно будет попросить завтрак в номер, поменять вам подушку на потеплее или включить какой-нибудь платный канал.
Давайте теперь немножко опустимся к техническим деталям. Схема работы с умным домом довольно простая. Есть очень много производителей умных устройств, и всеми этими устройствами можно управлять через мобильный телефон. Это значит, что у всех этих производителей есть какой-то API, с помощью которого пользователь кликает в мобильном телефоне, мобильный телефон отправляет какие-то запросы в облако, соответственно, этого производителя, и устройство включается, выключается, изменяется яркость, какие-то параметры.
Соответственно, именно в эту сторону мы и хотим встроиться. Мы же можем сказать, что пользователь не в телефоне тыкает, а голосом, например, говорит. И посылать точно такой же запрос в облако этого производителя. Это называется cloud-to-cloud взаимодействие. На следующем слайде оно подробно описано.
То есть человек управляет или с помощью мобильного телефона, или голосом. Дальше сервера Яндекса идут с облака соответствующего производителя, и устройство включается.
Как Яндекс узнает об устройстве, которое есть у пользователя? Для этого мы используем стандартную процедуру. Она называется Oauth2 account linking. Пользователю достаточно зайти в приложение Яндекса, связать, что называется, аккаунты. Грубо говоря, на пальцах, это работает так.
Когда мы хотим связать свой аккаунт с Philips, пользователь вводит свой логин, пароль, или сообщает нам специальный токен, и мы с этим токеном ходим якобы от имени пользователя в Philips.
Вторая большая часть, из которой состоит протокол умного дома, — голосовые интенты. Первый и самый главный — Discovery. Мы с токеном пользователя идем в облако соответствующего производителя, и производитель нам говорит: у пользователя есть такие устройства. А дальше все просто. Query, Action. Яндекс идет с запросом к Query, чтобы узнать, в каком статусе находится сейчас устройство — утюг выключен, включен, или какая температура сейчас на кондиционере. А Action, это значит, что текущий статус нужно поменять. Unlink происходит, когда пользователь решил разорвать связку аккаунтов, чтобы Яндекс полностью забыл обо всех устройствах, которые есть.
Давайте спустимся еще поглубже, и посмотрим, как работают все эти интенты. Первое, самое главное, это типы устройства — device type. Типы устройства влияют только на представления устройств в интерфейсе. Это специальные лейауты в мобильном приложении. Плюс, самое важное, наверное, что типы устройств обобщают некое голосовое представление, некие голосовые команды. То есть неважно, как пользователь назвал свою лампу, она все равно должна реагировать на слово «свет», например. Или совсем не должно быть важно, пользователь говорит «включи кондиционер» или «кондей». Причем этот кондиционер может называться как угодно.
И второе, это чтобы понять, как управлять устройством, нам нужно знать, что это устройство умеет. Мы называем эти штуки capabilities. То есть это как building block, которые рассказывают о том, что устройство умеет.
Чуть подробнее про device type. На самом старте у нас их было, по-моему, шесть. Сейчас мы выросли до такого количества. Например, две недели назад выпустили openable, и ребята смогли открыть свои ворота. Они могут теперь говорит: «Алиса, открой ворота», а не «Алиса, включи ворота», например.
Давайте теперь поговорим о capabilities, о том, какие capabilities бывают и как сделать так, чтобы Алиса поняла, как вашим устройством управлять.
Первое, самое главное и простое — on_off. Это capability есть практически у каждого устройства. Чтобы рассказать Алисе, что устройство умеет включаться, выключаться, достаточно добавить вот эти пару строчек Jason и определить флажок retrievable. Этот флажок означает, что можно у текущего устройства узнать, включен он или не включен.
Простой пример с телевизором. У всех вас есть дома телевизор вероятно, и, смотря на пульт от телевизора, невозможно понять, включен телевизор или выключен, конечно же, если этот пульт инфракрасный.
Следующий тип capability, который описывает световые приборы, это color_setting. У него также есть флажок retrievable. Но самое главное, вот эти два параметра — color_model. С помощью этого параметра производитель говорит нам о том, что он умеет управлять цветом. Этот цвет может быть в hsv-или rbg-режиме.
И второе — градация белого. То есть можно сказать, что моя лампочка умеет холодный белый цвет, теплый желтый цвет и так далее, чтобы пользователь мог говорить: «сделай, пожалуйста, свет потеплее».
Дальше у нас пойдут capabilities, обобщающие некие режимы. Очень хорошая аналогия с интерфейсом, это Radio buttons, когда вам нужно выбрать какой-то из нескольких режимов. Или вспомните стиральную машину с крутилочкой, где точно есть режим «хлопковое белье», «деликатная стирка» и т. д.
Здесь нам важно узнать, какой именно instance этого режима стоит. Текущие instance, там уже штук шесть их. Но именно те, которые мы реализовали на самом первом этапе, это instance работы кондиционера — автоматический режим, охлаждение, и т. д. Или, например, есть instance, режим работы вентилятора — самый медленный, средний или, опять же, автоматический.
И применительно к mode можно сказать: «Включи, пожалуйста, следующий режим». И это очень удобно для кондиционеров или для той же стиральной машины.
Еще одним capability является range. Применительно также с аналогией интерфейсов, это какой-то ползунок от минимального до максимального значения может что-то регулировать. У этого ползунка тоже есть instance. Например, это температура, громкость, яркость и так далее, практически любой range, который можно описать. Это unit, потому что некоторые люди, как оказалось, чтобы проверить кондиционеры, говорят значение температуры в фаренгейтах. И это, соответственно, совсем разные температуры. Когда человек просит включить в Фаренгейтах или в Цельсиях, и это тоже надо понимать.
Флажок random access, наверное, вам хорошо известен, это когда мы можем точную цифру, на которой в этом range нужно поставить значение. Довольно простой пример, опять же, с телевизорами. Громкостью можно управлять только вверх и вниз. А температуру на кондиционерах можно указать точную.
И само описание range, когда мы знаем какое-то минимальное значение, максимальное значение, и шажочек, с которым это значение можем изменять. На кондиционерах, опять же, оно может быть какое-то целое, или по долям десятков.
Последний capability аналогичен интерфейсу, это какая-то галочка. Помните, в старых компьютерах был такой турборежим — нажимаешь, и компьютер быстрее работает? Здесь ты говоришь: «Алиса, выключи звук», мы нажимаем кнопочку mute и звук исчезает. Можно сказать, наверное, что это какой-то бинарный режим.
И комбинация всех вот этих capabilities, всех умений. Мы можем описать всевозможные устройства, которые на данный момент представлены на рынке.
Например, умная лампочка. Она умеет включаться, выключаться. Она умеет регулировать цвет, и она умеет регулировать яркость. Но если с лампочкой все просто, давайте попробуем все вместе описать какое-нибудь другое устройство. Например, чайник.
Как вы считаете, что должен уметь умный чайник? Я дал вам подсказку, скриншот из интерфейса приложения Яндекс. Как бы вы описали чайник? Температура. Еще? Да, и включи-выключи. Чайник довольно простое устройство. Он умеет включаться, выключаться, и, например, мой любимый зеленый чай, я хочу его делать на 85 градусах. Есть ли в нем вода? Да, хорошее замечание. Тут мы ждем информацию от производителя.
Я хотел бы вам рассказать и про другие устройства. Одно из самых сложных устройств, которые сейчас есть, это кондиционер. Как вы считаете, что должен уметь кондиционер? Греть или охлаждать. Регулировать температуру. Режим со шторками. Скорость вентилятора. Все правильно. И кондиционер, который сейчас можно описать в нашем capability, умеет все это. Он умеет включаться, выключаться, выбирать режим охлаждения, регулировать температуру и скорость вентилятора, с которым дует или холодный, или горячий воздух. Может быть и простой воздух в режиме без кондиционера.
Давайте спустимся еще ниже и посмотрим, какие же ответы от производителей мы ждем при описании устройств. Это интент discovery. Здесь немножко YAML, но он довольно просто читается.
В тот момент, когда пользователь связывает аккаунты, мы спрашиваем у производителя, что же у этого пользователя есть, какие устройства — просто чтобы понимать, как ими управлять.
Первое, и самое главное: мы ждем user_id этого пользователя и список устройств.
Здесь описано только одно устройство: у пользователя есть лампочка, devices.types.light. Это может быть, кстати, не только лампочка. Это может быть какая-то РГБ-лента или газонокосилка с подсветкой. Нам это вообще неважно. Главное, чтобы она реагировала на слово «свет» и чтобы в интерфейсе мы смогли нарисовать capability, которое отвечает именно за свет.
Наша газонокосилка, похоже, умеет включаться, выключаться. Она умеет менять яркость. И она умеет регулировать цвет. Причем не только цвет — еще у этого осветительного прибора есть регулировка цветовой температуры.
Предположим, пользователь спрашивает: «Алиса, в каком состоянии сейчас моя лампочка?» или «Алиса, моя лампочка включена?» Тогда мы отправляем такой вопрос провайдеру, говорим, что у такого-то девайса нужно спросить, в каком сейчас цветовом режиме он находится и включено ли само устройство.
Если пользователь хочет изменить этот режим, он может, например, сказать: «Алиса, выключи свет». Есть лампочка с айдишником abc-123, «Пожалуйста, выключи», value false.
Ждем, что производитель устройства на той стороне облака нам ответит: окей, лампочка abc-123, action_result, status DONE. Значит, лампочка выключилась.
Еще немного про сценарии. Мы понимаем, что пользователи хотят не только управлять своими устройствами по отдельности, но и объединять их в группы. Например, просыпаясь, они говорят: «Алиса, доброе утро», и хотят, чтобы выполнилась некая комбинация действий.
Соответственно, в приложении Яндекса можно так сказать, и Алиса включит какую-то музыку, выключит ночник, чайник начнет работать, кипятить воду, чтобы сделать ваш любимый кофе.
О планах. Мы понимаем, что работа в текущем виде хотя и позволяет описать огромное количество устройств, но, например, не позволяет получать информацию от датчиков. Мы не сможем настроить в сценариях какой-то event так, чтобы по датчику протечки, дыма или открытия двери понять, что что-то случилось. Мы целимся это сделать. Также мы понимаем, что в данный момент не умеем управлять mediastream. Самый простой пример — курьер пришел к вам домой с горячей пиццей, и вам на телефон приходит пуш с фотографией этого человека. Это же супер! Сейчас с текущими capabilities это сделать невозможно — скорее всего, появятся capabilities, описывающие камеры.
Про датчики я затрону скользкую тему — IFTTT. C IFTTT мы хотим сценарий запускать не только голосом, как сделано сейчас. Мы хотим запускать их по разным events: по таймеру, расписаниям, восходу или заходу солнца и другим событиям. И мы очень хотим, чтобы умный дом был не только для гиков, которые понимают, зачем нужно передать свой пароль от Wi-Fi лампочке. Мы хотим сделать так, чтобы люди, абсолютно не связанные с умным домом, или не понимающие, как он работает, просто покупали какой-то чайник, стиральную машину, лампочку, неважно. И Алиса говорила: «Похоже, у вас в доме есть какое-то новое для меня устройство. Хотите его подключить?» И все, чтобы работало сразу.
В заключение хочу сказать: чтобы воспользоваться этой технологией, умным домом, вам нужно лишь прочитать документацию и правильно описать ваше устройство, используя device types и существующие сейчас capabilities. Спасибо.
