I’d like to introduce Universal Modbus, a custom Home Assistant integration for configuring and controlling Modbus TCP devices entirely through the Home Assistant UI.
The project is intended for users who want to connect devices such as energy meters, inverters, heat pumps, wallboxes, PLCs, or other Modbus TCP equipment without maintaining a large YAML configuration.
Main features
Configure multiple Modbus TCP devices through the UI
Dedicated sidebar editor for hubs and entities
No YAML configuration required
Read coils, discrete inputs, holding registers, and input registers
Write coils and holding registers
Create the following Home Assistant entity types:
Sensor
Binary sensor
Switch
Pulsed toggle switch
Button
Number
Select
Support for bool, int16, uint16, int32, uint32, and float32
Configurable scaling, offsets, byte order, and word order
Optional separate feedback registers for writable entities
Import and export complete device configurations
Combined reads for overlapping or adjacent register ranges
English and German translations
Diagnostic entities for response time, communication errors, and the last successful poll
The sidebar editor can also display current values, show the connection status, trigger manual updates, and directly control writable entities.
The integration has been submitted for inclusion in the default HACS repository, but the review is still pending.
Until then, it can be installed as a custom HACS repository:
Open HACS
Select Integrations
Open the menu and choose Custom repositories
Add:
https://github.com/Idelmaeaen/HA-Universal-Modbus
Select Integration as the repository type
Download Universal Modbus
Restart Home Assistant
Open Settings → Devices & services → Add integration
Search for Universal Modbus
Important notes
Currently, only Modbus TCP is supported
Register addresses are zero-based and are passed directly to pymodbus
Users still need the Modbus register documentation for their device
The editor cannot verify whether a register address or command is valid for the connected hardware
Project and documentation
GitHub repository:
The README contains installation instructions, supported data types, entity configuration details, known limitations, and troubleshooting information.
I’m looking for testers using different types of Modbus TCP devices. Feedback, bug reports, device configuration examples, and feature suggestions are very welcome.
If you test it, please let me know which device you are using and how well the integration works with it.
‘Fall off a log’ easy to install and to set up.
Works.
Only minor wish is for the hub entities [Antwortzeit, Kommunikationsfehler, Letzte erfolgreiche Abfrage] to be in English!
Piggy-backed onto my USR Lipstick RS485 ethernet adapter, connected to Solis Hybrid inverter. Adapter is also being polled by Node-RED Modbus at 15 second intervals, so have to wait and see if read collisions occur.
Unsure why you do use “poll” from the node-red side, since the advantage against the ha modbus implementation is the ability to not poll by intervals but to perform a real read upon request/requirement. (modbus-flex-getter against using modbus-read)
And yes I wished for the HA modbus integration would some day get it’s counterpart to modbus_write which would likely get a name such as modbus_read, not asking to define an interval and poll the sever all day long without much sense.
Good addition, considering the state of native HA Modbus support.
Let me ask: how does it support HA devices? Does it allow it to group entities into them?
Any option to export/import settings? Sharing is one of the reasons. The second is to create a batch of entities in the text editor and then import them. Creating about 100 entities using the GUI (this is how many are created for my PV inverter) might be annoying.
Hello,
I have installed Universal‑Modbus and I’m now starting to work with it to evaluate its functionality. My initial experience with Universal‑Modbus is definitely positive. Being able to configure hubs and entities directly from the UI is very convenient.
I have two Modicon (AEG) A984‑145 PLCs (PLC21 and PLC22). The Modbus TCP connection over Ethernet is linked to an Ethernet‑Modbus router (174CEV30010), which converts Ethernet Modbus‑TCP to RS485 Modbus RTU. PLC22 is connected to the 174CEV via RS485, and PLC22 is further connected to PLC21 via Modbus+.
In Home Assistant, I have already created several entities whose data is displayed across multiple dashboards. These sensors are defined in modbus.yaml using Home Assistant’s built‑in Modbus syntax.
My goal is to migrate these sensors one by one to Universal‑Modbus. I want to keep the exact same entity names as those defined in modbus.yaml, otherwise I would need to update many dashboard references manually.
During this migration, I encountered the following issues:
I created two hubs in the Universal‑Modbus UI: • 174CEV‑PLC21 • 174CEV‑PLC22
When I create a sensor named “21_gew_temp_boiler” under the hub 174CEV‑PLC21, Universal‑Modbus automatically adds the hub prefix. The resulting entity becomes: sensor.174cev_plc21_21_gew_temp_boiler Even though I entered only “21_gew_temp_boiler” in the UI, and it also appears that way in the list. This means I would have to update the dashboards to use the longer name, which is inconvenient and impractical.
When I duplicate a sensor in the UM UI—intending to simply change the name and register—a copy is created immediately, even before clicking “Save”. For example: I have the sensor “22wp1_act_verbruik”. I duplicate it and immediately get “22wp1_act_verbruik copy” as the name. I remove “copy”, change wp1 to wp2, adjust the holding register, and then click “Save”. However, the entity sensor.174cev_plc22_22wp1_act_verbruik_copy already exists at that point. It does not appear in the UM UI, but it does show up under Developer Tools → States. I then have to manually delete each of these “…_copy” entities, which is not ideal.
The scan interval can only be configured at the hub level, and applies to all entities within that hub. It would be useful to configure the scan interval per entity. Some sensors are fine with 60 seconds or longer, while others require 5‑second polling.
Aside from these issues, I still have several questions, as there are a number of items in the UI whose purpose is not yet clear to me.
But that’s for another time.
Greetings.
