Modbus binding with Sunny Boy SMA inverter

My SMA inverter is connected via WLAN. It has a built in webserver, so I can connect it with my webbrowser without problems. This connection has no problems at all.
The connection problem in my logfile didn’t appear again this morning, so I assume it occurs due to small disturbances.

I can see that the inverter has an (original) own WLAN network active. This is for installation purposes and only visible when I’m in the direct vicinity of the device. Could it be possible that the modbus communicates over this original WLAN ?

Can you tell me how to clear the OpenHAB Cache ?

Not unless you have written your WLAN IP adresse in the brigde setting…
My Battery inverter is exactly the same, both LAN and WLAN. It also has WLAN turned ON, but openhab (modbus binding) CANT use it, cause it got its own IP adresse. I use the LAN IP ind the brigde setting.

Yeah… Got to a terminal (Putty etc…). Log in…
Enter this:
sudo systemctl stop openhab2.service (press return)

And then enter this:
sudo openhab-cli clean-cache (press return and enter “Y” for ack.).

And then enter this:
sudo systemctl start openhab2.service (press return)

Openhab will start up, and it will take longer, because it has to rebuild the cache again.
Let openhab start up fully, (cant tell how long as it depends on the size of your system) and then do a new restart in the terminal by entering this:
sudo systemctl restart openhab2.service (press return)

You should have a nice clean and refreshed cache.

OK, Thanks.
I just cleaned the cache. Unfortunately no results.

I did some additional testing after I read some documentation on the SMA website. According to their documentation, external communication is possible through Modbus or their Webconnect service. Webconnect is a free service of SMA. I think it’s necessary to feed their App and portal with data.

I disconnected the Webconnect service on my inverter, but this makes no difference in OpenHAB.

Next, I switched off the modbus on my inverter. OpenHAB reacts immediately with errors in the logfile every five seconds.

My first conclusion is that the connection is technically OK.
I will now concentrate on the data formats. This could be the cause, especially when I look at the differences in de documentation of the several sma-devices.

I run web connect (Sunny Portal) as well. So using both webconnect and modbus doesnt have any influence… It works fine.

There has to be something wrong with your modbus setup… I just cant figure out where or why… It did work fine yesterday. Maybe Rossko have an idea.

Don’t worry about that at this stage; Modbus incorporates retries. Many slaves are sometimes just too busy to service a poll. When you get "Try 3 out of 3 failed ..." is the time to look into it.

I’m sure it’s just down to data Thing configuration. This requires knowledge of the target device registers - their format, if you will, as well as address and type.

I’m handicapped because I cannot see this spreadsheet, maybe my Excel is too ancient to deal with it.

Let’s concentrate on device type. You said you had that working at one time, reporting 9302. We don’t know what settings you used for that, I doubt you’ll remember!

You’re reading that using

// SMA SunnyBoy Device Type 30053 Device Type
     Bridge poller sma30053 [ start=30053, length=4, refresh=5000, type="input" ] {
        Thing data DevType [ readStart="30053", readValueType="int32" ]
     }

I think - please confirm, since your last changes.
So, what can be wrong with that? Maybe the address of course, maybe it should be holding not input - but maybe the type - is it really 32-bit?
It doesn’t need to be for 9032. If it is 32-bit, it is two 16-bit registers stuck together. Whch way round should they be stuck? A + B is nothing like B + A in this case, and will give hugely different results.

Let’s get the raw 16-bit data so that we can see more easily.

// SMA SunnyBoy Device Type 30053 Device Type
     Bridge poller sma30053 [ start=30053, length=4, refresh=5000, type="input" ] {
        Thing data DevType [ readStart="30053", readValueType="int32" ]
        Thing data DevTypeA [ readStart="30053", readValueType="uint16" ]
        Thing data DevTypeB [ readStart="30054", readValueType="uint16" ]
     }

We can interpret the same data different ways at the same time.
Make two temporary test Items

Number DevTypeA { channel="modbus:data:SMAinverter:sma30053:DevTypeA:number" }
Number DevTypeB { channel="modbus:data:SMAinverter:sma30053:DevTypeB:number" }

You don’t even need to put these on your sitemap if you watch for the update in your events.log after the first poll.
I’m expecting to find one of them is 9302?

Thanks Rossko.

I think that I had been playing with the data formats, but I don’t remember.

FYI, this is a screenshot of the spreadsheet.

Just added the temporary test items exactly as you described.

The values of DevTypeA and DevTypeB are switching every 5 seconds in my logfile between -1 to 65535 and back

2020-01-22 13:34:01.062 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:01.067 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:01.071 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:06.086 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:06.125 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:06.129 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:06.133 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:11.180 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:11.223 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:11.228 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:11.232 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:16.260 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:16.304 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:16.309 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:16.313 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:21.369 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:21.398 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:21.401 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:21.404 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:26.435 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:26.484 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:26.491 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:26.496 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:31.539 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:31.562 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

2020-01-22 13:34:31.564 [vent.ItemStateChangedEvent] - DevTypeA changed from -1 to 65535

2020-01-22 13:34:31.567 [vent.ItemStateChangedEvent] - DevTypeB changed from -1 to 65535

2020-01-22 13:34:36.586 [vent.ItemStateChangedEvent] - DevTypeB changed from 65535 to -1

2020-01-22 13:34:36.621 [vent.ItemStateChangedEvent] - DevTypeA changed from 65535 to -1

That is very odd… It looks like it´s not receiving anything at all… But it has been working yesterday.

Are you sure the IP and the device ID is still the same? I really cant think of anything doing this all of a sudden, except the connection somewhere. (Its just a wild guess).

EDIT - is modbus still activated inside the inverter… I wonder if it has gone back to default, which is OFF. However, I would have assumed the binding will complaint then. But this looks very odd to me.

uhhh you cannot get -1 from uint16 readDataType data Thing.
As it happens, 65535 (hex FFFF) is -1 for int16
To elaborate, that’s the same data interpreted two different ways.

I guess you’ve got two pollers running with each type, due to editing Things.
Restart the binding.

(The target is responding to Modbus polls, this is not data made up by the binding. If modbus were “disabled” in the target I would expect no response to polls? Not to say that there isn’t some gateway inbetween, which responds to polls but has no data. That’d be bad design, it happens.)

Okay, ignore my previous post then… I just think it looks very odd.

Well there was a post about fireplace or something recently … the supposed modbus service was provided by a separate gateway module, so yes there was added complication of getting gateway<>device comms working.

It is very odd, but it’s not a modbus communication problem

I´m sure the build-in “gateway” in his inverter is exact the same as in my inverter. So there shouldnt be a problem.

It has to be an openhab/modbus binding issue somewhere…

@Pjotr500
Perhaps delete the things file, start all over, create a new file with new poller/data naming…
And then start with only one data like the device type, which you know did work.

You won’t believe this.


I disabled the soft-access point on my inverter and changed the ID to 3 instead of 2.

Correct data is coming in now !!!

And it seems that DevTypeB has the correct value

If I remember right, these devices will respond on different IDs … with different data, different “pages” if you like.
This thread opened with a discussion about id=3

Yes, I tried this value several times, but without result. Also yesterday.
Perhaps I made more than one mistake in the beginning.

Does the ID matter, when its TCP/IP ?? I think I read somewhere it doesnt use ID when using modbus through ethernet…


Look at time 4:30 and forth…

Yes, it absolutely does.

A large number of TCP devices default to id=1
But the protocol absolutely requires an id in TCP (and so of course our binding implements it)
Why? That TCP target might be a gateway, say TCP<>serial. To function, it must be sent an id to address the right serial device on the other side. For master to know where a response comes from, it must come with id.
Even allows oddball reserved id like id=255 to address the gateway itself
This was all designed in decades ago,

As we’ve seen here, a TCP device can choose to respond to different ids with different data. You could for example have a modular design where id=1 be the modbus gateway itself, id=2 be a battery manager, id=3 be the solar controller, etc.

1 Like

But they´re all have unique IP`s. Why isnt that enough?

I’m talking about a modular system that has one ethernet plughole, one IP address, but allows you to address different modules using same IP + unique ID

I do not know if SMA implement that, but it is do-able. There will be a reason they use id=3 (and a reason that is default, implying that you can change it). Maybe it’s only relevant in industrial scale systems.

Whatever, the id is mandatory even in Modbus-TCP, and getting it wrong may “lead to disappointment” as they say.