Alright, there’s a “write” transaction; an FC06 command (write single holding register) to ID 01, address 0034 hex, data content 0000
And a successful response from ID 01, which in this case just mirrors to original command.
(note that the 03 “reads” in this same log to address 0000 are rejected, code 83)
So mbpoll can see the correct response, but openhab cannot. Something different. Same wire, dongle? Different environment, windows, nix? Different settings, flow control, parity?
There’s another complication I’ve just remebered for Serial users.
The Java serial library selected for OH3 is a bit, umm, nuisance. It works fine when it works in normal use, but error recovery processes can sometimes get it in a locked-up knot. This affects Modbus RTU serial as well as other serial/USB adaptor usages in openHAB.
I think there was an OH fix coming along but do not know the state of play.
Meantime you are invoking a lot of error recovery, so if you reconfigure Things, then you are for the time being going to have to reboot to ensure a clean new attempt.
Yes, I literally removed the dongle from RPi and connected it to a Windows 10 laptop. Settings are the same, as far as I know, since I did tried to be very careful with that. Flow control is something I am not sure what to choose, but in OH when I selected “none”, that’s when I could “write” to the device. Parity is the same, yes.
I mean that you currently have an openHAB Modbus poller Thing configured to read a block of registers from address 0000. We know that will fail, it’s in the logs you looked at. We know that will fail, as it fails in mbpoll too.
So while that is failing, it is an error and the error recovery process will be invoked.
Sometimes the serial library code screws up during that process.
So if you make changes and expect them to work, then you may need to reboot to un-screw the serial side. If you do not, you will not know if a failure is due to the new changes or a leftover screwup.
Having said that, I would reduce your OH Modbus config to the serial Bridge and one write-only data Thing for testing. If we can’t make that work, thee is no point introducing more known failures with bad read polls. We know they’re bad, because they don’t work in mbpoll either.
To sort the read polls out, try the following polls in mbpoll, one at a time.
Holding registers starting at 00, length 3 (the common registers)
Please, please, there are multiple error messages at various points in this thread. Be specific, be clear.
Having said that, there is not much that can go wrong apart from a write failure of your one remaining data Thing, so let’s guess its that.
So if the modbus write truly fails as before, and
guessing again that means the remote device responds, then we can deduce we transmit onto Modbus okay.
The conclusion is that openHAB cannot read from Modbus (so does not see the necessary acknowledgement).
The following remains the case
Looking at “Different environment, windows, nix?” in particular, I think you need to consider installing mbpoll or similar tool on your Pi. Remember to only test with one of mbpoll or openHAB at one time.
It’s quite possible that win/nix software will act differently in the presence of some weird fault.
Your USB dongle includes lights I think. What we’d expect to see is both Tx and Rx twinkle when you attempt a write from openHAB. Probably 3 times due to re-try.
What we don’t want to see is either stuck lit, indicating a jam on the wired bus.
I’ve not seen symptoms like this before (I don’t use USB dongles directly, but others do) but my gut feeling is somewhere in the tinkering you’ve got a messed up flow control setting.
The chain here includes 3rd party Javo libs, Java itself, your operating system, and the dongle itself. I don’t know how to pin it down any further.
I don’t understand what do you mean with this part.
Ok, if I do that, will it interfere with OH afterwards? I mean, if I install mbpoll to try and have readings, later on if I forget to remove, will it cause conflicts?
Ok, so you are refering to the fact that when I was using Mbpoll in Windows and got a “Response ok”, that should also be the case for OH but it seems that is not, so you are suspecting it might communicate or interpret communication differently?
Exactly, that’s what happens!
No, that never happened. Those two LEDs immediately turn OFF.
Oh, ok. So it definitely seems tricky.
I will then try mbpoll on my RPi and get back here.
You told us you ran mbpoll on a Windows machine.
In that environment, you got an “accepted” response to your write 54.
openHAB is running on a Pi.
On the Pi you get a “failed” response to your write 54.
The Pi does not run windows. These are different environments.
The pathway for serial port traffic runs through really quite low levels of the system in these environments. These low levels handle stuff like flow control, parity etc. in conjunction with your hardware - which is plugged into a different port as well…
[ ref installing mbpoll or similar tool on your Pi]
It’s a diagnostic tool. You run it when you want it. When you don’t run it, the resources (serial port) are free for others (openHAB) to use. If openHAB Modbus binding cannot get hold of the resources it wants (serial port), it tells you so in your openhab.log.
Great, I even forgot that I already had it installed from way back when I first started debuging with your help (when we understood that the Modbus was not even setup yet in Samsung equipments).
I just edited my previous answer with the results of my tests.
But anyway, you’ve set up a regular poll of holding register 0000 for length 1.
And its failing badly, with corrupt messages received.
Are you using twisted-pair cabling? How long is the run? Have you arranged RS-485 termination? It looks like a noisy line, which is an effect that can get exaggerated when plugging into ‘this’ box rather than ‘that’ box.
Consider also the power source for your USB dongle, I’ve heard stories the Pi sockets are power limited but don’t know much about that.
It can, yes. But in that case, I wouldn’t probably get the “Response ok” on Windows, or would I? Again, I literally unplugged the USB dongle from RPi and plugged on the Windows 10 laptop, just side-by-side .
THIS might just be the cause!!! The USB dongle is connected on a USB extension and NOT directly to RPi. So, yes, this might definitely be the cause here!
As soon as I can, I will go there and change it.
In the meantime, I will now start to setup all my “writes”.
Alright, child’s guide to transmission lines. An RS-485 bus is a data transmission line, not just a piece of wire. An important (unwanted) property is that signals can reflect off discontinuities in the line - usually meaning, bounce off the end of the wire.
The overlapping “real” and “reflected” signals are interfering waves and garble data clarity. The longer the line, the worse it gets.
The cure is to “terminate” the line - this means adding a resistor at each end that hides the discontinuity and damps out reflections. For RS485, a 120R resistor is used at each end.
In reality, termination can be dodged completely on very short cable run lengths (~1m)
Partial termination usually suffices for short runs (~10-20m) i.e. just one resistor somewhere on the line.
This doesn’t mean you have to go round physically sticking a resistor across your wire pairs.
Every USB-RS485 dongle I’ve seen has a terminator built in - but you may need to enable it (usually by moving a hardware link). Refer your dongle manual.
A great many Modbus devices also include onboard termination. But that is usually delivered disabled, it might be enabled by link or or switch software or whatever. I don’t see any mention of anything like that in the Samsung manual.
If I were you, I would try to ensure at least one of your RS485 devices is equipped with an enabled terminator for your 10m line. That will most likely be the USB dongle.
This is for the Samsung card to USB dongle run, yes? Make sure the shield is only connected at one end, the Samsung end. This makes it a shield and not a signal path.
.
The Windows box and the Pi box are two different boxes, each powering your Dongle with more or less noise or limitation. Each emitting more or less radio interference (The Pi is known to goose some zwave dongles with that).
I don’t know what else I can say about effects that might be worse on one box than another.
But if you are convinced it cannot be linked to the host system in some way, I don’t know what you do next.
I would hold off on that.
When this is working you are unlikely to actually want write-only data Things at all, that is just for test purposes.
On that same USB extension hub, I do have a Aeotec Z-Wave Gen 5+ USB connected!
Right now I am only sure of one thing: I have no idea what may be the problem here!
Still, can’t I later on just add the “read” details to get the responses? (if I ever get this working properly)
I will, anyway, double check with the technicians to really, really confirm that it was indeed a shielded crossover cable, because one thing I just remembered is that this cable they used is gray on the outside and it has 3 cables (one third for ground), but I am almmost sure that I saw the “shield” in there as well when I connected it to my USB dongle.
Remember the hierarchy is different. Read or read-write data Things must be the children of a poller Thing. The write-only data Thing can take a shortcut as a child of a Serial Bridge, but this is extraordinary usage.
Is this a self-powered hub? Not trying to power both dongles from one Pi port?
Oh right, I was forgeting about that! But won’t it work if I simply change the bridge to be the poller Thing instead?
This one is the USB hub I am using. But I have it connected to the USB 2.0 on the Rpi because, otherwise, if I connected to the USB 3.0 the zwave dongle wouldn’t work properly.
This how people get in to messes with weird ghostly configuration issues.
You don’t need to risk that.
If you want to make write-only data Things, go ahead - it’s your time and effort.
When the time comes to add pollers, do that i.e, add new poller Things, new data Things, and delete unwanted old data Things.
To follow the power concern, it appears this is an un powered hub. Every dongle connected to it draws its power from the one shared USB port on the Pi.
I’d be looking at that with deep suspicion and finding a hub with independent external power supply.
See if your mbpoll behaves better with the zwave dongle unplugged, at least.
I disconnected the Zwave USB pen, tried to communicate in OH and with the mbpoll and all gave the same errors. Maybe I should have rebooted or wasn’t it necessary?
Next time I will test connecting directly the RS485 USB dongle to Rpi.
In the mean time, I never got back to this due to lack of time literally.
But I did tried to connect the USB dongle directly to my Rpi instead of the USB “extension”, but I had to connect it to a USB 3.0 port in my Rpi 4.
I did some tests and everything was exactly the same, so since the same happens also when I connect the USB dongle to my windows PC using the software to check for the readings and writtings, I can only suppose this is a problem from the cable itself.
So it’s much probably not the appropriate cable or it’s having some problems/conflicts with something else. What do you say?
Hello. I am also using MIM-B19N to control DVM S Chiller AG056KSVANH/EU from BMS system. After connecting the Modbus module to the Chiller I can read all registers, but I cannot send any command. Can anyone help?
You need to add several options to poller thing to specify write function (single or multiple) and optionally writing behavior (encoding and offsets if any).
