> 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/data-source-node.md).
# Источник данных
Узел «Источник данных» — это точка входа IoT Logic для телеметрии устройства. Он получает данные по TCP, UDP, HTTP или MQTT, декодирует их и передает в последующие узлы. Он также может обогащать уже подключенный
## Технический обзор и возможности
{% columns %}
{% column %}
**Источник данных** Узел — это точка входа для телематических данных от IoT-устройств и OEM-платформ в системе IoT Logic. Он действует как универсальный преобразователь, получая данные по протоколам TCP/UDP/HTTP через сетевые интерфейсы и очереди MQTT, а затем декодируя входящие потоки данных в соответствии с выбранным протоколом. Узел преобразует сообщения устройств в стандартизированный формат, который можно далее обработать в вашем потоке.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
Помимо получения телеметрии, **Источник данных** Узел также может обогащать устройство, которое вы уже добавили в него. Внешняя система, например отдельная телематическая платформа, которая по умолчанию не отправляет данные в Navixy, передаёт дополнительные атрибуты в поток устройства. Иногда такой внешней платформой является собственная платформа производителя устройства. Вместо переноса устройства на встроенный приём данных Navixy **Программное обеспечение** вкладка сохраняет его зарегистрированным без изменений. Она непрерывно обогащает поток устройства данными с другой платформы, поэтому оба потока работают параллельно. См. [Как обрабатываются передаваемые данные](#how-pushed-data-is-handled) для получения сведений о механике работы и [Параметры конфигурации](#configuration-options) для настройки.
### Интеграция архитектуры потока
**Узел «Источник данных»** служит точкой входа для данных в потоке IoT Logic. Один поток может содержать несколько исходных узлов, каждый с независимой конфигурацией. Эта архитектура обеспечивает:
* Первичный сбор данных от устройств различных типов и в различных форматах протоколов
* Стандартизированное преобразование данных от различных производителей в унифицированные форматы
* Параллельные пути обработки при подключении одного источника данных к нескольким последующим узлам
* Выборочная фильтрация устройств для включения в поток только релевантных источников данных
* Обогащение потока уже подключённых устройств с помощью атрибутов, передаваемых внешней системой по HTTP
### Возможности узла
Этот **Узел «Источник данных»** сам по себе предоставляет:
* **Разнообразие протоколов**: Поддерживает устройства нескольких производителей, включая Teltonika, Queclink, Suntech, Jimi и других, с помощью унаследованных от Navixy парсеров и декодеров
* **Гибкость транспорта**: Поддерживает протоколы TCP, UDP, HTTP и подключения к брокеру MQTT
* **Унифицированное преобразование данных**: Преобразует сообщения, специфичные для устройств, в стандартизированный формат для согласованной обработки
* **Фильтрация устройств**: Предоставляет возможности фильтрации для выбора определённых моделей или протоколов
* **Обработка в реальном времени**: Обрабатывает входящие потоки телематических данных в реальном времени для немедленной обработки
* **Обогащение через HTTP push**: Объединяет атрибуты, передаваемые из внешней системы, с потоком устройства, уже выбранного в этом узле. В настоящее время HTTP — единственный поддерживаемый тип push, однако архитектура рассчитана на поддержку других типов в будущем
## Параметры конфигурации
{% columns %}
{% column width="58.333333333333336%" valign="middle" %}
Настройка **Источник данных** Узел определяет, какие устройства отправляют данные в ваш поток и, при необходимости, каким образом внешняя система может обогащать эти устройства передаваемыми данными.
Диалог настройки разделён на две вкладки:
* **Устройства**: позволяет выбрать устройства, отправляющие телеметрию в поток. Обязательна и работает так же, как раньше.
* **Программное обеспечение**: настраивает обогащение через HTTP push для устройств, выбранных на вкладке «Устройства». Необязательна и зависит от этого выбора.
{% endcolumn %}
{% column width="41.666666666666664%" %}
{% endcolumn %}
{% endcolumns %}
{% hint style="info" %}
Этот **Программное обеспечение** вкладка зависит от вкладки **Устройства** . Её **Исходное устройство** в списке выбора отображаются только устройства, уже выбранные в **Устройства**, и данные не отображаются, пока вы не выберете там хотя бы одно устройство.
{% endhint %}
Посмотрим, какие элементы использует этот узел и что можно настроить при работе с ним:
### Шаги настройки
{% stepper %}
{% step %}
#### Укажите имя узла
Введите понятное имя для этого источника данных:
* Используйте имя, которое поможет определить производителя, модели или другую релевантную информацию.
* Это имя будет отображаться на схеме потока для удобной идентификации.
{% endstep %}
{% step %}
#### Выберите источники
В отфильтрованном списке выберите устройства, которые необходимо включить. Для выбора доступны только устройства, зарегистрированные в вашей учётной записи Navixy. Этот выбор также является обязательным условием для необязательной вкладки **Программное обеспечение** , в которой можно сопоставить только выбранные здесь устройства.
{% endstep %}
{% step %}
#### Сохраните конфигурацию узла
Нажмите **Применить изменения** для завершения создания узла.
{% endstep %}
{% step %}
#### Настройте обогащение через HTTP push (необязательно)
Перейдите на вкладку **Программное обеспечение** вкладку, чтобы обогатить выбранные в разделе Devices устройства данными, передаваемыми из внешней системы. Этот шаг необязателен. См. [Настройка обогащения через HTTP push](#configuring-http-push-enrichment) для полной настройки.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Если вы измените настройки производителя или модели после выбора устройств, Navixy уведомит вас, если какие-либо выбранные устройства не соответствуют новым параметрам, но не удалит их автоматически из выбранных.
{% endhint %}
### Настройка обогащения через HTTP push
Обогащение через HTTP push позволяет внешней системе добавлять атрибуты к устройству, уже выбранному в этой узле's **Устройства** вкладке, отправляя данные на сгенерированный URL. Это необязательно и требует, чтобы сначала было выбрано как минимум одно устройство под [Шаги настройки](#configuration-steps) сначала.
Это полезно, когда устройство уже передает данные в отдельную систему, которая по умолчанию не передает данные в Navixy, например на платформу управления батареями, отслеживающую заряд батареи этого же автомобиля. Вместо того чтобы переносить устройство на нативный прием данных Navixy, вы можете оставить его зарегистрированным как есть и позволить этой другой платформе отправлять сюда свои показания. Push-запрос с `vehicle_id: "truck_12"`, `bms_battery_soc: 76`, и `bms_battery_temp: 34.2` добавляет `bms_battery_soc` и `bms_battery_temp` как новые атрибуты на сопоставленном устройстве вместе с его собственной GPS-телеметрией.
{% stepper %}
{% step %}
#### Задайте тип коннектора
Перейдите на вкладку **Программное обеспечение** вкладку и установите **Тип коннектора** на **HTTP**, на данный момент это единственный вариант.
{% endstep %}
{% step %}
#### Сохраните поток и скопируйте сгенерированный URL
Сохраните весь поток, а не только этот узел. Поле **URL** URL генерирует значение только после сохранения потока с **Тип коннектора** заданным параметром. До тех пор отображается заполнитель с просьбой сохранить поток. Когда URL появится, нажмите значок копирования рядом с ним; он отключен только пока поле пусто.
{% endstep %}
{% step %}
#### Аутентификация внешней системы
Предоставьте внешней системе действительный [ключ API Navixy](/docs/user/ru/guide/account/api-keys.md), и настройте ее на отправку `Authorization: NVX ` с каждым push-запросом вместе с URL. Запрос без этого заголовка завершится ошибкой, поэтому до поступления данных нужны и URL, и заголовок.
{% endstep %}
{% step %}
#### Определите первичный ключ и сопоставления
Введите **Первичный ключ**— имя поля, которое внешняя система использует для определения, какому устройству принадлежит отправленная запись. Допускает до 64 символов: только буквы, цифры и символы подчёркивания.
Добавьте по одной **строке сопоставления** на каждое устройство, которое нужно обогатить. Для каждой строки выберите **Исходное устройство**, доступное только для устройств, уже выбранных в разделе Devices, и введите **Значение ключа** которое идентифицирует это устройство во входящих push-запросах. Это поле хранит до 255 символов, но сама конечная точка push принимает не более 100 символов на поле, поэтому на практике держите значение значительно короче 100 символов.
{% hint style="warning" %}
И Primary key, и Key value принимают только буквы, цифры и символы подчёркивания — без дефисов и другой пунктуации. Общая проверка полей на конечной точке push более либеральна и допускает дефисы в любом поле без предупреждения, но значение с дефисом никогда не совпадет с сохраненным значением ключа, поэтому push-запросы с таким значением молча отбрасываются точно так же, как если бы значение не совпадало. Если идентификаторы вашей внешней системы используют дефисы (например `truck-12`), преобразуйте их, например в `truck_12`, перед отправкой.
{% endhint %}
{% endstep %}
{% step %}
#### Примените и сохраните
Нажмите **Применить изменения**, а затем снова сохраните поток, если вы настроили вкладку Software после первого сохранения.
{% endstep %}
{% endstepper %}
### Особенности обработки данных
**узел источника данных** наследует все парсеры и декодеры от Navixy, обеспечивая совместимость с широким спектром IoT-устройств. Когда данные поступают в этот узел, они проходят следующий процесс:
1. Входящий поток данных принимается по указанному транспортному протоколу
2. Данные передаются соответствующему декодеру протокола в соответствии с вашей конфигурацией
3. Сообщения устройства преобразуются в стандартизированный формат, который IoT Logic может обрабатывать
4. Сводные данные передаются в следующий узел в вашем потоке
Этот процесс стандартизации позволяет выстраивать единообразные потоки обработки независимо от исходного формата данных у различных производителей устройств.
### Как обрабатываются передаваемые данные
Navixy сопоставляет каждое входящее push-уведомление по значению его первичного ключа с настроенной у узла **строке сопоставления**затем объединяет оставшиеся поля в поток данных сопоставленного устройства в виде атрибутов: новыми, если имя поля новое, или записывает их в существующую историю этого атрибута, если имя совпадает с уже существующим, независимо от того, получено ли оно напрямую от устройства или передано коннектором другого потока. Они не влияют на местоположение или другую телеметрию. Поле, указанное в **Первичный ключ**, вместе с `поток_id` и `узел_id`, используется для маршрутизации и никогда не становится самим атрибутом. Запрос может оказаться в одном из трёх состояний:
| Результат | HTTP-ответ | Данные объединены? |
| ------------------------------------------------------------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| Значение первичного ключа соответствует сопоставлению | 200, `успех: true` | Да. Остальные поля объединяются как атрибуты: новые — если имя новое, существующая история — если оно совпадает с уже используемым |
| Значение первичного ключа не соответствует ни одному сопоставлению | 200, `успех: true` | Нет. Отбрасывается без уведомления |
| Отсутствует или некорректно `Authorization` заголовок | ошибка 400 | Нет. Отклоняется до того, как Navixy проверит первичный ключ |
{% hint style="info" %}
Ответ 200 лишь подтверждает, что Navixy приняла запрос, но не то, что данные были объединены. Значение первичного ключа, не совпадающее с ожидаемым, отбрасывается без уведомления и без ошибки. Если вы не уверены, что пуш был сопоставлен, проверьте атрибуты сопоставленного устройства в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md) вместо того чтобы полагаться на ответ.
{% endhint %}
{% hint style="warning" %}
Имя отправляемого поля использует одно пространство имен с собственными встроенными атрибутами устройства и с именами, отправленными коннектором другого потока, который обогащает то же устройство. Если имя совпадает с уже используемым — нативным для устройства или отправленным другим потоком, — пуш перезаписывает существующую историю этого атрибута вместо создания отдельной.
Датчики, Отчеты и Контроль событий считывают объединенное значение как реальное показание, поэтому совпадающее имя может привести к появлению ложных данных далее по цепочке. Например, отправляемое поле с именем `уровень топлива` совпадающее со встроенным атрибутом топлива устройства, будет подставлять ложное показание, создавая ложные события падения уровня топлива или заправки в отчетах.
Чтобы избежать этого, добавляйте префикс к именам отправляемых полей, чтобы они не могли конфликтовать со встроенными атрибутами устройства или именами, отправляемыми другим потоком, например `bms_battery_soc` вместо `уровень заряда аккумулятора`.
Поля системных сообщений, такие как `скорость`, `широта`, `долгота`, `курс`, `спутники`, и `hdop` не может быть перезаписано таким способом. Пуши всегда лишь создают или обновляют атрибуты, но никогда не телеметрию на уровне сообщения. Поле, переданное с одним из этих имён, по-прежнему отображается под этим именем в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md)отдельно от фактической телеметрии устройства.
{% endhint %}
Объединённый атрибут попадает в историю атрибутов устройства как запись на определённый момент времени, а не как закреплённое текущее значение. Если устройство отправляет собственную телеметрию гораздо чаще, чем внешняя система передаёт обновления, собственные пакеты устройства могут за считаные секунды продвинуть историю атрибута дальше переданного значения, даже если объединение прошло успешно.
{% hint style="info" %}
Это ожидаемое следствие работы двух потоков данных с разной скоростью, а не дефект. В последующей обработке обращайтесь к атрибуту как к `value('attribute_name', 0, 'valid')` вместо его простого имени. `'valid'` просматривает историю атрибута назад до последнего значения, отличного от null, поэтому последующие узлы получают переданное значение независимо от времени. См. [Отсутствующие значения и маршрутизация null](/docs/user/ru/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) о том, как `'valid'` сравнивается с `'все'` в условии узла Logic.
{% endhint %}
Конечная точка push принимает не более 1 запроса в секунду на каждый ключ API, с размером всплеска 1. Настройте частоту запросов внешней системы соответствующим образом.
## Часто задаваемые вопросы
#### Можно ли использовать несколько узлов Источник данных в одном потоке?
Да, вы можете использовать несколько **узлов Источник данных** в одном рабочем пространстве. Это полезно, когда нужно обрабатывать данные от устройств разных типов по-разному или объединять несколько потоков данных после определенных преобразований.
#### Что происходит, если устройство уже используется в другом потоке?
Устройство может одновременно принадлежать нескольким потокам. Если вы добавите устройство, которое уже используется в другом потоке, оба потока будут одновременно обрабатывать его данные, а результаты будут объединены, чтобы избежать потери данных. Назначение устройству другого потока не является ограничением. Однако если коннекторы двух потоков передают на это устройство одно и то же имя атрибута, они не объединяются без последствий. История одного push перезаписывает историю другого. См. [Как обрабатываются передаваемые данные](#how-pushed-data-is-handled) чтобы избежать конфликтов имен.
#### Все ли мои устройства Navixy автоматически доступны в IoT Logic?
Да, все устройства из вашей учетной записи Navixy могут использоваться в обработке IoT Logic. Это включает GPS-устройства, OEM-платформы, MQTT-устройства и шлюзы, а также коннекторы MQTT/Kafka. Устройство, уже выбранное в **Источник данных** узле, также может быть дополнено атрибутами, переданными из внешней системы по HTTP, через **Программное обеспечение** .
#### Как понять, какого производителя выбрать для моих устройств?
Протокол должен соответствовать протоколу связи, используемому производителем ваших устройств. Большинство устройств используют протокол, связанный с их производителем (например, устройства Teltonika используют протокол Teltonika). Проверьте документацию на устройство или обратитесь к поставщику устройства, если вы не уверены.
#### Можно ли подключить узел Источник данных к нескольким нижестоящим узлам?
Да, вы можете подключить **Узел «Источник данных»** к нескольким узлам обработки, чтобы создать параллельные пути обработки. Это позволяет применять разные преобразования к одному и тому же потоку данных. Вот пример:
#### Можно ли получать данные из системы, которая не является устройством Navixy?
Да, через **Программное обеспечение** вкладку, но только чтобы дополнить устройство, которое вы уже добавили в **Устройства** вкладке. Это не способ создать поток без устройств.
#### Система, из которой я отправляю данные, сообщает их реже, чем мое устройство; потеряются ли переданные данные?
Нет, но переданный атрибут может быстро перестать быть текущим значением, если устройство передает данные намного чаще, поскольку оба источника используют одну и ту же скользящую историю. Ссылайтесь на атрибут ниже по потоку как `value('attribute_name', 0, 'valid')` вместо его простого имени, чтобы надежно получать последнее фактическое показание независимо от времени. Это ожидаемое следствие работы двух потоков с разной скоростью, а не дефект. См. [Как обрабатываются передаваемые данные](#how-pushed-data-is-handled) и [Отсутствующие значения и маршрутизация null](/docs/user/ru/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) для `'valid'` и `'все'` различия в условии узла Logic.
#### Я передал данные, но они не отображаются. Что не так?
Проверьте это по порядку:
1. Убедитесь, что запрос содержал действительный `Authorization: NVX ` заголовок. Отсутствие или недействительность заголовка приводит к явной ошибке HTTP 400.
2. Убедитесь, что имя передаваемого поля точно совпадает с **Первичный ключ** настройкой узла, и что его значение точно совпадает с одним из настроенных **строке сопоставления** точно; только буквы, цифры и символы подчеркивания. Значение с дефисом — самая частая причина: оно проходит собственную проверку конечной точки push без ошибок, но никогда не сможет совпасть с сохраненным значением Key, поэтому запрос все равно возвращает успех, хотя ничего не объединяется.
3. Проверьте историю атрибута в Анализ данных, а не только его текущее значение. Устройство, которое часто передает собственную телеметрию, может за несколько секунд вытеснить объединенное значение из текущей ячейки, даже если объединение прошло успешно.
#### Я передал поле, и собственные показания устройства выглядят неверно
Скорее всего, имя переданного поля совпало с встроенным атрибутом, который устройство уже передает, или с атрибутом, переданным коннектором другого потока, и перезаписало его историю вместо создания отдельного атрибута. Переименуйте переданное поле, добавив уникальный префикс, затем проверьте историю атрибута в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md) чтобы убедиться, что переданные и встроенные значения больше не смешиваются.
---
# 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, and the optional `goal` query parameter:
```
GET https://navixy.com/docs/user/ru/guide/account/iot-logic/nodes/data-source-node.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
.png?alt=media)
