Sofar has a Modbus interface. But writing requires the sending of mutliple register values (e.g 32) in one telegramm. Is it possible to do this with the Modbus binding?
No. We can write 32-bit values, which writes two registers in one transfer. I’m not sure if a 64-bit integer write was ever implemented - that would be a 4-register transfer.
But there is no arbitrary size block transfer. I’ve never yet come across a device that needs that, but Modbus implementors do weird stuff.
I think the question is if FC16 is supported. According the documentation it is.
Thanks for the answers. I also think FC16 supports maximum 32/63 values.
I looks I’ve to use an external program triggered by OH2 to send the data. 
I’d question your vendor about the initial assumption that you really have to write multiple registers in one go. Most inverters to have such a transaction-like requirement will perform when all (single) writes are completed within a specific number of seconds.
I think you should read the binding docs.
This binding supports FC16
This binding supports 32-bit values in several formats.
This binding does not support FC16 to write arbitrary blocks of registers.
It’s a language problem, we are struggling to understand
Does that 32 registers or a 32-bit value?
Thanks - Sofar Solar inverter’s “MODBUS writing” requires the writing of blocks of registers.
It’s a Chinese product with no tangible support. No Help! You only know that you must write a block of data, but you don’t know the start address or how much data is required.
I will give up.
Here’s a Sofar spec.
5yr old so likely outdated but I guess the basic registers will still be correct.
It doesn’t say anything about block sending.
You could just give it a try.
SOFARSOLAR ModBus-RTU Communication Protocol.pdf (270.2 KB)
@mstormi - thanks, but it seams each Sofar has another set of MODBUS registers. I have a documentation for mine. But as far as I’m now with testing, Sofar does not support writing single register. It must allways be a whole block, sometimes 5 registers, sometime 7 or 19 are required. If you do not follow that, a data error is given and data is not updated. There is no documentation - as far I know - where starting registers and length are defined.
But that’s no more a problem, because I can’t anyway write multiple registers with OH.
That is really weird requirement, especially odd number of registers.
And no, openHAB binding will not do that natively, nor is it likely to do it in future.
Having said that, there is an obscure and rarely used binding feature “Advanced Write”.
We can apply a custom transformation that we create (usually javascript) to return some JSON that can describe a fairly arbitrary Modbus transfer. The binding makes a custom write transfer using this JSON “script”.
I think that could be used with a String Item to unpack data into a long FC16 block transfer. You’d probably want a write-only data Thing, and use “ordinary” data Things to split read data into separate Items.
You’d just have to decide how to pack your block of data - presumably from different sources - into a single String command, but that should be easy enough in rules. Comma-separated integer register values, perhaps.
This feature has been used for some equally weird devices that require writing to two different registers to “do xx”, it should work just as well with “write random block size”
You could of course use some external script instead to do all that and use the script with openHAB.
thanks for the tip - i will give it a try (would be better than another external program)
I’m implementing the “MultiRegister Write” following the advice.
It does work as expected when writing just one register.
But when sending values for multiple registers I have an error:
Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException CRC Error in received frame: 0 bytes:
Looks like there’s no answer from the device. May be a timeout? Wrong sent data?
I have a test application I can send the required MODBUS command strings. The string in openHAB Log
registers=ModbusRegisterArray(000000010000020000280000083400010C1F007F000000000000000000000000)
shows exactly same values which work with the test application. I’ve no idea what the problem is.