# sigenergy2mqtt: Modbus to MQTT, with the untested case named > sigenergy2mqtt reads a Sigenergy energy system over Modbus and republishes it to MQTT, with four optional extras including Home Assistant auto-discovery. Its README is short and its manifest is more informative than the prose, since the version lives in a config file and the release tags are dates. **seud0nym/sigenergy2mqtt** — Publish Modbus data from Sigenergy to an MQTT Broker, with optional Home Assistant Auto-Discovery and PVOutput updating - Repository: https://github.com/seud0nym/sigenergy2mqtt - Stars: 66 · Forks: 8 - Language: Python - License: MIT - Published: 2026-08-23 · Updated: 2026-08-23 · Language: en - Canonical page: https://hysenlabs.com/projects/seud0nym-sigenergy2mqtt ## A Modbus to MQTT bridge with four extras The core is one sentence: sigenergy2mqtt is a bridge between the Modbus interface of the Sigenergy energy system and the MQTT publish/subscribe messaging protocol. Everything else is optional, and the four extras are worth separating because each answers a different annoyance. Device auto-discovery finds Sigenergy devices and their device IDs, which removes the need to specify the host IP address by hand. Home Assistant auto-discovery publishes the messages that let Home Assistant find the devices itself, which removes the manual configuration. PVOutput upload sends production and consumption data automatically, which removes a spreadsheet. And direct InfluxDB publishing writes the Modbus data to a v1 or v2 time series database for long-term storage and analysis, which is the one extra that changes the shape of the deployment rather than adding a destination. ## Two pre-requisites, one of them a setting The pre-requisites are short enough to quote in full, which is unusual and useful. The first is a Sigenergy energy storage system or PV inverter with Modbus-TCP enabled, either by the installer or through the mySigen app, so the bridge is reading a protocol the device is already exposing. The second is an MQTT broker, named as Mosquitto, running either standalone or installed as an app to Home Assistant. Both are the kind of requirement that silently fails when missing: without Modbus-TCP the script has nothing to connect to, and without a broker it has nowhere to publish. The README also points at two screenshot sections, a dashboard and a diagnostics view, which tells you the project ships an interface rather than being a bare script, and the topic list it publishes and subscribes to is documented separately under the sensors resources. ## Three install guides, one configuration ladder Installation is three documents rather than one set of commands, one each for Home Assistant, Docker and a plain Linux host, and the README deliberately sends you to whichever matches. Configuration is a four-step ladder, and the order is the whole point. A configuration file is read first, then environment variables, then command line options, then the Home Assistant app configuration. Each later source overrides the one before it, so a value in the file can be replaced by an environment variable and then by a flag. One exception is marked: command line options do not apply to the Home Assistant app. That makes the ladder asymmetric by design, since the app supplies its own configuration surface and a shell is not part of the deal. A combined reference covering the flags, the environment variables and the YAML keys together exists so you are not reading three documents side by side. ## The version lives in a config file, so the tags are dates The packaging metadata declares the version as dynamic rather than writing it inline, and the build backend is pointed at a file inside the package to read it from. That single choice explains the release tags, which are dates rather than semantic versions: 2026.9.15, then 2026.9.10 and 2026.9.9 in the same week. A date tag is a reasonable fit for a bridge that tracks a firmware-driven device, and it makes the freshness of a release legible at a glance. It also means there is nothing to compare against a prior major, so an upgrade is a matter of reading the changelog rather than reasoning about a version number. The newest tag is dated 2026-09-15, and the last push to the default branch main is dated 2026-09-30, so the branch is ahead of the newest release. ## Seven pinned dependencies on a src layout The dependency list is pinned exactly, with no ranges, which is the right call for something that talks to hardware. It holds aiohttp, paho-mqtt, psutil, pydantic-settings, pymodbus, requests and ruamel.yaml, all at fixed versions. Two of those carry most of the design. pymodbus is the Modbus client, so its version determines how the inverter's registers are read, and paho-mqtt is the MQTT client, so its version determines the protocol behaviour your broker sees. Python 3.12 or newer is required. The build declares an sdist that includes the package directory and a wheel built from it, and the console entry point maps the sigenergy2mqtt command to the package's main module. A test extra carries the usual asynchronous test stack plus a distributed runner and a coverage plugin, and the coverage script is configured to run the suite in parallel and write an XML report without failing the run on the first error. ## The container exposes 8502 and checks its own health The image is small and does one upgrade on the way in: ``` EXPOSE 8502 HEALTHCHECK --interval=30s --timeout=5s --start-period=45s --retries=3 \ CMD python -c "import urllib.request as u; u.urlopen('http://127.0.0.1:8502/health', timeout=4)" ``` The base is a Python 3.14 Alpine image, and the first layer runs a package upgrade across everything available, with the comment that this is done to mitigate vulnerabilities. The build then copies a prebuilt wheel in and installs it, and the container command is the sigenergy2mqtt entry point rather than a shell. The port and the health check are the two numbers worth planning around. A 45-second start period is generous, which suggests the author expected a slow first connection to the inverter rather than a fast local start, and it means a compose file with a shorter dependency wait will report the container as unhealthy before the bridge has finished starting. ## The disclaimer names the untested case The last section of the README is the one to read before deploying. sigenergy2mqtt was developed for the author's own use and has only been tested in a single-phase environment without AC or DC chargers, although a testing environment in software was built to emulate the chargers and the three-phase implementation. That is a precise and unusual admission: the gap between what the software models and what the hardware does is exactly the part with no physical test behind it. The rest of the repository supports taking the disclaimer seriously rather than ignoring it. There is a tests/ directory, a changelog, a resources/ tree holding the three install guides, the configuration documents and the topic list, a scripts/ directory, and both a .vscode/ and an .agent/ directory at the top level, so the emulated three-phase path is exercised in automation even where it was never exercised on a real install. ## Conclusion sigenergy2mqtt suits a Sigenergy owner with Modbus-TCP enabled who already runs an MQTT broker and wants the inverter's data in Home Assistant, PVOutput or InfluxDB without writing glue code. It does not suit someone whose installation has AC or DC chargers, because the author's disclaimer says the real hardware was never tested with them, only emulated. Before deploying, read the disclaimer, decide which of the four optional features you actually need, and note that the container listens on 8502 with a 45-second health start period, so a reverse proxy or a slow inverter handshake should be allowed for in your compose timeout. ## FAQ ### How do I add Sigenergy to my Home Assistant? Follow the Home Assistant installation guide in resources/homeassistant/README.md. The bridge can publish the messages that let Home Assistant auto-discover the Sigenergy devices, and the Home Assistant app configuration is the fourth and lowest precedence configuration source, while command line options do not apply to the app at all. ### What are the pre-requisites for sigenergy2mqtt? A Sigenergy energy storage system or PV inverter with Modbus-TCP enabled, either by your installer or through the mySigen app, and an MQTT broker such as Mosquitto running either standalone or installed as an app to Home Assistant. ### Which sigenergy2mqtt configuration source takes precedence? The order is configuration file, then environment variables, then command line options, then the Home Assistant app configuration, with each later source overriding the one before it. Command line options do not apply to the Home Assistant app, and a combined reference for the flags, the environment variables and the YAML keys is published under the configuration resources. ### What port does the sigenergy2mqtt Docker image expose? Port 8502, with a healthcheck that requests the health endpoint on the loopback address every 30 seconds with a 5-second timeout, a 45-second start period and 3 retries. The container command is the sigenergy2mqtt entry point, and the base image is Python 3.14 on Alpine with a full package upgrade applied during the build. ### Has sigenergy2mqtt been tested with chargers and three-phase? Not on real hardware. The README says it was developed for the author's own use and tested only in a single-phase environment without AC or DC chargers, with a software test environment built to emulate the chargers and the three-phase implementation. Problems should be raised as issues. ## Sources - [Official README](https://github.com/seud0nym/sigenergy2mqtt#readme) - [Project repository](https://github.com/seud0nym/sigenergy2mqtt) - [Release notes](https://github.com/seud0nym/sigenergy2mqtt/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/seud0nym-sigenergy2mqtt