Форум » » Crestron + Алиса » Ответить

Crestron + Алиса

johnytsat: Добрый день,коллеги. Пытался кто-нибудь связать Алису с Crestron с помощью новой API "Умный дом" от Яндекс?

Ответов - 44, стр: 1 2 3 All

Paul_T: johnytsat пишет: Пытался кто-нибудь связать Алису с Crestron с помощью новой API "Умный дом" от Яндекс? А, где посмотреть этот API? И, совсем ламмерский вопрос: Обязательно пользоваться Умной Колонкой или можно говорить в телефон?

Вячеслав: Можно говорить в телефон. Api можно посмотреть в разделе Яндекс диалоги click here

Paul_T: Вячеслав пишет: Спасибо. Говорю в телефон. Кузя отвечает заданным ответом, т.е. Правило выполняется, но GET запрос пока не приходит... Порт проброшен, на компе поднят TCP сервер. Буду разбираться, вещь интересная...


Вячеслав: Похоже все таки сетевая проблема. Смотрите Wireshark-ом, ну и сервер свой проверьте Hercules -ом (сначала на локальный IP, потом на внешний)

Paul_T: Вячеслав пишет: Да, переброс портов не перебрасывается ))) Как раз Hercules'ом и слушаю TCP

johnytsat: Я просто не до конца понимаю видимо,что нужно указывать в IP адрес сервера. Потому что,чтобы что-то передать или получить сигнал Connect-F должен быть активным,как я понимаю? И его status должен быть равен 2d?Тогда какой IP должен выступать в роли сервера?Адрес контроллера?

Вячеслав: Для варианта TCP/IP server используется 2 типа адреса: Вариант1 0.0.0.0 позволяет организовать входящее подключение с любого внешнего адреса. Своего рода отключенный файервол. Вариант2 x.x.x.x позволяет подключаться к вашему серверу клиенту с IP адресом x.x.x.x (Например можно вписать вместо x.x.x.x адрес сервера alexstar.ru 46.173.214.134, хотя правильнее вписать доменное имя alexstar.ru используя поле use host name) . Впрочем, зная вашу url команду, другой пользователь сайта alexstar.ru сможет управлять вашими устройствами, поэтому держите ёё в секрете или реализуйте авторизацию basic (пароль и логин с вашей страницы настроек доступен только Вам). Но basic авторизация это уже однозначно программный код и на кубиках такого не сделать. Никакие 127.0.0.1 или адрес крестрона сюда вписывать не нужно. Можно посмотреть контекстную справку по этому элементу в SimplWindows. В общем случае status будет равен 1 (ожидание соединения), а Connect-F равен 0. Когда прилетит входящий Get, то статус поменяется на 2d , и Connect-F на 1. Это подключение будет вскоре разорвано (после передачи запроса Get), по инициативе сервера alexstar.ru, так как нет необходимости его поддерживать постоянно (оно и к лучшему). Не интересовался как долго сервис поддерживает это входящее соединение открытым, но скорее всего около 0,5s выделенные разработчиком для вашего ответа на Get запрос, если он предусмотрен.

johnytsat: Спасибо огромное,очень помогло двинуться!

johnytsat: Не понял как убрать задержку в 15с через поле Content-Length,ведь в GET-запросе этого поля нет. Убрал задержку через последовательный SocketServerStopListen,SocketServerStartListen после получения запроса. Не знаю только,создаст ли это какие-нибудь проблемы?

Вячеслав: Задержка возникает при не корректном ответе на входящий Get. Если вы не отправляете ответ с крестрона, то проблема задержки может быть иная.. Поле Content-Length относится лишь к ответу в формате json. Как влияет SocketServerStopListen, SocketServerStartListen не могу сказать. Я изначально закрываю соединение, если оно остается активным более 0,2s в силу особенностей единственно возможного подключения. Но это скорее костыль на всякий случай. (Вот он видимо меня и выручил) Вы хотите сказать, что если его не закрывать, то удаленная сторона закроет его не ранее чем через 15с и следовательно новые входящие запросы крестрон принять не сможет, потому что для них навык alexstar создает новые сессии?

Вячеслав: Paul_T пишет: Да, переброс портов не перебрасывается ))) Как раз Hercules'ом и слушаю TCP Вангую, у Вас наверное роутер получает серый внешний адрес от провайдера.

johnytsat: Вячеслав пишет: Да,я пока без ответа делал,только на получение)И такое ощущение что SocketStartListen,если его не останавливать слушает в течении 15с.

Paul_T: Вячеслав пишет: Естественно, но это никогда не мешало достучаться на локальный IP по переброшенному порту. Дело в корявой прошивке MI роутера, поставил альтернативную, все работает...

Viacheslav Alekseev: Вячеслав пишет: Да, возможно использовать внешний TCP/IP Server. Просто вы будете ограничены по длине голосовых команд. А что мешает прием буферизировать, он ведь данные не должен потерять, просто дошлет их в следующих посылках CHANGE Rx и если поставить BUFFER_INPUT Rx, то все в итоге должно прийти корректно. (или я чего-то не знаю про TCP Server?) А на отправку та же история - просто выходную команду отправлять в Tx циклом, разбивающим ее на куски по 250 байт, например. HTTP сервер ведь не дурак, знает когда HTTP запрос начинается и когда заканчивается (по нескольким \x0D\x0A).

Viacheslav Alekseev: Вячеслав пишет: Вы хотите сказать, что если его не закрывать, то удаленная сторона закроет его не ранее чем через 15с и следовательно новые входящие запросы крестрон принять не сможет, потому что для них навык alexstar создает новые сессии? johnytsat пишет: Да,я пока без ответа делал,только на получение)И такое ощущение что SocketStartListen,если его не останавливать слушает в течении 15с. Вклинюсь в диалог. HTTP клиент, отправив вам HTTP запрос, ждет адрекватного ответа на него, по всем правилам HTTP. (С кодом завершения и тд). А коль уж вы эмулируете HTTP сервер - вы должны ему этот ответ дать. Иначе он будет ждать его, пока не наступит таймаут. Это легко увидеть в браузере - набрав соответсвующий URL вы будете видеть как он пытается что-то загрузить и потом отваливается по таймауту. Вероятно, тот клиент не шлет следующие запросы, не завершив текущий. (Либо он однопоточный, либо крестроновский сокет не хочет принимать новые соединения.) Принудительный обрыв соединения позволяет избавиться от долгого таймаута, но это, конечно, костыль и для клиента формально означает ошибку (Удаленный хост неожиданно оборвал соединение). Поэтому обязательно ответьте на HTTP запрос минимально необходимым ответом, что-то типа HTTP/1.1 200 OK\x0D\x0A\x0A\x0A (пишу по памяти, примерно)

Paul_T: Минимальный ответ недостаточно. Я вот такой ответ шлю через Serial I/O HTTP/1.1 200 OK\x0d\x0aContent-Length: 30\x0d\x0aContent-Type: text/html\x0d\x0aConnection: keep-alive\x0d\x0a\x0d\x0a{"status":"ok","value":"100"}\x0D\x0A\x0D\x0A Алиса переваривает, задержки в 15 сек нет...

Вячеслав: А почему Content-Length: 30 получился, а не 29 или это рукотворный отредактированный вариант?

Paul_T: Вячеслав пишет: А почему Content-Length: 30 получился, а не 29 или это рукотворный отредактированный вариант? Да, рукотворный вариант. В Content-Lenght кроме основной нагрузки входит 1 символ перевода строки... Как я вычитал (хотя уже не уверен, сейчас перепроверю). Во всяком случае запрос моментально работает в из браузера, Алиса работает корректно, так-же корректно я вижу лог на сайте домовенка Кузи. UPD Лишний \n\r можно в конце не передавать. Content-Lenght сократил до реального значения 29 Кроме того, как оказалосьб достаточно передавать сообщение с таким заголовком: HTTP/1.1 200 OK\x0d\x0aContent-Length: 29\x0d\x0a\x0d\x0a{"status":"ok","value":"100"}\x0d\x0a

Вячеслав: Я вообще после блока json ничего не добавляю, тоже норм. Отправляю правда {"status":"ok","text":""} если ответ не предусмотрен. Наверное, можно и до {"status":"ok"} сократить

Viacheslav Alekseev: Вячеслав пишет: Я вообще после блока json ничего не добавляю, тоже норм. И это правильно, потому что длина контента задается в заголовке Content-Length и никаких дополнительных переводов строки в контенте не нужно. Они нужны чтобы отделить контент от http-запроса или обозначить конец запроса, если контента нет.



полная версия страницы