add Modbus Sunspec compatibility to opendtu-onbattery

[AloisKlingler]

this implementation is (maybe only partially) modbus-sunspec compatibility to simulate a sunspec energy-meter.

to have calculation (especially self-consumption) correct for e.g. fronius solar web you need to either place a 300€ fronius smart meter before each "foreign" inverter.

With this PR it is possible to configure OpenDTU with it's IP-address as a "Smartmeter" on Fronius Gen24 or Fronius Symo inverter. so the Fronius Inverter is able to poll current production and overall production continuously like a from a real fronius-smartmeter.

necessary configuration on OpenDTU:

configuration on an Gen24 Inverter:

visualisation on an Gen24 inverter:

visualisation of the additional "Smartmeter" in Fronius Solarweb as "Additional AC Source":

visualisation of the "Smartmeter" data in Solarweb is available as common curve like other inverters are:

for my OpenDTU (and also some other users of photovoltaikforum.com) this implementation is running now over a year (more or less) flawless.

to the PR: the tree conflicting files webapp_dist/* need to be resolved on merge. other conflicts I could solve.

[github-actions]

This pull-request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AloisKlingler]

@AndreasBoehm @schlimmchen @stefan123t
if I would change the above things, will the PR be merged?
what I can tell, the last released version from https://github.com/AloisKlingler/OpenDTU-FroniusSM-MB/releases/tag/v24.8.5-0.3.1 (the one with this PR) is running absolutely stable for me with one inverter. also about 10-20 users from photovoltaikforum.com use it and do not report issues.

I am not sure when I find time to do the changes requested above. my issue is, that adapting / merging to current OpenDTU versions (or also OpenDTU-OnBattery) is very time consuming caused by my knowledge.

it looks like there are some enhancement requests regarding ModbusTCP, I am happy if I can help, but I maybe need your help too if it is really wanted to be merged.

Thanks.

Best regards
Alois

[AndreasBoehm]

what if a user has configured multiple inverters?
Now that the DPL supports multiple inverters we shall not limit this feature a single inverter only.

[AloisKlingler]

with multiple inverters the modbus data for total power (40097 and 40098) and yieldtotal (40129 and 40130) is filled.
those two values are the important one which are accumulateable easily (like already done in the "Total Yield Total" and "Total Power" in webgui)

other data (like frequency, voltage, etc.) is not filled, as we do not know from which source to take, and accumulating / calculating averages makes no sense at all.
this data is not mandatory (at least not for fronius inverters) to accept the ModbusTCP as smartmeter.

[AndreasBoehm]

Let's talk about more about what this PR or your feature actually does, at least how i understood it. Please correct me if any of my assumptions are wrong.

• Its a ModbusTCP server that will be polled by other hardware to get data
• For this ModbusTCP server you implemented registers according to the 'SunSpec'-protocol

Changes that i would suggest

• it should have its own settings page as i don't see that its related to 'Network'
• classes, structs, fields need clear names, keeping ModbusTCPServer in mind
• cleanup the code, add more comments to make it easier to read and undrstand
• link a sunspec protocol documentation

I am wondering if this would be something that should be in the upstream project as its not related to having a battery at all?
https://github.com/tbnobody/OpenDTU

[AloisKlingler]

Let's talk about more about what this PR or your feature actually does, at least how i understood it. Please correct me if any of my assumptions are wrong.

• Its a ModbusTCP server that will be polled by other hardware to get data
• For this ModbusTCP server you implemented registers according to the 'SunSpec'-protocol

exactly.

Changes that i would suggest

• it should have its own settings page as i don't see that its related to 'Network'
• classes, structs, fields need clear names, keeping ModbusTCPServer in mind
• cleanup the code, add more comments to make it easier to read and undrstand
• link a sunspec protocol documentation

I copied existing elements with great difficulty to have the here available settings. I am sure I cannot manage to create its own page

renaming I can do, only the here mentioned? #1150 (comment)

code cleanup I think I can not do satisfying enough. I tried to make the code already best readable as possible for me.

the sunspec protocol documentation looks to be liable to pay costs: https://sunspec.org/sunspec-modbus-specifications/
I had as reference fronius registers (https://www.fronius.com/de/solarenergie/installateure-partner/technische-daten/alle-produkte/anlagen-monitoring/offene-schnittstellen/modbus-tcp) and also kostal registers (https://optosolar.se/produktfiler/modbusprotkollengelskakostalplenticoreplus.pdf)

I am wondering if this would be something that should be in the upstream project as its not related to having a battery at all? https://github.com/tbnobody/OpenDTU

there a previous modbus implementation was asked to offer a PR here.

[stefan123t]

@AloisKlingler there are three compatibel standards mentioned on the sunspec page you referred to:

• IEEE 1547-2018 - IEEE Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces (aka SunSpec)
• IEEE 2030.5-2018 - IEEE Standard for Smart Energy Profile Application Protocol
• IEEE 1815-2012 - IEEE Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3)

I have been able to download the IEEE_1547-2018_SunSpec.pdf PDF specifications for Distributed Energy Resource (DER) interoperability using the protocols defined in IEEE 2030.5-2018, IEEE 1815-2012 and SunSpec ModBus over TCP/IP transport via Ethernet / RS-485 (only the latter) from the above site. The other two are behind a paywall, access to which might be available to scientific researchers.

I agree with you all that it would be worthwhile to include this in the upstream project as it enables a standard ModBus interface besides MQTT and Web API to share data from the Hoymiles DTUs in the OpenDTU project.
Unfortunately @tbnobody and @schlimmchen have shown no need to include this functionality neither here tbnobody#582 nor there tbnobody#1893 so it was tried to add it to OpenDTU-OnBattery as it may be more applicable to integration with other Distribute Energy Resources.

I hope this may be (re-)considered at a later stage, once the PR has been more refined to both projects coding standards.

[github-actions]

This pull-request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull-request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LoQue90]

with victron adding the posibility to send a limit for pv inverters over modbus to any inverter that follows the sunspec protocol, adding this to openDTUonB would be great.
https://community.victronenergy.com/t/help-needed-sma-solar-edge-kostal-enphase-and-others/33869

someone already did add this question to tbnobody#1893

i do have not enough experience in coding to help build this, but i would like to help as much as i can.
I´ve running 4 hm-800 with openDTUonB and a ac coupled victron ess.

[github-actions]

This pull-request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LoQue90]

Still interesting :)

[AndreasBoehm]

@LoQue90 I would recommend you to create a feature request in Issues, because even though this PR mentions sunspec there are very different sunspec variants out there e.g. Smart Meter, Inverter, etc.

[LoQue90]

@AndreasBoehm i thought I don't add another FR because the first underlying needed part is the Modbus integration.
But I will pull together what is needed and open up a FR.
As far as I understand how opendtu and openDTUonB depending on each other, the Modbus part should be integrated in opendtu first?
Thanks for your work!

[AloisKlingler]

this PR only

• offers read access by Modbus TCP
• to a limited amount of registers (they which are used to be able to be a "readable" sunspec modbus tcp smartmeter"

there is no write to any registers implemented, also the further way back to the inverter is not implemented.

[AndreasBoehm]

This PR does integrate modbus, read only, but as discussed earlier in this PR we need to do a lot of cleanup to get this merged -> it probably makes more sense to start from scratch for this feature.

OpenDTU-OnBattery is based on OpenDTU, but not depending on it. If we want to integrate a feature we can do so, without the need to have this in OpenDTU first.

[LoQue90]

Thanks for the clarification!

[github-actions]

This pull-request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull-request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.