| |
| sharixopen:knowledge:scenarios:teltonika_gps_tracker [2026/10/28 21:39] – [sharixknowledge] approved package sx_knowledge_api_open | sharixopen:knowledge:scenarios:teltonika_gps_tracker [2026/10/31 13:21] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open |
|---|
| "ShariXKnowledgeOpenKnowledgeModulesHandlers", | "ShariXKnowledgeOpenKnowledgeModulesHandlers", |
| "ShariXKnowledgeScenarios" | "ShariXKnowledgeScenarios" |
| | ], |
| | "depends_on": [ |
| | "ShariXKnowledgeOpenKnowledgeModulesHandlers" |
| | ], |
| | "verified_by": [ |
| | "ShariXKnowledgeVerification" |
| ] | ] |
| }, | }, |
| "extensions": { | "extensions": { |
| "taxonomy": { | "taxonomy": { |
| "domain": "business_processes", | "domain": "integrations", |
| "lifecycle": "implemented", | "lifecycle": "implemented", |
| "component": "handlers", | "component": "handlers_examples, handlers_backend", |
| "parents": [ | "parents": [ |
| "ShariXKnowledgeScenarios" | "ShariXKnowledgeScenarios" |
| ], | ], |
| "terms": [ | "terms": [ |
| "Teltonika", | "audience_developer", |
| "UDP", | "audience_integrator", |
| "GPS", | "audience_operator", |
| "first-party", | "audience_support", |
| "BPMN" | "audience_ai", |
| | "product_sharix_open", |
| | "material_scenario", |
| | "topic_operations_diagnostics", |
| | "topic_handlers_blockly", |
| | "topic_handlers_runtime", |
| | "teltonika", |
| | "udp", |
| | "avl", |
| | "gpx", |
| | "device_ack", |
| | "first_party_handler", |
| | "xmpp", |
| | "bpmn", |
| | "blockly", |
| | "generated_python" |
| ] | ] |
| }, | }, |
| "teltonika_udp_receiver" | "teltonika_udp_receiver" |
| ] | ] |
| | }, |
| | "classification": { |
| | "schema": "sharix.knowledge.classification.v1", |
| | "products": [ |
| | "sharix_open" |
| | ], |
| | "audiences": [ |
| | "developer", |
| | "integrator", |
| | "operator", |
| | "support", |
| | "ai" |
| | ], |
| | "material": "scenario", |
| | "topics": [ |
| | "operations/diagnostics", |
| | "handlers/blockly", |
| | "handlers/runtime" |
| | ], |
| | "tag_terms": [ |
| | "audience_developer", |
| | "audience_integrator", |
| | "audience_operator", |
| | "audience_support", |
| | "audience_ai", |
| | "product_sharix_open", |
| | "material_scenario", |
| | "topic_operations_diagnostics", |
| | "topic_handlers_blockly", |
| | "topic_handlers_runtime", |
| | "teltonika", |
| | "udp", |
| | "avl", |
| | "gpx", |
| | "device_ack", |
| | "first_party_handler", |
| | "xmpp", |
| | "bpmn", |
| | "blockly", |
| | "generated_python" |
| | ], |
| | "registry_document": "ShariXKnowledgeClassification", |
| | "state_meaning": "implemented — описана проверенная реализация исходников; серверный runtime отдельно; review — состояние текста" |
| | }, |
| | "editorial_review": { |
| | "date": "2026-10-31", |
| | "scope": "Конкретизация действий, условий, результатов и диагностики; перечисления; исходные BPMN сохранены", |
| | "current_source_records_verified": 15, |
| | "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence", |
| | "canonical_regeneration": { |
| | "kind": "first_party", |
| | "compared_python_paths": [ |
| | "handlers/open_teltonika_gps_tracker.py" |
| | ], |
| | "generator_sources_verified": 11, |
| | "handler_executed": false |
| | }, |
| | "runtime_checked": false |
| } | } |
| }, | }, |
| "content_sha256": "a8bdb952d349928ecacd847e4e93a0e119cef316907848918a7d96e358bbebbf", | "content_sha256": "219a0431e5fc529909c786fb6d4c09fae6263f12d7c8b0335642c3d9a0c380ab", |
| "schema": 1 | "schema": 1 |
| } | } |
| ~~NOCACHE~~ | ~~NOCACHE~~ |
| |
| **Область:** ShariX Open. **Обработчик:** ''open_teltonika_gps_tracker'', системный first-party handler без типа/рабочего статуса Ticket. Проверено 29.10.2026: опубликованный Python побайтово совпадает с каноническим first-party Blockly renderer. Сеть, устройства, runtime version и фактические env конкретного сервера отдельно не проверялись. | **Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]]. |
| | |
| | **Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#integrator|Интегратор]] · [[sharixopen:knowledge:classification:audiences#operator_razvjortyvanija|Оператор развёртывания]] · [[sharixopen:knowledge:classification:audiences#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]]. |
| | |
| | **Темы:** [[sharixopen:knowledge:classification:topics#diagnostika|Эксплуатация → Диагностика]] · [[sharixopen:knowledge:classification:topics#blockly|Обработчики → Blockly]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]]. |
| | |
| | |
| | |
| | **Область:** ShariX Open. **Обработчик:** ''open_teltonika_gps_tracker'', системный first-party handler без типа/рабочего статуса Ticket. 31.10.2026 исходники повторно получены из Git. First-party Python совпал с каноническим renderer; отдельно проверены операция, catcher, decoder, recorder и общий launcher. Сам обработчик и его внешние действия не запускались. Выбранная версия, настройки и доступность подключений конкретной установки проверяются отдельно. |
| |
| ===== Назначение и канонический контракт ===== | ===== Назначение и канонический контракт ===== |
| Handler запускает пример UDP-приёмника AVL-пакетов: получает датаграмму, разбирает её, пишет читаемую диагностику и отвечает устройству. Условно доступна запись GPX и отдельных AVL-файлов. В этом пути нет записи координат в Orders/Provider/Ticket, интеграции с картой или автоматического изменения статуса заказа. | Обработчик запускает пример UDP-приёмника AVL-пакетов: |
| | |
| | * получает датаграмму и разбирает её; |
| | * пишет читаемую диагностику; |
| | * при включённых режимах записывает GPX и отдельные AVL-файлы; |
| | * отправляет ответ устройству. |
| | |
| | Координаты не записываются этим путём в Orders/Provider/Ticket; интеграция с картой и смена статуса заказа здесь не выполняются. |
| |
| В Blockly зафиксирована typed operation ''teltonika_udp_receiver''. Сгенерированный Python вызывает binding; runtime сверяет точную program tuple с каталогом и загружает ''first_party_operations/open_teltonika_gps_tracker.py''. Бизнес-детали находятся также в catcher/decoder/GPX recorder, поэтому они включены в источники сценария. Совпадение generated wrapper не заменяет анализа вложенной operation. | В Blockly зафиксирована typed operation ''teltonika_udp_receiver''. Сгенерированный Python вызывает binding; runtime сверяет точную program tuple с каталогом и загружает ''first_party_operations/open_teltonika_gps_tracker.py''. Бизнес-детали находятся также в catcher/decoder/GPX recorder, поэтому они включены в источники сценария. Совпадение generated wrapper не заменяет анализа вложенной operation. |
| Несмотря на UDP-полезную работу, текущий binding имеет **requires_xmpp=true** и создаёт JabberBot. Общий launcher сначала подключает XMPP, регистрирует callback/supervisor и ждёт connection preflight. При неуспехе UDP loop не начинается. Успешный XMPP connect, напротив, ещё не доказывает доступность UDP endpoint устройству. | Несмотря на UDP-полезную работу, текущий binding имеет **requires_xmpp=true** и создаёт JabberBot. Общий launcher сначала подключает XMPP, регистрирует callback/supervisor и ждёт connection preflight. При неуспехе UDP loop не начинается. Успешный XMPP connect, напротив, ещё не доказывает доступность UDP endpoint устройству. |
| |
| Operation создаёт IPv4 UDP socket, включает SO_REUSEADDR, timeout=1.0 секунды и bind на TELTONIKA_HOSTNAME/TELTONIKA_PORT. Пока exit_event не установлен, вызывается receive_and_print. Обычный TimeoutError/socket.timeout продолжает цикл. Иное исключение выходит через finally с закрытием socket и передаётся общей политике рестартов launcher. При штатной остановке loop замечает exit_event между вызовами; затем socket и XMPP закрываются. | UDP loop после XMPP bootstrap: |
| | |
| | - Создать IPv4 UDP socket с SO_REUSEADDR. |
| | - Установить timeout=1.0 секунды и bind на TELTONIKA_HOSTNAME/TELTONIKA_PORT. |
| | - Пока exit_event не установлен — вызывать receive_and_print. |
| | - При TimeoutError/socket.timeout продолжать цикл. |
| | - При другом исключении выйти через finally с закрытием socket; далее действует общая политика launcher. |
| | |
| | При штатной остановке exit_event проверяется между вызовами; затем закрываются socket и XMPP. |
| |
| В operation нет отдельного TCP listener или IMEI handshake. Закомментированный TCP-код в catcher не является активным путём запуска. | В operation нет отдельного TCP listener или IMEI handshake. Закомментированный TCP-код в catcher не является активным путём запуска. |
| </sharix-bpmn> | </sharix-bpmn> |
| |
| receive_and_print делает recvfrom(1024), сохраняет raw bytes и sender addr в decoder, затем вызывает parse_data. Decoder сопоставляет заявленную длину с фактической, извлекает заголовки, IMEI, codec id, records и IO. При успешной структуре формируется читаемый logging-output; отдельный AVL-файл пишется только при write_logs=true. | Обработка одной датаграммы: |
| |
| Если структура возвращена и GPX recorder включён, по IMEI добавляются точки с координатами, высотой и timestamp. Точка (0,0) пропускается. Далее answer_to_device формирует ACK и sendto отправляет его на адрес источника датаграммы. | - Получить до 1024 байт через recvfrom и адрес отправителя. |
| | - Передать raw bytes и addr decoder. |
| | - Проверить заявленную/фактическую длину, извлечь заголовки, IMEI, codec, records и IO. |
| | - При успешной структуре сформировать читаемый logging-output. |
| | - Отдельный AVL-файл писать только при write_logs=true. |
| | |
| | После parse: |
| | |
| | - Если есть структура и GPX recorder включён — добавить точки с координатами, высотой и timestamp по IMEI. |
| | - Пропустить точку (0,0). |
| | - Сформировать ACK через answer_to_device. |
| | - Вызвать sendto на адрес источника датаграммы. |
| | |
| | ACK формируется и после parse_data=None, если до него не было исключения. |
| |
| ==== ACK не равен сохранённой телеметрии ==== | ==== ACK не равен сохранённой телеметрии ==== |
| ACK собирается из raw byte slices: UDP packet id, AVL packet id и count по фиксированному смещению. Count не вычисляется по фактически разобранным/сохранённым GPX-точкам. Даже если parse_data вернул None и GPX не выполнялся, catcher продолжает к answer_to_device и sendto, если не было исключения. | ACK берёт поля непосредственно из raw bytes: |
| | |
| | * UDP packet id — data[2:4]; |
| | * AVL packet id — data[5:6]; |
| | * count — data[24:25]. |
| | |
| | Count не вычисляется по фактически разобранным или записанным GPX-точкам. Получение ACK не подтверждает сохранённую телеметрию или обновление бизнес-объекта. |
| |
| Поэтому ACK не доказывает корректность всех координат, запись файла или обновление бизнес-объекта. Исключение декодирования, файловой операции или sendto — другой исход: оно не обрабатывается как обычный socket timeout и может завершить текущий запуск с последующим restart. Разбор не содержит полноценного fail-closed валидатора всех возможных форматов/codec; IMEI извлекается как данные, а не сопоставляется здесь с разрешённым устройством в БД. | Поэтому ACK не доказывает корректность всех координат, запись файла или обновление бизнес-объекта. Исключение декодирования, файловой операции или sendto — другой исход: оно не обрабатывается как обычный socket timeout и может завершить текущий запуск с последующим restart. Разбор не содержит полноценного fail-closed валидатора всех возможных форматов/codec; IMEI извлекается как данные, а не сопоставляется здесь с разрешённым устройством в БД. |
| |
| ===== Что действительно включено при штатном запуске ===== | ===== Что действительно включено при штатном запуске ===== |
| GPX_Recorder создаётся с is_recording=false, AVL_DATA — с write_logs=false и show_broken_data=false. Штатный first-party binding вызывает receive_and_print напрямую; он **не вызывает catcher.main**, control_thread и переключатели записи. Поэтому команды stdin g/l/b/q из самостоятельного примера не являются интерфейсом управления этим handler через XMPP или launcher. | В штатном first-party запуске: |
| | |
| | * GPX_Recorder создаётся с is_recording=false; |
| | * AVL_DATA — с write_logs=false и show_broken_data=false; |
| | * binding вызывает receive_and_print напрямую; |
| | * catcher.main, control_thread и переключатели записи этим путём не вызываются. |
| | |
| | Команды stdin g/l/b/q самостоятельного примера не являются интерфейсом управления handler через XMPP или launcher. |
| |
| Обычный читаемый logging при удачном parse выполняется, но отдельные AVL-файлы и GPX в этом binding автоматически не включаются. Директории могут создаваться при импорте recorder/decoder ещё до открытия socket; наличие каталога не доказывает активную запись. Если запись включена другим разрешённым способом, GPX хранится по IMEI и времени первой точки, AVL logs — по IMEI в своих output dirs. Это файлы примера, а не проекция в БД сервиса. | Обычный читаемый logging при удачном parse выполняется, но отдельные AVL-файлы и GPX в этом binding автоматически не включаются. Директории могут создаваться при импорте recorder/decoder ещё до открытия socket; наличие каталога не доказывает активную запись. Если запись включена другим разрешённым способом, GPX хранится по IMEI и времени первой точки, AVL logs — по IMEI в своих output dirs. Это файлы примера, а не проекция в БД сервиса. |
| Относительные output paths разрешаются от корня проекта; реальные значения и managed permissions определяет установка. Не следует считать default внутри каталога примера доказательством фактического пути production. Проверяйте штатную env/permission-подготовку, не создавая параллельный неуправляемый конфиг для handler. | Относительные output paths разрешаются от корня проекта; реальные значения и managed permissions определяет установка. Не следует считать default внутри каталога примера доказательством фактического пути production. Проверяйте штатную env/permission-подготовку, не создавая параллельный неуправляемый конфиг для handler. |
| |
| Диагностируйте последовательно выбранную Python version/binding, XMPP preflight, импорт/права output dirs, bind UDP, приход датаграммы, parse result, режимы записи и ACK. Не путайте XMPP callback с UDP decoder: callback только логирует допустимые chat/normal от технического allowlist, не переключает GPX и не обновляет трекер в БД. | Порядок диагностики: |
| | |
| | - Сверить выбранные Python version и binding. |
| | - Проверить XMPP preflight: без него UDP loop не начинается. |
| | - Проверить import и права output dirs, затем bind UDP. |
| | - Проверить приход датаграммы и реальный parse result. |
| | - Отдельно проверить флаги записи, созданные данные и ACK. |
| | |
| | XMPP callback только логирует допустимые chat/normal от технического allowlist; он не переключает GPX и не обновляет трекер в БД. |
| |
| ===== Проверенные источники ===== | ===== Проверенные источники ===== |
