> 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, **Software** вкладка оставляет его зарегистрированным как есть. Она постоянно обогащает поток устройства данными с другой платформы, поэтому оба потока работают параллельно. См. [Как обрабатываются данные, переданные push-методом](#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" %}
Настройка **Источник данных** Узел определяет, какие устройства отправляют данные в ваш поток, и, при необходимости, как внешняя система может обогащать эти устройства передаваемыми данными.
Диалог настройки состоит из двух вкладок:
* **Устройства**: выбирает, какие устройства отправляют телеметрию в поток. Обязательно, и работает точно так же, как раньше.
* **Software**: настраивает обогащение через HTTP push для устройств, выбранных вами на вкладке Devices. Необязательно и зависит от этого выбора.
{% endcolumn %}
{% column width="41.666666666666664%" %}
{% endcolumn %}
{% endcolumns %}
{% hint style="info" %}
Вкладка **Software** вкладка зависит от **Устройства** вкладки. Ее **Исходное устройство** селектор отображает только устройства, уже выбранные в **Устройства**, и не показывает доступных данных, пока вы не выберете там хотя бы одно.
{% endhint %}
Рассмотрим, какие элементы использует этот узел и что можно настроить при работе с ним:
### Шаги настройки
{% stepper %}
{% step %}
#### Укажите имя узла
Введите описательное имя для этого источника данных:
* Используйте имя, которое поможет вам определить производителя, модели или другую релевантную информацию.
* Это имя будет отображаться на схеме потока для удобства идентификации.
{% endstep %}
{% step %}
#### Выберите источники
Из отфильтрованного списка выберите устройства для включения. Для выбора доступны только устройства, зарегистрированные в вашей учетной записи Navixy. Этот выбор также является обязательным условием для необязательной **Software** вкладки, которая может сопоставлять только выбранные здесь устройства.
{% endstep %}
{% step %}
#### Сохраните конфигурацию узла
Нажмите **Примените изменения** чтобы завершить создание узла.
{% endstep %}
{% step %}
#### Настройте обогащение через HTTP push (необязательно)
Переключитесь на **Software** вкладку, чтобы обогатить выбранные вами в Devices устройства данными, переданными внешней системой. Этот шаг необязателен. См. [Настройка обогащения через HTTP push](#configuring-http-push-enrichment) для полной настройки.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Если вы измените настройки производителя или модели после выбора устройств, Navixy уведомит вас, если какие-либо выбранные устройства не будут соответствовать новым параметрам, но не удалит их автоматически из вашего выбора.
{% endhint %}
### Настройка обогащения через HTTP push
Обогащение через HTTP push позволяет внешней системе добавлять атрибуты к устройству, уже выбранному на **Устройства** вкладке этого узла, отправляя данные на сгенерированный 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 %}
#### Задайте тип коннектора
Переключитесь на **Software** вкладку и установите **Тип коннектора** в **HTTP**, пока единственный вариант.
{% endstep %}
{% step %}
#### Сохраните поток и скопируйте сгенерированный URL
Сохраните весь поток, а не только этот узел. The **URL** поле генерирует значение только после того, как поток сохранён с **Тип коннектора** заданным. До тех пор оно показывает заполнитель с подсказкой сохранить поток. Когда URL появится, нажмите значок копирования рядом с ним; он отключён только пока поле пустое.
{% endstep %}
{% step %}
#### Аутентифицируйте внешнюю систему
Предоставьте внешней системе действительный [ключ API Navixy](/docs/user/ru/guide/account/api-keys.md)и настройте ее на отправку `Authorization: NVX ` с каждым push-запросом вместе с URL. Push без этого заголовка завершится ошибкой, поэтому до получения данных требуются и URL, и заголовок.
{% endstep %}
{% step %}
#### Определите первичный ключ и сопоставления
Введите **Первичный ключ**: имя поля, которое внешняя система использует для определения, какому устройству принадлежит передаваемая запись. Допускается до 64 символов, только буквы, цифры и символы подчёркивания.
Добавьте одну **Сопоставления** строку на устройство, которое нужно обогатить. Для каждой строки выберите **Исходное устройство**, ограничено устройствами, уже выбранными в разделе «Устройства», и введите **Значение ключа** которое идентифицирует это устройство во входящих push-запросах. Это поле хранит до 255 символов, но сама конечная точка push принимает только до 100 символов на поле, поэтому на практике держите значение заметно короче 100 символов.
{% hint style="warning" %}
И первичный ключ, и значение ключа принимают только буквы, цифры и символы подчёркивания, без дефисов и другой пунктуации. Общая проверка полей на конечной точке push более либеральна и допускает дефисы в любом поле без ошибок, но значение с дефисом никогда не совпадёт с сохранённым значением Key value, поэтому push-запросы с таким значением молча отбрасываются точно так же, как если бы значение не совпало. Если идентификаторы вашей внешней системы используют дефисы (например `truck-12`), переведите их, например в `truck_12`, перед отправкой.
{% endhint %}
{% endstep %}
{% step %}
#### Применить и сохранить
Нажмите **Примените изменения**, затем снова сохраните поток, если вы настроили вкладку Software после первого сохранения.
{% endstep %}
{% endstepper %}
### Особенности обработки данных
**Узел источника данных** наследует все парсеры и декодеры Navixy, обеспечивая совместимость с широким спектром IoT-устройств. Когда данные поступают в этот узел, они проходят следующий процесс:
1. Входящий поток данных принимается по указанному транспортному протоколу
2. Данные передаются соответствующему декодеру протокола в соответствии с вашей конфигурацией
3. Сообщения устройства преобразуются в стандартизированный формат, который может обрабатывать IoT Logic
4. Объединённые данные передаются в следующий узел в вашем потоке
Этот процесс стандартизации позволяет выстраивать единообразные процессы обработки независимо от исходного формата данных от устройств разных производителей.
### Как обрабатываются данные, переданные push-методом
Navixy сопоставляет каждое входящее push-сообщение по значению его первичного ключа с настроенным Узлом **Сопоставления**\`, затем объединяет оставшиеся поля в поток данных сопоставленного устройства в виде атрибутов: новые, если имя поля новое, или записываются в существующую историю этого атрибута, если имя совпадает с уже существующим, независимо от того, было ли оно нативно передано устройством или отправлено коннектором другого потока. Они не влияют на местоположение или другие телеметрические данные. Поле, указанное в **Первичный ключ**, вместе с `идентификатор потока` и `узел_id`, используется для маршрутизации и никогда не становится атрибутом само по себе. Запрос может оказаться в одном из трех состояний:
| Результат | HTTP-ответ | Данные объединены? |
| ---------------------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Значение первичного ключа совпадает с сопоставлением | 200, `успех: true` | Да. Остальные поля объединяются как атрибуты: создаются новые, если имя новое, либо используется существующая история, если оно совпадает с уже используемым |
| Значение первичного ключа не совпадает ни с одним сопоставлением | 200, `успех: true` | Нет. Отбрасывается без предупреждения |
| Отсутствует или недопустимо `Authorization` заголовок | ошибка 400 | Нет. Отклоняется до того, как Navixy проверит первичный ключ |
{% hint style="info" %}
Ответ 200 лишь подтверждает, что Navixy приняла запрос, но не то, что данные были объединены. Значение первичного ключа, которое не совпадает, отбрасывается без предупреждения, без ошибки, которая указала бы на это. Если вы не уверены, что push был сопоставлен, проверьте атрибуты сопоставленного устройства в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md) а не полагайтесь на ответ.
{% endhint %}
{% hint style="warning" %}
Имя отправляемого поля использует то же пространство имен, что и собственные нативные атрибуты устройства, а также имена, отправленные коннектором другого потока, который обогащает то же устройство. Если имя совпадает с уже используемым — независимо от того, является ли оно нативным для устройства или отправлено другим потоком, — push перезаписывает существующую историю этого атрибута вместо создания отдельной.
Датчики, отчеты и контроль событий читают объединенное значение как реальное показание, поэтому совпадающее имя может привести к ложным данным ниже по цепочке. Например, отправляемое поле с именем `Уровень топлива` которое совпадает с нативным атрибутом уровня топлива устройства, подставит ложное показание и создаст ложные события снижения уровня топлива или заправки в отчетах.
Чтобы избежать этого, добавляйте префикс к именам отправляемых полей, чтобы они не могли совпасть с нативными атрибутами устройства или именами, отправляемыми другим потоком, например `bms_battery_soc` вместо false `battery_soc`.
Поля системных сообщений, такие как `скорость`, `широта`, `долгота`, `курс`, `спутники`, и `hdop` не могут быть перезаписаны таким способом. Отправки могут только создавать или обновлять атрибуты, но никогда — телеметрию на уровне сообщения. Отправляемое поле с одним из этих имен все равно отображается под этим именем в [Анализ данных](/docs/user/ru/guide/account/iot-logic/data-stream-analyzer.md)отдельно от реальной телеметрии устройства.
{% endhint %}
Объединенный атрибут попадает в историю атрибутов устройства как запись на конкретный момент времени, а не как закрепленное текущее значение. Если устройство передает свою телеметрию гораздо чаще, чем внешняя система отправляет обновления, собственные пакеты устройства могут всего за несколько секунд продвинуть историю атрибута дальше отправленного значения, даже если объединение прошло успешно.
{% hint style="info" %}
Это ожидаемое следствие того, что два потока данных работают с разной скоростью, а не дефект. Ссылайтесь на атрибут ниже по цепочке как на `value('attribute_name', 0, 'valid')` вместо его простого имени. `'действительный'` возвращается по истории атрибута к последнему ненулевому показанию, поэтому нижестоящие узлы получают отправленное значение независимо от времени. См. [Отсутствующие значения и маршрутизация null](/docs/user/ru/guide/account/iot-logic/nodes/logic-node/logic-node-expressions-and-syntax.md#missing-values-and-null-routing) о том, как `'действительный'` сравнивается с `'все'` в условии узла Logic.
{% endhint %}
Конечная точка push принимает до 1 запроса в секунду на каждый ключ API, с размером всплеска 1. Устанавливайте для запросов внешней системы соответствующий темп.
## Часто задаваемые вопросы
#### Можно ли использовать несколько узлов Источник данных в одном потоке?
Да, вы можете использовать несколько **узлов источника данных** в одном рабочем пространстве. Это полезно, когда вам нужно по-разному обрабатывать данные от устройств разных типов или объединять несколько потоков данных после определенных преобразований.
#### Что произойдет, если устройство уже используется в другом потоке?
Устройство может одновременно принадлежать нескольким потокам. Если вы добавите устройство, которое уже используется в другом потоке, оба потока будут обрабатывать его данные одновременно, а результаты объединятся, чтобы избежать потери данных. Назначение другому потоку не является ограничением. Но если коннекторы двух потоков отправляют на это устройство одно и то же имя атрибута, они уже не объединяются без последствий. История одной отправки перезаписывает историю другой. См. [Как обрабатываются данные, переданные push-методом](#how-pushed-data-is-handled) чтобы избежать совпадающих имен.
#### Все ли мои устройства Navixy автоматически доступны в IoT Logic?
Да, все устройства из вашей учетной записи Navixy можно использовать в обработке IoT Logic. Сюда входят GPS-устройства, OEM-платформы, устройства и шлюзы MQTT, а также коннекторы MQTT/Kafka. Устройство, уже выбранное в узле, также можно обогатить атрибутами, отправленными из внешней системы по HTTP, через **Источник данных** Устройство, уже выбранное в узле, также можно обогатить атрибутами, отправленными из внешней системы по HTTP, через **Software** вкладку.
#### Как узнать, какого производителя выбрать для своих устройств?
Протокол должен соответствовать протоколу связи, используемому производителем вашего устройства. Большинство устройств используют протокол, связанный с их производителем (например, устройства Teltonika используют протокол Teltonika). Проверьте документацию к устройству или обратитесь к поставщику, если вы не уверены.
#### Можно ли подключить узел Источник данных к нескольким последующим узлам?
Да, вы можете подключить **узле Источник данных** к нескольким узлам обработки, чтобы создать параллельные пути обработки. Это позволяет применять разные преобразования к одному и тому же потоку данных. Вот пример:
#### Можно ли импортировать данные из системы, которая не является устройством Navixy?
Да, через **Software** вкладку, но только чтобы обогатить устройство, которое вы уже добавили на **Устройства** вкладке. Это не способ создать поток без устройств в нем.
#### Система, из которой я отправляю данные, передает данные реже, чем мое устройство, — потеряются ли отправленные данные?
Нет, но отправленный атрибут может быстро перестать быть текущим значением, если устройство сообщает намного чаще, поскольку оба источника используют одну и ту же скользящую историю. Ссылайтесь на атрибут ниже по цепочке как на `value('attribute_name', 0, 'valid')` вместо его простого имени, чтобы надежно получать последнее фактическое значение независимо от времени. Это ожидаемое следствие того, что два потока работают с разной скоростью, а не дефект. См. [Как обрабатываются данные, переданные push-методом](#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) для `'действительный'` против `'все'` различие в условии узла логики.
#### Я отправил данные, но они не отображаются. Что не так?
Проверьте это по порядку:
1. Убедитесь, что запрос содержал действительный `Authorization: NVX ` заголовок. Отсутствующий или некорректный заголовок приводит к явной ошибке HTTP 400.
2. Убедитесь, что имя отправляемого поля точно совпадает с **Первичный ключ** настройкой узла и что его значение точно совпадает с одним из настроенных **Сопоставления** точно, только буквы, цифры и символы подчёркивания. Значение с дефисом — самая частая причина: оно проходит встроенную проверку конечной точки отправки без ошибки, но никогда не совпадёт со значением 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 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/data-source-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.
.png?alt=media)
