Sounds like the solution, can you please explain how to combine two channels for one Item?
Since you want to read input registers, the poller should have input registers as the type, not holding as you have now.
The data thing is already configured correctly, itās writing holding registers.
Essentially, the poller defines the read path, while data thing defines the write path.
Then just bind your item to the data thing. I donāt think you need to bind to two channels.
I have already tried what you suggest
// #Smartlight Function
Bridge poller Smartlight [ start=4298, length=300, refresh=1000, type="input" ] {
Thing data Smartlight [ readStart="4298", readValueType="uint16", writeStart="4538", writeValueType="uint32_swap", writeType="holding" ]
}
But it gives me this error
11:59:43.940 [WARN ] [ort.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@5c07769f[slaveId=1,functionCode=READ_INPUT_REGISTERS,start=4298,length=300,maxTries=3]). Will try again soon. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID 880e0e65-ce7e-4e52-a2d2-4e1a026c9b19]
11:59:44.003 [ERROR] [ort.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@5c07769f[slaveId=1,functionCode=READ_INPUT_REGISTERS,start=4298,length=300,maxTries=3]). Aborting. Error was: net.wimpi.modbus.ModbusSlaveException Error Code = 3 [operation ID 880e0e65-ce7e-4e52-a2d2-4e1a026c9b19]
If I set up two Things and two items I get the correct reading and writing:
// #Smartlight Function
Bridge poller Smartlight [ start=4538, length=300, refresh=1000, type="holding" ] {
Thing data Smartlight [ writeValueType="uint32_swap", writeType="holding" ]
}
// #Smartlight Function
Bridge poller Smartlight1 [ start=4298, length=21, refresh=1000, type="input" ] {
Thing data Smartlight1 [ readStart="4305", readValueType="uint16" ]
}As an aside, Iām curious about length=300 ā¦ does that work, exceeding Modbus transfer size?
Iāll change the memory map of the Slave device so I will not exceed the Modbus transfer size and see if that changes anything.
I have changed the memory map on the slave device, so I donāt exceed the modbus transfer size.
Changed the Thing to this:
// #Smartlight Function
Bridge poller Smartlight [ start=4700, length=25, refresh=1000, type="input" ] {
Thing data Smartlight [ readStart="4700", readValueType="uint16", writeStart="4738", writeValueType="uint32_swap", writeType="holding" ]
}
I donāt see any errors and I can control the written value.
The function controls a dimmer, when I change the value the output changes, but somehow turns back to 100% in 1-2 seconds ?
12:29:38.501 [INFO ] [smarthome.event.ItemCommandEvent ] - Item āLight_GF_Sove_Sengā received command 20
12:29:38.503 [INFO ] [smarthome.event.ItemStateChangedEvent] - Light_GF_Sove_Seng changed from 100 to 20
12:29:39.345 [INFO ] [smarthome.event.ItemStateChangedEvent] - Light_GF_Sove_Seng changed from 20 to 100
This error 3 from the slave directly, check out http://www.simplymodbus.ca/exceptions.htm for the explanation.
By default openhab updates item state on commands. This seems to be why the state gets updated immediately to 20. However, next poll of data updates it back to 100.
You can disable the automatic state updates using the autoupdate parameter. See https://www.openhab.org/docs/configuration/items.html#item-definition-and-syntax
It looks like the input register remains unchanged even though holding register is modified? This is all device specific, and not much I can comment further.
If I seperate the read and write I get it correct.
#Smartlight Function
Bridge poller Smartlight1 [ start=4700, length=21, refresh=1000, type="input" ] {
Thing data Smartlight1 [ readStart="4700", readValueType="uint16" ]
}
Only difference is I read as a Number
Number Light_GF_Sove_Seng2 "LED Seng2 [%d %%]" (GF_Sove, Lights) { channel="modbus:data:endpointSmarthouse:Smartlight1:Smartlight1:number" }`I strongly recommend following Samiās suggestion of applying auotupdate=āfalseā.
This applies to any device that is read-polled, really.
There is more on this in the docs
The problem with Autoupdate=false is that the light also is controlled by a Physical light switch 
I do not think it is a problem, thatās why you have polling.
With and without autoupdate, changes due to physical switch are picked up by the polling.
There is still something I donāt understand.
I have changed my item to this
Dimmer Light_GF_Sove_Seng "LED Seng [%d %%]" (GF_Sove, Lights) { channel="modbus:data:endpointSmarthouse:Smartlight:Smartlight:dimmer", autoupdate="false" }
The light is dimmed correct, the slider is staying on the correct value for 10-20 seconds - then goes to 100%.
The light stay on the selected value.
If I read the modbus with a simple modbus tool, register it is the value written (Not 100% as Openhab reads)
Could you please share things as well?
When reading with other tool, are you reading the input registers or holding registers?
Yesā¦ At first I was reading holding registers, as I was experienced this issue.
Then I tested it with the status register that was a input.
I have now gone back to what I used to do with this device:
Bridge poller Smartlight [ start=4738, length=2, refresh=1000, type="holding" ] {
Thing data Smartlight [ readStart="4738", readValueType="uint32_swap", writeStart="4738", writeValueType="uint32_swap", writeType="holding" ]
}
When I read it with my modbus tool, I read it as a holding register and there I can see the value changes between 0-100
Ok Thanks
Itās quite weird indeed.
From verbose logs we should be able to see what data the binding is polling exactly.
Would be interesting to see verbose logs for this sequence of eventsā¦
One thing to check out is any warnings regarding queue size in the log. With verbose logs you can find out the binding queue size, it should stay small.
Ill turn on verbose logging and grab some data
Here is a sequence with Debug turned on
13:55:09.014 [DEBUG] [.handler.ModbusPollerThingHandlerImpl] - Thing modbus:poller:endpointSmarthouse:Smartlight received registers RegisterArrayWrappingInputRegister(00 45 00 00) for request ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@47eb7870[slaveId=1,functionCode=READ_MULTIPLE_REGISTERS,start=4738,length=2,maxTries=3]
13:55:09.015 [DEBUG] [modbus.handler.ModbusDataThingHandler] - Thing modbus:data:endpointSmarthouse:Smartlight:Smartlight channels updated: {modbus:data:endpointSmarthouse:Smartlight:Smartlight:dimmer=ON, modbus:data:endpointSmarthouse:Smartlight:Smartlight:lastReadSuccess=2018-09-09T13:55:09.015+0200}. readValueType=uint32_swap, readIndex=Optional[4738], readSubIndex(or 0)=0, extractIndex=0 -> numeric value 69 and boolValue=true. Registers RegisterArrayWrappingInputRegister(00 45 00 00) for request ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@47eb7870[slaveId=1,functionCode=READ_MULTIPLE_REGISTERS,start=4738,length=2,maxTries=3]
13:55:09.029 [DEBUG] [modbus.handler.ModbusDataThingHandler] - Successful write, matching request ModbusWriteRegisterRequestBlueprintImpl@71075449[slaveId=20,reference=0,functionCode=WRITE_SINGLE_REGISTER,registers=ModbusRegisterArrayImpl(38 10),maxTries=3]Itās not clear what you mean here. The value reverts to 100 after 20 seconds?
As your OH config is for a uint32 type, you should read two holding registers with modbus tool, just in case there is something going on in the āother halfā.
What iām trying to explain 
If I set the Holding register to eg. 60, the light changes to 60 and stays on that level.
However OH revert the reading that should have been 60 to 100. This is delayed between 5-20 sec.
If I read the holding register (two words) with my modbus tool I see the value 60 and nothing in the other half