Exactly. The big advantage of the modbus binding is that you can get much more information than just the power values and you can decide the poll rate.
Ok. I will try the modbus binding, but I thought modbus was just a generic transport layer. Where do I find the information on how to decode the data returned to get the values I need?
The problem was on my test environment. A Raspberry Pi 4 with Openhabian 32 Bit and could be related to the snapshot version.
I’ve now deleted all related things, the binding from the configuration, and the jar file from the add-on directory.
Cleaned the cache from Openhab and upgraded to the latest snapshot. I check the karaf console.
The strange thing was, that I still had a meter in the inbox. So, I removed this meter from the inbox. Cleaned the cache again and rebooted the system.
I’ve than copied the jar-file again in the add-on directory and now everything look good.
I got just one meter in the inbox with the correct serial number.
I will now observe the system and the values. If this is stable, I will change my second meter to the same multicast IP.
@splatch I’ve now tested the binding in different setups without any major problems.
Setup:
SMA meters:
SMA Home Manager 2.0 Firmware: 3.13.0.R
SMA Smart Meter 10 Firmware: 1.02.04.R
OpenHab:
Main: Openhabian 32 Bit with Openhab 3.3 GA on Raspberry Pi 4
Slave/Test: Openhabian 32 Bit with Openhab 3.4 GA on Raspberry Pi 4
As written before, I had some problems which I guess were related to some old data in the system.
With a clean system, the binding is working as expected. The meters are discovered in the inbox and the values are now correct for several days.
It was really important to get rid of any remaining data before the installation of the new binding. Which means: delete the thing, uninstall the binding in the console, remove any meter from the inbox, stop OpenHab, clean OpenHab cache.
I have only discovered two minor problems/warnings:
A)
I got the following error in the logfile, but only on the first start when I placed the jar-file in the folder:
[WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.smaenergymeter-3.4.0-20221127.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.smaenergymeter [26]
Unresolved requirement: Import-Package: org.openhab.core.config.core
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.4]
B)
When I shutdown OpenHab, I always have the following warning in the logfile at the end.
[WARN ] [.packet.PacketListener$ReceivingTask] - Failed to receive data for multicast group 239.12.255.254:9522
java.net.SocketException: Socket closed
at java.net.PlainDatagramSocketImpl.receive0(Native Method) ~[?:?]
at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:200) ~[?:?]
at java.net.DatagramSocket.receive(DatagramSocket.java:814) ~[?:?]
at org.openhab.binding.smaenergymeter.internal.packet.PacketListener$ReceivingTask.run(PacketListener.java:114) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Thanks for your effort to provide this new version of the binding.
Hello all,
thanks for all the effort you put into the development of the binding!
I was wondering if there is a version of the “SMA EnergyMeter” binding that runs under OH4.0.3 (Openhabian on Raspberry). It looks like the issue [smaenergymeter] Fix handling of broadcast frames is not yet fixed in the official repros.
Or is there a way to use this Version of the binding with OH4 “org.openhab.binding.smaenergymeter-3.4.0-20221127.jar”? It works fine for me with OH3, but than I head to upgrade and I thought the fix is implemented in the last Version of the Binding.
Greetings Marc
Changes in PR do not depend on OH version. I think 3.4.0 build should work mostly fine. Let me know if it fails, I’ll make a new build against 4.0.x or 4.1.x.
Hi Lukasz,
That would be awesome!
When I restart OH, (cache cleared) I cannot see any error message in openhab.log. In the event.log then the following message appears.
I have two energy meters and I have set the poll interval differently for test reasons.
2023-09-20 19:33:00.094 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:3014928569' changed from ONLINE to OFFLINE (GONE): No update received within 120 seconds
2023-09-20 19:36:52.845 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:1901450051' changed from OFFLINE (GONE): No update received within 60 seconds to UNINITIALIZED
2023-09-20 19:36:52.876 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:1901450051' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2023-09-20 19:36:54.964 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:1901450051' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2023-09-20 19:36:55.123 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:3014928569' changed from OFFLINE (GONE): No update received within 120 seconds to ONLINE
2023-09-20 19:37:54.986 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'smaenergymeter:energymeter:1901450051' changed from INITIALIZING to OFFLINE (GONE): No update received within 60 seconds
When I install the 4.0.3 SMA binding, the things come online, but the data has the issues described above, sometimes very high or very low values.
Greetings Marc
Hi @splatch,
I’ve the same problem as Marc described. I’ve upgraded from 3.4 to 4.0 with your jar file from version 3.4. Both meter went from online to gone, due to timeout problems as no update received.
I’ve still a second OpenHab in the the network which is still on 3.4. I’ve installed your binding on this instance and it works again like a charm. The current binding in OH4 does not handle the broadcast frames with the serial number, as your code did.
It may is not directly related to the OH4 update by it self. I had to upgrade the Java version which may impact the broadcast handling.
OH3 Environment:
openjdk version “11.0.18” 2023-01-17
OpenJDK Runtime Environment (build 11.0.18+10-post-Raspbian-1deb11u1)
OpenJDK Server VM (build 11.0.18+10-post-Raspbian-1deb11u1, mixed mode)
OH4:
openjdk version “17.0.7” 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Raspbian-1deb11u1rpt1)
OpenJDK Client VM (build 17.0.7+7-Raspbian-1deb11u1rpt1, mixed mode, emulated-client)
I’ve updated download links in earlier message: SMA Energy Meter Binding yields unplausible values - #71 by splatch. Please let me know if a clean build for 4.0.4 have issues. I had just single meter in earlier installation which I have no access any more, thus I can’t test binding behavior any more.
1 Like
I’ve installed the new binding in my OH 4.0.3 and removed every old meter from the inbox.
Both meter came right back to the inbox with the correct serial number.
I added them and linked some test items. It seams everything is working fine. Both meter are online and the values are correct. I will monitor the behavior the next days. Thanks for your support.
Thank you for commitment and quick turnover. While checking PR I’ve realized that fixes I’ve made soon will turn 2 years old. 
Since they are old enough to walk away I’ve somehow lost a fix for communication watchdog, which I might need to bring back later on to increase reliability and feedback loop for end user.
Thank you, Lukasz!
You made my day.
Your Binding works like a charm. All values are as expected.
Thank you very much for your support.
Greetings Marc
Thanks also from me. I have both an SMA Energy Meter (for PV power) and a SMA Home Controller 2.0 for the grid connection. They have both started working correctly again following an upgrade from 3.3 to 4.0.3
PJG
Running openhab 4.1.0M3 on Raspberry PI with org.openhab.binding.smaenergymeter-4.1.0-20230921.jar and SMA HM:
Getting following error in openhab.log:
Any idea what is wrong?
2023-11-28 03:10:07.090 [INFO ] [.packet.PacketListener$ReceivingTask] - Unexpected payload received for group 239.12.255.254:9522
java.io.IOException: java.lang.IllegalArgumentException: Received frame with wrong protocol ID [96, 101]
at org.openhab.binding.smaenergymeter.internal.handler.EnergyMeter.parse(EnergyMeter.java:108) ~[bundleFile:?]
at org.openhab.binding.smaenergymeter.internal.packet.PacketListener$ReceivingTask.run(PacketListener.java:117) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.lang.IllegalArgumentException: Received frame with wrong protocol ID [96, 101]
at org.openhab.binding.smaenergymeter.internal.handler.EnergyMeter.parse(EnergyMeter.java:81) ~[bundleFile:?]
… 7 more
In mean time upgraded to openhab 4.1.0 stable. on Raspberry PI
My setup consists of:
1/ SMA Homemanager 2.0: SN1, multicast 239.12.255.254, port 9522, ip: 192.168.2.52
2/ SMA Energymeter 20: SN2, multicast 239.12.255.253, port 9522, ip: 192.168.2.53
3/ SMA Energymeter 20: SN3, multicast 239.12.255.252, port 9522, ip: 192.168.2.54
I still get one of the following errors every 1 to 5 minutes (see post above) from every meter:
Unexpected payload received for group 239.12.255.254:9522
Unexpected payload received for group 239.12.255.253:9522
Unexpected payload received for group 239.12.255.252:9522
with: Received frame with wrong protocol ID
I also see that the associated power/energy items are updated with after a delay of 15-20minutes.
Please help. I am willing to verify any update of the binding or the settings.
The official release smaenerymeter binding does not have a delay, but still yields unplausible values as described earlier.
@splatch Still problems with this binding. See my last 2 posts in this thread. Is your code on github? How can I help to debug/verify this issue.
Thanks
I wouldn’t consider this as an error. From your log I see that your log level is set to INFO. I assume splatch has added this log output to check if the code is working. If I translate the output [96, 101] from hex to decimal I get 6065 which is one of the three possible packets SMA is currently transmitting.
The packet id’s are 6069, 6065 and 6081. Only 6069 contains the expected emeter values.
I recommend to change the log level to WARN.
Sorry for no reply for your earlier message, I missed your post. I second here Thomas point, that the log entries about wrong payload are expected, since home manager uses different packet header and emit different contents. I am not quite sure why would extra devices within network lead to delays in the processing.
Can you share your thing definition (without serial number), I will try to refresh my memory about this code and see if its possible that we have side effects caused by additional traffic within network.
Thanks a lot ,Thomas.
You are right.
The 2 reported wrong protocols are:
[96, 101] => 60 65
[96, -127] => 60 81 (-127 is two’s complement of 129)
Protocol [96, 69] does not show up in the error log.
I changed the log setting on the openhab setting / add-on settings page to Warning,
The errors in the log file are gone now.
Remains is the big delay till the items get updated. (Raspbarry Pi Openhab item update with new binding is > 10 minutes later than Nuc/Ubuntu Openhab item update with standard binding)