I’m experience some slow response from one of my slave devices, do you have an idea if this response could have something to do with that?
05:33:00.546 [INFO ] [ort.modbus.internal.ModbusManagerImpl] - Unregistering regular poll task PollTaskImpl@76bdd456[request=ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@470aa079[slaveId=30,functionCode=READ_INPUT_REGISTERS,start=100,length=14],endpoint=ModbusTCPSlaveEndpoint@13bb9a66[address=192.168.100.30,port=502],callback=java.lang.ref.WeakReference@2840e986] (interrupting if necessary)
05:33:00.547 [INFO ] [ort.modbus.internal.ModbusManagerImpl] - Poll task PollTaskImpl@76bdd456[request=ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@470aa079[slaveId=30,functionCode=READ_INPUT_REGISTERS,start=100,length=14],endpoint=ModbusTCPSlaveEndpoint@13bb9a66[address=192.168.100.30,port=502],callback=java.lang.ref.WeakReference@2840e986] canceled
Hello again, @ssalonen
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
Not a single error and everything works like a charm. I really like the the new
.things file and how the config is simplified.
Keep up the good work and thank you!
I will test your binding and keep you inform.
@Nanna_Agesen that should happen only when things are changed, I believe.
Do you get that message constantly?
Verbose logs probably reveal more where the time goes…
@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
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’ve been using a PLC to control my house with OH2 and the 1.11 stable modbus binding for like, a year now? 100 or so registers/items, zero problems
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.
@Nanna_Agesen did you manage to see the problem again, or get verbose logs?
@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:
Would it make sense to comment there?
Updated the development version just now
- removed read, write, and readwrite things
- added retry (
poller (retry with reads) and
data (retry with writes)
- consistent handling of errors in polling and writing, previously
connection errors were not handled properly with write, for example.
- some errors now trigger re-connection (e.g. “broken pipe”), while
with some we re-use the connection (e.g. modbus slave exception
responses). This is improvement from openHAB1 binding which just retried the write with broken TCP connection (no chance of succeeding even with many retries)
- transport API changes and cleanup
Apologies if this is covered somewhere, but after searching I couldn’t find an answer. I’m on OH2 using the OH1 modbus binding. If I move to this OH2 modbus binding, can I use my existing modbus.cfg definition file? I have over 100 slaves/registers defined and I really don’t want to re-do all of them.
They’re in this format:
# UPS 2 Battery
@ssalonen Great job on the binding! I have been testing it for a while (I only use modbus RTU devices) and from my tests it proves to be very reliable. However, it seems to have issues with the plugwise binding.
Plugwise is a zibee-like network, communicates with OH2 via a usb-stick device, itself using a ftdi usb-serial adapter. When I am using the plugwise binding on a different serial port, the modbus binding crashes after some time and stops communicating with the rs485 adapter (I am using a usb-rs485 gateway, non-ftdi one). The OS is debian linux and I am polling quite often - every 200ms. I have done quite a lot of similar work in the past so I should be able to debug this myself but I am looking for pointers where the culprit may be to isolate the problem.
Is anyone having problems (or, perhaps, no problems) with modbus-RTU communication interfering with another serial-based protocol?
Is OH2 serial connection using some locks on hardware resources?
Any other suggestions where to look for?
Thanks in advance for any help.
I’d say no. Configuration files are very much different. You can find examples of them in this topic and here’s the link to documentation. https://github.com/ssalonen/openhab2-addons/blob/modbus-openhab2-native-binding/addons/binding/org.openhab.binding.modbus/README.md
Thanks for reporting this!
Sounds very peculiar. What do you mean that binding “crashes”? Do you have any logs?
Documentation also has section regarding this very topic, “Changes from Modbus 1.x binding”.
Anyone experience High CPU load with the new Modbus Binding Latest update.
I’m running openhab in a virtual environment, with the version before Developer I had 0% Cpu load, with the latest version this has increased to 20% and a delay in the modbus communication about 45 Seconds.