Connect your Victron System to Claude/AI via local Modbus TCP (New MCP Server)

Modifications
, , ,
1

Hi everyone,

I wanted to share a new tool for those of you experimenting with AI and home automation. I’ve just released/found a project called victron-tcp, which is an MCP (Model Context Protocol) server that bridges your Victron GX device (Cerbo, Venus, etc.) directly to AI agents like Claude.

What is this?

This tool allows you to talk to your solar system in plain English using the Claude Desktop app. Instead of checking a dashboard, you can simply ask:

  • “What is my current battery state of charge?”

  • “How much solar power did I generate in the last hour?”

  • “Is my inverter currently in Passthru mode?”

How it works

Unlike other integrations that use the VRM Cloud API, this server uses local Modbus TCP. This means:

  1. Speed: Instant data retrieval from your local network.

  2. Privacy: Your data stays local and doesn’t rely on an internet connection to the VRM portal.

  3. Control: Access to any register supported by the GX Modbus service.

Key Features:

  • Real-time Monitoring: Fetch battery SOC, voltage, current, and power.

  • System Overview: Get the full state of your system (Solar, Grid, Battery, and Loads).

  • Device Discovery: Automatically identifies units on your GX device via Modbus Unit IDs.

  • Easy Integration: Built specifically for the Model Context Protocol (MCP), so it works out of the box with Claude Desktop.

Quick Start:

  1. Enable Modbus TCP: On your GX Device, go to Settings > Services > Modbus/TCP and turn it ON.

  2. Install: ```bash npm install -g victron-tcp

  3. Configure Claude: Add the server to your claude_desktop_config.json:

    JSON

    "mcpServers": {
  "victron-tcp": {
    "command": "npx",
    "args": ["-y", "victron-tcp"],
    "env": {
      "VICTRON_IP": "192.168.1.xxx" 
    }
  }
}

Why use an MCP Server?

Instead of just “seeing” data, an AI agent can help you analyze it. You can ask Claude to “Watch my battery usage and tell me if I’ll make it through the night based on current loads” or “Explain why my solar yield is lower than yesterday.”

Check out the full documentation and source here: https://www.npmjs.com/package/victron-tcp

Would love to hear if anyone else is using AI to monitor their off-grid setups!

2 Likes
2

Last thing I would ever do…

3

There’s no way I’m going to hand over oversight of something as critical as my local energy infrastructure to a third party. The only exception I’d consider is using AI to process a limited, well-defined batch of historical data — strictly for advisory purposes when fine-tuning future control settings — not for real-time control or decision-making.

1 Like
4

Hello @Rene2322 and @MikeD ,

Thanks for the feedback. This MCP is useful for the initial setup of connected GX components and additional development work with Grafana, Flux, etc., followed by Vibecoding. It’s helpful for gathering data and setting up mapping for historical data analysis.

However, it’s not intended for recurring historical data collection—that’s better handled by scripts rather than an LLM. Also, if you’ve read the documentation, you’ll see it currently supports read-only access, not write operations.

I’m curious—are you actually using this MCP server in your setup? It would help to understand your specific use case or concerns based on hands-on experience rather than theoretical objections.

5

That’s great because it suggests that genuinely useful applications will emerge from this in the future. I’m thinking of instructions to Claude that lead to changes in the Victron system’s settings, without requiring any programming via Node-RED.

But I’m not someone who wants to talk to their devices or furniture. Just as I see little point in controlling the living room lights with voice commands to Alexa, I see little point in talking to my Victron system to query its current data. I can see that data with a single mouse click in the console.

6

@TomBerger — You’re absolutely right. Asking “what’s my SOC?” when you can glance at the console is a step backwards. That’s not where the value is.

I think the real use case is implementation and commissioning, not daily monitoring:

For installers and system integrators:

  • victron_network_scan auto-detects GX devices on the subnet without knowing any IP. victron_setup then tests both Modbus and MQTT, discovers every connected device (inverters, MPPTs, batteries, tank sensors, gensets…), maps all unit IDs, and generates the config — in one step. On a new install with 10+ devices, that replaces a lot of manual register hunting.

  • The commissioning prompt runs a full checklist — discovers all devices, verifies firmware versions, validates wiring and configuration, and produces a pass/fail report. That’s an hour of clicking through menus replaced by one conversation.

  • device-inventory produces a complete device table with unit IDs, service types, and firmware ready to paste into documentation.

  • Scale matters for a residential system with one Cerbo and a few MPPTs, you know your setup. But for commercial installs with 20+ devices across multiple GX units, automated discovery and asset mapping saves real time.

For non-Victron developers and integrators:

This might be the most underrated use case. If you’re a home automation developer, an HVAC integrator, or building an energy management system, and you need data from a Victron system you’d normally have to learn Modbus TCP register addressing, unit ID assignment, Venus OS MQTT topic structure, scale factors, enum mappings… The MCP server abstracts all of that.

You just ask “what’s the grid power on L1?” and get a clean answer. The 942-register catalog and all the protocol complexity is handled for you. You don’t need to become a Victron expert to integrate with one.

For Node-RED development:

The nodered-check prompt maps all available MQTT topics on the Venus OS broker, shows the exact topic structure (N/<portalId>/<service>/<instance>/<path>), explains the keepalive mechanism, and lists writable registers. If you’re building a Node-RED flow to control ESS mode based on tariff schedules, the AI can tell you exactly which topics to subscribe to and which to write — without digging through the CCGX register PDF. It doesn’t replace Node-RED, but it makes developing flows significantly faster.

ESS tuning on new installs:

The energy-optimizer reads your current ESS mode, grid setpoint, battery limits, and Dynamic ESS state, then recommends specific changes based on a goal you pick (self-consumption, cost-savings, battery-longevity, backup-ready). “Set grid setpoint to -30W to avoid export” or “switch to Optimized with BatteryLife” — actionable advice instead of guesswork.

You’re right that once an off-grid system is running and stable, there’s less need for this — you know your system, your Node-RED flows are built, your settings are dialed in. The value is front-loaded: getting there faster with fewer mistakes. And for anyone integrating Victron into a larger system without being a Victron specialist — it’s an always-available translator between your world and theirs.

7

Victron have already been implementing carefully curated AI features into the VRM stack. Every other attempt to date with AI has been underwhelming. It only needs to be a few percent off to have consequences.
I would never encourage handing off initial setup to an AI, we have enough users who lack experience attempting setups, empowering more is asking for trouble, and we’re already dealing with too many topics of failed efforts following poor AI advice.

I have used n8n and the api to extract data. The local device does not store trends and the real value is interpretation of longer term trends.
For critical infrastructure I will be keeping an llm as far away from it as possible.