MajorDoMo

fandaymon писал(а):

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

Ну почему же нельзя? В шаблонах тоже контекст есть.

Имеется в виду, что нельзя из обработчика шаблона решить, хотите Вы передать управление модулям или нет.

olehs писал(а):

fandaymon писал(а):

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

Ну почему же нельзя? В шаблонах тоже контекст есть.

Имеется в виду, что нельзя из обработчика шаблона решить, хотите Вы передать управление модулям или нет.

Ну так можно же точно так же с помощью процессинга подписки запустить что хочешь

Тут все не так просто. Во первых, не хотелось бы в каждом обработчике шаблона, если он сработал, но "не до конца", прописывать вызов обработчиков модулей.
Во-вторых, ни шаблоны, ни commandReceived не получают информацию об источнике события (юзер, терминал), соответственно не могут передать их в модули (а в API.AI я успешно воспользовался этими параметрами).

olehs писал(а):Тут все не так просто. Во первых, не хотелось бы в каждом обработчике шаблона, если он сработал, но "не до конца", прописывать вызов обработчиков модулей.
Во-вторых, ни шаблоны, ни commandReceived не получают информацию об источнике события (юзер, терминал), соответственно не могут передать их в модули (а в API.AI я успешно воспользовался этими параметрами).

Так не каждому шаблону такое нужно. Навскидку не могу придумать зачем это вообще нужно...

Всё что получается API.AI могут получить и шаблоны. Конечно есть разница прописать это в одном месте или в многих, но возможность такая есть.

Я ни в коем случае не хочу никому рассказывать как ему удобней строить свою систему... Меня вот хак с обработкой в конце - вполне устроит.

Просто опишу ситуацию...

Имеется простое устройство телевизор (тип - кнопка)
Имеется шаблон - Включи телевизор
В api.ai нет ничего с этим связанного

Произносим "включи телевизор"...
Что происходит:
-Отрабатывает простое устройство кнопка
-Шаблон не отрабатывает вообще (непонятно как в таком случае в принципе вызывать одноимённые шаблоны)
-Более того команда передаётся в API.AI, API.AI не находит её, и возвращает unknown intent...и если у нас прописан в api.ai реакция на unknown intent - выдаётся эта реакция...например говорим "Ваша команда не найдена", хотя в 1 пункте она отлично отработала.
Всем обработчикам команда передаётся одновременно. Никто из них не знает выполнилась ли команда в соседних. А шаблоны вообще не в теме получаются, если в них присутствует имя любого устройства.

Что должно происходить по моему мнению (и не только моему...как раз там это обсуждалось):
-Выполняем шаблон
-Если данного шаблона не найдено - передаём в простые устройства
-Если в простых устройствах не найдено - передаём управление API.AI
-Если в API.AI ничего не найдено - он возвращает intetnt.unknown (это собственно так и есть сейчас)
Если хоть в 1 из обработчиков нашлась реакция - НЕ ПЕРЕДАЁМ управление далее.
Порядок обработчиков должен задаваться пользователем...(как кому удобно - сперва шаблоны, потом устройства, наоборот, или вообще сперва в api.ai передавать)...

Сейчас не хватает именно очередности и прерываний в нужных местах.

Надеюсь внёс хоть немного понимания тому, у кого есть желание "сделать правильно"...лично я не на столько силён в ядре системы, чтобы так глубоко копать.

nick7zmail писал(а): Всем обработчикам команда передаётся одновременно. Никто из них не знает выполнилась ли команда в соседних. А шаблоны вообще не в теме получаются, если в них присутствует имя любого устройства.

Нет, не одновременно - по очереди. И выполнилась или нет - в принципе знают. Точнее есть механизм чтобы знали, но без переделок он не работает так как надо.

nick7zmail писал(а): Что должно происходить по моему мнению (и не только моему...как раз там это обсуждалось):
-Выполняем шаблон
-Если данного шаблона не найдено - передаём в простые устройства
-Если в простых устройствах не найдено - передаём управление API.AI
-Если в API.AI ничего не найдено - он возвращает intetnt.unknown (это собственно так и есть сейчас)
Если хоть в 1 из обработчиков нашлась реакция - НЕ ПЕРЕДАЁМ управление далее.
Порядок обработчиков должен задаваться пользователем...(как кому удобно - сперва шаблоны, потом устройства, наоборот, или вообще сперва в api.ai передавать)...

Сейчас не хватает именно очередности и прерываний в нужных местах.

Надеюсь внёс хоть немного понимания тому, у кого есть желание "сделать правильно"...лично я не на столько силён в ядре системы, чтобы так глубоко копать.

Ну вот выше написано как это реализовать. Отписать обработчики devices и apiai и вызывать их в методе commandReceived в том порядке, который нужен

nick7zmail писал(а): Что должно происходить по моему мнению (и не только моему...как раз там это обсуждалось):
-Выполняем шаблон
-Если данного шаблона не найдено - передаём в простые устройства
-Если в простых устройствах не найдено - передаём управление API.AI
-Если в API.AI ничего не найдено - он возвращает intetnt.unknown (это собственно так и есть сейчас)
Если хоть в 1 из обработчиков нашлась реакция - НЕ ПЕРЕДАЁМ управление далее.
Порядок обработчиков должен задаваться пользователем...(как кому удобно - сперва шаблоны, потом устройства, наоборот, или вообще сперва в api.ai передавать)...

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

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

Последней точкой (реакцией на неизвестную команду), к.м.к, все-таки лучше сделать как и задумано Сергеем - метод commandReceived. т.к. он локальный и там не так много вариантов ответа. Использовать для этой цели "Искусственный Интеллект " API.AI - это как из пушки по воробьям, хотя у меня самого довольно долго в этом месте стоял бот iii.ru - гостям нравилось.

Ну и для понимания, зачем я все это затеял
У меня через шаблоны уже были настроены схемы включения типа Включи свет - Где именно - В прихожей. Но у меня есть несколько стационарных терминалов и если запрос приходит от них - зачем спрашивать Где? Эту проблему теперь можно решить с помощью api.ai - туда передается терминал.

Вторая проблема - это одновременные голосовые запросы из разных мест. Сейчас sayReply отвечает на тот терминал, с которого пришел последний запрос. Если кроме Вас кто-то еще решил воспользоваться голосовым управлением одновременно с вами - скорее всего последним сообщением в логе будут маты
Модуль api.ai сейчас ведет отдельные сессии для каждого терминала (если он указан). Туда же передается пользователь, что тоже может пригодится в случае мобильных терминалов.

Кроме того, сейчас я сделал возможным передавать из МЖД в api.ai сущности (Entity, как глобальные, так и сессионные). Что это даст? Можно, например сказать "Включи Deep Purple", где Deep Purple - это имя альбома из вашей медиатеки или вообще конкретную песню. И это не должно конфликтовать со всеми остальными "включи ..."

Отдельная тема - это контексты и реализуемые с их помощью диалоги. Сейчас их можно реализовывать как в шаблонах, так и в api.ai. Тут я вообще не понимаю как сделать, чтобы они не мешали друг другу. Получается их можно вести только в том модуле, который обрабатывается первым.

UPD. посмотрел devices/processCommand.inc.php
все верно - PROCESSED выставляется, а BREAK - нет.
Т.е. шаблоны не сработают, а другие модули - вполне.

olehs писал(а):
Ну и для понимания, зачем я все это затеял
У меня через шаблоны уже были настроены схемы включения типа Включи свет - Где именно - В прихожей. Но у меня есть несколько стационарных терминалов и если запрос приходит от них - зачем спрашивать Где? Эту проблему теперь можно решить с помощью api.ai - туда передается терминал.

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

olehs писал(а):
Кроме того, сейчас я сделал возможным передавать из МЖД в api.ai сущности (Entity, как глобальные, так и сессионные). Что это даст? Можно, например сказать "Включи Deep Purple", где Deep Purple - это имя альбома из вашей медиатеки или вообще конкретную песню. И это не должно конфликтовать со всеми остальными "включи ..."

Это интересная тема... А как это реализуется с точки зрения api.ai? В какой-то момент просто передаётся вся информация о существующих группах/песнях?

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

olehs писал(а): Отдельная тема - это контексты и реализуемые с их помощью диалоги. Сейчас их можно реализовывать как в шаблонах, так и в api.ai. Тут я вообще не понимаю как сделать, чтобы они не мешали друг другу. Получается их можно вести только в том модуле, который обрабатывается первым.

Мне кажется выход тут прост - делаешь контексты только в том модуле, который нравится и да - ставишь его первым.

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