Binding Request: SMA Sunny home manager using


yes, there ist the RRD4j persistance. This holds the data in backround and send it e.g. to cometvisu.


1 Like

Hello OpenHab community,

I just started to use OpenHab and to integrate all the different things. I also have a SMA Sunny Tripower and A Sunny Home Manager, which transfers all the data about produced and consumed energy to

I didn’t find any recent information / integration of that setup into OpenHab - is there any?

In other forums, I found the link to an internal (but pretty neat) API ( - which provides all the data I like to have:



Would it be a recommended way to import produced / consumed data from there? Is the HTTP binding an appropriate way to do so?

Thank you guys in advance,

I personally would not rely on a third party service when everything you need is present in your local network.
Like written above from others use the modbus binding with specific registers defined by your devices (can be found on the sma website) directly @OH. Another option is GitHub - datenschuft/SMA-EM: SMA Energymeter measurement - pretty nice for getting the modbus data via mqtt - which I am currently using as prod.

I know your this is an old thread but thanks for sharing your SMA config. Could need a bit assistance with that. I have a Tripower 10 which uses a lot of the same registers. However I am having trouble getting this to work with OH3. No matter what IP I put in it always displays as “online”. What IP are you using? I connect to the web config (LAN) by, Speedwire is and WiFi So I set it to the 66 and 502/3, same config as yours. Once I put the files in the correct paths I get a long list of TP_things, the tripower thing got no channels so I assume I have to get that from the TP_ things? They don´t seem to get any data, any chance to validate the connection to the Tripower?

the configuration is still the same. You need the LAN IP.
If you add the thing file than you should see a lot of new things in the openhab configuration. If these things are online than the communication works. But this is only the getting of the data.
In second step you need the items. If you add this item file than the items sould appear in the openhab configuration.

1 Like

I did check with the RMMS tool if the modbus thing is working and I was able to connect and fetch some data with that. Anyway, back to OpenHAB for example with TP_30537_2 “Tagesertrag” if I go to channels it remains “NULL”. So it looks to me like there is no connection.
What exactly to the other numbers in the config?
Number TPTagesertrag “Tagesertrag [%d kWh]” (gPV) { channel=" modbus:data:tripower:input_30529_72:30537_2:number" }

I understood 30529 is the register but what is _72 and _2 doing?
In the RMMS test tool I get 10 values as a result (probably due to the length 10) +1 and +7 are increasing, so probably the current “Ertrag” (*wir könnten das auch in Deutsch machen aber ich will hier das Forum nicht sabotieren :wink: )

What does your openhab.log have to say about modbus?

“tripower” as used here is some arbitrary name that you gave to some TCP or Serial modbus Bridge Thing. The “owning” Thing, if you like.

“input_30529_72” is some arbitrary name that you gave to some modbus poller Thing.
Maybe you’ve chosen to use a convention, at a guess the “input” part represents the modbus register type, “30529” the base register address, “72” the block length?

“30537_2” is some arbitrary name that you gave to some modbus data Thing.
Maybe you’ve chosen to use a convention, at a guess the “30537” part represents a register address, maybe the “2” is because it’s a two-register 32-bit value.

There’s no magic here; it just needs to match Things and channels that you configured and chose your own names for. Yes, I realise you copy-pasted really, but these are just names to match up.

Show us the settings you used there.

1 Like

Yes, this is exactly how I set the names. So you can always see which register is read.
The bridge:

Bridge poller input_30529_72 "TP_Input_30529_72" [ start=30529, length=72, refresh=2000, type="input" ]

polls the data from the device. It starts with register 30529 and it’s reading 72 16-bit words every 2 seconds. There is a limit on the SMA devices how meny registers you can read at once, it is in the documentation. This is the reason why there is a lot of bridges.

The thing inside if this bridge:

Thing data 30529_2 "TP_30529_2" [ readStart="30529", readValueType="uint32"]

Reads reads from this recived data the register 30529 a “uint32”, this is a 2 16-bit words value and saves this inside of 30529_2.

The Item is the interface to this thing, it is referencing to the bridge input_30529_72 and thing 30529_2 , like above.

Number TestValue "Test [%d W]"   { channel="modbus:data:boystorage:input_30529_72 :30529_2 :number" }

Edit: Typo: Changed Byte into 16-bit words

1 Like

72 16-bit words to be pedantic, but that’s the principle yes.

1 Like

Oh, yes, you’re right, I was to fast… fixed.

1 Like

Okay understood.
The settings I used wit RMMS:
Device ID : 3
Holding registers
Address 30529
Length 10 (2 works too)
Display Options: Decimal

Okay I think I undrstand the concept now. The item got 11 channels and Value as Number is marked with a blue (1)

However it remains NULL.

It’s not getting 11 item types. The modbus item type has different channels for value conversion and several status channels. If you link the channel “number” then the value of the thing will be converted into a openhab number item (this is what the item config file does). If you link the string channel then you will get an openhab string item etc. etc. It depends on what you want to do with this modbus value.
It looks good, should works.

1 Like

Maybe limit as first the range of the bridge poller input to a length of 2 and only one thing/item. Maybe it’s not possible on your device to read 72 words starting with this register…

1 Like

Here’s the hierarchy;

A modbus Bridge TCP or serial Thing defines a device - the IP address, the ID number etc.

A modbus poller Thing defines a block of registers to fetch - address, type, how many.
A Bridge may have several pollers.

A data Thing defines how to deal with one or more of that block of registers. A poller may have several data Things.
Because registers are just numbers, the data Thing offers a number of ways to interpret the same number - as a Dimmer or Switch, for example.

Finally, you can link one those data Thing channels to an appropriate Item type.

None of it works unless you get the correct settings in your various Things. If there is something wrong, your openhab.log will most likely be telling you about it.

equivalent -

Bridge modbus:tcp:yourDeviceName [ host="your.mystery.ip.address", port=502, id=3 ] {
// poller to follow

Here we must be careful. There are two ways to count modbus addresses. You can start with 0, or you can start with 1. There’s no way to guess which one a manufacturer uses unless they tell you in the manual.

openHAB modbus binding always uses “start from 0”.

Luckily @Markinus has already been through this and knows SMA address blocks should start with an odd (not even) number.

Equivalent -

Bridge modbus:tcp:yourDeviceName [ host="your.mystery.ip.address", port=502, id=3 ] {
   Bridge poller yourPollerName [ start=30529, length=10, refresh=2000, type="holding" ] {
      // data Thing to follow

But -

Are you really sure? Markinus uses input type.



Bridge modbus:tcp:yourDeviceName [ host="your.mystery.ip.address", port=502, id=3 ] {
   Bridge poller yourPollerName [ start=30529, length=10, refresh=2000, type="holding" ] {
      Thing data yourDataName [ readStart="30529", readValueType="uint16"]

None of that is any good until you link it to an Item, so

Number myItem "some text" {channel="modbus:data:yourDeviceName:yourPollerName:yourDataName:number" }
1 Like

Holding registers is what SMA suggests for the RMMS tool, so yes I used those with it.
Since I am not getting any further with the config files I am currently trying to replicate a basic structure using the GUI but with the same result. @Markinus This is the pretty reduced version now, only looking at the 30529, I also tried with a length of 2, holding register as well as input register. Isn´t that quite the same I did with RMMS? Shouldn´t be an issue of the Tripower then. Also nothing in the log about it now :-/

Bit of a whopping clue.
Give it a garbage IP address to make it fail, and fix the binding install or config or logging until you see the expected errors. Then return to trying with real settings.

Always exercise caution when editing Things, ideally restart binding to ensure latest settings are in use.
When the binding does start, you should get at least one announcement in your openhab.log

1 Like

Thanks! This was the deal. Reinstalling the binding. I really should keep that in mind. Now I get incremental values :slight_smile: