Ошибка проверки доступности endpoint url провайдера

Необходимое для начала

•  Аккаунт в Яндексе (он же у Вас есть, верно?)
•  Настроенный Home Assistant, с подключенным внешним IP и ssl на домене, или настроенным dDNS (я использую duckdns.org). Описывать первоначальную настройку HA я не буду, здесь на sprut.ai написано об этом (и немного больше) уже очень много.

Сам процесс настройки подключения сервисов

Для начала необходимо создать новый каталог с именем «custom_components» , если у Вас его нет (как у меня ранее), путь ~/.homeassistant/custom_directory/ или ~/config/custom_components/ в зависимости от места и версии HA).

Далее нужно склонировать туда гит, на котором вся система и работает — GitHub (все лайки именно туда, писал его не я) или же создать вручную папку yandex_smart_home и туда скопировать файлы из архива, которые были скачаны из гитхаба оттуда.

git clone https://github.com/dmitry-k/yandex_smart_home.git

Далее прописываем в configuration.yaml этот самый компонент:

• как я, просто добавляем в конце файла «yandex_smart_home:» (без кавычек, конечно);
• или же «курим» расширенный мануал от создателя компонента этого: ReadMe.

После, проверяем, на всякий случай, конфигурацию в настройках, и перезагружаем HA.

После этого уже переходим на сам процесс подключения всего, что сделали, в Умный дом Яндекса:

•  Создаём Навык Умный Дом на https://dialogs.yandex.ru/developer/  (Очень важно создавать навык именно залогинившись с того аккаунта, в котором будем будем устройства использовать в Яндексе).

•  Заполняем все поля, отмеченные звездочкой.

Не закрываем страничку и переходим пока на https://dialogs.yandex.ru/developer/settings/oauth , где добавляем новую связку аккаунтов:

НазваниеИдентификатор приложения/Client identifier : https://social.yandex.net/Секрет приложения/Client Password (без него сохранить не получилось связку, но в итоге она из неё сама удалилась. Я вписал туда стандартный, видимо, пароль из файла secrets.yaml. Может можно вообще что угодно вписать, или этот «секрет» где-то настраивается и это важно — но я об этом не знаю хD): passwordURL авторизации/API authorization endpoint: https://[внешний_адрес_сервера_HA:порт]/auth/authorizeURL для получения токена/Token Endpoint: https://[внешний_адрес_сервера_HA:порт]/auth/tokenURL для обновления токена/Refreshing an Access Token: https://[внешний_адрес_сервера_HA:порт]/auth/token

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

По сути все: осталось в приложении Яндекс на Android/iOS или на ПК в браузере  добавить нашего нового «производителя». Покажу на примере мобильного приложения.

И все доступные устройства из HA добавляются в список устройств.
Надписей красным цветом и восклицательных знаков не пугаемся: необходимо лишь переназвать каждое устройство, используя «кириллицу, без пунктуации и спецсимволов; между словами и числами ставьте пробелы«.

На данный момент поддерживаются только вот эти domains в HA:

• group (on/off)
• input_boolean (on/off)
• switch (on/off)
• fan (on/off)
• light (on/off)
• cover (on/off)
• media_player (on/off, mute/unmute)

В дальнейшем будет также добавлена возможность проброса из Home Assistant в Яндекс:

• поддержка громкости в media_player;
• яркость/цвет ламп;
• скорость увлажнителя/вентилятора.

На этом все, мы вместе смогли подключить те устройства, которые «нативно» не поддерживаются пока в Умном Доме Яндекс.
Кроме того, это позволяет избежать возможных лагов из-за cloud-2-cloud системы, когда Яндекс обращается в облако производителя, который обращается в облако подключенного к нему производителя, который…. — и все они лагают =)
Остаются, по сути, только Ваш сервер, за который Вы и в ответе, и облако самого Яндекса, куда все и интегрируется.

Текст составлен с неоценимой помощью @OXOTH1K , а также всего сообщества, которые и двигают весь прогресс на основе «ступенек» от компаний, подобных Яндексу.

Содержание

Что такое код ответа HTTP

Как проверить код состояния страницы

В браузере

В Яндекс.Вебмастере

В Google Search Console

1* класс кодов (информационные сообщения)

100 Continue

101 Switching Protocols

102 Processing

103 Checkpoint

105 Name Not Resolved

2* класс кодов (успешно обработанные запросы)

200 ОК

201 Created

202 Accepted

203 Non‑Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

207 Multi‑Status

226 IM Used

3* класс кодов (перенаправление на другой адрес)

300 Multiple Choices

301 Moved Permanently

302 Found/Moved 

303 See Other

304 Not Modified

305 Use Proxy

306 Unused

307 Temporary Redirect

308 Resume Incomplete

4* класс кодов (ошибки на стороне клиента)

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Timeout

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request‑URI Too Long

415 Unsupported Media Type

416 Requested Range Not Satisfiable

417 Expectation Failed

418 I’m a teapot

422 Unprocessable Entity

423 Locked

424 Failed Dependency

425 Unordered Collection

426 Upgrade Required

428 Precondition Required

429 Too Many Requests

431 Request Header Fields Too Large

434 Requested Host Unavailable

444 No Response

449 Retry With

450 Blocked by Windows Parental Controls

451 Unavailable For Legal Reasons

456 Unrecoverable Error

499 Client Closed Request

5* класс кодов (ошибки на стороне сервера)

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

505 HTTP Version Not Supported

506 Variant Also Negotiates

507 Insufficient Storage

508 Loop Detected

509 Bandwidth Limit Exceeded

510 Not Extended

511 Network Authentication Required

Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.

Что такое код ответа HTTP

Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос. 

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

Как проверить код состояния страницы

Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.

В браузере

Для примера возьмём Google Chrome.

1. Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы». 

2. Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу: 

В Яндекс.Вебмастере

Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:

Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса

В Google Search Console

Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:

Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».

А затем в открывшемся окне перейдите на вкладку «Подробнее»:

Теперь расскажем подробнее про все классы кодов состояния HTTP.

1* класс кодов (информационные сообщения)

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

100 Continue

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

101 Switching Protocols

Сервер одобрил переключение типа протокола, которое запросил пользователь, и в настоящий момент выполняет действие.

102 Processing

Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.

103 Checkpoint

Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.

105 Name Not Resolved

Не удается преобразовать DNS‑адрес сервера — это  означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.

2* класс кодов (успешно обработанные запросы)

Эти коды информируют об успешности принятия и обработки запроса. Также сервер может передать заголовки или тело сообщений. 

200 ОК

Все хорошо — HTTP‑запрос успешно обработан (не ошибка).

201 Created

Создано — транзакция успешна, сформирован новый ресурс или документ.

202 Accepted

Принято — запрос принят, но ещё не обработан.

203 Non‑Authoritative Information

Информация не авторитетна — запрос успешно обработан, но передаваемая информация была взята не из первичного источника (данные могут быть устаревшими).

204 No Content

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

205 Reset Content

Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.

206 Partial Content

Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.

При работе с подобными ответами следует уделить внимание кэшированию.

207 Multi‑Status

Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus. 

226 IM Used

Успешно обработан IM‑заголовок (специальный заголовок, который отправляется клиентом и используется для передачи состояния HTTP).

3* класс кодов (перенаправление на другой адрес)

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

300 Multiple Choices

Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.

301 Moved Permanently

Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.

302 Found/Moved 

Временно перемещено — страница временно перенесена на другой URL,  который указан в поле Location.

303 See Other

Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.

304 Not Modified

Модификаций не было — с момента последнего визита клиента изменений не было.

305 Use Proxy

Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.

306 Unused

Зарезервировано. Код в настоящий момент не используется.

307 Temporary Redirect

Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.

Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.

308 Resume Incomplete

Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.

4* класс кодов (ошибки на стороне клиента)

Эти коды указывают на ошибки со стороны клиентов. 

400 Bad Request

Неверный запрос — запрос клиента не может быть обработан, так как есть синтаксическая ошибка (возможно, опечатка).

401 Unauthorized

Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.

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

402 Payment Required

Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.

403 Forbidden

Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.

404 Not Found

Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).

405 Method Not Allowed

Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.

406 Not Acceptable

Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).

407 Proxy Authentication Required

Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.

408 Request Timeout

Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение  и просто обновите страницу.

409 Conflict

Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).

410 Gone

Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и  недоступен (серверу неизвестно месторасположение).

411 Length Required

Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length. 

Нужно исправить заголовки на сервере, и в следующий раз робот сможет проиндексировать страницу.

412 Precondition Failed

Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.

413 Request Entity Too Large

Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.

414 Request‑URI Too Long

Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.

415 Unsupported Media Type

Формат не поддерживается —  сервер не может принять запрос, так как  данные подгружаются в некорректном формате, и сервер разрывает соединение.

416 Requested Range Not Satisfiable

Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.

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

417 Expectation Failed

Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».

418 I’m a teapot

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

422 Unprocessable Entity

Объект не обработан — сервер принял запрос, но в нём  есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.

423 Locked

Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.

424 Failed Dependency

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

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

425 Unordered Collection

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

426 Upgrade Required

Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection. 

Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.

428 Precondition Required

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

429 Too Many Requests

Слишком много запросов — отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS‑атаки, для защиты от которой запросы блокируются.

431 Request Header Fields Too Large

Превышена длина заголовков — сервер может и не отвечать этим кодом, вместо этого он может просто сбросить соединение.

Исправляется это с помощью сокращения заголовков и повторной отправки запроса.

434 Requested Host Unavailable

Адрес запрашиваемой страницы недоступен.

444 No Response

Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.

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

449 Retry With

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

450 Blocked by Windows Parental Controls

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

451 Unavailable For Legal Reasons

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

456 Unrecoverable Error

Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.

499 Client Closed Request

Запрос закрыт клиентом — нестандартный код, используемый nginx в ситуациях, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

5* класс кодов (ошибки на стороне сервера)

Эти коды указывают на ошибки со стороны серверов. 

При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. И его можно использовать в работе.

500 Internal Server Error

Внутренняя ошибка сервера — сервер столкнулся с неким условием, из‑за которого не может выполнить запрос. 

Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

501 Not Implemented

Не выполнено —  код отдается, когда сам сервер не может идентифицировать метод запроса. 

Сами вы эту ошибку не исправите. Устранить её может только сервер.

502 Bad Gateway

Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.

Актуально исключительно для прокси и шлюзовых конфигураций.

503 Service Unavailable

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

В поле Retry‑After заголовка сервер укажет время, через которое  можно повторить запрос.

504 Gateway Timeout

Тайм‑аут шлюза —  сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.

Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере. 

Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого  нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.

505 HTTP Version Not Supported

Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.

506 Variant Also Negotiates

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

507 Insufficient Storage

Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.

508 Loop Detected

Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.

509 Bandwidth Limit Exceeded

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

510 Not Extended

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

511 Network Authentication Required

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

Ошибка «Узел не прошел проверку» при обращении к веб-сервису

В платформе 8.3.10 была переработана логика валидации доверенных сертификатов.

При работе в ОС Windows для проверки сертификата происходит обращение к внешнему ресурсу в сети Internet. Для успешного выполнения данной операции у пользователя, от которого запускается процесс rphost, должна быть возможность обратиться к этому внешнему ресурсу, а также сам ресурс должен быть доступен.

В случае некорректно заданных настроек доступа в Internet после перехода на 8.3.10 с более ранних версий платформы могут возникать ошибки :

а) при обращении к веб-сервисам или получении определения веб-сервиса по причине «ошибка работы с Интернет: Удаленный узел не прошел проверку»

б) при попытке выполнить OpenID-авторизацию вида «Ошибка подключения к OpenID провайдеру», сопровождающиеся появлением в технологическом журнале событий EXCP вида:

9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Ошибка доступа к файлу ‘https://mycloud.ru/openid/e1cib/oid2op’: srcHTTPImpl.cpp(2598):

896db6ac-cc39-4065-8298-1bf5fccb9d98: Ошибка работы с Интернет: Удаленный узел не прошел проверку «

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

Диагностика проблемы

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

Целенаправленно только сайты, предназначенные для валидации сертификатов, никто не блокирует, поэтому скорее всего у пользователя не доступен ни один сайт (можно легко проверить, запустив браузер от имени данного пользователя – зажать Shift, правой кнопкой мыши на ярлык браузера, «Запустить от имени другого пользователя»). Однако расследование необходимо проводить именно на том примере, на котором ошибка воспроизводится.

Наиболее распространенные причины:

• Доступ к ресурсу заблокирован через файл hosts
• Нет доступа к ресурсу из-за использования прокси-сервера
• Ресурс заблокирован firewall
• Ресурс блокирован антивирусом

Для подробной диагностики ошибки в случае, если причина оказалась нетривиальной, рекомендуется настроить сбор дополнительных event-логов Windows, согласно описанию, приведенному в статье (раздел Use CAPI2 logging)

Решение проблемы

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

Про настройки прокси и hosts опишем подробнее.

Прокси сервер

1) Запустить Internet Explorer от имени пользователя, под которым работает rphost

2) В меню Свойства браузера (Свойства обозревателя) на закладке Подключения нажать кнопку Настройка сети

3) Если в настройках указано использование прокси-сервера, которая не предусмотрена политикой безопасности (кто-то когда-то установил и забыл) – отключить использование прокси-сервера, сняв соответствующий флаг

4) Если использование прокси действительно предусмотрено, нужно разрешить прямое обращение к ресурсам, на которые пытается обратиться платформа для валидации сертификата, нажав кнопку Дополнительно и указав данный ресурс в качестве исключения для прокси-сервера

Файл hosts

Доступ к некоторым сайтам может блокироваться через файл hosts. Лежит здесь:

Пример того, как блокированный сайт выглядит в файле hosts:

Источник

1C ошибка HTTP при обращении к серверу

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

При запуске базы появляется сообщение об ошибке

Сегодня рассмотрим еще одну, она возникает в момент запуска информационной базы которая опубликована на веб сервере.

1C ошибка HTTP при обращении к серверу удаленный узел не прошел проверку

Если нажать «Подробно» то можно увидеть.

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
по причине:
Ошибка HTTP при обращении к серверу: https://…
Удаленный узел не прошел проверку

Это говорит о том что на сервере по каким либо причинам не работает HTTPS. Либо сбились настройки самого сервера либо просто истек срок действия сертификата SSL. Проверить это можно введя в браузере путь до информационной базы. Если вы видите тоже самое что на скриншоте ниже то проблема точно с сертификатом сервера.

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

Потом нужно нажать «Дополнительно».

Первое окно пропускаем.

А в следующем выбираем «Не предоставлять сертификат» и «Не проверять сертификат сервера».

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

Либо как вариант можно также изменить HTTPS на HTTP в адресе информационной базы.

Источник

Ошибка «Удаленный узел не прошел проверку»

Обработка обмена при подключении к серверам ST-Mobi.com создает SSL-cоединение с использованием стандартных методов платформы.

Если при попытке выполнить обмен возникает сообщение: » Ошибка работы с Интернет: Удаленный узел не прошел проверку«, это означает, что возникает ошибка установки SSL-соединения (защищенного соединения с внешним (сторонним) сервером), т.к. у программы «1С» нет доверия к SSL-сертификату ресурса, с которым идет попытка установить такое соединение.

Обычно проблема кроется в некорректных настройках «окружения» и проблему надо устранять вне программы «1С».

Чтобы убедиться, что проблема вне «1С», можно проверить есть ли доверие к ресурсу внешнего сервера в обычном Интернет-браузере (лучше в «Internet Explorer»), т.е. выполнить диагностику.

Последовательность шагов диагностики

1. узнать адрес сервера, с которым устанавливается защищенное соединение (зависит от сервиса, которым пытаетесь воспользоваться);
2. правильно определить компьютер, с которого устанавливается защищенное соединение (зависит от режима использования программы «1С») и там открыть Интернет-браузер;
3. указать в адресной строке Интернет-браузера адрес сервера и убедиться, что к данном узлу на компьютере есть доверие.

Шаг 1: как найти адрес сервера?

Обработка при работе устанавливает соединение с сайтом ST-Drive https://st-drive.systtech.ru

Шаг 2: как определить компьютер, на котором надо открыть Интернет-браузер?

Если программа «1С» используется в одном из следующих режимов(см. форму «Справка»-«О программе»):

2а) режим «Файловый», то соединение с внешним сервером устанавливается с того компьютера, на котором пользователь запускает программу «1С».

Надо на этом компьютере открыть Интернет-браузер (лучше «Internet Explorer);

2б) режим «Серверный», то соединение с внешним сервером устанавливается с того компьютера, на котором запускается служба «Агент сервера 1С:Предприятия 8.х».

Надо зайти на компьютер, где запускается служба «Агент сервера 1С:Предприятия 8.х» под учетной записью пользователя операционной системы, под которым эта служба стартует, и уже там открыть Интернет-браузер (лучше «Internet Explorer»).

Шаг 3: как определить, есть или нет доверие к внешнему серверу?

В адресной строке Интернет-браузера следует указать адрес сервера, с которым надо проверить установку соединения, и нажать клавишу «Enter»:

3а) Если в адресной строке отобразится «закрытый замок» (Требование №1) — защищенное соединение успешно установлено (на сообщение в основном окне браузере не надо обращать внимание):

Необходимо щелкнуть на «замок» и посмотреть сведения о сертификате:

В открывшемся окне перейти на последнюю закладку и убедиться, что цепочка сертификатов корректная (непрерывная и без каких-либо предупреждающих иконок — Требование №2 ), и статус последнего в цепочке сертификата — «ОК» ( Требование №3 ):

Внимание! Если на компьютере выполнились Требования №1, 2, 3 — это означает, что «окружение» настроено корректно.
Рекомендуется после проведенной диагностики повторить попытку соединения из программы «1С» и, если сообщение «Удаленный узел не прошел проверку» возникает вновь, то это проблема, требующая дополнительного анализа .
В таком случае необходимо собрать всю информацию о параметрах клиентского компьютера и используемого сервера и прислать ее на Линию консультаций «1С» для воспроизведения проблемы.

3б) Если на каком-то из шагов диагностики нет доверия к внешнему ресурсу в браузере (нарушено, хотя бы одно из Требований 1, 2, 3) – рекомендуем обратиться в тех.поддержку соответствующего сервиса или банка, чтобы сначала настроить «окружение» и добиться того, что в браузере есть доверие к внешнему ресурсу, а уже затем пробовать повторно подключаться из программы «1С».

Источник

«Ошибка HTTP при обращении к серверу: https:// Удаленный узел не прошел проверку»

Ошибка возникает при запуске ИБ. Например, когда выполняете соединение по HTTPS через тонкого клиента, но 1С не может проверить SSL-сертификат сервера. В большинстве случаев — это самоподписанный сертификат.

Возможные решения

1. Проверка даты/времени на ПК

Проверьте корректность через «Панель управления — Часы и регион — Дата и время». Отправьте команду на автоматическую синхронизацию, если вы соединены с сетью Интернет.

2. Проверка доступности

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

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

Если адрес не открывается — другие распространенные причины:
• доступ заблокирован через файл hosts;
• нет доступа из-за прокси-сервера;
• ресурс блокирован firewall/антивирусом.

3. Отключение проверок

Список ИБ — Выбор базы — Изменить… — Дополнительно… — Далее >
Выберите клиентский сертификат: Не предоставлять
Выберите способ проверки сертификата сервера: Не проверять

Не проверять сертификат сервера

4. Игнорирование ошибки проверки отзыва

В конфигурацию платформы — в файл conf с расширением cfg — добавьте следующую опцию:

Расположение файла:
• C:Program Files1cv88.х.хх.ххххbinconf
• C:Program Files (x86)1cv88.х.хх.ххххbinconf

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

5. Импорт самоподписанного сертификата

Добавьте сертификат сервера на ПК, с которого вы подключаетесь, в список «Локальный компьютер — Доверенные корневые центры сертификации — Сертификаты».

В этом случае поставьте режим «Выберите способ проверки сертификата сервера = Хранилище сертификатов Windows». Или укажите файл сертификатов CA — как удобнее.

6. Диагностика ошибок

Используйте методические рекомендации по диагностике ошибок ОС Windows из официальной статьи 1С.

Если окружение настроено корректно и есть доверие к сертификату удаленного ресурса, то ошибки не будет. Пусть все получится. 🤗

Если требуется дополнительная поддержка — наши специалисты готовы вам помочь → +7-911-500-10-11

Источник

«Ошибка HTTP при обращении к серверу: https:// Удаленный узел не прошел проверку» в 1С

Ошибка возникает при запуске ИБ. Например, когда выполняете соединение по HTTPS, но 1С не может проверить SSL-сертификат сервера. В большинстве случаев — это самоподписанный сертификат.

Возможные решения

1. Проверка даты/времени на ПК

Проверьте корректность через « Панель управления — Часы и регион — Дата и время ». Отправьте команду на автоматическую синхронизацию, если вы соединены с сетью Интернет.

Пуск — Выполнить — timedate.cpl

2. Проверка доступности

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

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

Если адрес не открывается — другие распространенные причины:

• доступ заблокирован через файл hosts;
• нет доступа из-за прокси-сервера;
• ресурс блокирован firewall/антивирусом.

3. Отключение проверок

Список ИБ — Выбор базы — Изменить. — Дополнительно. — Далее >

Выберите клиентский сертификат: Не предоставлять сертификат

Выберите способ проверки сертификата сервера: Не проверять сертификат сервера

Источник

Современные приложения не могут подключаться при использовании VPN-подключения Check Point

В этой статье данная статья позволяет решить проблему, из-за которой современные приложения не могут подключаться к Интернету после подключения к корпоративной сети с помощью VPN-программного обеспечения Check Point.

Применяется к: Windows 8
Исходный номер КБ: 2855849

Симптомы

Рассмотрим следующий сценарий.

• Вы используете версию VPN удаленного доступа к конечным точкам Check Point, которая является более ранней, чем E80.50.
• Успешно запущены Windows 8 (Store Apps) и классические настольные приложения.
• Подключение к корпоративной сети с помощью клиентского программного обеспечения Check Point VPN в «концентраторном режиме» (то есть весь трафик проходит через виртуальный сетевой адаптер).
• После подключения индикатор состояния сети показывает, что подключение к Интернету полностью доступно.

В этом сценарии классические приложения могут успешно подключаться к Интернету. Однако современные приложения не могут подключаться. Кроме того, компьютерная версия Windows Internet Explorer 10 не может подключиться, если включен режим расширенной безопасности.

Причина

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

Решение

Чтобы устранить эту проблему, установите check Point VPN E80.50 (ожидается, что она будет доступна осенью 2013 г.) на следующем веб-сайте Центра поддержки контрольных точек:

Обходной путь

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

Чтобы решить эту проблему, запустите следующий Windows PowerShell, чтобы изменить скрытое свойство для виртуального сетевого интерфейса в реестре:

Этот сценарий также задокументирован на следующем веб-сайте Check Point: Microsoft Store (Windows приложение не удается связаться с помощью VPN-туннеля.

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

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

Источник

Современные приложения не могут подключаться при использовании VPN-подключения Check Point

В этой статье данная статья позволяет решить проблему, из-за которой современные приложения не могут подключаться к Интернету после подключения к корпоративной сети с помощью VPN-программного обеспечения Check Point.

Применяется к: Windows 8
Исходный номер КБ: 2855849

Симптомы

Рассмотрим следующий сценарий.

• Вы используете версию VPN удаленного доступа к конечным точкам Check Point, которая является более ранней, чем E80.50.
• Успешно запущены Windows 8 (Store Apps) и классические настольные приложения.
• Подключение к корпоративной сети с помощью клиентского программного обеспечения Check Point VPN в «концентраторном режиме» (то есть весь трафик проходит через виртуальный сетевой адаптер).
• После подключения индикатор состояния сети показывает, что подключение к Интернету полностью доступно.

В этом сценарии классические приложения могут успешно подключаться к Интернету. Однако современные приложения не могут подключаться. Кроме того, компьютерная версия Windows Internet Explorer 10 не может подключиться, если включен режим расширенной безопасности.

Причина

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

Решение

Чтобы устранить эту проблему, установите check Point VPN E80.50 (ожидается, что она будет доступна осенью 2013 г.) на следующем веб-сайте Центра поддержки контрольных точек:

Обходной путь

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

Чтобы решить эту проблему, запустите следующий Windows PowerShell, чтобы изменить скрытое свойство для виртуального сетевого интерфейса в реестре:

Этот сценарий также задокументирован на следующем веб-сайте Check Point: Microsoft Store (Windows приложение не удается связаться с помощью VPN-туннеля.

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

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

Источник

Решение проблемы «Connectivity with the Check Point Endpoint Security Service is lost» в Check Point Endpoint Security VPN

Уже не первый раз сталкиваюсь с проблемой «Connectivity with the Check Point Endpoint Security Service is lost» после установки Check Point Endpoint Security VPN.

Выглядит ошибка «Connectivity with the Check Point Endpoint Security Service is lost» следующим образом:

В попытках решить данную проблему можно наткнуться на несколько советов:

В данном примере советуют открыть список установленных приложений и попытаться запустить «Repair». Но очень вероятно мы получим ошибку «The installer has insufficient privileges to modify this file: C:WINDOWSSysWOW64vsdata.dll» (vsdata.dll, vsutil.dll и vsinit.dll):

В данном случае нам рекомендуют переименовать библиотеку vsdata.dll. Но и переименовать мы ее не сможем, поскольку получим: «Запросите разрешение от СИСТЕМА на изменение этой папки или файла». И как на зло, даже инструкция по смене владельца файла не помогает.

Теоретически, можно загрузиться с какого-нибудь Live CD и сменить имя библиотекам «vsdata.dll, vsinit.dll, vsutil.dll».

4. И, наконец, способ, который помог мне.

Чудом наткнулся на патч, который решает проблему «Connectivity with the Check Point Endpoint Security Service is lost» — https://supportcenter.checkpoint.com/supportcenter/portal?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=111732.

Если помогло и вам, благодарности принимаю в комментариях :).

Источник

Пользователи VPN-сервиса Check Point столкнулись с проблемами из-за просроченного сертификата

Компания предупреждала о наличии патча, исправляющего проблему, еще в августе 2019 года.

Примечательно, что компания предупреждала о наличии патча, исправляющего проблему, еще в августе 2019 года, но, судя по всему, некоторые клиенты Check Point пропустили сообщение или не смогли применить исправление из-за политик организаций.

На прошлой неделе компания выпустила еще одно уведомление, в котором предупредила, что решения Endpoint/VPN E80.81 — E81.10 (только версия для Windows ) и агент SandBlast E80.61 — E81.10 (только версия для Windows) перестанут нормально работать с 1 января 2021 года.

«Эти более не поддерживаемые решения прекратят функционировать 1 января 2021 года. Начиная с этой даты, после перезагрузки компьютера, версии клиента Remote Access VPN and Endpoint Security Client E81.10 и ниже могут перестать работать, а обновиться не получится», — предупредила компания.

Как рассказал изданию The Register один из читателей, работающий в правительственной организации, из-за истекшего срока действия сертификата примерно 1 600 ноутбуков, выделенных сотрудникам, не смогли подключиться к сети. Предлагаемый Check Point патч заменяет .SYS файл без задействования администратора, что запрещено правилами организации, пояснил источник.

В свою очередь, представители Check Point сообщили изданию, что начали информировать пользователей устаревших версий о проблеме еще до нового года. Сколько клиентов уже применили патч, в компании не сообщили.

Источник

Checkpoint проблемы с подключением

Full Member Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору Народ. Есть проблема. Есть CheckPoint и. как его настраивать никто не знает. В сети нигде описалова конкретного нет. Может кто помогёт личным опытом. или может кто кинет линку на доки (желательно по русски) по этому зверю.
Заранее спасибо.

Добавляете, плиз, полезную информацию в шапку.

Цитата:

CheckPoitn встает под Linux нормально. Я даже по Solaris ставил

Есть кое-какие доки на Ftp из варезной темы.. Всего записей: 525 | Зарегистр. 02-07-2002 | Отправлено: 18:55 09-07-2002 | Исправлено: Out, 18:06 15-08-2006

Необходимое для начала

•  Аккаунт в Яндексе (он же у Вас есть, верно?)
•  Настроенный Home Assistant, с подключенным внешним IP и ssl на домене, или настроенным dDNS (я использую duckdns.org). Описывать первоначальную настройку HA я не буду, здесь на sprut.ai написано об этом (и немного больше) уже очень много.

Сам процесс настройки подключения сервисов

Для начала необходимо создать новый каталог с именем «custom_components» , если у Вас его нет (как у меня ранее), путь ~/.homeassistant/custom_directory/ или ~/config/custom_components/ в зависимости от места и версии HA).

Далее нужно склонировать туда гит, на котором вся система и работает — GitHub (все лайки именно туда, писал его не я) или же создать вручную папку yandex_smart_home и туда скопировать файлы из архива, которые были скачаны из гитхаба оттуда.

git clone https://github.com/dmitry-k/yandex_smart_home.git

Далее прописываем в configuration.yaml этот самый компонент:

• как я, просто добавляем в конце файла «yandex_smart_home:» (без кавычек, конечно);
• или же «курим» расширенный мануал от создателя компонента этого: ReadMe.

После, проверяем, на всякий случай, конфигурацию в настройках, и перезагружаем HA.

После этого уже переходим на сам процесс подключения всего, что сделали, в Умный дом Яндекса:

•  Создаём Навык Умный Дом на https://dialogs.yandex.ru/developer/  (Очень важно создавать навык именно залогинившись с того аккаунта, в котором будем будем устройства использовать в Яндексе).

•  Заполняем все поля, отмеченные звездочкой.

Не закрываем страничку и переходим пока на https://dialogs.yandex.ru/developer/settings/oauth , где добавляем новую связку аккаунтов:

НазваниеИдентификатор приложения/Client identifier : https://social.yandex.net/Секрет приложения/Client Password (без него сохранить не получилось связку, но в итоге она из неё сама удалилась. Я вписал туда стандартный, видимо, пароль из файла secrets.yaml. Может можно вообще что угодно вписать, или этот «секрет» где-то настраивается и это важно — но я об этом не знаю хD): passwordURL авторизации/API authorization endpoint: https://[внешний_адрес_сервера_HA:порт]/auth/authorizeURL для получения токена/Token Endpoint: https://[внешний_адрес_сервера_HA:порт]/auth/tokenURL для обновления токена/Refreshing an Access Token: https://[внешний_адрес_сервера_HA:порт]/auth/token

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

По сути все: осталось в приложении Яндекс на Android/iOS или на ПК в браузере  добавить нашего нового «производителя». Покажу на примере мобильного приложения.

И все доступные устройства из HA добавляются в список устройств.
Надписей красным цветом и восклицательных знаков не пугаемся: необходимо лишь переназвать каждое устройство, используя «кириллицу, без пунктуации и спецсимволов; между словами и числами ставьте пробелы«.

На данный момент поддерживаются только вот эти domains в HA:

• group (on/off)
• input_boolean (on/off)
• switch (on/off)
• fan (on/off)
• light (on/off)
• cover (on/off)
• media_player (on/off, mute/unmute)

В дальнейшем будет также добавлена возможность проброса из Home Assistant в Яндекс:

• поддержка громкости в media_player;
• яркость/цвет ламп;
• скорость увлажнителя/вентилятора.

На этом все, мы вместе смогли подключить те устройства, которые «нативно» не поддерживаются пока в Умном Доме Яндекс.
Кроме того, это позволяет избежать возможных лагов из-за cloud-2-cloud системы, когда Яндекс обращается в облако производителя, который обращается в облако подключенного к нему производителя, который…. — и все они лагают =)
Остаются, по сути, только Ваш сервер, за который Вы и в ответе, и облако самого Яндекса, куда все и интегрируется.

Текст составлен с неоценимой помощью @OXOTH1K , а также всего сообщества, которые и двигают весь прогресс на основе «ступенек» от компаний, подобных Яндексу.

Прямое подключение

Только для продвинутых пользователей!

Для использования прямого подключения вы самостоятельно создаёте приватный навык в Яндекс.Диалогах,
который будет напрямую подключаться к вашему Home Assistant (не используя навык Yaha Cloud).

Предварительные требования¶

• Доступность Home Assistant из интернета по доменному имени используя белый IP адрес или
  сторонние сервисы: Dataplicity, KeenDNS.
• Настроенный HTTPS сертификат. При наличии белого IP адреса можно воспользоваться официальным аддоном Let’s Encrypt.
  При использовании Dataplicity или KeenDNS HTTPS настраивается автоматически. Самоподписанные сертификаты работать не будут.
• Добавленная интеграция Yandex Smart Home в режиме прямого подключения.

Настройка¶

• Установите компонент и добавьте интеграцию используя прямой тип подключения
• Проверьте доступность HA из интернета и корректность настройки компонента

• Зайдите на dialogs.yandex.ru и создайте диалог (навык) с типом «Умный дом».
  Желательно это делать из под аккаунта, который планируется использовать для управления умным домом.
  При необходимости доступ к навыку можно предоставить другим пользователям Яндекса (вкладка Доступ).

  

• Заполните параметры (вкладка Настройки):

Поле	Значение
Название	Любое (например Home Assistant)
Backend	Endpoint URL: https://[YOUR_HA_DOMAIN:PORT]/api/yandex_smart_home (пример: https://XXXX.dataplicity.io/api/yandex_smart_home)
Тип доступа	Приватный
Подзаголовок	Любой
Имя разработчика	Любое
Официальный навык	Нет
Описание	Любое
Иконка	Любая (например эта)

• Заполните параметры (вкладка Связка аккаунтов):

Поле	Значение
Идентификатор приложения	https://social.yandex.net/
Секрет приложения	Любой, например: secret
URL авторизации	https://[YOUR_HA_DOMAIN:PORT]/auth/authorize
URL для получения токена	https://[YOUR_HA_DOMAIN:PORT]/auth/token
URL для обновления токена	https://[YOUR_HA_DOMAIN:PORT]/auth/token

• На вкладке Настройки обязательно нажмите Опубликовать (для приватных навыков публикация автоматическая и моментальная).
  В этот момент УДЯ попробует подключиться к вашему Home Assistant, и если у него не получится — появятся ошибки валидации.

Не используйте навык в режиме «Черновик», это может вызывать различные проблемы (дубли уcтройств, ошибки в нотификаторе)

При публикации навыка в журнале Home Assistant возникает ошибка Login attempt or request with invalid authentication. Это нормально и не влияет на работу компонента.

• Откройте квазар или приложение Дом с Алисой
• Нажмите иконку в правом верхнем углу → Устройство умного дома
• Найдите в списке и выберите производителя (ищите по названию диалога, который создали ранее)
• Нажмите кнопку Привязать к Яндексу, откроется страница авторизации Home Assistant. Рекомендуется создать отдельного пользователя
  специально для УДЯ и авторизоваться под ним. В этом случае в журнале событий будет видно, когда устройством управлял Яндекс.
• Настройте отправку уведомлений об изменении состояний устройств

Уведомления об изменении состояний устройств¶

Для уведомления УДЯ об актуальном состоянии устройств и датчиков необходимо выполнить настройку службы notifier (нотификатор).

Если этого не сделать, вас ждёт ряд проблем:

1. УДЯ будет узнавать актуальное состояние только при входе в устройство или обновлении страницы
2. Для датчиков не будет отображаться история изменений и графики, бинарные датчики работать не будут
3. Устройства будет невозможно использовать в сценариях УДЯ в качестве условий
4. Непредсказуемое поведение команд вида «Алиса, вентилятор» (без указания что именно нужно сделать)

Для настройки понадобятся:

• oauth_token: Получить по этой ссылке. Для получения правильного токена вы должны войти в Яндекс с аккаунта, на котором был создан навык
• skill_id: Идентификатор диалога на вкладке Общие сведения в консоли Яндекс.Диалогов
• user_id: ID пользователя в Home Assistant под которым выполнялась авторизация при связке аккаунтов,
  посмотреть в Настройки → Люди → Пользователи → (выбрать пользователя) → ID (для видимости раздела включите Расширенный режим в профиле пользователя):

• Добавьте в YAML конфигурацию:

  configration.yaml

  yandex_smart_home:
    notifier:
      # xxx замените реальными значениями
      - oauth_token: XXXXXXXXXXXXXXXXXXXXXXXXXXX
        skill_id: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
        user_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  
      # Если в диалоге авторизовано несколько пользователей Home Assistant или
      # к одному Home Assistant подключено несколько навыков - на каждое сочетание
      # диалог/пользователь_HA нужно добавить отдельные записи:
      - oauth_token: XXXXXXXXXXXXXXXXXXXXXXXXXXX  # запрашивается с аккаунта владельца диалога, в котором авторизован user_id
        skill_id: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
        user_id: yyyyyyyyyyyyyyyyyyyyyyyyyyyy
  

• Перезагрузите YAML конфигурацию

• Выполните Обновление списка устройств

Проблемы¶

Яндекс не может достучаться до Home Assistant¶

1. Проверьте доступность Home Assistant из интернета через сервис httpstatus.io:

   • Вставьте ссылку https://YOUR_HA_DOMAIN:PORT/api/yandex_smart_home/v1.0/ping и нажмите Check status. По этой ссылке должно возвращаться OK: количество_устройств_отдаваемых_в_УДЯ
   • Убедитесь, что возвращается код 200 (столбец Status codes)

   • Если возвращается 404:

     1. Компонент Yandex Smart Home не установлен
     2. Интеграция Yandex Smart Home не добавлена
     3. В настройках интеграции выбрано облачное подключение

   • Если возвращаются другие ошибки — нажмите на стрелку слева от ссылки, чтобы узнать подробнее. Пример ошибки некорректной настройки SSL сертификата:

   

2. Если сертификат настраивался вручную: убедитесь, что используется fullchain сертификат
   (в случае штатного аддона Let’s Encrypt он в файле fullchain.cer):

   http:
     ssl_certificate: /config/acme.sh/YOUR_HA_DOMAIN/fullchain.cer
     ssl_key: /config/acme.sh/YOUR_HA_DOMAIN/YOUR_HA_DOMAIN.key
   

3. Если DNS запись добавлялась вручную: убедитесь, что у используемого домена нет AAAA записи (должна быть только A).

Появляются дубли устройств¶

Скорее всего часть устройств были добавлены в Черновик навыка.
Удалите их оттуда вручную через dialogs.yandex.ru/developer (вкладка Тестирование).

Ошибки при публикации навыка¶

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

Превышено время ожидания ответа¶

Если Home Assistant доступен из интернета, но публикация навыка даёт ошибку Превышено время ожидания ответа,
скорее всего проблема в неработающем (или частично работающем) DNSе внутри контейнера Home Assistant.

Такое иногда встречается на NAS (например QNAP). Для исправления:

• Зайдите внутрь контейнера Home Assistant: docker exec -it homeassistant sh
• Укажите DNS сервер Яндекса: echo nameserver 77.88.8.8 > /etc/resolv.conf

Исправление актуально только для публикации навыка и не требуется для обычной работы УДЯ.

Другая причина возникновения проблемы — использование Яндекс.DNS с фильтрацией.
Попробуйте отключить фильтрацию, если вы её используете.

URL не найден¶

Возможные причины:

1. Некорректно задан Endpoint URL в настройках навыка
2. Компонент Yandex Smart Home не установлен
3. Интеграция Yandex Smart Home не добавлена
4. В настройках интеграции выбрано облачное подключение

Внутренная ошибка навыка¶

Обычно возникает из-за проблем в разрешении IP-адреса из имени.
По состоянию на конец октября 2021 замечено, что без видимой причины могут не работать домены *.tplinkdns.com (попробуйте использовать другой динамический DNS).

Ошибка [401] Unauthorized¶

Полный текст ошибки: Failed to send state notification: [401] b'Unauthorizedn'

Возникает из-за неверного OAuth токена в параметре oauth_token в настройках нотификатора.

Для исправления: замените oauth_token на актуальный, получить его можно по этой ссылке.

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

---

---

---