Схема MCP-моста: датчик → MQTT → TimescaleDB → LLM → ответ на русском языке

MCP-мост MQTT TimescaleDB LLM: анализ данных датчиков на русском

ИИ-инструменты 1 июля 2026 г.

Инженер на заводе тратит полдня, чтобы выяснить, почему влажность подскочила в три часа ночи в прошлый вторник. Ему нужно написать SQL-запрос, выгрузить данные в CSV, перенести в Python, построить график в Excel и вручную искать аномалии. Данных — гигабайты, а ответ нужен сейчас.

Источник: Habr

Современные языковые модели (LLM) умеют анализировать такие данные, но передавать им терабайты сырых логов напрямую — дорого и бессмысленно. Решение — Model Context Protocol (MCP), открытый стандарт, который позволяет LLM безопасно вызывать внешние инструменты. В данном случае — базу данных временных рядов TimescaleDB.

В этой статье — пошаговая инструкция, как собрать цепочку: датчик → MQTT → Telegraf → TimescaleDB → MCP-сервер → LLM. И получить возможность задавать вопросы на русском языке и мгновенно получать ответы и графики.

Что такое MCP и зачем он нужен инженеру

Model Context Protocol (MCP) — это открытый стандарт, разработанный компанией Anthropic и поддерживаемый Google, Microsoft и другими крупными игроками. Он позволяет языковой модели безопасно и стандартизированно вызывать «инструменты» во внешнем мире.

Раньше, чтобы LLM могла получить доступ к данным, нужно было писать сложные интеграции, передавать огромные объёмы данных в контекст или использовать нестандартные API. MCP решает эту проблему: модель сама понимает, какой инструмент вызвать, и получает только необходимый, сжатый ответ.

Для инженера это означает, что вместо написания скриптов и ручного анализа он может просто открыть чат с AI-ассистентом (Claude, OpenCode или любой клиент с поддержкой MCP) и написать обычным текстом: «Посмотри показания датчиков с температурой и влажностью и покажи максимальные и минимальные значения за 3 дня». Модель сама выполнит SQL-запрос к TimescaleDB и выдаст аккуратную сводку.

Как это работает на практике: демонстрация

Представьте, что на объекте стоят два датчика, которые измеряют температуру и влажность. Данные с них непрерывно пишутся в базу. Вместо написания скриптов дежурный инженер просто открывает чат с AI-ассистентом.

Вот как выглядят типичные запросы:

  • «Посмотри показания датчиков с температурой и влажностью и покажи максимальные и минимальные значения за 3 дня». Модель сама формирует SQL-запрос, вызывает MCP-инструмент, получает сжатый ответ и выдаёт сводку.
  • «Нарисуй гистограмму изменений температуры». Ассистент мгновенно строит график прямо в интерфейсе чата.
  • «Нарисуй гистограмму изменений влажности с шагом в 10 минут». Аналогично — график с нужным шагом.
  • «Проанализируй корреляцию при изменении значений температуры и влажности по времени». Сложная аналитика, на которую у человека ушло бы много времени, выполняется за секунды.

AI-инженер работает безупречно: он неутомим, бесстрастен и очень быстр. За секунды он просеивает миллионы точек телеметрии и выдает готовые выводы.

Собираем цепочку данных: пошаговая инструкция

Цепочка данных выглядит так: Датчик → Mosquitto (MQTT) → Telegraf → TimescaleDB → MCP-сервер → LLM.

В качестве серверной платформы используется Ubuntu. Пройдёмся по всем этапам настройки.

Шаг 1. Настраиваем хранилище: PostgreSQL + TimescaleDB

Обычный PostgreSQL под большой нагрузкой от IoT-датчиков начинает «грустить». Поэтому используется расширение TimescaleDB — оно превращает PostgreSQL в мощную базу данных для временных рядов (time-series), автоматически разбивая таблицы на партиции (гипертаблицы) по времени.

Для удобства и изоляции всё разворачивается в Docker. Вот пример docker-compose.yml:

version: '3.8'

services:
  timescaledb:
    image: timescale/timescaledb:latest-pg16
    ports:
      - "5433:5432"
    environment:
      POSTGRES_PASSWORD: your_password
    volumes:
      - timescaledb_data:/var/lib/postgresql/data

volumes:
  timescaledb_data:

Обратите внимание: база вынесена на нестандартный порт 5433, чтобы не конфликтовать с локальным PostgreSQL, если он уже установлен.

Шаг 2. Настраиваем MQTT-брокер и сбор данных

Для сбора данных с датчиков используется MQTT-брокер Mosquitto. Данные с датчиков публикуются в топики, например sensors/temperature и sensors/humidity.

Для передачи данных из MQTT в TimescaleDB используется Telegraf — агент для сбора и передачи метрик. Он подписывается на нужные топики MQTT и записывает данные в гипертаблицу TimescaleDB.

Шаг 3. Создаём MCP-сервер для доступа к базе данных

MCP-сервер — это промежуточное звено, которое позволяет LLM безопасно выполнять SQL-запросы к TimescaleDB. Сервер реализует протокол MCP и предоставляет модели инструмент для выполнения запросов.

Важные моменты при создании MCP-сервера: - Сервер должен принимать только SELECT-запросы, чтобы избежать случайного изменения данных. - Ответы должны быть сжатыми — модель не должна получать сырые гигабайты данных. - Необходимо настроить ограничение по времени выполнения запроса и по объёму возвращаемых данных.

Шаг 4. Подключаем LLM-клиент с поддержкой MCP

Любой клиент, поддерживающий MCP (Claude, OpenCode и другие), может подключиться к вашему MCP-серверу. После подключения модель «узнаёт» о новом инструменте и может его использовать.

Что можно проверить за неделю без перестройки компании

Перед тем как внедрять решение в промышленную эксплуатацию, стоит провести небольшую проверку:

  1. Разверните тестовый стенд на отдельном сервере или в Docker. Убедитесь, что все компоненты (Mosquitto, Telegraf, TimescaleDB, MCP-сервер) работают вместе.
  2. Подключите один-два датчика и проверьте, что данные записываются в TimescaleDB.
  3. Протестируйте MCP-сервер с простыми запросами: «Покажи последние 10 значений температуры».
  4. Проверьте работу с LLM-клиентом: задайте несколько вопросов на русском языке и оцените качество ответов.
  5. Оцените стоимость: сколько будет стоить каждый запрос к LLM (если используется платный API) и сколько времени экономится по сравнению с ручным анализом.

Где скрытые риски и ограничения

Несмотря на привлекательность решения, есть несколько важных ограничений, которые стоит учитывать:

  • Стоимость API. Если вы используете платную LLM (например, Claude), каждый запрос к модели стоит денег. При большом количестве запросов затраты могут быть значительными.
  • Доступность модели. Некоторые LLM могут быть недоступны в определённых регионах или иметь ограничения по API. Уточните актуальный статус перед внедрением.
  • Безопасность. MCP-сервер должен быть настроен так, чтобы модель не могла выполнять опасные запросы (например, DELETE или DROP TABLE). Используйте только SELECT-запросы.
  • Надёжность. Если MQTT-брокер или база данных выйдут из строя, AI-ассистент перестанет работать. Продумайте резервирование.
  • Качество ответов. LLM может ошибаться в интерпретации данных или формировании сложных запросов. Всегда проверяйте критически важные выводы.

Практический чек-лист для внедрения

Этап Что проверить Статус
1 Развёрнут ли TimescaleDB в Docker или на сервере?
2 Настроен ли MQTT-брокер (Mosquitto) и публикуются ли данные датчиков?
3 Настроен ли Telegraf для передачи данных из MQTT в TimescaleDB?
4 Создан ли MCP-сервер с ограничением на SELECT-запросы?
5 Подключён ли LLM-клиент с поддержкой MCP?
6 Проведено ли тестирование с реальными данными?
7 Оценена ли стоимость запросов к LLM?
8 Продумано ли резервирование критических компонентов?

Что делать на этой неделе

  1. Разверните тестовый стенд с TimescaleDB и MQTT-брокером. Это займёт не более часа.
  2. Настройте Telegraf для сбора данных с одного-двух датчиков.
  3. Создайте простой MCP-сервер на Python или Node.js, который выполняет SELECT-запросы к TimescaleDB.
  4. Подключите LLM-клиент (например, Claude или OpenCode) и задайте несколько вопросов.
  5. Оцените результат: сколько времени вы сэкономили и насколько точны ответы модели.

Если тестирование пройдёт успешно, можно масштабировать решение на все датчики и добавить более сложные аналитические запросы.

Источники

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше

Теги