SMA Energy Meter Binding yields unplausible values

Ok, are you interested in this output from netsat - what do you get out of it:

udp6  215040      0 :::9522                 :::*
udp6  212992      0 :::9522                 :::*
udp6  215040      0 :::9522                 :::*
udp6  212992      0 :::9522                 :::*
udp6  215040      0 :::9522                 :::*
udp6  212992      0 :::9522                 :::*

It seems to me that I have a problem that is unusual and does not occur with you - my GridFeedInPowerL1 is not receiving any data from the HM. The event log clearly shows that there is no event for GridFeedInPowerL1 in the log:

2024-02-13 09:19:31.454 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedPower' changed from 13.0 to 0.0
2024-02-13 09:19:31.455 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPower' changed from 0.0 to 6.7
2024-02-13 09:19:31.455 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedPowerL1' changed from 1478.5 to 1468.3
2024-02-13 09:19:31.456 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedEnergyL1' changed from 3942.739 to 3942.741
2024-02-13 09:19:31.457 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPowerL2' changed from 724.3 to 729.3
2024-02-13 09:19:31.459 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergyL2' changed from 7886.4346 to 7886.4355
2024-02-13 09:19:31.460 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPowerL3' changed from 741.2 to 745.7
2024-02-13 09:19:31.461 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergyL3' changed from 8062.3584 to 8062.3594
2024-02-13 09:19:32.995 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedPower' changed from 0.0 to 11.1
2024-02-13 09:19:32.996 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPower' changed from 6.7 to 0.0
2024-02-13 09:19:32.998 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedEnergy' changed from 2208.305 to 2208.3047
2024-02-13 09:19:32.999 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedPowerL1' changed from 1468.3 to 1459.0
2024-02-13 09:19:33.001 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedEnergyL1' changed from 3942.741 to 3942.729
2024-02-13 09:19:33.003 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPowerL2' changed from 729.3 to 715.4
2024-02-13 09:19:33.004 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergyL2' changed from 7886.4355 to 7886.429
2024-02-13 09:19:33.006 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPowerL3' changed from 745.7 to 732.6
2024-02-13 09:19:33.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergyL3' changed from 8062.3594 to 8062.3535
2024-02-13 09:19:35.605 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedPower' changed from 11.1 to 23.5
2024-02-13 09:19:35.608 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedEnergy' changed from 2208.3047 to 2208.311
2024-02-13 09:19:35.611 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergy' changed from 18780.59 to 18780.596
2024-02-13 09:19:35.611 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedPowerL1' changed from 1459.0 to 1818.1
2024-02-13 09:19:35.613 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedEnergyL1' changed from 3942.729 to 3943.5627
2024-02-13 09:19:35.613 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPowerL2' changed from 715.4 to 991.2
2024-02-13 09:19:35.616 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergyL2' changed from 7886.429 to 7886.863
2024-02-13 09:19:35.616 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinPowerL3' changed from 732.6 to 803.4
2024-02-13 09:19:35.617 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_PurchasedEnergyL3' changed from 1304.8967 to 1304.8969
2024-02-13 09:19:35.617 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SMAEnergyMeter_GridFeedinEnergyL3' changed from 8062.3535 to 8062.754

Do you have any idea why I am facing this issue?

Do you see any delays? Is L1 + L2 + L3 power equal to Total power?

What position are we talking about when you ask me if there is a delay? The inverter in its web front end shows everything correctly. The binding with its channels does not!
If I am to name a Total, it would be important for me to get the name of the channel of interest - e.g. GridFeedInPower (Total?)

In my case I can see in OpenHab:
powerOutL2 (Grid feed-in power L2) + powerOutL3 (Grid feed-in power L3) = powerInL1 (Purchased Power L1)

@Totomar @tomE @lsiepel @Lolodomo
Hi all
After reviewing the update binding, and days of try-outs, I have quite some of remarks.
SMAmeterRequiredBindingUpdates.pdf (735.2 KB)

I am not a full blown Java specialist, but I hope you take my considerations into account when updating the binding. No problem to test any available update.

@fcambron These are really good findings, I haven’t noticed that isOpen check is not effective.

In regard to the fixes - if condition is fixed then we shall not need socket reuse flag, it is a signal for OS network stack to begin multiplexing of packets. I’d rather attempt to do it on our end as we then could dispatch frames to proper handlers. The joinGroup call was previously in worker but it resulted in slow updates which you saw in your case. Probably it was due to accumulation of packets.

The frame parsing logic is older than my fixes, hence it misses for sure meter variants which come after 2020 (if not earlier!).

I saw new review comments from @Lolodomo, I’ll take care of them and also your findings within next build.

I have read your pdf document and am a little confused about this statement/approach:

As far as I understand, the HM sends values for all defined channels every second, so I would assume that you should accept all these data records and store them in an “In memory queue” in the binding and determine an average value for a period of time (e.g. 5, 10, 20, 30 seconds), which you then output to the channels accordingly. As far as I understand, at the moment I only get, for example, one of 30 received data records, as the production values can fluctuate greatly within 30 seconds, the value is very volatile.

I would like to apologize if I am annoying you in the wrong place, I am just trying to make a helpful contribution - but I have to get into the subject first.

I’ve installed an IntelliJ and checked out the repo to look at the source code, but haven’t had time to get it running yet. Is there a readme to get initial info on how to get it to fly - start the binding to access to subscribe to the multicast group?

What about extending the binding with http/rest requests to get data also from the SunnyWebPortal or the inverters itself?

When I searched for the integration of SMA products, I found something with developer APIs:

Are you familiar with this possibilities or could you do something with it?

The binding is indeed sampling the power values every 30s (default). As a result 29 out of 30 samples are ignored. The sampled value is only an indication of the power usage, and only more or less correct if the power flow is quite stable. Averaging all values might be difficult (I don’t know if openhab is able to handle bindings at a 1 sec pace). Alternative could be to calculate the average as the (delta energy) divided by (delta time).

My update jar file is available at:

I you want to build the jar yourself. Install Java17 and Maven on your computer. Goto to folder:
and run: mvn clean install -pl :org.openhab.binding.smaenergymeter
sometimes also mvn spotless:apply is required. If succesfull, you will find the jar file in the target folder.
More info on:

About SMA API. It looks like this is only B2B, and not available for private usage

Updated binding should listen continuously but publish value only at configured ratio. This is a basic “debounce” mechanism to avoid spamming openHAB event bus with tens of events every second without possibility to control. There is no built-in sampling limiter within the distribution hence publishing every meter frame into bus would hit it quite hard. Even with persistence configured with every change strategy, you will get a lot of writes because, values such as voltage / power / current always change.

Thanks @fcambron for the confirmation, but I don’t think I’ve explained my suggestion properly yet.
The binding, which is a java thread that runs, already gets the data every second, even if it were polling, that doesn’t really make a load. The binding fetches the data every second into a “list” (cache, buffer, in memory queue …) until there are as many entries as time is configured (e.g. 30 seconds). Then an average is calculated from the entries (algorithm per category?) and this value is delivered to OpenHab → Channel event!? This means that there are no more data records than before, but the quality of the information is better.
In the words of splatch “basic “debounce” mechanism” I would call my proposal an advanced decoupling mechanism

Regarding the testing of binding changes, you always do a build and deployment in OpenHab - can’t you test directly against the HM from the IDE?

Will it also work with OpenHab 4.1 ?

Maybe I will take a look at the dev API of SMA sometime and get in contact with them to evaluate what is possible. At the moment I have a heating system that the energy supplier shot down and that I now have to convert to Shellys and OpenHab :frowning:

Hi Thomas
Not sure if it will work with 4.1. Worth to try it. Otherwise you can build the 4.1 version from the connectorIO repository and select the branch sma-fixes-4.1 + update the 2 .java files + rebuild.
If you have problems with it, just let me know. I will do it for you.

Hi @fcambron,

I would have tested it already, but to be honest, I didn’t find the .jar file under the link you provided.

My update jar file is available at:

I’m probably too stupid to see it? :face_with_peeking_eye:

Jar file is included in zip file:
jar files cannot be directly uploaded to github

1 Like

@fcambron your download is not working anymore - just an .html behind!?

Hi Thomas. Sorry for this. Please try download from

The build for OpenHab 4.2.x is not working for me in OpenHab 4.1.
@fcambron - If you could provide a build for 4.1 I would appreciate it :slight_smile:

Hi Thomas. jar added for 4.1. However not tested, but build was OK

@fcambron I have added the binding this morning, but not able to find it after restart - nor in Inbox, search bindings … - just found the official binding provided with OpenHab.
I assume the binding should appear in the Inbox after removing the Thing ("SMA …)?
The logs do not show any error or warning, just Debug content.
So I gues the binding will not work with OpenHab 4.1!?

@Totomar On linux based system, you have to copy the jar file to /usr/share/openhab/addons
Best is to restart openhab as follows:
sudo systemctl stop openhab
sudo openhab-cli clean-cache
sudo systemctl start openhab

Once it is copied to that folder, it will appear under the “other Add-ons” on the Add-on Store page:

Next on the Things page, use the + sign in the corner down right and select
Schermafbeelding 2024-02-21 174537

then add manually:

All these screenshots are from the stable openHAB 4.1.1 release.

By the way, on which operating system is your Openhab running?
How many energymeter do you have in your network?
Are these SMA Homemager 2.0 or SMA Energymeter 20 ?

Good luck