Reading Data from Solaredge inverters via Modbus TCP

Tags: #<Tag:0x00007f6170948ad0> #<Tag:0x00007f6170948a08>

Why? I find it pretty easy actually and working rock steady…
Which SMA devices have you got?

Hi Kim,

I’m sure it’s easy when it’s up and running, but I’m still trying to receive data from my Sunny Boy inverter SB2.5-1VL-40. I’m using port 502, Id=2.

‘ModBus Data’ and ‘TCP Slave’ are properly online and also is the ‘Regular Poll’
I’m experimenting with the address 40200 (actual power)

My logfile presents incidentally a reading error, so it seems that there is some data available. But my linked item for presenting the actual power (number) remains empty.

Kind regards,
Pieter

I have the same SMA Sunnyboy Storage 2.5…
This is my things file: (Notice I have NOT added all registers, only those I wanted to catch).

Bridge modbus:tcp:inverter2 [ host="10.4.28.249", port=502, id=3, connectMaxTries=3] {


// SMA SunnyBoy Storage 2.5
	Bridge poller device_typ [ start=30053, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data device_typ [ readStart="30053", readValueType="int32"]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Condition
	Bridge poller status [ start=30201, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data status [ readStart="30201", readValueType="int32"]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 GridRelay on/off
	Bridge poller GridRelay [ start=30217, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data GridRelay [ readStart="30217", readValueType="int32"]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Total Yield.
	Bridge poller TotalYield [ start=30529, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data TotalYield [ readStart="30529", readValueType="int32", readTransform="JS(divide1000.js)" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Daily Yield
	Bridge poller DayYield [ start=30535, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data DayYield [ readStart="30535", readValueType="int32", readTransform="JS(divide1000.js)" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Power
	Bridge poller Power [ start=30775, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data Power [ readStart="30775", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 PowerL1
	Bridge poller PowerL1 [ start=30777, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PowerL1 [ readStart="30777", readValueType="int32", readTransform="JS(divide1000.js)" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Grid Voltage L1
	Bridge poller GVoltageL1 [ start=30783, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data GVoltageL1 [ readStart="30783", readValueType="int32", readTransform="JS(divide100.js)" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Current battery state of charge
	Bridge poller CurrentBatStatCharge [ start=30845, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data CurrentBatStatCharge [ readStart="30845", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Current battery capacity
	Bridge poller CurrentBatcapacity [ start=30847, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data CurrentBatcapacity [ readStart="30847", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 PowerDrawn
	Bridge poller PowerDrawn [ start=30865, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PowerDrawn [ readStart="30865", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Power grid feed-in
	Bridge poller PowerGridFeedIn [ start=30867, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PowerGridFeedIn [ readStart="30867", readValueType="int32" ]
	   	 
  	 }


// SMA SunnyBoy Storage 2.5 Battery oper. status
	Bridge poller BatteryStatus [ start=30955, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data BatteryStatus [ readStart="30955", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Status battery application area:
	Bridge poller BatteryAppArea [ start=31057, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data BatteryAppArea [ readStart="31057", readValueType="int32" ]
	   	 
  	 }


// SMA SunnyBoy Storage 2.5
	Bridge poller PowerDrawnGridL1 [ start=31265, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PowerDrawnGridL1 [ readStart="31265", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5
	Bridge poller PowerDrawnGridL2 [ start=31267, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PowerDrawnGridL2 [ readStart="31267", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5
	Bridge poller PowerDrawnGridL3 [ start=31269, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PowerDrawnGridL3 [ readStart="31269", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Present battery charge
	Bridge poller PresBatCharge [ start=31393, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data PresBatCharge [ readStart="31393", readValueType="int32" ]
	   	 
  	 }

// SMA SunnyBoy Storage 2.5 Present battery discharge
	Bridge poller PresBattDischarge [ start=31395, length=2, refresh=5000, type="input" ] {
	    
	    	 Thing data PresBattDischarge [ readStart="31395", readValueType="int32" ]
	   	 
  	 }

}

Ps. This my belong in a new thread for SMA devices… So if/when you have questions, you should start a new thread, and Tag me. And I´ll be there helping you :slight_smile:

Thank you verry much for this example.

I don’t have a ‘Sunny Boy Storage’ but a ‘Sunny Boy Solar Inverter’
I suppose this is a different device, but I will make some attemps with this input.

Ahh sorry… I misread, I thought it was the Storage (those damn SMA namings! :hot_face:)
Yours IS different… You´ll need the correct modbus registers for your device, which can be a pain to find on SMA website. I´ll check if I get the one you need when I get back home tonight.
I also have a SMA STP 6000TL-20 solar inverter working. And I have a LG Chem Battery, which also communicate (via the SMA SunnyBoy storage inverter)

And please start a new thread, otherweise others might complaint :smiley:

Existing thread, which it would seem sensible to continue

1 Like

Hello SolarEdge folks,

this is a short and humble question related to ModBus.

(I do hope this is not seen as hijacking the thread, if yes, please advise and I will create a new thread).

I have a working SolarEdge/ModBus connection nicely integrated with (latest) openHAB 2.5.1-2 (Release Build) on Raspberry Pi 2 Model B Rev 1.1

I am using the SolarEdge binding (binding-solaredge - 2.5.1) and data gets updated once every minute via the private API (which is the minimum value, as it seems, as defined per the binding config.

Example from log:

020-02-05 19:41:50.050 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.42 kW to 0.34 kW
2020-02-05 19:42:49.867 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.34 kW to 0.32 kW
2020-02-05 19:43:49.968 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.32 kW to 0.34 kW
2020-02-05 19:45:49.878 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.34 kW to 0.35 kW
2020-02-05 19:47:49.915 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.35 kW to 4.74 kW
2020-02-05 19:48:49.913 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 4.74 kW to 0.3 kW
2020-02-05 19:52:49.962 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.3 kW to 0.33 kW

What I do not understand:
Why is the local ModBus update frequency (artificially?) restricted to a 60 seconds interval?

I am asking because in the SolarEdge Monitor (Android application, which shows live data nicely on the cellphone as well) the data is updating much more frequently and reacts more “snappy” compared to what I can see in via ModBus/openHABian values.

If a cloud is passing by I immediately “see” this in my cellphone’s app, but there is rather often a delay in openHABian due to the “1 minute”-config.

In my world ModBus/openHABian should be picking up the data without any artificial delay, same like the cellphone app?

I wonder if my ModBus/SolarEdge-binding/openHABian configuration can be set up in a way, that I can see the same (more speedy) update frequency like what I can observe on my cellphone ,e.g every 5 seconds.

Please advice should I have missed or misunderstood something here, as there might be good reasons (which I am just not aware about).

Thanks for any enlightening comments!

[EDIT]: code fences :slight_smile:

You can change the update frequence in the modbus setting. I update my data in 6000ms (6 seconds). And it could probably be as low as 1000ms.
But I cant help unless you tell if you´re using modbus v2 or the old modbus v1 binding?

Hello Kim,

thanks for your fast reply.

I am not using any ModBus binding at all. I am using the SolarEdge binding.

As I said in my OP, I am not sure If I am asking this in the right place… please excuse If this should be the case.

Thanks for any guidance in this topic.

Then you are not using local modbus.
Hint, you might want to change if you do want more frequent updates? I do not know if you need extra/different interface options.

The Solaredge binding docs point out that the binding uses the solaredge API. Access rates are limited when using a public key. It also suggests how to try private API, but points out that may not be reliable.

But you wrote:

And

And

And for your question:

I would say you have misunderstood at least one basic thing… You´re not running modbus :wink:

But he is using the Solaredge binding.

Sorry for causing some confusion. I should have written “ModBus hardware” rather than ModBus.
The minimum allowed value for live date is 1, which I am already using.

I wonder why this can not be changed in the programming of the binding to allow 0.1 (=6 seconds), for example

What makes you think that the API the binding talks to is not rate limited?

Hi, thank you for the question.

I know that the PUBLIC API is limited to avoid users hammering the SolarEdge servers 24/7.

That is why I ordered the ModBus Hardware, as that will allow me to use the PRIVATE API using the setup seen in the screenshot.

What I see in reality, however, is that the private API updates less frequently (compared to the cellphone app). The cellphone app gets its data from the PUBLIC API (and still updates faster) which is kind of unexpected.

What exactly is the private api??

The private API intercepts the traffic to the SolarEdge Cloud and makes it available locally.

So using the private API, you can eleminate the need to first send the data away, just to be forced to download it again (using the Public API), directly afterwards as step 2.

(At least this is my understanding).

It sounds pretty ackward to me… Well, ackward is probably not the right word. But its first time I have heard of an inverter with its own API. Normally an inverter would support industrial standard communications, (like modbus, E-Bus, etc).

My SMA inverters I´ve got two options. And I´m actually using both at the same time, cause both options are through the ethernet of the devices.

  1. Is the devices which sends data to SMA cloud server (called Sunny Portal). This I have used from the start. My Inverter and my Storage Inverter communicated with the Energy Meter, which collect some of the data and send it to Sunny Portal.
  2. Direct access to each device (Inverters) through modbus protocol (ethernet). This is where I use openhab and the modbus binding, to connect to the devices and collect data to openhab.

I assume yours would be the exact same. And if I understand correctly, what you call Private API, is the same as my devices communicating with the SMA cloud server. And for this, you´re using the specific binding (SolarEdge Cloud binding).

What I suggest is to still continue to use that, and then try if you can access your inverters directly as well through an interfcae like ethernet using modbus or anything else.
I´m not quantee this will work, but I suspect it will. It all depends on your devices (inverters).

Hi, from the screenshot Bert was posting earlier he is using SolarEdge binding which can be installed directly from Paper UI. This binding is using API of SolarEdge cloud and it seems that appart from Public API SolarEdge is offering and which is limited in number of request per daty they offer additionally some less stable Private API. From the configuration of the binding it looks to me that it is not using Modbus as it only requires SolarEdge ID. There is however another SolarEdge binding based on Modbus which you can configure to poll as often as you want, I do reading every second for example. This binding is working together with Modbus binding. However you do not need any extra hardware on the invertor, it has an Ethernet port and you can enable on the invertor Modbus over TCP.

I do not know if there is other way, but I have installed this by putting into addon folder /usr/share/openhab2/addons/ following jar files

org.openhab.binding.modbus-2.4.0-SNAPSHOT.jar
org.openhab.binding.modbus.sunspec-2.4.0-SNAPSHOT.jar
org.openhab.io.transport.modbus-2.4.0-SNAPSHOT.jar

Then need to configure your Modbus thing, I do it in Paper UI

and then add things using SolarEdge binding - one for Invertor and one for the Meter where you select Modbus TCP slave as the bridge and configure polling frequency

I believe that binding you are using is for the cloud only. This SolarEdge binding is based on Sunspec which shared also with other invertors https://www.solaredge.com/sites/default/files/sunspec-implementation-technical-note.pdf and gives you way more details on usage then cloud based binding.

3 Likes