AI queries over MCP: ask better questions about your Zigbee telemetry

Months of Zigbee2MQTT telemetry can contain useful evidence: temperature trends, humidity changes, battery decline, energy consumption, and device reporting gaps.

The difficulty is often not collecting the data. It is asking the right question of it. A dashboard can show a dozen charts, but you still need to choose the date range, device, field, aggregation, comparison, and threshold. A SQL, InfluxQL, or Flux query can express that precisely, but only if you know the data model and query language.

Natural-language interfaces offer another way to explore the same history. Instead of beginning with a query, you begin with the operational question: “Which room was warmest overnight last week?” or “Which sensors have shown the fastest battery decline?”

MCP—the Model Context Protocol—is an open standard for connecting AI assistants with external tools and data sources. An MCP server can expose tools that a compatible AI client discovers and invokes, while the client remains responsible for presenting and authorising tool use according to its implementation.

That can make telemetry easier to explore, but it does not make the underlying data perfect or remove the need to validate the answer.

The query barrier is real

In a DIY InfluxDB setup, a simple question may require knowledge of the schema, measurement names, tags, fields, time syntax, and aggregation functions. A query might look like this:

SELECT mean("temperature")
FROM "sensors"
WHERE "device_id" = 'living_room'
  AND time > now() - 7d
GROUP BY time(1h)

An equivalent Flux query might look like this:

from(bucket: "zigbee")
  |> range(start: -7d)
  |> filter(fn: (r) => r._measurement == "sensors")
  |> filter(fn: (r) => r.device_id == "living_room")
  |> aggregateWindow(every: 1h, fn: mean)

These are not inherently bad interfaces. They are precise and reproducible once you understand them. The barrier appears when the question is exploratory, the schema is unfamiliar, or you want to compare several devices without first building a dashboard for every variation.

A natural-language request can hide those implementation details. The assistant can identify the likely device or topic, select a time window, call a history tool, and explain the result in ordinary language.

The quality of the result still depends on the assistant having access to the right data and interpreting the request correctly. “Last week” needs a timezone and date range. “Average temperature” needs a device scope and aggregation period. “Biggest battery drop” needs a comparison window and a definition of drop.

A good system should ask for clarification when those choices materially change the result.

What MCP actually provides

MCP is a protocol for connecting AI applications to external context and tools; it is not itself a database, an analytics engine, or a guarantee that an AI answer is correct. Its server tools can be discovered through tools/list and invoked by an MCP client. The MCP specification recommends input validation, access controls, rate limiting, output sanitisation, timeouts, and user visibility around tool calls.

For a telemetry use case, an MCP-connected assistant might have access to read-only operations such as:

• List devices and their latest known payloads.
• Retrieve history for a device topic over a defined range.
• Compare returned values across devices.
• Calculate a trend or summary from the retrieved points.
• Explain gaps, outliers, or limitations in the result.

The assistant should show enough scope for you to understand what it did: the devices considered, the date range, the fields used, the aggregation, and any missing data.

This is more trustworthy than presenting a confident answer with no provenance. For example, “The bedroom was 1.8 °C warmer on average between 22:00 and 06:00 during 18–24 August” is more useful when you can see which sensor supplied the data, how many points were available, and whether the comparison room had gaps.

Questions that work well

Natural-language telemetry queries are most useful when they describe a measurable comparison, period, or threshold.

Investigate trends

• “Has the basement humidity increased over the last 30 days?”
• “What was the average temperature in the bedroom during the last seven nights?”
• “How different were living-room and hallway temperatures during working hours?”

The assistant should define “increased” and “average” clearly. A linear slope, first-versus-last comparison, and weekly average comparison can produce different answers.

Find outliers

• “Which sensors had the largest battery decline over the last month?”
• “Which smart plugs reported unusually high overnight power?”
• “Which devices have not produced a recent message?”

Outlier detection needs a baseline. A battery-powered contact sensor is expected to report differently from a mains-powered plug. A device without a new battery reading may still be working normally if its other state events continue to arrive.

Support maintenance

• “Which devices should I check during the next battery replacement round?”
• “Did this sensor’s reporting pattern change after the bridge restart?”
• “Which room has the longest humidity recovery after a peak?”

These questions can prioritise inspection, but they should not be phrased as automatic diagnoses. Telemetry can show what changed; it rarely proves the physical cause without additional evidence.

Answers need a provenance trail

AI-generated answers are summaries of retrieved data and model reasoning. They are not independent measurements. A reliable telemetry assistant should make it possible to distinguish:

• Observed data: the points actually returned by the history query.
• Calculated result: an average, difference, slope, count, or ranking derived from those points.
• Interpretation: a possible explanation of the pattern.
• Recommendation: a suggested next action.

For example:

The basement sensor’s average relative humidity was higher during the second half of the selected period. This is an observed comparison. It does not establish whether the cause was rainfall, ventilation, temperature, or a leak. Inspect the timing against those events before changing the automation.

This separation prevents a plausible explanation from being mistaken for a measured fact.

The assistant should also report limitations:

• Missing observations or bridge outages.
• Devices with different reporting intervals.
• Downsampled history.
• Ambiguous device names.
• Values that reset or use different units.
• A time range that does not contain enough representative data.

In ZigStream’s documented history interface, wider 7-day and 30-day ranges are automatically downsampled to one point per hour. That resolution can be suitable for room-level trends, but it may hide short power spikes or individual event timing.

The DIY AI route

You can build this workflow yourself. A typical implementation would expose your telemetry through an API, define tools for querying devices and ranges, connect an LLM through function calling or MCP, and write the rules that validate and present results.

The engineering work includes more than generating a query:

1. Define a stable telemetry schema and device identity model.
2. Expose only the data and operations the assistant needs.
3. Validate device names, fields, date ranges, and aggregation parameters.
4. Prevent arbitrary query execution or unintended data access.
5. Handle missing data, timezones, resets, and incompatible units.
6. Show tool calls and query scope to the user.
7. Log usage and limit expensive or repeated requests.
8. Test the assistant with ambiguous and adversarial questions.

MCP’s security guidance explicitly treats tools as operations requiring validation and access control, and recommends user confirmation or visibility for sensitive calls. For a read-only telemetry assistant, the risk is lower than for an agent that controls switches or changes configuration, but privacy and data-sharing decisions still matter.

Self-hosting this layer is a good fit when you want full control over the model, prompts, storage, query implementation, and network boundary. It is a separate project, not merely a prompt added to Grafana.

Where ZigStream fits

ZigStream’s role is to provide a focused history interface for Zigbee2MQTT device topics. Its currently exposed tools include device listing, historical device queries, and account usage information. Historical queries accept a device topic and a time range; 7-day and 30-day ranges are automatically downsampled to one point per hour. That history layer can support an AI-assisted workflow when an MCP client or integration exposes appropriate read-only telemetry tools.

Ask questions that can be checked

The best natural-language telemetry questions are specific enough to reproduce:

• Name the device, room, or group.
• Give a clear period, such as “18–24 August” or “the last seven complete days.”
• Specify the metric and unit.
• Define the operation: average, maximum, minimum, change, count, or comparison.
• Ask the assistant to include missing-data notes and the points or periods used.

Instead of asking, “Why is the house using more energy?”, ask, “Compare the daily energy reported by the kitchen and office plugs during the last seven complete days, show the difference, and list any days with missing data.”

Instead of asking, “Is the basement getting damp?”, ask, “Compare the basement sensor’s daily average and maximum relative humidity over the last 30 days, identify whether the values increased, and show the dates of the largest peaks.”

These prompts do not eliminate interpretation, but they make the result easier to inspect and challenge.

The bottom line

MCP can make telemetry easier to explore by giving an AI client a standard way to call read-only data tools. The benefit is not that the assistant magically understands your home. The benefit is that you can express a measurable question without manually translating it into SQL, Flux, dashboard filters, and aggregation choices.

The important safeguards are scope, provenance, validation, and user control. An assistant should show which devices and dates it queried, distinguish calculations from explanations, and acknowledge gaps or downsampling.

A DIY implementation remains appropriate when you want full control over the data and AI pipeline. If your main requirement is a managed source of Zigbee2MQTT history for inspection or integration, ZigStream provides documented device-history queries while leaving local Zigbee control in place. Verify the current MCP and AI capabilities before presenting them as built-in features.

Start with one reproducible question—such as a seven-day temperature comparison or a battery trend—and require the answer to show its scope. Natural language is most useful when it makes analysis easier without hiding how the conclusion was reached.