Hello, I have a controller that uses modbus RTU Over Ethernet. This is usually Modbus RTU encapsulation in an Ethernet Packet. So, it does not work with Modbus TCP binding since it is Modbus with a special header.
I did a test with a proprietary M2M software, which has a binding called “Modbus IP” with a check box to select this option “Encapsulation”. My device works great with this.
I’m no expert on the TCP binding so I can’t really address whether it is possible with that or not.
If it turns out not to be possible, you can probably still make it work by coding the interaction outside of OH (e.g. using Python) and communicate with OH through the Exec binding, HTTP binding, REST API, and/or MQTT binding. Not the best solution but sometimes the way we have to do it.
Unfortunately modbus RTU over tcp is not supported in the binding. For more information what modbus variants are supported, please consult the wiki article. There you can also find the syntax for tcp slave connection parameter (there is no way to specify modbus variant as RTU with tcp slaves)
I believe adding the support might not be trivial since the jamod library (java modbus library) that we use does not support it either. I would think that code need to be refactored such that the actual protocol (rtu/modbus tcp) is separated from the transport layer (tcp/serial). Perhaps you would like to try to do this? EDIT: found this fork of jamod that implements the feature on top of jamod. Perhaps the code could be integrated with our fork of jamod?
I find the virtual serial device really elegant way to handle this case. Perhaps you could document this to the wiki for other users?
Thank you so much. I am starting with programming, I do some scripting, but I am a begginer. I will start to look the souce code and start to teach myself coding.
I would love to see this feature on Open Hab, since I have various devices using this protocol.
I am getting used with wiki, I edited Modbus Binding page, but it needs an adjust. The problem is when I try to edit it again I got 404 page. It seems they think I am a robot… I should stop digging the wiki…lol
Sounds excellent! Please feel free to ask if you need help with the implementation.
I looked a bit deeper with the fork and was not really happy with the quality. There were quite many unnecessary or unrelated changes but the basic structure is there. The developer went the pragmatic way: introducing new transport class etc and not trying to refactor the actual protocol away from the communication layer. It will be more duplicated / similar code but likely more straight forward code.
