> 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).
# Узел передачи данных
Узел передачи данных передает обработанные данные устройств из потоков IoT Logic внешним системам с помощью Navixy Generic Protocol для стандартизированной доставки данных.
## Технический обзор и возможности
{% columns %}
{% column %}
**Узел передачи данных** служит компонентом передачи данных в потоках 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. Введите **Идентификатор клиента 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://navixy.com/docs/user/ru/guide/account/iot-logic/nodes/output-endpoint-node.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
