> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/user/ru/guide/account/iot-logic/nodes/output-endpoint-node.md).
# Выходная точка
## Технический обзор и возможности
{% columns %}
{% column %}
**узла Output Endpoint** служит компонентом передачи данных в потоках IoT Logic, определяя, куда отправляются обработанные данные устройства. Его основная функция — приводить разнородные данные устройств к единообразному формату перед передачей во внешние системы или сервисы. Все данные передаются в унифицированном формате, что обеспечивается [Navixy Generic Protocol](/docs/iot-logic-api/technologies/navixy-generic-protocol.md).
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
Подробнее о формате, в котором передаются данные, см. [Формат выходных данных](#output-data-format).
### Интеграция в архитектуру потока
Один поток IoT Logic может содержать несколько выходных узлов, каждый со своей независимой конфигурацией. Такая архитектура обеспечивает:
* Передачу данных в несколько пунктов назначения в разные внешние системы одновременно
* Обработку нескольких источников данных с разными входящими форматами данных
* Выборочную маршрутизацию данных, обеспечивающую гибкие сценарии потока данных
{% hint style="info" %}
Каждый поток должен включать **Точке выхода по умолчанию** узел для отправки данных на платформу Navixy. Сохраняйте соединения между вашими **Источник данных** узлами и этим выходом. Соединение гарантирует, что данные устройства отправляются на платформу, обеспечивая возможности мониторинга с помощью инструментов Navixy. Если выход Navixy будет удалён, данные с устройств, участвующих в потоке, больше не будут поступать на платформу.
{% endhint %}
### Возможности узла
Отчёт **Выходная точка** Сам по себе узел предоставляет:
* **Безопасная передача**: Реализует шифрование SSL и механизмы аутентификации для защиты данных при передаче
* **Настраиваемое обеспечение доставки**: Предоставляет выбор уровня QoS MQTT для баланса между гарантией доставки и сетевыми накладными расходами
* **Повторное использование конфигурации**: Поддерживает создание профилей конечных точек, которые можно повторно использовать в нескольких потоках, обеспечивая согласованность конфигурации
* **Параллельная обработка**: Принимает входные данные из нескольких источников в рамках потока, позволяя осуществлять объединённую передачу данных
* **Выбор версии транспортного протокола**: Поддерживает как MQTT 3.1.1, так и 5.0 для совместимости с различными реализациями брокеров
## Параметры настройки
{% columns %}
{% column valign="middle" %}
Настройка **узлу конечной точки вывода** определяет, как и куда будут доставляться данные из конкретного потока. Каждый параметр конфигурации служит определённой цели в обеспечении надёжной передачи данных.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
Давайте посмотрим, какие элементы использует этот узел и что можно настроить при работе с ним:
### Шаги настройки
{% stepper %}
{% step %}
**Укажите имя конечной точки**
Введите уникальное, описательное имя для этой конфигурации конечной точки
* Используйте имя, которое поможет вам определить получатель, куда отправляются данные
* Это имя будет отображаться на схеме потока для удобства идентификации
{% endstep %}
{% step %}
**Выберите режим конечной точки**
Выберите, какой тип передачи использовать для этой конечной точки
* **Конечная точка по умолчанию** - стандартная конфигурация для отправки данных потока на платформу Navixy, которую нельзя редактировать
* **Конечная точка MQTT** - пользовательская конфигурация, использующая MQTT в качестве транспортного протокола для отправки данных потока в сторонние системы. Для конкретных параметров конфигурации этого режима см. [MQTT](#mqtt).
{% endstep %}
{% step %}
**Сохраните конфигурацию**
Нажмите **Примените изменения** чтобы завершить создание узла.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Убедитесь, что вы подключили соответствующие узлы данных к новому выходу; иначе он не будет получать никаких данных.
{% endhint %}
### Конфигурации, зависящие от режима
MQTT
Если вы планируете использовать MQTT-выход, вам необходимо настроить следующие параметры:
1. **Настройки конечной точки**
1. Выберите **Версия MQTT**: 3.1.1 или 5.0.
2. Введите целевой **IP** в формате: *123.123.123.123* или *example.example.com*.
3. Укажите **Порт** номер. По умолчанию, *1883* используется для стандартного MQTT.
4. Укажите **Тема** в виде тегов, которые будут использоваться для передачи данных.
5. Выберите **QoS** уровень, который определяет логику передачи данных:
1. **QoS 0** — без подтверждения доставки.
2. **QoS 1** — гарантированная доставка с возможным дублированием.
3. **QoS 2** — гарантированная доставка без дублирования.
6. Введите **ID клиента MQTT**. На стороне получателя имеется фиксированный список клиентов. В этом поле необходимо указать правильное значение, чтобы данные не были отклонены.
2. **Аутентификация MQTT** (необязательно)
1. Переключите **Использовать аутентификацию** в положение «Вкл.».
2. Введите **Имя пользователя MQTT** и **Пароль MQTT** для принимающей стороны в появившихся полях.
3. **SSL** (необязательно)
1. Переведите в положение «Вкл.» **Использовать SSL** для защищённых соединений. Это действие автоматически устанавливает порт на 1*883* если он не был изменён вручную.
## Формат выходных данных
Основная функция узла — стандартизация формата данных посредством [Navixy Generic Protocol](/docs/iot-logic-api/technologies/navixy-generic-protocol.md). Эта стандартизация решает фундаментальную проблему в реализациях IoT — разнообразие протоколов, специфичных для устройств, которые требуют индивидуальной интеграционной работы.
Обычно каждый тип устройства использует собственный формат данных, что требует отдельных обработчиков протоколов на принимающих системах. По мере расширения парка устройств такой подход экспоненциально увеличивает затраты на разработку и сопровождение. IoT Logic решает эту проблему, нормализуя все данные устройств в стандартизированную JSON-структуру, независимо от исходного производителя или протокола.
Отчёт [Navixy Generic Protocol](/docs/iot-logic-api/technologies/navixy-generic-protocol.md) спецификация включает стандартизированные поля для идентификации устройства, данных о местоположении, значений телеметрии и метаданных. Этот формат поддерживает двустороннюю связь, позволяя как передавать данные из IoT Logic во внешние системы, так и импортировать данные из внешних источников на платформу.
Реализуя один протокол, **Выходная точка** узел обеспечивает:
* Единую схему интеграции для принимающих систем вместо нескольких обработчиков, специфичных для устройств
* Единообразную структуру данных, которая остаётся одинаковой для всех подключённых устройств
* Снижение нагрузки на обработку на стороне сервера за счёт нормализации протокола
* Упрощённое масштабирование при добавлении новых типов устройств в существующие развёртывания
* Возможности двустороннего обмена данными с внешними системами
Узел реализует MQTT в качестве транспортного протокола для этой стандартизированной JSON-нагрузки, обеспечивая надёжный и лёгкий механизм передачи, подходящий для развёртываний IoT.
## Часто задаваемые вопросы
#### Можно ли подключить несколько источников данных к одному узлу выходной конечной точки?
Да. **Выходная точка** узел принимает входные данные от нескольких **Источник данных** узлов одновременно. Все обработанные данные, включая координаты местоположения, идентификаторы устройств, параметры телеметрии и вычисленные атрибуты, сериализуются в соответствии со [Navixy Generic Protocol](/docs/iot-logic-api/technologies/navixy-generic-protocol.md) спецификацией перед передачей.
#### Что произойдёт, если я изменю конечную точку, которая используется в нескольких потоках?
Конфигурации конечных точек хранятся как повторно используемые ресурсы во всей учётной записи клиента. Изменения существующей конфигурации конечной точки повлияют на все узлы, ссылающиеся на эту конечную точку, во всех потоках. Такое поведение облегчает стандартизацию конфигурации, но требует тщательного управления изменениями при обновлении параметров конечной точки.
#### Какие практики безопасности рекомендуются для производственных развёртываний?
Для реализаций, требующих высоких стандартов безопасности (здравоохранение, финансовая сфера и т. д.), включите SSL и реализуйте аутентификацию MQTT. Хотя это немного увеличивает накладные расходы протокола, оно обеспечивает необходимую защиту данных при передаче. В стандартных реализациях следует использовать как минимум уровень QoS 1, чтобы обеспечить подтверждение доставки.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://navixy.com/docs/user/ru/guide/account/iot-logic/nodes/output-endpoint-node.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.