Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[sunspec] Add Modbus SunSpec Binding #3216

Closed
mrbig opened this issue Feb 7, 2018 · 44 comments
Closed

[sunspec] Add Modbus SunSpec Binding #3216

mrbig opened this issue Feb 7, 2018 · 44 comments
Assignees
Labels
new binding If someone has started to work on a binding. For a new binding PR.

Comments

@mrbig
Copy link

mrbig commented Feb 7, 2018

Dear openHAB developers!

This is a notification per contribution guidelines, that I started developing a new binding to support the so called "SunSpec" standard PV inverters and meters over the modbus protocol.

What is SunSpec?
"SunSpec publishes free, open interoperability specifications and information models that software developers, hardware manufacturers, and integrators use to achieve plug-and-play interoperability between Distributed Energy Resource (DER) components and smart grid applications. All SunSpec specifications are free to download and use. SunSpec also supports international standard communication protocols that adhere to open principles."
-- https://sunspec.org/about-sunspec-specifications/

What does that mean to openHAB?
SunSpec compatible devices could be connected to openHAB regardless who the manufacturer is. There are already several certified products from various manufacturers like ABB, Fronius, Schneider Electric, SMA, SolarEdge...

Design concepts
Original idea came from Thomas Kuehne's post https://community.openhab.org/t/reading-data-from-solaredge-inverters-via-modbus-tcp/26290/1 who set up monitoring with the modbus OH1 binding. But IMHO this method needs lots of tweaking mostly because there are some caveats in the SunSpec protocol. I'd like to make the sunspec binding more user friendly.

My concept is to have the inverters/meters as things, and all the data will be available as channels, OH2 style.

For the transport layer I use ssalonen's work in progress OH2 modbus binding (https://github.com/ssalonen/openhab2-addons/tree/modbus-openhab2-native-binding/addons/binding/org.openhab.binding.modbus ) which includes a very robust modbus transport I/O addon. So my binding uses the transport addon to handle all the modbus related stuff, and the handler mostly does parse and interpret the data and updates the states of the thing channels.

Work in progress code can be found here: https://github.com/mrbig/openhab2-addons/tree/3216-binding-sunspec-modbus/addons/binding/org.openhab.binding.modbus.sunspec

Since this will be my first OH binding, any feedbacks, ideas, comments are welcome!

@wborn wborn added the new binding If someone has started to work on a binding. For a new binding PR. label Mar 25, 2018
@mrbig
Copy link
Author

mrbig commented May 9, 2018

@triller-telekom you commentend in PR #2246 :

The sunspec binding however should not be another "binding" but rather a separate OSGi bundle within this generic modbus binding.

Can you please point me to another binding how this is actually done?

I was trying to follow the advices of @kaikreuzer from this conversation: eclipse-archived/smarthome#5301 (comment)

@triller-telekom
Copy link

@mrbig The explanation from Kai is the proper way to do it.

Basically the extension should use the same binding id as the generic binding and not specify its own binding.xml, see
https://github.com/eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.bluetooth.blukii/src/main/java/org/eclipse/smarthome/binding/bluetooth/blukii/BlukiiBindingConstants.java#L27

@ssalonen
Copy link
Contributor

ssalonen commented Jun 2, 2018

@mrbig
Copy link
Author

mrbig commented Jun 4, 2018

Thanks @ssalonen yes I believe I did the same already when @triller-telekom commented. Maybe he was looking at different branch?

Anyways now I'm a bit on hold waiting for the modbus binding's approval.

@RealMalWare
Copy link

@mrbig If you start working on this excellent approach again (now that the modbus binding is approved) I'd be happy the to support you by testing the sunspec ids
1 - common
101 - single phase inverter
103 - three phase inverter
203 - three phase meter
801 - energy storage
802 - battery
803 - lithium-ion battery
with my devices.

@mrbig
Copy link
Author

mrbig commented Sep 15, 2018

Dear @PartTimeDev
thanks for reminding me. I've rebased my branch on top of the current development thread, and fixed any issues there existed.
Currently 101-103 inverters are supported, will you have some time to try it out? I'd like to be interested specially in three phase inverter.

If you're willing to compile openhab yourself you can find the sourcecode here: https://github.com/mrbig/openhab2-addons/tree/3216-binding-sunspec-modbus/addons/binding/org.openhab.binding.modbus.sunspec

Or I can send you the precompilend jars as well.

@RealMalWare
Copy link

@mrbig Thanks for the quick reaction!
Ran it from the debugger for now.

One phase inverter values seem to be fine - at least for my solar edge device. There might be single phase inverters where the first block is not starting at address 69.

Which brings me to the first issue regarding the three phase inverter. I need to set the start address for the block, as my three phaser is modeled like this:

address desc block id
40001 Well-known base address – 0x53756e53
40003 Common Model 1
40071 Energy Storage Base Model 801
40095 Battery Base Model 802
40117 Lithium-Ion Battery Model 803
40151 Inverter (Three Phase) 103
40203 (abcn) meter 203
40310 (abcn) meter external generator input 203

There should be a setting for this.
Or the fancy way: parse for 0x53756e53 from the start on. The next register should hold the ID followed by its length. Jump to length-offset-register, get ID + length...

Also I can not set a Bridge as there is no "Bridge Selection" control. Same for split phase.

Thing config

@mrbig
Copy link
Author

mrbig commented Sep 17, 2018

Thanks, I've fixed the issue with the bridge not showing up.

And you are right, it was a mistake to hardcode the begin address of the blocks into the binding. I'll change it to autodetect the available blocks, this could also be a nice way to implement autodiscovery.

@mrbig
Copy link
Author

mrbig commented Sep 26, 2018

Hello @PartTimeDev
yesterday I've pushed a new version of the binding wich supports sunspec meters and autodetection of the base address.
Unfortunately I do not have the possibility to test the meters against a real device, so please appreciate if there are some bugs.
Will you be able to test it out? Do you need the binding jar-s?

@RealMalWare
Copy link

Detection is working already. Pretty cool :)

Sunspec detector found block ModelBlock type=1 address=2 length=68
Sunspec detector found block ModelBlock type=801 address=70 length=24
Sunspec detector found block ModelBlock type=802 address=94 length=22
Sunspec detector found block ModelBlock type=803 address=116 length=34
Sunspec detector found block ModelBlock type=103 address=150 length=52
Sunspec detector found block ModelBlock type=203 address=202 length=107
Sunspec detector found block ModelBlock type=203 address=309 length=107

But it leaves me hanging there for the 3 phase device described earlier:

error

Modbus/Sunspec activity ends after that. (Eclipse hangs randomly while trying to debug - is driving me nuts)

2018-09-27 00:58:18.139 [WARN ] [t.m.internal.ModbusManagerImpl:614  ] - Try 1 out of 3 failed when executing request (BasicModbusReadRequestBlueprint@35b3328d[slaveId=1,functionCode=READ_MULTIPLE_REGISTERS,start=416,length=2,maxTries=3]). Will try again soon. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID 3c7cb250-3d67-4e7d-bddb-0fac21e54414]
2018-09-27 00:58:18.201 [WARN ] [t.m.internal.ModbusManagerImpl:614  ] - Try 2 out of 3 failed when executing request (BasicModbusReadRequestBlueprint@35b3328d[slaveId=1,functionCode=READ_MULTIPLE_REGISTERS,start=416,length=2,maxTries=3]). Will try again soon. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID 3c7cb250-3d67-4e7d-bddb-0fac21e54414]
2018-09-27 00:58:18.264 [ERROR] [t.m.internal.ModbusManagerImpl:618  ] - Last try 3 failed when executing request (BasicModbusReadRequestBlueprint@35b3328d[slaveId=1,functionCode=READ_MULTIPLE_REGISTERS,start=416,length=2,maxTries=3]). Aborting. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID 3c7cb250-3d67-4e7d-bddb-0fac21e54414]
2018-09-27 00:58:18.265 [WARN ] [b.m.s.i.detector.ModelDetector:281  ] - Error with read: org.openhab.io.transport.modbus.internal.ModbusSlaveErrorResponseExceptionImpl Slave responsed with error=3

Full log: https://gist.github.com/PartTimeDev/d116ada37fb00e7a60aa39ff61aab5cc


Works great for the Single Phase SolarEdge already (Besides number formatting 😬 ):
SolarEdge

https://gist.github.com/PartTimeDev/20515f683f28ba65bccfdf6ffd69f689

@mrbig
Copy link
Author

mrbig commented Sep 27, 2018

Thanks for the report and the logs. Looks like your device does not have an end model (id 0xffff) at the end of the block list. The detector now tries to find that one, but instead it receives a modbus exception.
I'll try to handle this exception as if the end model was received.

btw: the current detector will use the first available block. Your device has 2 three phase meters (203). I'm considering how this should be selectable? Either one could enter the base address for the block but it's prone to errors, or there could be just an instance selector (eg 1, 2, 3) that will tell wichone to use if there are multiple of the same type.

@mrbig
Copy link
Author

mrbig commented Sep 27, 2018

Hello @PartTimeDev , I've pushed a possible fix for your issue. I had to change a few thing in the modbus transport bundle as well, so make sure you recompile that as well.

@mrbig
Copy link
Author

mrbig commented Sep 28, 2018

I would like to add auto discovery to this feature set. I basically have everything ready for that, I just have to get hold of any new modbus slave bridge that shows up in the system.

And my problem is this: modbus bridges are handled by the modbus bundle (ModbusHandlerFactory) while my sunspec code resides in the sunspec bundle (SunSpecHandlerFactory). I don't know how the two could communicate with each other? Or is there a way get notification about newly created bridges?

@triller-telekom @ssalonen do you have any hints for me?

Thanks

@RealMalWare
Copy link

RealMalWare commented Sep 29, 2018

getting closer...
But the/my meter gives odd values. As it's the main/first meter, there should be reasonable values. Added some log lines in getScaled.
This somehow looks as if the scale factors are incorrectly set, as
2018-09-29 14:41:33.646 [INFO ] [b.m.s.h.AbstractSunSpecHandler:489 ] - getScaled: 239 * 10^-32768 = 0,0000000000
should be the voltage IMO

Screenshot from PaperUI

Log excerpt truncated, after a views seconds after start.

Regarding your former question, I'd go for the index to select out of multiple identical block types

@ssalonen
Copy link
Contributor

@mrbig I don't now directly but browsing the codebase found these resources:

Perhaps you can hook into those to listen for new things?

@triller-telekom
Copy link

@mrbig Regarding your discovery problem: You should not listen to any events here, this is not reliable and also a Thing must not have a handler attached when it is created... So instead you should do it like its done in bluetooth:

The generic Binding (in your case this has to go into the generic modbus binding, i.e. please extend it) should have a ModbusDicoveryParticipant interface like the one in bluetooth:

https://github.com/eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.bluetooth/src/main/java/org/eclipse/smarthome/binding/bluetooth/discovery/BluetoothDiscoveryParticipant.java

And in the generic Modbus discovery service you collect all participants via OSGi:

https://github.com/eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.bluetooth/src/main/java/org/eclipse/smarthome/binding/bluetooth/discovery/internal/BluetoothDiscoveryService.java#L110-L119

In your sunspec binding you can implement such a participant as an OSGi service like its done in the blukii binding for example:

https://github.com/eclipse/smarthome/blob/master/extensions/binding/org.eclipse.smarthome.binding.bluetooth.blukii/src/main/java/org/eclipse/smarthome/binding/bluetooth/blukii/internal/BlukiiDiscoveryParticipant.java

If you have any questions, feel free to ask. I hope these explanations are helpful.

@mrbig
Copy link
Author

mrbig commented Oct 1, 2018

@PartTimeDev ok, I thing I've found the problem, the scale factor was incorrectly handled by my parser. I pushed some updates, hope you'll be able to check this out.

@RealMalWare
Copy link

@mrbig tested the latest changes. Looks better now.

Seeing values the values -32768 and 32768, i guess the "not implemented" checks need to be changed? (See SMA page 13 or Sunspec page 14 )

Regarding all the 0s and 32768s I contacted the vendor for clarification if and which fields are field correctly.

Please check the (full) event log. There are way to much zeros. Besides that, some values seem to be reasonable but hiden behind some scale factor: 2018-10-03 23:56:34 - modbus_meter_wye_phase_a2df3b9c_acPhaseB_ac_exported_real_energy

PaperUI

@mrbig
Copy link
Author

mrbig commented Oct 23, 2018

Hi @PartTimeDev I believe I could fix those issues by now. I refactored a lot of parts of the parsing so unsupported fields should be much better handled by now.

I've also added auto discovery, and this should be the preferred way to add new items. If you update to the branch I've pushed today, then you'll be able to turn on discovery on modbus tcp slave via the gui or by the enableDiscovery=true parameter.

Then your things can be added through discovery: they should show up at the add new thing screen and in the inbox.

If you want to add a thing manually then you should use the address and the length attributes to set the start address and the length of the block you want to get handled.

@grizzlyfred
Copy link

Hi @mrbig
I am also very interested in getting readings not only from proprietary cloud service of the manufacturer but more fresh local data that is obviously there.
So far I have followed Mr. Kuehne's approach and been not lucky, nothing retrieved from the SE9K and its attached Modbus meter... though all should be there...
could you maybe offer a .jar - Artifact for the public to check out?

@mrbig
Copy link
Author

mrbig commented Oct 28, 2018

Hello @grizzlyfred ,

I've attached the current version. I consider it more on less ready, with the documentation updated things seem to work fine for me.

You will have to install the modbus and the modbus io package as well. There are some changes in my version in the modbus package as well, so make sure you use the one in the tarball below:
sunspec-devel-20181028.tar.gz

@mrbig
Copy link
Author

mrbig commented Oct 29, 2018

@grizzlyfred I've update the tar.gz because the previous had some errors referencing a non existing class.
Please try this one:
sunspec-devel-20181029.tar.gz
Also note, that my se4000 needs at least a second between tries. This can result in timeouts during the discovery. This is how I set up my bridge:

Bridge modbus:tcp:se4000 [ host="hostorip", port=502, id=1, timeBetweenReconnectMillis=1300, timeBetweenTransactionsMillis=1500, enableDiscovery=true, connectMaxTries=3]

Alternatively you can set a high reconnectAfterMillis value to keep the connection open:

Bridge modbus:tcp:se4000 [ host="hostorip", port=502, id=1, reconnectAfterMillis=3600000, enableDiscovery=true, connectMaxTries=3]

@flaviodexter
Copy link

Hi, I've installed today a solar edge inverter in my new house wich actually is stilla work in progress.
I have a bench installation of HO in the old house and plan to move to the new one in the upcoming weeks.
I'd love to test this binding. still its not clear to me how to configure the inverter. LAN connection seems to work only with proprietary solaredge protocol, so I guess I'll have to connect OH via RS485

@mrbig
Copy link
Author

mrbig commented Dec 10, 2018

Hi @flaviodexter ,
if you have network connection working, then there is a great chance that you will able to use this binding. Take a look at this document from solaredge "MODBUS over TCP Support" chapter describes how to enable modbus support. You can leave the port on default 502 and the device id on 1.

@wborn wborn changed the title enhancement: sunspec binding for solaredge inverters [sunspec] Add Modbus SunSpec Binding Dec 19, 2018
@wborn wborn added the PR pending There is a pull request for resolving the issue label Dec 19, 2018
mrbig added a commit to mrbig/openhab2-addons that referenced this issue Jan 26, 2020
SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
mrbig added a commit to mrbig/openhab2-addons that referenced this issue Mar 12, 2020
SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
mrbig added a commit to mrbig/openhab2-addons that referenced this issue Mar 21, 2020
SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
J-N-K pushed a commit that referenced this issue Apr 18, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: #3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
yfre pushed a commit to yfre/openhab-addons that referenced this issue Apr 27, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
Signed-off-by: Eugen Freiter <freiter@gmx.de>
markus7017 pushed a commit to markus7017/openhab-addons that referenced this issue May 29, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
LoungeFlyZ pushed a commit to LoungeFlyZ/openhab2-addons that referenced this issue Jun 8, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
J-N-K pushed a commit to J-N-K/openhab-addons that referenced this issue Jul 14, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
CSchlipp pushed a commit to CSchlipp/openhab-addons that referenced this issue Jul 26, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
Signed-off-by: CSchlipp <christian@schlipp.de>
@ssalonen
Copy link
Contributor

I think this issue is solved by PRs merged above?

@mrbig
Copy link
Author

mrbig commented Jul 28, 2020

You are right, I have absolutely forgot about this issue.

This has already been merged, and big thanks everyone for the help!

@mrbig mrbig closed this as completed Jul 28, 2020
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
DaanMeijer pushed a commit to DaanMeijer/openhab-addons that referenced this issue Sep 1, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
Signed-off-by: Daan Meijer <daan@studioseptember.nl>
markus7017 pushed a commit to markus7017/openhab-addons that referenced this issue Sep 19, 2020
* [sunspec] Modbus: SunSpec bundle basic version

SunSpec is an open standard for solar inverters and other related devices to share data about their internal state. The standard is implemented by several vendors like ABB, Fronius, SMA, Schneider Electric, Solaredge, etc.

The goal of this work is to add user friendly support of these devices to openHAB.

The standard is built on the Modbus protocol, so this work is heavily based on the Modbus binding. Also the Bluetooth binding and several of it's solutions were taken as an example how to extend an already existing binding with a new bundle.

Related issue: openhab#3216

This is a stripped down version of a SunSpec bundle aimed to ease reviewing.

Original PW with all the features can be found here:
  https://github.com/openhab/openhab2-addons/pull/4220

This version contains only a limited support for single phase inverters, but no auto discovery or any other fancy features are included.

Other changes from my original PR:
 - migrated to the new build system
 - using NonNull values wherever possible
 - modell classes were moved to a dto package and highly simplified
 - other minor code changes

Signed-off-by: Nagy Attila Gabor <mrbig@sneaker.hu>
@AchimWilden
Copy link

Hello,
I run a PV inverter and a battery inverter (both from SMA) at home, as well as a wallbox and make everything a little smarter. I've never heard of SunSpec before, so I've tried to read it and ended up here.
It all reads pretty well, but I can't figure out how to use it. I have an openHab installation running, the Modbus connection is used for the wallbox, for example, but what steps do I have to take to use autodicovery for SunSpec compatible inverters ...
I am not sure what to download and where to copy it to.

Then the next question: The last comment is two years old. Is the project still alive?

@mrbig
Copy link
Author

mrbig commented Nov 2, 2020

Hello @AchimWilden yes, it's still alive, and it has been merged into the main openhab release. Main documentation can be found here: https://www.openhab.org/addons/bindings/modbus.sunspec/
You should install both the modbus and the sunspec bindings. You can do this using the paperui as well.
You can the set it up using the paper ui as well: you will need to add first a modbus bridge (tcp or serial based on how you connect to your inverter), then turn on auto discovery on this bridge, then do a scan. If your inverter talks the protocol, then it should appear in the "inbox"

@AchimWilden
Copy link

AchimWilden commented Nov 3, 2020

Hi @mrbig,
thanks for the answer.
This is exactly how I would have imagined the installation.
But my problem is, when I search for "sun" under Addon in the PaperUI, there is no match in any category (apart from meetings related to any Samsung addons).
What am I doing wrong?
2020-11-03 07_21_07-Paper UI

@ssalonen
Copy link
Contributor

ssalonen commented Nov 3, 2020

@AchimWilden you might be suffering from this: #8538

Manual installation is one workaround...

That might be fixed with latest 2.5.x release but I am not sure. What version on openHAB do you have?

EDIT: installation might be simpler https://community.openhab.org/t/modbus-binding-with-sunny-boy-sma-inverter/81847/142?u=ssalonen

@AchimWilden
Copy link

Hi,
openHAB runs at version 2.5.10-1.
Okay, manual installation but how do I do it. That was the point of my initial question "what do I copy where"?
Sorry if I ask such simple questions, I am still at the beginning with my OH knowledge: - /

@ssalonen
Copy link
Contributor

ssalonen commented Nov 3, 2020

No problem!

EDIT: installation might be simpler https://community.openhab.org/t/modbus-binding-with-sunny-boy-sma-inverter/81847/142?u=ssalonen

First install modbus binding via paper ui.

The other modbus based addons like modbus.e3dc or modbus.sunspec you need install manually using the below instructions.

You can download the addons from https://www.openhab.org/download/

Under manual installation there is "Download openHAB 2.5.10 stable addons"

  • rename the downloaded .kar file to .zip
  • Unzip
  • find addon jars from the following locations of the extracted files:
    /repository/org/openhab/addons/bundles/
  • copy the jar file to your openhab addons folder

@AchimWilden
Copy link

A first hard-fought success. The addon is installed. Now the documentation of the binding finally picks up but the next question comes up.

I have now created a thing file based on the example in the documentation, with the following content

Bridge modbus:tcp:bridge [ host="192.168.133.16", port=502, id=3, enableDiscovery=true ] Thing modbus:inverter-three-phase:bridge:STP10000 "STP10000" (modbus:tcp:modbusbridge) [ address=40069, length=52, refresh=15 ]

What is still unclear to me is, what is this: modbus: inverter-three-phase: bridge:
In the example there is SE4000h, which is an inverter. Is that just a label and does it not matter what I write there or is there a lookup table with suppoertet inverter somewhere?

I want to read out an SMA STP10000. Where can I get the starting address? Or is that always register 40069?
I have found the definition of the Modbus register but which part the start register should point to is unclear.

Thanks for the help. Without them I would have given up in frustration :-)

@ssalonen
Copy link
Contributor

ssalonen commented Nov 3, 2020

@AchimWilden you should proceed creating a new thread in the community forums. The question will get more attention there

@AchimWilden
Copy link

correct you are right. I do it directly

@mrbig
Copy link
Author

mrbig commented Nov 3, 2020

@AchimWilden those are only labels. But please avoid setting up the inverter manually unless you really need this. The autodiscovery will try to find the starting address automatically wich can be a bit tricky if done by hand. If the device is found then it will be reported in undert the device properties, so if you really wish, you could later copy them into a file config.

@kaikreuzer kaikreuzer removed the PR pending There is a pull request for resolving the issue label Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new binding If someone has started to work on a binding. For a new binding PR.
Projects
None yet
Development

No branches or pull requests