Анализ логов контейнеров RiCoder
Для анализа ситуации, при которой события не доходят до ПЦН, нужно просмотреть логи следующих контейнеров:
- chop_deploy-eqgateway-1 — прием, обработка, передача событий от Ri-HUB в очередь.
- chop_deploy-surgard-1 — прием событий из очереди, сопоставление кодам ADEMCO , передача в ПЦН.
1. Где находятся логи контейнера?
1.1. В Docker Desktop
1. Откройте Docker Desktop.
2. Перейдите на вкладку Сontainers.
3. Выберите нужный контейнер.
4. Выберите вкладку Logs.
Экран Docker: Вкладка Logs
1.2. В консоли (для Linux / Windows)
1. В консоли введите команду для просмотра логов конкретного контейнера.
docker logs <имя_контейнера>где <имя_контейнера> - имя нужного контейнера:
- chop_deploy-surgard-1
- chop_deploy-eqgateway-1
Команда вернёт все доступные логи, начиная с момента запуска контейнера.
Если контейнер остановлен, его логи остаются доступны — они не удаляются автоматически при остановке.
Полезные команды для удобного просмотра логов:
# Просмотр логов в реальном времени
docker logs -f <имя_контейнера>2. Структура лога
Пример:
2025-12-11T10:52:38.412Z DEBUG [eqserver] (eqgateway/client_service.go:61) try to find the client in the backend service: id:212 {"addr": "217.66.157.83:30962"}Здесь:
- Дата и время в формате ISO 8601 (`2025-12-11T10:52:38.412Z`), Z - нулевой часовой пояс, .412Z - миллисекунды;
- Уровень важности: `ERROR`, `WARN`, `INFO`, `DEBUG`;
- Источник лога: "[eqserver] (eqgateway/client_service.go:61)" - контейнер eqgqteway и соответствующая функция обработки;
- Сообщение об ошибке или информационное сообщение;
- Контекст: "{“adr”:“217.66.157.83:26127”}" - адрес подключения.
Время в логах указано по Гринвичу - UTC+0.
Логи контейнера пишутся часто при каждому событии, связанным с подключенными центрами управления (Ri-HUB) к RiCoder. Для точной идентификации сообщений, относящихся к конкретному устройству, используйте идентификатор ClientID, который присвоен каждому Ri-HUB.
Где посмотреть идентификатор Ri-HUB (ClientID) в интерфейсе?
ClientID - идентификатор Ri-HUB.
1. В веб-панели RiCoder откройте раздел Объекты.
2. Вариант 1. Столбец Контроллер в списке домов отображает ClientID.
3. Вариант 2. В адресной строке браузера в конце строки указан номер - ClientID.
Экран RiCoder: Объекты
3. Логи контейнера eqgateway-1
В разделе описаны типовые сценарии работы контейнера eqgateway-1 отвечающего за приём и трансляцию событий от центра управления Ri-HUB в ПО RiCoder. Описаны нормальные режимы работы и возможные сбои связи — с указанием причин, статусов в интерфейсе и поведения системы при восстановлении.
3.1. Получение тестовых сообщений от Ri-HUB
Контейнер eqgateway-1 успешно принимает тестовое сообщение от Ri-HUB, соединение между Ri-HUB и RiCoder установлено, состояние Ri-HUB в веб-панели RiCoder - Активен. Нормальная работа автотеста связи между Ri-HUB и RiCoder.
Таблица с расшифровкой текста логов
№ | Время | Текст строки лога | Что означает? |
1 | 2025-12-11T10:51:38 | ПОЛУЧЕН ПАКЕТ packetID: 1731 ClientID: 170 | Контейнер получил какой-то пакет от Ri-HUB (170). packetID - идентификатор пакета, формируется в Ri-HUB ClientID - идентификатор Ri-HUB. Посмотреть ClientID в интерфейсе. |
2 | 2025-12-11T10:51:38 | Сбрасываем таймер | Сразу сбрасывается таймер контроля связи между Ri-HUB (170) и RiCoder. Таймер сбрасывается всегда, когда приходит любой пакет (PacketType: 0 или 2). Таймер сбрасывается у конкретного соединения. Для каждого канала Channel предусмотрен отдельный таймер. Работа таймера 1. Пришел пакет с PacketType: 0 -> сброс таймера 2. Пришел пакет с PacketType: 2 -> сброс таймера 3. Нет пакетов с PacketType: 0 или 2 в установленный период -> сброс таймера -> статус в UI “Не активен” |
3 | 2025-12-11T10:51:38.788Z | Пришел пакет ClientID: 170, PacketType: 0, Channel: 2 | Контейнер идентифицировал, что от Ri-HUB (170) пришло тестовое сообщение по каналу GPS. PacketType 0 - проверка связи 2 - сообщение, любое кроме проверки связи Других значений нет, либо 0, либо 2. Channel 2 - SIM 3 – WI-FI / Ethernet Других значений нет, либо 2, либо 3. |
Скриншот лога
3.2. Установка/обновление соединения с Ri-HUB
Контейнер успешно устанавливает соединение с Ri-HUB, состояние Ri-HUB в веб-панели RiCoder - Активен. Соединение зарегистрировано, Ri-HUB получает право на обмен сообщениями c RiCoder. Нормальная работа при установке соединения.
Таблица с расшифровкой текста логов
Сообщения об аутентификации выводятся одновременно и отображаются группой из 4-х строк.
№ | Время | Текст строки лога | Что означает? |
1 | 2025-12-11T10:52:38.412Z | ПОЛУЧЕН ПАКЕТ packet ID: 873 ClientID: 212 | Контейнер получил какой-то пакет от Ri-HUB (212). packetID - идентификатор пакета, формируется в Ri-HUB ClientID - идентификатор Ri-HUB. Посмотреть ClientID в интерфейсе. Доставлен пакет от Ri-HUB. |
2 | 2025-12-11T10:52:38.412Z | try to find the client in the backend service: id:212 | Функция котейнера пытается найти запись о Ri-HUB c id 212. |
3 | 2025-12-11T10:52:38.421Z | save or update client in active clients: id:212 | Cоединение успешно установлено и зарегистрировано. |
4 | 2025-12-11T10:52:38.421Z | authentication: client_id:212, channel:map[] | Запуск процедуры аутентификации.
channel:map[] - канал связи еще не назначен. |
5 | 2025-12-11T10:52:38.421Z | successful client authentication | Аутентификация Ri-HUB пройдена успешно. |
Если аутентификация не пройдена и соединение не установлено, то после 4-ой строки не будет никаких сообщений от Ri-HUB (id: 212) каналу SIM (2). Возможно, придут сообщения по каналу Wi-Fi/Ethernet (3), если произошло переключение каналов в Ri-HUB.
Скриншот лога
3.3. Ri-HUB давно не выходил на связь
Контейнер eqgateway-1 фиксирует отсутствие связи с Ri-HUB: таймаут контроля связи превышен, Ri-HUB давно не выходил на связь. Состояние Ri-HUB в веб-панели RiCoder - не Активен. Соединение разорвано, канал SIM переведён во внутреннее состояние "оффлайн".
- Таймаут отправки события о разрыве (7.0.1)
- Таймаут отправки события о восстановлении (7.0.0)
Посмотреть настройки таймаутов в интерфейсе.
Таблица с расшифровкой текста логов
№ | Время | Текст строки лога | Что означает? |
1 | 2025-12-11T10:51:38 | Пришел пакет ClientID: 170, PacketType: 0, Channel: 2 | Контейнер получил последний пакет с тестовым сообщением от Ri-HUB (170) по каналу SIM. Контроль наличия связи. |
2 | 2025-12-11T10:52:38 | Отправляем дисконнект | Сработал таймер - превышено время таймаута. Пакеты с типом PacketType: 0 не приходили больше 1 минуты. Таймаут отправки события о разрыве (7.0.1) в UI установлен 60 сек для Ri-HUB (170). Происходит отправка статуса в функцию контейнера eqgateway. |
3 | 2025-12-11T10:52:38 | Меняем статус на оффлайн | Изменение статуса в функции контейнера eqgateway. |
4 | 2025-12-11T10:52:38 | Channel 0x2 of client 170 is temporary offline | Отправлены пуш-уведомления в МП и в веб-панель RiCoder о том, что Ri-HUB оффлайн по SIM каналу. |
5 | 2025-12-11T10:52:38 | setting client 170 channel 2 status to offline | Обновление внутреннего статуса канала 2 (SIM) у Ri-HUB (id: 170) на "оффлайн" в функции управления подключениями. |
Скриншот логов
3.4. Не удалось установить соединение с Ri-HUB по одному из каналов связи
Контейнер eqgateway-1 получил пакет от Ri-HUB по каналу SIM, но соединение аварийно разорвалось: удалённая сторона сбросила TCP-соединение. Состояние Ri-HUB в веб-панели RiCoder может временно измениться на не Активен, однако это не ошибка системы — соединение может восстановиться автоматически.
Таблица с расшифровкой текста логов по каналу SIM
№ | Время | Текст строки лога | Что означает? |
1 | 2025-12-11 10:52:51 | ПОЛУЧЕН ПАКЕТ packetID: 875 ClientID: 212 | Контейнер получил какой-то пакет от Ri-HUB (212). |
2 | 2025-12-11 10:53:01 | Сбрасываем таймер | Сразу сбрасывается таймер контроля связи между Ri-HUB (212) и RiCoder. |
3 | 2025-12-11 10:53:01 | Пришел пакет ClientID: 212, PacketType: 0, Channel: 2 | Контейнер идентифицировал, что от Ri-HUB (212) пришло тестовое сообщение по каналу SIM. |
4 | 2025-12-11 10:53:01 | unpack err: read tcp 172.18.0.7:10003 -> 217.66.157.83:26127: read connection reset by peer | Разрыв удаленного соединения. Удаленная сторона (IP: 217.66.157.83) аварийно разорвала TCP-соединение в тот момент, когда функция внутри контейнера eqgateway (IP 172.18.0.7) пыталась прочитать данные из установленного ранее соединения. |
5 | 2025-12-11 10:53:01 | network error while reading (expected), by client: 212 err: read tcp 172.18.0.7:10003 -> 217.66.157.83:26127: read connection reset by peer | Информационное сообщение от контейнера о разрыве соединения. Это не ошибка RiCoder. Иногда соединение может разорваться, но потом восстановивается.
Если соединение может в течение периода контроля связи восстановиться, соединиться заново, то это никак не повлияет на работу трансляции. |
Скриншот логов
3.5. Переключение каналов связи с SIM на Wi-Fi
Контейнер eqgateway-1 фиксирует переключение Ri-HUB с канала SIM на Wi-Fi — приходят пакеты по обоим каналам, таймеры сбрасываются. Состояние Ri-HUB в веб-панели RiCoder остаётся — Активен. Контейнер корректно обрабатывает смену канала связи.
Таблица с расшифровкой текста логов
№ | Время | Текст строки лога | Что означает? | Канал |
1 | 2025-12-11 10:52:05 | ПОЛУЧЕН ПАКЕТ packetID: 867 ClientID: 212 | Контейнер получил какой-то пакет от Ri-HUB (212). | SIM |
2 | 2025-12-11 10:52:05 | Сбрасываем таймер | Cбрасывается таймер контроля связи между Ri-HUB (212) и RiCoder. | SIM |
3 | 2025-12-11 10:52:05 | Пришел пакет ClientID: 212, PacketType: 0, Channel: 2 | Контейнер идентифицировал, что от Ri-HUB (212) пришло тестовое сообщение по каналу SIM. | SIM |
В Ri-HUB произошло подключение | к Wi-Fi и отключение по каналу SIM. | |||
4 | 2025-12-11 10:52:27 | ПОЛУЧЕН ПАКЕТ packetID: 867 ClientID: 212 | Контейнер получил какой-то пакет от Ri-HUB (212). | Wi-Fi |
5 | 2025-12-11 10:53:27.398Z | Сбрасываем таймер | Сразу сбрасывается таймер контроля связи между Ri-HUB (212) и RiCoder. | Wi-Fi |
6 | 2025-12-11 10:53:27.399Z | Пришел пакет ClientID: 212, PacketType: 0, Channel: 2 | Контейнер идентифицировал, что от Ri-HUB (212) пришло тестовое сообщение по каналу Wi-Fi. | Wi-Fi |
7 | 2025-12-11 10:52:51 | ПОЛУЧЕН ПАКЕТ packetID: 875 ClientID: 212 | Контейнер получил какой-то пакет от Ri-HUB (212). | SIM |
8 | 2025-12-11 10:52:51.317Z | Сбрасываем таймер | Сразу сбрасывается таймер контроля связи между Ri-HUB (212) и RiCoder. | SIM |
9 | 2025-12-11 10:52:51 | Пришел пакет ClientID: 212, PacketType: 0, Channel: 2 | Контейнер идентифицировал, что от Ri-HUB (212) пришло тестовое сообщение по каналу SIM. | SIM |
10 | 2025-12-11 10:53:01.377Z | unpack err: read tcp 172.18.0.7:10003 -> 217.66.157.83:26127: read connection reset by peer | Разрыв удаленного соединения. | SIM |
11 | 2025-12-11 10:53:01.378Z | network error while reading (expected), by client: 212 err: read tcp 172.18.0.7:10003 -> 217.66.157.83:26127: read connection reset by peer | Информационное сообщение от контейнера о разрыве соединения для Ri-HUB (212) по каналу SIM. | SIM |
Скриншот логов
3.6. Получение сообщения с данными от Ri-HUB
Контейнер eqgateway-1 успешно принимает пакет с данными от Ri-HUB по одному из каналов связи, соединение активно, состояние в веб-панели RiCoder — Активен. Пакет расшифрован и передан в очередь обработки для дальнейшей трансляции в контейнер surgard-1. Нормальная работа при передаче событий от Ri-HUB.
Таблица с расшифровкой текста логов
№ | Время | Текст строки лога | Что означает? |
1 | 2025-12-11 10:53:01 | ПОЛУЧЕН ПАКЕТ packetID: 1073741918 ClientID: 170 | packetID - идентификатор пакета, формируется в Ri-HUB ClientID - идентификатор Ri-HUB. Посмотреть ClientID в интерфейсе. Доставлен пакет от Ri-HUB. |
2 | 2025-12-11 10:53:01 | Сбрасываем таймер | Сразу сбрасывается таймер контроля связи между Ri-HUB (212) и RiCoder. |
3 | 2025-12-11 10:53:01 | Пришел пакет ClientID: 170, PacketType: 2, Channel: 3 | Пришел пакет по каналу wi-fi. |
4 | 2025-12-11 10:53:01 | New data message. Packet ID: 1073741918, magic: 228. Message: rpcprotocol.MessageEventECP{ClientID:0х7397, Time: 0х693aa28c, Code:0x70101, Address:0x0, SubAddress:0x0, Channel:0x0, Params:[]uint8(nil)} | Преобразование пакета из бинарного формата в текстовый. MessageEventECP - формируется в Ri-HUB |
5 | 2025-12-11 10:53:01 | Отправляем пакет с messageID: 29591 | Пакет расшифрован в eqgatteway и отправлен в очередь сообщений, контейнер rabbitmq-1 |
Скриншот логов
3.7. Анализ потери событий по Message ID
Message ID - это порядковый номер сообщения, присвоенный Ri-HUB при его отправке. Каждое сообщение от устройства имеет свой уникальный идентификатор, который позволяет отслеживать последовательность передачи.
С помощью Message ID можно:
- Определить, какие именно сообщения не дошли до контейнера eqgateway-1. Например, если в последовательности есть пропуски.
- Выявить задержки или потери данных на этапе передачи.
Пример:
Были получены сообщения с Message ID: 100, 101, затем 104.
Это означает, что сообщения 102 и 103 не были доставлены.
Такая ситуация может возникнуть, если:
- Сообщения задержались в очереди внутри Ri-HUB;
- Потерялись при передаче между устройством и контейнером eqgateway;
- Задержались в очереди обработки внутри контейнера.
4. Логи контейнера surgard-1
4.1. Нормальная работа
Контейнер surgard-1 успешно принимает и обрабатывает сообщение из очереди сообщений (контейнер rabbitmq-1), шифрует и отправляет в ПЦН. Связь между RiCoder и ПЦН подтверждена, состояние сервера ПЦН в веб-панели RiCoder - Соединение установлено.
Условия нормальной работы трансляции событий:
1. Отправка тестовых сообщений с сервера ПЦН выполняется через заданные промежутки времени. Нет долгих промежутков между сообщениями - свыше установленного времени. Пункт 1 и 7 в таблице ниже.
Экран RiCoder: Трансляции - значение периода контроля связи
2. Выполнена последовательность действий почти одновременно. Пункты 2 - 6 в таблице ниже.
Прием сообщения от eqgateway -> кодирование RiDom/Ademco -> отправка в ПЦН -> уведомление о доставке.
Таблица с расшифровкой текста логов нормальной работы
№ | Время | Текст строки лога | Что означает? |
1 | 2025-12-11T11:33:34.30.658Z | ping id 53 translation 80.246.243.36:14403 passed! Time: 2025-12-11 11:34:30 | Контроль наличия связи с ПЦН. id - номер трансляции translation - внешний IP-адрес и порт сервера ПЦН |
2 | 2025-12-11T11:33:35.01.866Z | Принято сообщение с MessageID: 29593 | Принято сообщения от eqgateway. MessageID - какое по счету сообщение ушло с хаба с момента первого подключения. |
3 | 2025-12-11T11:33:35.01.866Z | Начинается обработка сообщения Started processing message for client 170, event: 67840, packetID: 29593 | Процесс сопоставления кодов RiDom -> Ademco. |
4 | 2025-12-11T11:33:35.01.877Z | Сообщение обработано Parcel details received - consumerClientID: 53, clientID: 170, event: 67840, packetID: 29593, name: Закрыт корпус центра управления | Процесс сопоставления кодов окончен успешно. packetID - пакет ушедший с RiHUB clientID - номер RiHUB consumerClientID - номер трансляции |
5 | 2025-12-11T11:33:35.02.156Z | Отправляем сообщение Sending event by timer. Buffer length: 1 {"consumerClientID": 53, "address": "80.246.243.36:14403"} | Отправка сообщения в ПЦН. address - внешний IP-адрес и порт сервера ПЦН |
6 | 2025-12-11T11:33:35.02.161Z | Сообщение доставлено! Message delivered! 21 bytes send, 1 bytes received, ответ от АРМа answer: [6] {"consumerClientID": 53, "address": "80.246.243.36:14403"} | Сообщение доставлено успешно. ХХ bytes send - отправлено ХХ байт 1 bytes received - получен ответ |
7 | 2025-12-11T11:33:35.46.657Z | ping id 53 translation 80.246.243.36:14403 passed! Time: 2025-12-11 11:35:46 | Контроль наличия связи с ПЦН через 46 сек. |
Скриншот лога
4.2. Восстановление соединения с ПЦН
Контейнер surgard-1 успешно восстанавливает соединение с сервером ПЦН после его отключения — все накопленные события из очереди переданы. Статус соединения с сервером ПЦН в веб-панели RiCoder - Соединение установлено. Трансляция событий возобновлена без потерь.
Условия корректного восстановления трансляции событий:
- Пришло сообщение, о том что соединение с сервером ПЦН восстановлено
- В АРМ ПЦН Пришли все недоставленные события, накопленные за время недоступности сервера ПЦН.
- События из eqgateway передаются через очередь ( контейнер rabbitmq-chop-1) в нормальном режиме.
- Пинг (период контроля наличия связи) сервера ПЦН, выполняется через заданные промежутки времени.
Как происходит восстановление?
1. В лог приходит сообщение, о том что соединение с сервером ПЦН восстановлено:
INFO ... Surgard connection established {"consumerClientID": 53, "address": "80.246.243.36:14403"}2. Начинают идти события из таблицы Troublesend, которые не могли дойти до сервера ПЦН, когда он был недоступен.
Troublesend – таблица не доставленных событий в ПЦН.
Если нет соединения с сервером ПЦН, но события были получены с RiHUB в контейнер eqgateway-1, обработаны и переданы в контейнер surgard-1, но не были переданы в ПЦН, то события записываются в таблицу Troublesend.
3. После передачи всех событий из таблицы Troublesend передаются события из очереди (контейнер rabbitmq-chop-1), поступившие с Ri-HUB(ов). Аналогично п. 2 Ситуация 1
4. Нормальный процесс работы трансляции восстановлен. После отправки всех событий в очереди, в лог приходят сообщения о контроле связи.
ping id 53 translation 80.246.243.36:14403 passed! Time: 2025-12-11 11:34:30Скриншот лога
Таблица с расшифровкой текста логов после восстановления связи
№ | Признак, RU | Что означает? |
1 | Surgard connection established {"consumerClientID": 53, "address": "80.246.243.36:14403"} | Соединение с сервером ПЦН восстановлено. address - внешний IP-адрес и порт сервера ПЦН consumerClientID - номер трансляции |
2 | Сообщение доставлено! Message delivered! 21 bytes send, 1 bytes received, ответ от АРМа answer: [6] {"consumerClientID": 54, "address": "80.246.243.36:14403"} | Сообщение доставлено успешно. ХХ bytes send - отправлено ХХ байт 1 bytes received - получен ответ |
3 | Начинается обработка сообщения Started processing message for client 170, event: 459009, packetID: FromTS {"consumerClientID": 53, "address": "80.246.243.36:14403"} | client - номер RiHUB event - ? packetID: From TS - признак того, что сообщения передано в АРМ из таблицы Troublesend. |
4 | Сообщение обработано Parcel details received - consumerClientID: 53, clientID: 170, event: 459009, packetID: FromTS {"consumerClientID": 53, "address": "80.246.243.36:14403"} | Процесс сопоставления кодов окончен успешно. packetID - пакет ушедший с RiHUB clientID - номер RiHUB consumerClientID - номер трансляции |
5 | Отправляем сообщение Sending event by timer. Buffer length: 1 {"consumerClientID": 53, "address": "80.246.243.36:14403"} | Отправка сообщения в ПЦН. address - внешний IP-адрес и порт сервера ПЦН |
6 | Сообщение доставлено! Message delivered! 21 bytes send, 1 bytes received, ответ от АРМа answer: [6] {"consumerClientID": 53, "address": "80.246.243.36:14403"} | Сообщение доставлено успешно. ХХ bytes send - отправлено ХХ байт 1 bytes received - получен ответ |
В логах нет информации, что доставлено конкретное сообщение, например с номером event: 459009. Можно понять, что доставлены все сообщения только по сумме сообщений. Если сумма обработанных событий совпадает с суммой доставленных событий, значит вся таблица troublesend была передана. Нужна ли в логах детальная информация какой id сообщения был доставлен?
client 170 в строке 3 немного не сопоставляется с ClientID. Кажется, что это другая сущность.
Если RiCoder будет недоступен (UI, какой-то конкретный контейнер, все контейнеры) вместо признака From TS, будет признак From RiDom. События с Ri-HUB будут записываться в RiCloud и не были потеряны. Очень редкая ситуация. Тимур
Признак корректной работы трансляции - номера сообщений MessageID с конкретного RiHUB следуют один за другим. Например: MessageID: 29593, 29594, 29595, 29596, видно, что сообщения приходят по очереди - нормальная работа.
4.3. Нет соединения с ПЦН
Контейнер surgard-1 не может отправить данные на сервер ПЦН — соединение разорвано, в логах появляются ошибки уровня ERROR. Статус соединения с сервером ПЦН в веб-панели RiCoder - Ошибка подключения, события не транслируются.
Описание сообщений об ошибках
Текст ошибки | Что означает? | Причина |
Cannot send event TCP packet: ... write: broken pipe: | Неудачная попытка записать данные в TCP-соединение, организованное с сервером ПЦН. | Сервер ПЦН выключен, завис, перегружен. |
sending ping packet error: | Попытка отправить служебный пакет для проверки связи, но обнаружено, что сервер уже закрыл соединение. Требуется переподключение. | Ошибка прикладного уровня. Отправка служебного пакета инициирована компонентом контейнера. Команда ping не является ICMP-пингом. |
Failed to retry initialize consumer client (ХХХ): | Внутренний компонент контейнера (consumer client) не смог повторно установить соединение с ПЦН даже после нескольких попыток. | Ошибка прикладного уровня. |
Устранение неисправностей
Если возникла любая ошибка, описанная в таблице выше или все сразу, то необходимо:
1. Проверить доступность удалённого сервера ПЦН с помощью команд в консоли:
# Зайти в контейнер
docker exec -it <имя_контейнера> sh
# Попробовать подключиться к порту (!не ping)
nc -zv X.X.X.X XXXXX
# или
telnet X.X.X.X XXXXX2. Узнать у службы поддержки сервера ПЦН, стабилен ли сервер и не завершает ли он долгие соединения.
3. Дождаться установки соединения с сервером ПЦН.
Когда соединение с ПЦН установлено, в логе отображается сообщение и запускается процесс передачи не переданных событий из таблицы Troublesend. Подробнее ...
INFO ... Surgard connection established {"consumerClientID": XX, "address": "X.X.X.X:XXXXX"}Если сервер ПЦН работает корректно, то необходимо проверить сетевые настройки в веб-панели RiCoder для сервера ПЦН. Подробнее в статье.
Дата обновления: 23.12.2025