SMA Energy Meter Binding - Problems with 4.2.1

Hoerli · August 15, 2024, 9:37am

Hello Community,

I think I have to report an error

I have an SMA inverter with the “SMA Sunny Home Manager 2.0” energy meter.
The Home Manager can be read out with the binding “SMA Energy Meter Binding”.
This has worked more or less well so far.
Since openHAB 4.2.1, however, nothing works anymore.
No more values are read out.

What have I tried so far?

Examined the multicast traffic
=> The traffic arrives and I can intercept it via Wireshark, for example. (At first I suspected a router update as the problem, but this is not the case)
Created the Thing again
=> Always gets stuck in the Unknown status
Restarted openHAB
=> Did not help
Cleared the cache
=> Did not help
Reinstalled the binding
=> The following error appears in the error log when uninstalling:

2024-08-15 11:08:38.986 [WARN ] [$UnstoppableScheduledExecutorService] - shutdownNow() invoked on a shared thread pool 'OH-binding-smaenergymeter-listener'. This is a bug, please submit a bug report
java.lang.IllegalStateException: null
	at org.openhab.core.common.ThreadPoolManager$UnstoppableExecutorService.shutdownNow(ThreadPoolManager.java:242) ~[?:?]
	at org.openhab.binding.smaenergymeter.internal.packet.DefaultPacketListenerRegistry.shutdown(DefaultPacketListenerRegistry.java:67) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:245) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:687) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:531) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) ~[?:?]
	at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) ~[?:?]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:421) ~[?:?]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:165) ~[?:?]
	at org.apache.felix.scr.impl.manager.SingleComponentManager.ungetService(SingleComponentManager.java:1043) ~[?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:273) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$2.run(ServiceFactoryUse.java:1) ~[org.eclipse.osgi-3.18.0.jar:?]
	at java.security.AccessController.doPrivileged(AccessController.java:318) ~[?:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryUngetService(ServiceFactoryUse.java:270) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.ungetService(ServiceFactoryUse.java:167) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.ungetService(ServiceConsumer.java:53) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:632) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.ungetService(ServiceRegistry.java:613) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.ungetService(BundleContextImpl.java:703) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.apache.felix.scr.impl.manager.SingleRefPair.safeUngetService(SingleRefPair.java:109) ~[?:?]
	at org.apache.felix.scr.impl.manager.SingleRefPair.ungetServiceObjects(SingleRefPair.java:74) ~[?:?]
	at org.apache.felix.scr.impl.manager.DependencyManager$AbstractCustomizer.ungetService(DependencyManager.java:231) ~[?:?]
	at org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.close(DependencyManager.java:1426) ~[?:?]
	at org.apache.felix.scr.impl.manager.DependencyManager.deactivate(DependencyManager.java:1568) ~[?:?]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateDependencyManagers(AbstractComponentManager.java:1280) ~[?:?]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:854) ~[?:?]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:825) ~[?:?]
	at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:589) ~[?:?]
	at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:722) ~[?:?]
	at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:492) ~[?:?]
	at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:652) ~[?:?]
	at org.apache.felix.scr.impl.Activator.access$300(Activator.java:74) ~[?:?]
	at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:490) ~[?:?]
	at org.apache.felix.scr.impl.AbstractExtender$1.run(AbstractExtender.java:216) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at org.apache.felix.scr.impl.AbstractExtender.destroyExtension(AbstractExtender.java:238) ~[?:?]
	at org.apache.felix.scr.impl.AbstractExtender.bundleChanged(AbstractExtender.java:132) ~[?:?]
	at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:255) ~[?:?]
	at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:949) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:229) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:138) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:130) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:217) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.publishEvent(Module.java:499) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.doStop(Module.java:658) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.container.Module.stop(Module.java:521) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.stop(EquinoxBundle.java:472) ~[org.eclipse.osgi-3.18.0.jar:?]
	at org.apache.karaf.features.internal.service.BundleInstallSupportImpl.stopBundle(BundleInstallSupportImpl.java:171) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.stopBundle(FeaturesServiceImpl.java:1165) ~[?:?]
	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:783) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	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) [?:?]

My system:

Raspberry Pi 4B
Java version
openjdk 17.0.9 2023-10-17 LTS
OpenJDK Runtime Environment Zulu17.46+19-CA (build 17.0.9+8-LTS)
OpenJDK 64-Bit Server VM Zulu17.46+19-CA (build 17.0.9+8-LTS, mixed mode, sharing)
openHAB 4.2.1 (release build)

After reinstalling the binding about 5 times, I was able to manually add the Home Manager again.
It is now shown as online.
The automatic discovery did not work. Not even by pressing the SCAN button.
Apparently there is a problem with V4.2.1

florian-h05 · August 15, 2024, 6:09pm

Thanks for the report, but better report this to on GitHub: Sign in to GitHub · GitHub
There is no guarantee it is seen there, but devs tend to check the issues regularly but don’t have an eye on the whole community forum …

splatch · August 16, 2024, 4:06pm

Hello @Hoerli,
There were some changes in receiving of SMA data in 4.2.0 or 4.2.1 (not sure which release included addon fixes). Receiving of data did not change much, there is still an UDP socket opened by binding which you can confirm (under linux) with netstat -u|grep 9522.
Error you found in log might interfere a bit, cause it can lead to thread leak. It should however be fine after OH restart.

Hoerli · August 17, 2024, 9:07pm

Hi @florian-h05
I will do that.

@splatch
Something must have been done in 4.2.0. Before that, I always had extreme spikes of 2000000000 watts, which then disappeared.
As of 4.2.1, something else must have been fixed that caused the error.
Currently everything seems to be running normally again.

splatch · August 19, 2024, 3:09pm

Correct, there is updated packet parsing logic which refuses non-matching packets. It also filter incoming data so you can have multiple SMA meters in one installation.

If you could, please send me a pcap with sma meter udp packets you caught. I will replay them against 4.2.1 to confirm and hopefully fix your bug.

Best,
Łukasz

mstormi · October 7, 2024, 8:32pm

FWIW as also reported on Github, I am still seeing this with 4.3.0M2.
The SHM thing is stuck in unknown state and does not report feed-in. Neither bundle nor OH restarts change anything about it.

mstormi · October 8, 2024, 7:13am

@splatch FWIW I had to configure the SHM via .things as it wasn’t found on scanning, and manually adding it requires the serialNumber to be added.
Do you know the S/N format I need to use ?

splatch · October 8, 2024, 8:27am

@mstormi It is a string. We had some changes in this regard, before the long standing PR to fix packet handling was merged, but serial number remained to be a string. In terms of what to put in the string - it is hex representation of serial number. But with lover case characters. It could be that if you copy the SN from the meter with capital letters, it won’t work. Try small caps.

If you can confirm that’s the issue I can ship one liner to fix this.

mstormi · October 8, 2024, 2:21pm

Changing the decimal S/N to hex fixed it.
Please add that information to the binding docs and the UI description.

Then again, scanning did not make any SHM show up. But the textually configured thing is online now. Thanks.