[MODBUS] Possible to reuse TCP connections? Else, need conversion tips

Hi folks,

I am beginning to develop a love-hate relationsship with my new Solaredge solar inverter. It is possible to read some interesting values from the inverter via Modbus TCP, but solaredge has opted to make this extra tricky, since the inverter will only support one TCP connection, but the registers are a happy mix of int16, uint16 and uint32 values.

Due to the architecture of the modbus binding, I will however need a separate slave definition for each item type, like so:

tcp.se9ku.connection=192.168.199.122:502:200:0:200:3:500
tcp.se9ku.id=1
tcp.se9ku.type=holding
tcp.se9ku.start=69
tcp.se9ku.length=50
tcp.se9ku.valuetype=uint16

tcp.se9ki.connection=192.168.199.122:502:200:0:200:3:500
tcp.se9ki.id=1
tcp.se9ki.type=holding
tcp.se9ki.start=69
tcp.se9ki.length=50
tcp.se9ki.valuetype=int16

tcp.se9k4.connection=192.168.199.122:502:200:0:200:3:500
tcp.se9k4.id=1
tcp.se9k4.type=holding
tcp.se9k4.start=93
tcp.se9k4.length=2
tcp.se9k4.valuetype=uint32

The inverter usually doesn’t like this and the connections will be unstable, or not be established at all. Is it possible to make the modbus binding resuse the same tcp connection for different slave connections? How would I go about raising a feature request to get this looked at? Another problem with the current slave definition is, that the binding will most likely try to read multipbe registers in parallel, something that the inverter also does not like. Resuing the same TCP connection would most likely serialize those requests as well.

In the meantime, I guess it would be possible to collapse those slave definitions into a single one to read uint16 values and convert the necessary registers back to signed int16 values. However, I’ll need some help to get the uint32 values back. Any idea, how to take two uint16 numbers and make a uint32 out of them?

Thanks!

BR,

Thomas

Pretty straightforward (high word * 65536) + low word

By design, TCP connection is closed & reconnected, as the method you want causes other people problems - can’t please everybody!

Guessing that your problem with the current binding lies with the slave not liking rapid TCP disconnect/reconnect - you could try longer interTransactionDelayMillis to give the slave time to recover