How to read a data from PV Victron energy via modbus?

I have PV system from Victron energy and I want read a data from this system into OpenHab and make a visualisation. I prefer modbus communication. Because I’m new to openhab I need a help with this and also I’m interested which visualisation is possible.
I already installed a modbus binding, but not sure how to continue, there is a lot of options:

I have a text programming:

Bridge mqtt:broker:venus "MQTT Broker VenusOS"[ host="",port="1883", secure=false ]
Thing mqtt:topic:victron "Victron VenusOS" (mqtt:broker:venus) {
    Type number : V_AC_V_L1 "Victron Verbrauch L1" [ stateTopic="N/b827eb9a431d/system/0/Ac/Consumption/L1/Power", transformationPattern="JSONPATH:$.value"]
    Type number : V_AC_V_L2 "Victron Verbrauch L2" [ stateTopic="N/b827eb9a431d/system/0/Ac/Consumption/L2/Power", transformationPattern="JSONPATH:$.value"]
    Type number : V_AC_V_L3 "Victron Verbrauch L3" [ stateTopic="N/b827eb9a431d/system/0/Ac/Consumption/L3/Power", transformationPattern="JSONPATH:$.value"]
    Type number : V_AC_G_L1 "Victron Netz L1"      [ stateTopic="N/b827eb9a431d/system/0/Ac/Grid/L1/Power", transformationPattern="JSONPATH:$.value"]
    Type number : V_AC_G_L2 "Victron Netz L2"      [ stateTopic="N/b827eb9a431d/system/0/Ac/Grid/L2/Power", transformationPattern="JSONPATH:$.value"]
    Type number : V_AC_G_L3 "Victron Netz L3"      [ stateTopic="N/b827eb9a431d/system/0/Ac/Grid/L3/Power", transformationPattern="JSONPATH:$.value"]

    Type number : V_DC_Power "Victron DC Power"    [ stateTopic="N/b827eb9a431d/battery/1/Dc/0/Power", transformationPattern="JSONPATH:$.value"]
    Type number : V_DC_Volt "Victron DC Volt"      [ stateTopic="N/b827eb9a431d/system/0/Dc/Battery/Voltage", transformationPattern="JSONPATH:$.value"]
    Type number : V_Batt_Soc "Victron Batt Soc"    [ stateTopic="N/b827eb9a431d/system/0/Dc/Battery/Soc", transformationPattern="JSONPATH:$.value"]
    Type number : V_Batt_Temp "Victron Batt Temp"  [ stateTopic="N/b827eb9a431d/battery/1/Dc/0/Temperature", transformationPattern="JSONPATH:$.value"]
    Type number : V_Batt_Curr "Victron Batterie Strom" [ stateTopic="N/b827eb9a431d/system/0/Dc/Battery/Current", transformationPattern="JSONPATH:$.value"]
    //Type number : V_Batt_Stat1 "Victron Batt Status1"  [ stateTopic="N/b827eb9a431d/system/0/Batteries", transformationPattern="JSONPATH:$.value[0].state"]
    Type number : V_Sys_Stat "Victron Sys Status"  [ stateTopic="N/b827eb9a431d/system/0/SystemState/State", transformationPattern="JSONPATH:$.value"]

Group Victron         "Victron"                          <energy>      (boilerroom)  ["Inverter"]
 Number V_AC_V_L1      "Victron Verbrauch L1 [%.1f W]"                 (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_AC_V_L1" }
 Number V_AC_V_L2      "Victron Verbrauch L2 [%.1f W]"                 (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_AC_V_L2" }
 Number V_AC_V_L3      "Victron Verbrauch L3 [%.1f W]"                 (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_AC_V_L3" }
 Number V_AC_G_L1      "Victron Netz L1 [%.1f W]"                      (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_AC_G_L1" }
 Number V_AC_G_L2      "Victron Netz L2 [%.1f W]"                      (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_AC_G_L2" }
 Number V_AC_G_L3      "Victron Netz L3 [%.1f W]"                      (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_AC_G_L3" }

 Number V_DC_Power     "Victron Battery Power [%.1f W]"                (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_DC_Power" }
 Number V_DC_Volt      "Victron Battery Volt [%.2f V]"                 (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_DC_Volt" }

 Number V_Batt_Soc     "Victron Battery Soc [%.1f %%]"  <battery>      (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_Batt_Soc" }
 Number V_Batt_Temp    "Victron Battery Temp [%.1f °C]" <temperatur>   (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_Batt_Temp" }
 Number V_Batt_Curr    "Victron Battery Strom [%.1f A]" <text> (Victron) ["Energy"]   { channel="mqtt:topic:victron:V_Batt_Curr" }
 //Number V_Batt_Stat1   "Victron Status [MAP(]" (Victron) ["Energy"] { channel="mqtt:topic:victron:V_Batt_Stat1" }

 Number V_Sys_Stat     "Victron Status [MAP(]" (Victron) ["Energy"] { channel="mqtt:topic:victron:V_Sys_Stat" }

But you may change it to UI

I’m not skilled with openhab, so not sure how complicated it is to change to UI.
Also I see that it’s MQTT. Not sure what’s difference between MQTT and Modbus.
I have komplete modbus TCP register list, but not sure how to configurate in modbus binding.

(commercial spoiler warning to apply)

I’m selling an energy management system that also supports Victron inverters using Modbus, see Energie Managen: Effektiv & Flexibel »
It’s essentially a shrink-wrapped openHAB-in-a-box image to run on a dedicated Raspi, but it’s also a full-blown openHAB installation that you can extend any way you like to or connect it to your main OH instance via remote binding.

If as you say you are not proficient in openHAB using this will save you a lot of time as it also contains most stuff you also will be looking for sooner or later like UI setup and rule templates.
And of course there’s the active energy management procedures, they’re designed to save you money by increasing your self consumption rate which is usually the real agenda / long term intention when people come here and ask for inverter monitoring.
You can download a free demo at

Thank you, but I want spend a time and make my own system. But you can help me with first steps and modbus configuration. I will be grateful.

Sure thing. You can deploy the system to work as an appliance but the EMS is written in OH so you can also use it as a knowledge repository if that’s really that what you’re up to. It includes OH modbus config templates for Victrons, tips’n’tricks to reuse in your UI setup, and sophisticated rules to copy’n paste from or use to teach yourself rules DSL.

You should be as there’s a lot of work involved with fiddling out, reverse engineering and validating configs to work with inverters. So why not express that gratitude in Euros ?

What I already did. I created a biridge :

next I want create a thing to read a data, there is only one option :

rest look like pre-defined for exact product

And here I’m not sure :

I know :


and from supplier a know:

what I’m not sure is where to place a slave and address information

I do not see, we are happy to help you, but PAY my business !!!

@mstormi is a valued part of this community. That does not oblige him to give free advice. He already has given some free advice.

There are many other people who can help. There is extensive existing documentation, and also examples in this forum. Because you are dealing with real people, “Do it all for me” generally does not get good results.
So -

that is an excellent approach. Modbus is very technical and there are a lot of details to configure in openHAB. There is no off-the-shelf solution. Except of course, where someone has invested their own time and effort to create one.

So spend some time and look at other people’s PV modbus configurations - not for the exact detail of your particular model, but for examples of how Modbus Things are structured, e.g. with pollers.

clear. Thanks. I need one information which isn’t clear for me and also can see in oter posts. I have two informations. Slave number and adress number. For me isn’t clear where what insert.

Have you seen the binding documentation?

IP address and Modbus ID are configured in a TCP Bridge Thing.

That’s not enough on its own to get useful information from the target device, because there are many thousand possible registers of different types that you might want to read from. You’d usually go on to create a poller Thing to select blocks of registers to read. There we are talking about register addresses and types of course. You’ll have seen that in the examples that you have already looked at.

I readed, but hard to understand for me, and also examples don’t look like for OH3 version.

Yes, it is hard to understand. Generic Modbus is very fiddly with a lot of codes and numbers. It’s very low-level with no built in help or self-identifying.

There are two ways to configure Things in OH3. The old fashioned way is from a text file, looking like

Bridge modbus:tcp:localhostTCPex2 [ host="", port=502 ] {

    Bridge poller items [ start=4, length=2, refresh=1000, type="discrete" ] {
        // read from index 4, write to coil 5
        Thing data readDiscrete4WriteCoil5 [ readStart="4", readValueType="bit", writeStart="5", writeValueType="bit", writeType="coil" ]
        Thing data resetCoil5 [ writeTransform="0", writeStart="5", writeValueType="bit", writeType="coil" ]

or you can configure using the GUI, like you are.

That’s just about configuring, the Things created are Things, just the same.

It’s easier for posters to include “text” configurations as shown above in examples and posts, that one above includes four different Things that would otherwise take four screenshots - and still not show clearly how they relate to each other as parent/child.

It’s not difficult to translate from one to other.

Some Modbus users stick to using text files, because with the large number of related Things it’s easier to manage in some ways. Some use GUI. Your choice.

You might be wasting your time here. Does this Victron unit conform to SunSpec standard?
Sunspec is an agreement amongst several manufacturers to use Modbus in the same way, all looking similar in data terms.

The Modbus binding includes a SunSpec extension that really simplifies configuring.

ok, when I have some tests done in UI, can I switch to text now ?
and back to modbus: I defined a bridge TCP slave : here I defined a IP adress, port and also as ID I inserted a slave number (in my case 100).
To this is connected a regular poll where I defined adress 842 (hope it’s adress where from I want read a data from previously defined slave 100). Length 1 and input register.
I think on the end I must create a modbus data thing, but there is again read address and this I don’t know what is it.

I can share my config, but I don’t know other method when I’m using a UI then make a screen copy

not sure if victron is a sunspec. Maybe yes

Look at the examples.
the data Thing is a child of a poller Thing.
The poller Thing defines a block of registers, say 842 to 849 (by configuring start 842, length 8)
If you want the data Thing to look at register 844, just say so (read start)

Note that if you wanted a 32-bit value, that is two of the 16-bit standard registers that the poller fetches, so saying start=844 there would have the data Thing use 844 and 845. That’s why it’s called start there as well, because there might be more than one register.

When you’ve finally made data Thing(s), they automatically get children channels of various types - mostly you would use the number type channel. That’s useless until you link it an Item (usually number) to be able to see the data.

Find out. You might save months - generic modbus is very fiddly.

looks like it’s part of sunspec :

so on the adress 842 I want read a information about power (W). It’s int16 (-32768 to 32767=65535 ) . So I need a 16bits to read means one 16-bit register. So only address 842