My point:
The docs never actually mention ‘true’ as an option. Only ‘false’ is mentioned 
Yep. That’s a consequence of increased flexibility - you could have mixed registers of int16, two of float32, another three int16, some bytes … wasn’t easily available in v1 binding.
It would be “nice” to define a range of similar registers in one go, but it wouldn’t make it work any better. Only got to do this stuff once.
I find it unsurprising that editing Things messes up. I believe there are ways to restart just the binding for a clean configuring, but restart whole OH myself.
As it is boolean, not string, it’s true or false,
without quotes. If it works with quotes as well, great, but would not rely on it.
See beginning of docs for explanation of data types in textual configuration https://www.openhab.org/addons/bindings/modbus/#thing-configuration
I know why you might see this. When you save, openhab refreshes all things in that file which means everything is scrapped and recreated.
During this recreation things are initializing and things might be offline for a moment (few seconds) while this happens. Thing status changes are logged and probably would confirm this.
I didn´t try restart the binding. I guess I´m to used to restart openhab, (due to other issues (Zigbee) I´m struggling with.
I see what you mean.
I would have expected “true” and “false” as options for writeMultipleEvenWithSingleRegisterOrCoil in the data Thing section. Maybe an example showing how the writeMultipleEvenWithSingleRegisterOrCoil is used in the data Thing. None of the examples shows this.
It didn´t come back online untill I restarted openhab… I´ll see if I can reproduce this, as I´ll be sittng here the next couple of hours continuing my data Things
I can reproduce this problem.
If I (by mistake) change the length parameter of a data Thing which has been working, I´ll get an error, ofcouse, and the data Thing will go offline. When change the lenght parameter back to its real value, data Thing will not return Online again by itself.
But I can get it to go online, if I change one of the data inside the data Thing. (ie one of the adresses, or an write parameter).
You may have to factor in real-world effects; a messed config is likely to make polls that the target device can’t handle, and rejects or ignores.
If you can reproduce this with verbose logs and clear&exact steps I can have look. Would need thing definitions and item definitions. The more minimal example, the more easier it is to me.
I would indeed expect things to resume to normal when parameters are restored to their previous values.
Btw, when things go offline, the thing status tells the
reason. You can see thing status in PaperUI and perhaps in logs as well.
Good comments regarding the documentation, really valuable to have others reading the doc with fresh eyes. I invite you to contribute your improvements to the general version. You can find it here https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.modbus/README.md It’s volunteer and community project after all 
Best
Sami
I´ll get you the log as soon as I get through my setup (I´m almost there, now having something like a trillion Things 
)
About the steps, I guess I can only explain what I´m doing. I would assume you should be able to reproduce as well, unless this is different for TCP connection…
I´d discovered this, because I dont fully trust Nilans modbus documentation. I have found a few mistakes/misleading informations in it. So whenever I have a problem with an adress not acting according to the Nilan modbus doc, I change the length setting to see if thats the problem. And then this issue with the modbus binding appear.
As soon as I get through, I´ll contribute to the doc including examples for serial, which I believe could come in hand as well. I´ll have to find my github account though 
Awesome! With the detailed steps (what was changed) it is easier to correlate events with logs, that’s all.
I have run into a very strange problem…
When I try to write (set) a holdning register (adresse), the value changes, but a second after, it´s change back to the old value by itself… Like it never gets saved or something simular…
This is my Thing file with Bridge, Bridge Poller and Thing data:
Bridge modbus:serial:myNilan [ port="/dev/ttyUSB0", id=30, baud=19200, stopBits="1.0", parity="even", dataBits=8, encoding="rtu" ] {
Bridge poller AirTempRegisters [ start=1200, length=8, refresh=6000, type="holding" ] {
Thing data hol1200 [ readStart="1200", readValueType="int16", writeStart="1200", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)" ]
Thing data hol1201 [ readStart="1201", readValueType="int16", writeStart="1201", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)" ]
Thing data hol1202 [ readStart="1202", readValueType="int16", writeStart="1202", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)" ]
Thing data hol1203 [ readStart="1203", readValueType="int16", writeStart="1203", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)" ]
Thing data hol1204 [ readStart="1204", readValueType="int16", writeStart="1204", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)" ]
Thing data hol1205 [ readStart="1205", readValueType="int16", writeStart="1205", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)" ]
}
}
This is my nilan.items (for these adresses)
Number Nilan_AirTemp_CoolSet "Cooling temperature setpoint select [%d]" <temperature> (gNilan) {channel="modbus:data:myNilan:AirTempRegisters:hol1200:number"}
Number Nilan_AirTemp_TempMinSum "Inlet temp. min. summer [%.1f °C]" <temperature> (gNilan) {channel="modbus:data:myNilan:AirTempRegisters:hol1201:number"}
Number Nilan_AirTemp_TempMinWin "Inlet temp. min. winter [%.1f °C]" <temperature> (gNilan) {channel="modbus:data:myNilan:AirTempRegisters:hol1202:number"}
Number Nilan_AirTemp_TempMax "Inlet temp. max. summer [%.1f °C]" <temperature> (gNilan) {channel="modbus:data:myNilan:AirTempRegisters:hol1203:number"}
Number Nilan_AirTemp_TempMaxWin "Inlet temp. max. winter [%.1f °C]" <temperature> (gNilan) {channel="modbus:data:myNilan:AirTempRegisters:hol1204:number"}
Number Nilan_AirTemp_TempSummer "Summer/winter limit [%.1f °C]" <temperature> (gNilan) {channel="modbus:data:myNilan:AirTempRegisters:hol1205:number"}
And this is my nilan.sitemap file:
Frame label="Air1200 Holding" {
Selection item=Nilan_AirTemp_CoolSet label="Temperaturforskydning til køling" mappings=[0="Off (No cooling allowed)", 1="Set + 0 °C (User setpoint plus 0 degrees)", 2="Set + 1 °C", 3="Set + 2 °C", 4="Set + 3 °C", 5="Set + 4 °C", 6="Set + 5 °C", 7="Set + 7 °C", 8="Set + 10 °C"]
Setpoint item=Nilan_AirTemp_TempMinSum label="Temperaturminimum (Sommer)" minValue=0 maxValue=65 step=1
Setpoint item=Nilan_AirTemp_TempMinWin label="Temperaturminimum (Winter)" minValue=0 maxValue=65 step=1
Setpoint item=Nilan_AirTemp_TempMax label="Temperaturmaximum (Sommer)" minValue=0 maxValue=65 step=1
Setpoint item=Nilan_AirTemp_TempMaxWin label="Temperaturmaximum (Winter)" minValue=0 maxValue=65 step=1
Setpoint item=Nilan_AirTemp_TempSummer label="Begræns sommer / vinter" minValue=0 maxValue=65 step=1
}
When I try write a value to 1201, this is what happens:
2018-12-20 23:02:14.633 [ome.event.ItemCommandEvent] - Item 'Nilan_AirTemp_TempMinSum' received command 14
2018-12-20 23:02:14.652 [nt.ItemStatePredictedEvent] - Nilan_AirTemp_TempMinSum predicted to become 14
2018-12-20 23:02:14.672 [vent.ItemStateChangedEvent] - Nilan_AirTemp_TempMinSum changed from 13.0 to 14
2018-12-20 23:02:17.575 [vent.ItemStateChangedEvent] - Nilan_AirTemp_TempMinSum changed from 14 to 13.0
Any idea why this happen??
I have tried with and without writeMultipleEvenWithSingleRegisterOrCoil. Without I get an CRC error. With, I get no error, but the value just return to original state.
Do you mean the change fails to get the nilan, or that OH view of the register reverts back? See the effects of autoupdate described in the binding docs.
Short version: if you are going to write a register that you read poll frequently, include {autoupdate="false} in each Item.
Autoupdate is a feature of openHAB that is generally useful, but becomes a nuisance for frequently polling tech like Modbus.
I cant really tell, since I get no errors. But I´ll give the autoupdate=false a try…
EDIT…
autoupdate=“false” did not do any good. Infact I believe now it´s the value which does get to the Nilan, but not beeing saved.
This is what happened with autoupdate=“false”
2018-12-20 23:12:14.688 [ome.event.ItemCommandEvent] - Item 'Nilan_AirTemp_TempMinSum' received command 14
Thats it, and nothing more! The actual value in the NIlan has NOT changed.
That’s a good thing, you’ve removed autoupdate interfering in what is going on, so you can see woods for trees. I do recommend you disable it for any writable Item that is regularly polled.
OK, so to your real problem. Item Nilan_AirTemp_TempMinSum is bound to channel hol1201 , which is writable. A numeric command is passed, which looks okay. There are no errors reported, so the assumption is that your Nilan accepted it, rather than ignoring or rejecting.
You’re sure this value can actually be set, and is not say calculated by the nilan?
If you are, you’ll probably need to turn on some tracing for Modbus so you can see command and response traffic.
EDIT - maybe Nilan doesn’t like an out-of-range value. You’re using a read transform … shouldn’t there be a write transform too?
1 Like
Using the old modbus binding I could write this register just fine…
The Nilan Modbus doc doesn´t specific say anything, other than it´s a holding register.
Feel free to have a look: page 13 for the 12xx series. E-Pages
It happens to other holding registers as well, but some do work allright.
Guess I´ll try to trace whats happening.
Here is a trace/debug of whats happening:
2018-12-20 23:37:14.540 [ome.event.ItemCommandEvent] - Item 'Nilan_AirTemp_TempMinSum' received command 14
2018-12-20 23:37:14.546 [TRACE] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:myNilan:AirTempRegisters:hol1201 'Modbus data' received command '14' to channel 'modbus:data:myNilan:AirTempRegisters:hol1201:number'
2018-12-20 23:37:14.549 [nt.ItemStatePredictedEvent] - Nilan_AirTemp_TempMinSum predicted to become 14
2018-12-20 23:37:14.555 [vent.ItemStateChangedEvent] - Nilan_AirTemp_TempMinSum changed from 13.0 to 14
2018-12-20 23:37:14.561 [TRACE] [ernal.handler.ModbusDataThingHandler] - Submitting write task: BasicWriteTask@14ebe79[request=BasicModbusWriteRegisterRequestBlueprint@13c7390[slaveId=30,reference=1201,functionCode=WRITE_MULTIPLE_REGISTERS,registers=ModbusRegisterArrayImpl(00 0e),maxTries=3],endpoint=ModbusSerialSlaveEndpoint@10ce781[portName=/dev/ttyUSB0],callback=org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler@10a835c]
2018-12-20 23:37:14.594 [DEBUG] [ernal.handler.ModbusDataThingHandler] - Successful write, matching request BasicModbusWriteRegisterRequestBlueprint@13c7390[slaveId=30,reference=1201,functionCode=WRITE_MULTIPLE_REGISTERS,registers=ModbusRegisterArrayImpl(00 0e),maxTries=3]
2018-12-20 23:37:17.009 [DEBUG] [handler.ModbusPollerThingHandlerImpl] - Thing modbus:poller:myNilan:AirTempRegisters received registers RegisterArrayWrappingInputRegister(00 00 05 14 07 d0 08 98 09 c4 05 78 00 00 07 08) for request ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@237174[slaveId=30,functionCode=READ_MULTIPLE_REGISTERS,start=1200,length=8,maxTries=3]
2018-12-20 23:37:17.065 [TRACE] [ernal.handler.ModbusDataThingHandler] - Channel number will be updated to '0.0' (type DecimalType). Input data: number value 0 (value type 'int16' taken into account) and bool value false. Transformation: Transformation@f35f91[tranformation=JS(divide100.js),transformationServiceName=JS,transformationServiceParam=divide100.js]
2018-12-20 23:37:17.069 [DEBUG] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:myNilan:AirTempRegisters:hol1200 channels updated: {modbus:data:myNilan:AirTempRegisters:hol1200:number=0.0}. readValueType=int16, readIndex=Optional[1200], readSubIndex(or 0)=0, extractIndex=0 -> numeric value 0 and boolValue=false. Registers RegisterArrayWrappingInputRegister(00 00 05 14 07 d0 08 98 09 c4 05 78 00 00 07 08) for request ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@237174[slaveId=30,functionCode=READ_MULTIPLE_REGISTERS,start=1200,length=8,maxTries=3]
2018-12-20 23:37:17.111 [TRACE] [ernal.handler.ModbusDataThingHandler] - Channel number will be updated to '13.0' (type DecimalType). Input data: number value 1300 (value type 'int16' taken into account) and bool value true. Transformation: Transformation@10ca854[tranformation=JS(divide100.js),transformationServiceName=JS,transformationServiceParam=divide100.js]
2018-12-20 23:37:17.115 [DEBUG] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:myNilan:AirTempRegisters:hol1201 channels updated: {modbus:data:myNilan:AirTempRegisters:hol1201:number=13.0}. readValueType=int16, readIndex=Optional[1201], readSubIndex(or 0)=0, extractIndex=1 -> numeric value 1300 and boolValue=true. Registers RegisterArrayWrappingInputRegister(00 00 05 14 07 d0 08 98 09 c4 05 78 00 00 07 08) for request ModbusPollerThingHandlerImpl.ModbusPollerReadRequest@237174[slaveId=30,functionCode=READ_MULTIPLE_REGISTERS,start=1200,length=8,maxTries=3]
2018-12-20 23:37:17.123 [vent.ItemStateChangedEvent] - Nilan_AirTemp_TempMinSum changed from 14 to 13.0
It looks like it gets wirtten value 14 allright, but “something” changes it back to 13.
Did you see my edit about transform? I imagine the Nilan doesn’t like a target temperature equating to 0.13 C
1 Like
Just did 
Arrgh damit!
I just looked in the old items file, (for the old modbus binding). And there is a divide transformation for reading and as well as an multiply transformation for writing.
The old modbus binding.
{modbus="<[nilan_holding_airtemp:1:transformation=JS(divide100.js)], >[nilan_holding_airtemp:1:transformation=JS(multiplydv100.js)]"}
I never actually thought of that part of the items before. I just took for granted, when reading an tranformed value, the same transform would be used when writing… So damn logical, a stupid mistake by me, I should have noticed…And not to blame the doc´s this time. This part is actually explained quite good
I havn´t tried yet, but I believe you´re right (again)… 
Thats probably also the reason why it works fine with some addresses (like steps), but not for temperature writing without a write transform. Thanks alot Rossko!!
Just upgraded my openhab from version 2.3 to version 2.4.
Of course I had to use the new modbus binding instead of the old one.
The transitions was very smooth and just by examine the examples and the parameters of the configuration for the serial connection (this is what I use) was enough to have it up and running in about 5 minutes (including handwriting all the stuff).
I have to say to @ssalonen a big thank you for this amazing job you have done!
1 Like
This one did solved the problem… Thanks again, rossko…