M-Bus HTTPD API

Name: M-Bus HTTPD API
Brand: M-Bus HTTPD API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentIOTSensor Datanone7 EndpointsREST

For Agents

Read utility meter data over M-Bus through an HTTP wrapper — power the HAT, scan for meters, and pull single or multi-frame meter readings.

Install Jentic One Beta

Connect the M-Bus HTTPD API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the M-Bus HTTPD API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with M-Bus HTTPD API.

Power the M-Bus HAT on or off via HTTP

Scan a serial bus to discover connected meter addresses

Read a single data record from a specific meter at a chosen baud rate

Read multiple frames from a meter for richer historical data

GET STARTED

Start building with M-Bus HTTPD API

Explore with Jentic

View OpenAPI Document

Use Cases

Patterns agents use M-Bus HTTPD API for, with concrete tasks.

★ Scheduled Utility Meter Polling

Poll connected gas, water, heat, or electricity meters at a regular interval and write the readings to a time-series database for billing, analytics, or fault detection. The /mbus/get endpoint returns a single frame for a known meter address, which agents can run on a cron-like schedule. This replaces manual meter readings in district heating networks and multi-tenant buildings.

Every hour, call GET /mbus/get/{device}/{baudrate}/{address} for each meter in the configured list and write the parsed value plus timestamp to InfluxDB.

Bus Discovery for New Installations

Discover what meters are physically connected to the M-Bus before configuring polling jobs. The /mbus/scan endpoint walks the bus at a chosen baud rate and returns the addresses of responding devices. Installation engineers and commissioning agents use this once at deployment to capture the device inventory without manually checking each meter.

Call GET /mbus/scan/{device}/2400 and return the list of discovered meter addresses, then write each one to a meters table for later polling.

Multi-Frame Historical Reads

Pull multiple frames from a meter that supports historical records, enabling agents to retrieve consumption history rather than just the latest value. The /mbus/getMulti endpoint accepts a maxframes parameter, returning as many records as the meter exposes. This supports retrospective billing reconciliation and gap-filling after a polling outage.

Call GET /mbus/getMulti/{device}/{baudrate}/{address}/24 to retrieve up to 24 historical frames and store each with its frame index in the readings table.

AI Agent for Building Energy Reporting

Build an agent that aggregates M-Bus readings across all meters in a building and produces a weekly energy report flagging anomalies. The agent searches Jentic for 'read M-Bus meter', loads the meter-read schema, and executes calls in parallel for each known meter address. The output is a summary highlighting unusual consumption patterns without an engineer manually pulling each meter.

For every meter address in the configured inventory, call GET /mbus/get and aggregate readings for the past 7 days, then return a markdown report flagging meters whose consumption is more than 20% above their 4-week average.

Key Endpoints

7 endpoints — m-bus httpd is a small http server that exposes the wired m-bus (meter-bus) protocol used to read utility meters such as gas, water, heat, and electricity.

METHOD

PATH

DESCRIPTION

GET

/mbus/api

Service status and version

GET

/mbus/hat

Get HAT power state

GET

/mbus/hat/on

Power the HAT on

GET

/mbus/hat/off

Power the HAT off

GET

/mbus/scan/{device}/{baudrate}

Scan the bus for meters

GET

/mbus/get/{device}/{baudrate}/{address}

Single-frame meter read

GET

/mbus/getMulti/{device}/{baudrate}/{address}/{maxframes}

Multi-frame meter read

GET

/mbus/api

Service status and version

GET

/mbus/hat

Get HAT power state

GET

/mbus/hat/on

Power the HAT on

GET

/mbus/hat/off

Power the HAT off

GET

/mbus/scan/{device}/{baudrate}

Scan the bus for meters

GET

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

M-Bus HTTPD itself has no credentials. Jentic still tunnels traffic through the MAXsystem connection layer so the local service is not exposed to the public internet, and agents reach it only via signed Jentic execution calls.

Intent-based discovery

Agents search Jentic by intent (e.g. 'read an M-Bus meter') and Jentic returns the matching M-Bus HTTPD operation with its input schema, so the agent can call the right endpoint without reading the protocol documentation.

Time to first call

Direct M-Bus HTTPD integration: 1-3 days for HAT setup, address discovery, and parsing of frame data. Through Jentic: under 1 hour once the local service is reachable from the Jentic execution environment.

FAQs

Specific to using M-Bus HTTPD API through Jentic.

What authentication does the M-Bus HTTPD API use?

The M-Bus HTTPD spec defines no authentication scheme; the service is intended to run on a trusted local network behind whatever firewalling the deployment provides. When exposed through Jentic, agents reach the service via Jentic's connection layer rather than over the open internet.

Can I discover connected meters with the M-Bus HTTPD API?

Yes. GET /mbus/scan/{device}/{baudrate} walks the bus and returns the addresses of responding meters. Run this once at commissioning and persist the inventory; subsequent polling uses GET /mbus/get against the discovered addresses.

What are the rate limits for the M-Bus HTTPD API?

There are no published rate limits — the service is bound by serial-port bandwidth at the chosen baud rate (typically 300, 2400, or 9600). Practical limits are one read per meter per second; bus contention is the real constraint, not the HTTP layer.

How do I read a meter with the M-Bus HTTPD API through Jentic?

Search Jentic for 'read an M-Bus meter', load the schema for GET /mbus/get/{device}/{baudrate}/{address}, and execute with the device path (e.g. /dev/ttyAMA0), baud rate, and meter address. Jentic routes the call to the local M-Bus HTTPD service.

Does the M-Bus HTTPD API support multi-frame reads?

Yes. GET /mbus/getMulti/{device}/{baudrate}/{address}/{maxframes} returns up to maxframes historical records from a meter that supports them. Use this to back-fill readings after a polling outage or to capture richer consumption history at commissioning.

Why do I need to power the HAT before reading?

The M-Bus HAT supplies the bus voltage that connected meters draw to communicate. GET /mbus/hat/on energises the bus before reads; GET /mbus/hat/off de-energises it. Agents typically power the HAT once at boot and only toggle it during fault recovery.