[SOLVED] Many(+100) modbus pollers, is it slowing down the binding?

Thanks everyone!

The pull request is now merged to main snapshot version, and will be part of the 2.5.0 release.

I’ve tested the current snapshot from 20190129. It looks like the new feature ( updateUnchangedValuesEveryMillis) is not implemented here.

And i get a lot of errors like this one, went back to “org.openhab.binding.modbus-2.5.0-pr-4701-lazy-updates-SNAPSHOT.jar”:

2019-01-29 10:59:06.028 [ERROR] [org.openhab.binding.modbus          ] - FrameworkEvent ERROR - org.openhab.binding.modbus
org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.SingleComponentManager.getService()
        at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:222) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:508) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461) ~[?:?]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:624) ~[?:?]
        at org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:73) ~[?:?]
        at org.apache.felix.scr.impl.inject.BindParameters.getServiceObject(BindParameters.java:47) ~[?:?]
        at org.apache.felix.scr.impl.inject.methods.BindMethod.getServiceObject(BindMethod.java:662) ~[?:?]
        at org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2304) ~[?:?]
        at org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1915) ~[?:?]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:432) ~[?:?]
        at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:390) ~[?:?]
        at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:302) ~[?:?]
        at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1242) ~[?:?]
        at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1137) ~[?:?]
        at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:997) ~[?:?]
        at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1176) ~[?:?]
        at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) ~[?:?]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:920) ~[?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[?:?]
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:805) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry$1.run(ServiceRegistry.java:1) ~[?:?]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:803) ~[?:?]
        at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) ~[?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:912) ~[?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.unregister(AbstractComponentManager.java:877) ~[?:?]
        at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:135) ~[?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterService(AbstractComponentManager.java:954) ~[?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:808) ~[?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:790) ~[?:?]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:579) ~[?:?]
        at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:716) ~[?:?]
        at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:511) ~[?:?]
        at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:428) ~[?:?]
        at org.apache.felix.scr.impl.Activator.access$300(Activator.java:49) ~[?:?]
        at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:291) ~[?:?]
        at org.apache.felix.scr.impl.AbstractExtender$1.run(AbstractExtender.java:216) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
        at org.apache.felix.scr.impl.AbstractExtender.destroyExtension(AbstractExtender.java:238) ~[?:?]
        at org.apache.felix.scr.impl.AbstractExtender.bundleChanged(AbstractExtender.java:132) ~[?:?]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908) ~[?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) ~[?:?]
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher$1.run(EquinoxEventPublisher.java:124) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher$1.run(EquinoxEventPublisher.java:1) ~[?:?]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:122) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168) ~[?:?]
        at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) ~[?:?]
        at org.eclipse.osgi.container.Module.doStop(Module.java:634) ~[?:?]
        at org.eclipse.osgi.container.Module.stop(Module.java:498) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer.uninstall(ModuleContainer.java:399) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.uninstall(EquinoxBundle.java:446) ~[?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.uninstall(DirectoryWatcher.java:1098) ~[?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.uninstall(DirectoryWatcher.java:901) ~[?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:487) ~[?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) ~[?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) ~[?:?]

I just want to ask if it is fixed? Should I test with the current snapshot?

I am not sure, suggest you open separate thread for this, sounds like something wrong outside the binding.

Previously snapshot has reflected merged changes, perhaps there is something wrong there as well. Fix was merged after all. Did you remove the custom version from addons folder? What does bundle:list say? Does it say that correct version is active?

Just to be sure:
I download modbus snapshot for here:

https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.modbus

There are two additional folders which I do not use:

org.openhab.binding.modbus.sunspec/
org.openhab.binding.modbus.test/

my working version:

org.openhab.binding.modbus-2.5.0-pr-4701-lazy-updates-SNAPSHOT.jar
221 | Active   |  80 | 2.4.0                  | openHAB MODBUS Transport Bundle
229 | Active   |  80 | 2.5.0.201901250552     | Modbus Binding

with latest snapshot, the feature updateUnchangedValuesEveryMillis is not working:

221 | Active   |  80 | 2.4.0                  | openHAB MODBUS Transport Bundle
230 | Active   |  80 | 2.5.0.201901301419     | Modbus Binding

Thanks this was useful.

The sunspec folder refers to another piece of contribution from a fellow developer https://github.com/openhab/openhab2-addons/issues/3216. The pull request is still open actually. So indeed the version is matching what is in that PR.

You should be more lucky by following these instructions Frequently Asked Questions (FAQs)

I do not 100% understand what you have written.

Which version of the snapshot binding includes the updateUnchangedValuesEveryMillis feature.

The sunspec version? Should I test this one or wait until change goes to normal snapshot.

Hi

You downloaded “pull request build” (stuff being developed and reviewed) but what you really want is “snapshot build” (includes merged stuff but not work-in-progress stuff).

Check FAQ link for further instructions.

The download link in the FAQ for the snapshot binding looks wrong, can you provide me the new link?

hmm… it does work for me?

The blue text as below:

Perhaps you got confused by the 2.3.0 in openhab-addons-2.3.0-SNAPSHOT.kar? Take that only as example, actual link leads you to latest snapshot (find the kar file in the image):

I downloaded it from here now:
https://ci.openhab.org/job/openHAB2-Bundles/org.openhab.binding$org.openhab.binding.modbus/

Still the same, updateUnchangedValuesEveryMillis does not work.

I am not sure if that is the correct location. It certainly is not matching the FAQ I linked :frowning:

Please follow the FAQ, download the kar file and continue from there as guided.

Thanky ou for your reply.
I used the link you’ve and the FAQ provided to me. I’m on OH2.4 stable and don’t want to change to OH2.5 snapshot. This is why I do not use the full .kar file with all bindings. I only need the feature for modbus. This is why I use the lazy-pr-version from you. Works perfect.

If I click on openHAB2-Bundles on your screenshot
grafik
I can reach the single .jar download versions of the snapshot bindings. This is direct reachable by the link I posted.
Can I verify in any way, if the changes you’ve merged into the snapshot are exist in this snapshot binding? It looks like the last version which includes the change is the lazy pr4701 version.

Sorry but you still are not following the steps in FAQ.

It says

  • Snapshot build
    If you want to install the latest snapshot version of an add-on, you can download the archive file openhab-addons-2.3.0-SNAPSHOT.kar from https://ci.openhab.org/job/openHAB-Distribution/ . This file contains all add-ons that were built in the last successful snapshot build.
    The .kar file is a zip archive. You can extract the add-on’s jar file this archive file. The add-ons are stored in the folder repository/org/openhab/ (e.g. the Homematic add-on jar file is stored in repository/org/openhab/binding/org.openhab.binding.homematic/2.3.0-SNAPSHOT/ ).

Even though you just want to use snapshot for modbus, you still need download the kar file.

To use single snapshot from kar, read some further

The .kar file is a zip archive. You can extract the add-on’s jar file this archive file.

Note that you should not click openhab2-bundles link in ci.openhab.org. That leads you to download wrong files yet again.

Now I downloaded the .kar-file from https://ci.openhab.org/job/openHAB-Distribution/ and extract .jar-file from the subfolder repository/org/openhab.

This one has the same problem, updateUnchangedValuesEveryMillis does not work.

In the doc’s there is written:

Modbus binding by default is not updating the item and channel state every time new data is polled from a slave, for performance reasons. Instead, the state is updated whenever it differs from previously updated state

Which means that without the parameter it should update only on change? Is this a error in the doc’s? Or do I misinterpret this? Should I try to not use the parameter ’ updateUnchangedValuesEveryMillis’ and see what is happen?

I browsed through the source code of both version:

The difference looks like is in ModbusDataThingHandler.java - whenExpired

The version PR4701 which is working:

        if (lastUpdatedMillis > 0L && lastState != null && this.updateUnchangedValuesEveryMillis > 0L && millisSinceLastUpdate <= this.updateUnchangedValuesEveryMillis) {
            if (lastState.equals(state)) {
                return;
            }
        }

in the snapshot which is not working:

        if (lastUpdatedMillis <= 0L || lastState == null || this.updateUnchangedValuesEveryMillis <= 0L || millisSinceLastUpdate > this.updateUnchangedValuesEveryMillis || !lastState.equals(state)) {
            action.accept(uid, state);
        }

Maybe this will help?

Thank you @HomeAutomation for your persistence. I think you now have the correct binding installed.

The code looks a bit different actually in PR 4701.

Anyway, there is indeed an issue - I made a sloppy modification based on code review comment from a maintainer, which lead to situation that “time of last update” was not kept up-to-date.

Will introduce fix for this. UPDATE: PR introduced for the fix: https://github.com/openhab/openhab2-addons/pull/4802

If the PR is inside of the new snapshot please tell me, then I can test again.

Another remark:
I made an SHA256 compare of:

.kar-file from https://ci.openhab.org/job/openHAB-Distribution/ and extract .jar-file from the subfolder repository/org/openhab .

and

https://ci.openhab.org/job/openHAB2-Bundles/org.openhab.binding$org.openhab.binding.modbus/

Both are the same version. One is inside the .kar file one is the single file if just this one is needed.

1 Like

Thanks @HomeAutomation for the help – I will post when I have something to test.

Please note that openHAB-distribution seems more recent than openHAB2-Bundles. In fact, openHAB2-Bundles is currently disabled, that is it’s not building anything new.

Perhaps something you want to raise in the FAQ thread and ask? :slight_smile: