Здравствуйте!

Тестируем IPVideoRecord на распознавание номеров. Хотим интегрировать с БД 1С.

Из документации не совсем понятно в каком виде вписывать адрес внешнего сервера в соответствующее поле. В виде просто IP или FQDN или же в виде запроса http://IP_сервера:порт/some-path/ ?

В нашем случае БД 1С на вебсервере отвечает на запросы по URL http://IP_сервера:порт/some-path/

Спасибо!

Добрый день!

Можно указать просто адрес без протокола, будет добавлено http://. То есть так: IP_сервера:порт/some-path
По поводу пути после адреса, можно указать любой путь, к нему просто добавится строка вида ?plate=H877TA18&camid=Nzli...NDU3&direction=1. И будет отправлен GET запрос.

Спасибо!
Не смог найти в логах (сервер на Debian 10) никаких записей по запросам/ответам от внешнего сервера 1С.
Подобные логи ведутся на сервере?
Как понять, что после распознавания номера запрос на разрешение проезда производится на внешнем сервере?
Нужно для отладки

Посмотрите в логе медиасервера. Сделайте поиск по названию функции: "NumberPlate::HttpCheckPlaneNumber"

К сожалению, в логе нет ни единой записи, содержащей такой набор символов

Как же понять (не имея на этапе тестирования ни одного исполняющего устройства), что программа принимает ответ от нашей 1С корректно?

Да, Вы правы - нашли ошибку, из-за которой запрос не передаётся в лог. Если хотите его посмотреть - то либо сделайте это при помощи сетевого снифера (wireshark, например), либо посмотрите логи веб-сервера 1С - если на него приходят запросы, то он их зафиксирует. Ошибку исправим в следующем релизе, и можно будет смотреть в логах.

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

То, что запрос от ПО приходит, видим в логах веб-сервера. Ответы логируем средствами 1С. Все, как будто, корректно.
Однако, в самом ПО, в "Текущие номера" и "Общий отчет" по-прежнему распознанные номера (все подряд) идут как "Не в списке". Даже те из них, на которые был получен ответ от внешнего сервера:
listtype=2
isallowaccess=1

Смотрите вложенный скриншот.

Поэтому и возникает вопрос - как понять, что ПО верно идентифицирует ответ внешнего сервера и, условно, поднимает шлагбаум?

Проверьте следующие моменты:
1. Возможно, ответы приходят в несколько неверном формате? Попробуйте в браузере выполнить запрос и покажите, какой выводится ответ от сервера.
2. Покажите, созданы ли у вас какие-то списки доступа и типы доступа (типы есть только в 3-й версии ПО)?

1. Ответ в IE от 1С на скрине.
2. Списки в самом ПО не формировал

Какая у Вас версия ПО?

Версия сервера 3.3.4.491 (на Debian 10)
Клиент на Windows 10 - версия 2.3.17.467

\\Честно говоря, не знаю, почему клиент устаревший. Наверное, поставил по невнимательности. Это может влиять?

Создайте в программе тип доступа с ID=2 (у вас такой возвращается в ответе listtype). Но для этого сперва обновите клиент, во второй версии не было типов доступа.

Обновился.
Сделал три типа доступа.
Теперь колонка "Список" просто пустая. Хотя машины проезжали из, как минимум, двух типов

Собрали отладочную версию. Прошу Вас сделать так:
1. Скачать и обновить IPVR: https://sprecord.ru/files/downloads/vid ... .2.495.exe
2. Включить отладочные логи в настройках (см. скрин).
3. Прогнать несколько машин, чтобы зафиксировать запросы и ответы сервера.
4. Выгрузить логи и прислать нам (см. скрин) - support@sprecord.ru

Сделал. Логи отправил. Спасибо

Из-за того, что в ответе ожидается простой текст, разделенный переносом строки, неверно парсится ответ. И в поле type_id=<br>listtype=0<br>isallowaccess=0 записывается вся строка.

Нужно отправить в ответе просто текст с переводом строки: listtype=0\nisallowaccess=0

Внесли изменения в конфигурацию 1С. Сделал новые логи и выслал почтой. Посмотрите пожалуйста.

Вы передаёте символ \n между параметрами, и он не преобразуется в перевод строки, а передаётся как есть. Смысл в том, что нужно передать 2 строки, разделённые переводом. Не знаю, как это сделать на языке Вашего сервера, который посылает ответ, но в других языках программирования есть спецсимволы, которые его формируют. Если мы на языке С создадим строку "listtype=0\nisallowaccess=0", то компилятор её преобразует в
"listtype=0
isallowaccess=0"
То есть заменит \n на перевод строки. Вам надо найти что-то подобное, чтобы в ответ нашему серверу уходили строки, разделённые переводом.

Спасибо за помощь - наконец-то получилось. Теперь ПО корректно проверяет ГРЗ в БД 1С.

Однако, есть еще вопрос по этой теме.
По логам 1С обнаружил, что с момента распознавания номера в ПО до запроса к 1С проходит 4-5 секунд. Оба сервера синхронизируют время в одном и том же источнике и расхождение в локальном времени исключены.
Ранее, когда на сервере было 2 камеры, грешил на загрузку ЦПУ. Сейчас для ВМ, в которой крутится сервер, выделено очень много ресурса по ЦПУ и ОЗУ, для теста заведена только одна камера.
load average: 1,16, 1,22, 1,29

Это так и задумано? Или же есть смысл искать причину такой задержки в запросе?

Для более надёжного распознавания программа ждёт получения нескольких кадров с одним номером, затем производит слияние (т.к. на разных кадрах некоторые символы в номере могут отличаться из-за ошибок). После слияния получается некий наиболее вероятный результат, который и отправляется в запросе на Ваш сервер 1С. А в базу данных программы IPVR при этом фиксируется время прихода самого первого кадра с данным номером. Думаю, что задержка связана именно с этим, то есть можно сказать, что так задумано. Чем меньше частота кадров на камере и чем больше настроено кадров для фиксации (см. скриншот), тем больше может быть время задержки. Соответственно, чтобы его уменьшить, можно попробовать увеличить FPS камеры или уменьшить кол-во кадров в условии занесения номера в БД в настройках.