I’ve tested the
org.openhab.binding.modbus-2.5.0-pr-4701-lazy-updates-SNAPSHOT.jar
too. It is working perfect. You can merge it with the snapshot binding.
It’s probably worth having a discussion about that.
, “uUVEM” we know by now, when set to some value e.g. “60000”
(a) updates Item immediately when read poll finds a change
(b) if no change, still updates periodically, like a keep-alive heartbeat
Sending Command to Item, producing modbus write, doesn’t affect that at all. But if the write causes a change at the slave, that will get picked up at next read poll and update the Item.
But - you might have autoupdate="true" (or defaulted) on the Item, which will cause an Item update a short time after a Command is sent, quite independently of modbus.
If autoupdate has already made the change, the next modbus read poll has nothing to do and no further update takes place?
Is that right Sami, “uUVEM” looks at actual Item state - or at a cache in the binding?
In a rare worst case, a modbus read poll might return the “old” value before it changes at slave, and “undo” what autoupdate did. Next read poll after that, it should all come right again.
But you could get the occasional double-update that way, unexpectedly triggering rules etc.
Personally I would set autoupdate=“false” where the polling is frequent.
Okay, enough about normal use of “uUVEM”.
There are two ways we might want non-“uUVEM” to behave.
The obvious one is the binding default behaviour, update on every read poll. This fits openHAB general philosophy, and when it’s a nuisance we can turn it off, or rather reduce it. All good.
Plus, there’s what @HomeAutomation is suggesting, a “never update unchanged” option. I think that’s a reasonable suggestion myself, and I guess shouldn’t be too much work.
Setting “uUVEM”=“0” would be a good way to select that - but I suppose the problem is that the default behaviour is already selected that way. Is there a way for the parameter parser to pick out some special value, like “-1” or “false” for this job?
The binding has a cache of its own. It unaware of the item state. As far as I have understood (in previous discussions with developers), it is not “allowed” to inspect item state in bindings, since it breaks the general philosophy of the architecture.
To be very precice, the binding looks at the transformed value to decide if it is changed. Let’s say we are polling an integer from modbus. We have read transformation converting a number to strings “cold” and “hot”. The trigger for channel update is when string output changes, not the underlying number originally polled from modbus.
Plus, there’s what @HomeAutomation is suggesting, a “ never update unchanged” option. I think that’s a reasonable suggestion myself, and I guess shouldn’t be too much work.
Default for the configuration parameter is actually 1000 ms. The readme is as follows:
Interval to update unchanged values.
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, or when enough time has passed since the last update. The time interval can be adjusted using this parameter. Use value of0if you like to update state with every poll, even though the value has not changed. In milliseconds.
With this interpretation, I don’t agree using zero value for this purpose. As mentioned, you can use a big number for this purpose. To be honest, I don’t see any practical difference between “never” vs. “very large time”.
Btw, regarding auto-update setting: nowadays in openHAB2 the binding can influence the default behaviour, see Archived Projects | The Eclipse Foundation.
Best,
Sami
1 Like
I have also tested your latest version and everything works well.
1 Like
Dear @ssalonen,
testing this version now also; looks good!
I keep an eye on it and come back to you in case of problems.
Thanks a lot
Wolfgang
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 
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
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 fileopenhab-addons-2.3.0-SNAPSHOT.karfrom https://ci.openhab.org/job/openHAB-Distribution/ . This file contains all add-ons that were built in the last successful snapshot build.
The.karfile is a zip archive. You can extract the add-on’s jar file this archive file. The add-ons are stored in the folderrepository/org/openhab/(e.g. the Homematic add-on jar file is stored inrepository/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
.karfile 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.