Access Fronius SmartMeter

I try to read data from a Fronius Smart Meter 63A, connected via Modbus RTU to a Datamanager via Modbus TCP using the modbus.sunspec binding.
I have a things file with

Bridge modbus:tcp:bridgemeter [ host="", port=502, id=240, enableDiscovery=true ]
Thing modbus:meter-wye-phase:bridgemeter:fronius "Fronius SmartMeter" (modbus:tcp:bridgemeter) [ address=40069, length=127, refresh=15 ]

and and items file

Number:ElectricCurrent Fronius_Meter_Total_Power {channel="modbus:meter-wye-phase:bridge:fronius:ac-total-current"}

But get the following errors

2020-11-29 16:37:03.015 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint@5d956a[slaveId=240,functionCode=READ_MULTIPLE_REGISTERS,start=40069,length=127,maxTries=3]). Will try again soon. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID ea419547-7044-4fdd-ac0d-0a2862300f55]
2020-11-29 16:37:03.080 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusReadRequestBlueprint@5d956a[slaveId=240,functionCode=READ_MULTIPLE_REGISTERS,start=40069,length=127,maxTries=3]). Will try again soon. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID ea419547-7044-4fdd-ac0d-0a2862300f55]
2020-11-29 16:37:03.145 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusReadRequestBlueprint@5d956a[slaveId=240,functionCode=READ_MULTIPLE_REGISTERS,start=40069,length=127,maxTries=3]). Aborting. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID ea419547-7044-4fdd-ac0d-0a2862300f55]

It seems that there is an issue with the length, but from where do I get the correct block length? - As Reading data from the Fronius Symo at device ID 1 with length=52 seems to work.

After a few tries with different settings I reached

2020-11-29 20:47:36.853 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusReadRequestBlueprint@8214ec[slaveId=240,functionCode=READ_MULTIPLE_REGISTERS,start=40069,length=123,maxTries=3]). Aborting. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 2 [operation ID ad91ca77-4fb2-4f07-8a28-034d7660d2a3]

and changing the Sunspec Model Type from “int + SF” to “float” in the Fronius settings I get data, but completely weird values :frowning:

@mrbig do you have any idea? Is the float32 sunspec model supported by the binding? What is wrong in case I use the Int+SF model and get “Error Code = 2”?

Hello @ramack
had to look into the modbus source code, but if I’m not mistaken then code 2 means “Illegal address exception”:

This exception code is returned if the reference:

  • does not exist on the slave
  • the combination of reference and length exceeds the bounds of the existing registers.

Code 3 is illegal value exception:

This exception code indicates a fault in the structure of the data values of a complex request, such as an incorrect implied length. This code does not indicate a problem with application specific validity of the value.

So there must be an error either with the start address, or the block length you have specified. I highly recomment using the autodiscovery feature, wich will get the correct values from the invertert. The actual vendor implementations can vary slightly, and this is tolerated by the specification.

Thanks @mrbig for your investigation. It turned out, that the sunspec interpretation in the modbus binding doesn’t work with the float model of the Fronius and I read strange values with the int+sf model due to a wrong start address.

With this setting in the fronius datamanager
Bildschirmfoto von 2020-12-04 20-48-50
Bildschirmfoto von 2020-12-04 20-48-50

and the following things:

Bridge modbus:tcp:bridge "Fronius Inverter Bridge" [ host="", port=502, id=1, enableDiscovery=false ]
Thing modbus:inverter-three-phase:bridge:fronius "Fronius Symo" (modbus:tcp:bridge) [ address=40069, length=112, refresh=15 ]
Bridge modbus:tcp:meterbridge "Fronius Meter Bridge" [ host="", port=502, id=240, enableDiscovery=false ]
Thing modbus:meter-wye-phase:meterbridge:meter "Fronius SmartMeter" (modbus:tcp:meterbridge) [ address=40069, length=107, refresh=15 ]

and an extract of the items:

Number:Power Fronius_Meter_Total_Power "AC Power Total [%.1f W]" {channel="modbus:meter-wye-phase:meterbridge:meter:acGeneral#ac-total-real-power"}
Number:Energy Fronius_Energy "AC Lifetime Energy" {channel=" modbus:inverter-three-phase:bridge:fronius:acGeneral#ac-lifetime-energy"}

While the block length still is somehow magic for me it works now. Do you see a chance to add this info to the docs?

Autodiscovery does not work in my case, at least I do neither get anything helpful in the log nor a new thing in the inbox. If you see anything I should try to find out why, let me know. Additionally I would like to show some DC properties of the different strings - especially to compare the two string to detect an issue in one of them, but I don’t see anything how to access those.

The docs mention:

This group contains summarized data for the DC side of the inverter. DC information is summarized even if the inverter has multiple strings.

which is not correct for the Fronius - there the modbus address list cleary states Not supported if multiple DC inputs; current can be found in Multiple MPPT model

Is there any chance to get the value from the sunspec block 160 / the Multiple MPPT Inverter Extension Model?

Why not use the Fronius binding? I have submitted a PR to support reading the Smart Meter data as well.

If you just want to know the current power generated the the PV, and the total energy, that’s already supported in the Fronius binding.

I used the Fronius binding in the beginning, but it has even less datapoints (I think also limited by the used JSON API) than the sunspec. - So far I am using plain modbus and configure all datapoints by hand. As written above I at least want to read the different strings individually.

I’m curious which data do you need and what do you do with the data?

Having two strings, one in the lower part of the roof, where from time to time - especially in winter is - there is some shadow, seeing the effect on diagrams gives insight. In the long term it also helps to recognize dirt (which in my case is much more on the lower part) by the power ratio of the two strings.

Yes, having this is not essential, but as an engineer I am just too curios to not having this data :slight_smile: And even calculating once whether the lowest row of modules paid out or not is interesting.

Hi @ramack

You are correct, the Sunspec model supports only the int+SF format. According to my docs, the float format is completely different model. Also the int+SF seems to be more common, most of the other models do not have float variant.

The address and block length you came up with is pretty standard, so I wonder why the autodiscovery did fail. Any chance that you turn on logging for org.openhab.openhab.binding.modbus.* to INFO or TRACE level? Then I could see in more detail what is happening.

I looked into the docs, and the MPPT model does not seem to be that complicated. It contains a repeating block with relatively few fields, wich could be modelled in OH with things for each string. However without access to a physical device it could be quite tricky to implement it.

I have the logging on TRACE, but didn’t see anything interesting for autodiscovery. What should I look for?
For the MPPT I can for sure do some debugging if you have a jar for me. If you guide me I could even try to do it on my side but during the little time I have these days for Openhab, I’d prefer to work on the Resol binding. - Which is actually why I setup some basic system with OH3 right now :slight_smile:

After a few months of stable setup I installed a “Greenrock” battery and the controller needs the Fronius to operae in the float model for the sunspec :disappointed_relieved:

Any plans or ideas? Otherwise I guess I will have to set it up manually - or give the Fronius binding another try…

The Fronius binding seems to theoretically work, but in my setup it is extremely slow and often yields a timeout, as described in feature request [Fronius] increase timeout · Issue #11117 · openhab/openhab-addons · GitHub