I’m seeing this error, and only able to read/write the first Data Thing from the poller
08:49:25.036 [ERROR] [ort.modbus.internal.ModbusManagerImpl] - Unhandled exception in callback: java.lang.IllegalArgumentException Index=16 with type=uint16 is out-of-bounds given registers of size 8
java.lang.IllegalArgumentException: Index=16 with type=uint16 is out-of-bounds given registers of size 8
at org.openhab.io.transport.modbus.ModbusBitUtilities.extractStateFromRegisters(ModbusBitUtilities.java:91) ~[?:?]
at org.openhab.binding.modbus.handler.ModbusDataThingHandler.onRegisters(ModbusDataThingHandler.java:451) ~[?:?]
at org.openhab.binding.modbus.handler.ModbusPollerThingHandlerImpl$ReadCallbackDelegator.lambda$2(ModbusPollerThingHandlerImpl.java:67) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184) ~[?:?]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:?]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) ~[?:?]
at java.util.Iterator.forEachRemaining(Iterator.java:116) ~[?:?]
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:?]
at org.openhab.binding.modbus.handler.ModbusPollerThingHandlerImpl$ReadCallbackDelegator.forEachAllChildCallbacks(ModbusPollerThingHandlerImpl.java:62) ~[?:?]
at org.openhab.binding.modbus.handler.ModbusPollerThingHandlerImpl$ReadCallbackDelegator.onRegisters(ModbusPollerThingHandlerImpl.java:67) ~[?:?]
at org.openhab.io.transport.modbus.internal.ModbusManagerImpl.invokeCallbackWithResponse(ModbusManagerImpl.java:247) ~[?:?]
at org.openhab.io.transport.modbus.internal.ModbusManagerImpl.lambda$18(ModbusManagerImpl.java:556) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:159) ~[?:?]
at org.openhab.io.transport.modbus.internal.ModbusManagerImpl.lambda$9(ModbusManagerImpl.java:556) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
I can confirm that the latest version with date of today fixes the issue. @Nanna_Agesen I think you are seeing the same error I had. Have you tried the version that was published today?
I have now converted my complete setup with approx 500 Data Things on 6 different slave devices.
I haven’t found any bugs since your update this morning.
I believe the setup covers most of the read/write types supported by your binding, I haven’t got the chance to test Coils, and hopefully the future will bring Uint64 support
It’s quite hard to estimate when it will be “released”. We are still in testing phase, and would like to keep it like that for a while. After that I fear that the pull request to be accepted might take some months (there was already some copyright related discussion ongoing)
The good news is that there is the Eclipse IOT marketplace which allows you to accept the binding even before it is “official”. If you feel bold I welcome you try the binding as it is now!
As an alternative, you can always use the old but more stable modbus binding, it works as before with openHAB2.
As a background info I renewed my system changing RPi3+openHABian to an dedicated desktop/server running Debian 8+ latest openHAB 2.2.0 snapshot. Updated your binding also to the latest version and changed all thing types to data.
Not a single error and everything works like a charm. I really like the the new .things file and how the config is simplified.
@ssalonen I get them if my polling interval is too low, I have tested the troubled device and if I have it under 5000 I get those warnings - and also every other devices are delayed for 4-8 seconds.
Ill try logging in verbose later today, to se if that reveal more.
Everyone, please switch to data things. I will remove the read, write and readwrite in the coming days.
Let me know if you find any issues!
Progress update: have been working on the README mostly, it’s progressing pretty well.
The next step after README will be code cleanup, commenting the code etc. in preparation of polishing it for merging as official addon for openHAB2. There is also some discussions how the code is organized, but I’m sure some solution is found there.
I remember having to install serial transport feature manually from karaf console following these steps in post #24. Does the binding install it automatically now?
I don’t think it installs the serial feature automatically. Not sure I can fix that before the binding is official and the feature installable from karaf console.
@ssalonen After some more tests I found that these errors only shows up after a restart/initializing - been on vacation, and will do a few more test this week.
@ssalonen First off: thx for writing the extensive Readme file - it has been hugely helpful.
However, there is one question left: Is it possible to change thing parameters (in my case the refresh parameter of the poller bridge) using rules?
I have a device which after it has been given the command to perform a measurement is not reachable via modbus for a certain amount of time. It would be very handy to have coils and registers of the device polled as often as possible and to switch off polling for the amount of time it takes the device to perform the measurement. Using the otherwise useful refresh command is not really an option because I would have to send the refresh command multiple times per second to achieve the same speed I can get when the data is polled constantly…
Yeah good question! I am not sure if this is possible, I am bit too unfamiliar with the new base still. I did find this thread from eclipse smarthome forums regarding the same thing:
