Transition from Modbus1 to Modbus2. OpenHab2

Nope; I stick to Things files. The binding does work for many other users.

Beware if you change settings in PaperUI it does not get recorded back into any xxx.things file, I don’t know how/if conflicts get resolved, or how to flush out any lingering PaperUI settings.

EDIT - turned out to be conflict with PaperUI representation of “1” and “1.0”, either works in text setups.

Thats what I´m trying to and prefere too.

I do not doubt that. But if my discovery is correct, only serial users will have this problem.

I´ll start a new thread, as this is not really related to transistion from modbus1 to modbus2. Thx for all your help @rossko57 without I would probably still be pulling my hair off in frustration :slightly_smiling_face:

Serial Modbus users are thinner on the ground.

I expect we can come back here for Nilan register specifics later…

Sure, I will return in this thread with full setup!

It´s me again… :slight_smile:

I have gone as far as to writing holding registers. And just as you say, I might run into troubble… Well I did… And now I´m trying to understand how to use this writeMultipleEvenWithSingleRegisterOrCoil.

This is my data thing for this specific holding register:

  Bridge poller controlRegisters [ start=1001, length=7, refresh=6000, type="holding" ] {
      Thing data hol1001 [ readStart="1001", readValueType="int16", writeStart="1001", writeValueType="int16", writeType="holding" ]
      Thing data hol1002 [ readStart="1002", readValueType="int16", writeStart="1002", writeValueType="int16", writeType="holding"  ]
      Thing data hol1003 [ readStart="1003", readValueType="int16", writeStart="1003", writeValueType="int16", writeType="holding"  ]
      Thing data hol1004 [ readStart="1004", readValueType="int16", writeStart="1004", writeValueType="int16", writeType="holding"  ]
      Thing data hol1005 [ readStart="1005", readValueType="int16" ]
      Thing data hol1006 [ readStart="1006", readValueType="int16" ]
      Thing data hol1007 [ readStart="1007", readValueType="int16" ]

   }

When trying to write to register 1002, I get this error:

2018-12-19 00:00:34.426 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - Last request: 1e 06 03 eb 00 02 7a 14
2018-12-19 00:00:34.430 [ERROR] [t.wimpi.modbus.io.ModbusRTUTransport] - failed to read: CRC Error in received frame: 0 bytes: 
2018-12-19 00:00:34.435 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute try 1/1 error: I/O exception: IOException CRC Error in received frame: 0 bytes: . Request: net.wimpi.modbus.msg.WriteSingleRegisterRequest@b7ddc3 (unit id 30 & transaction 41751). Serial parameters: SerialParameters@18b01b9[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
2018-12-19 00:00:34.440 [ERROR] [pi.modbus.io.ModbusSerialTransaction] - execute reached max tries 1, throwing last error: I/O exception: IOException CRC Error in received frame: 0 bytes: . Request: net.wimpi.modbus.msg.WriteSingleRegisterRequest@b7ddc3 (unit id 30 & transaction 41751). Serial parameters: SerialParameters@18b01b9[portName=/dev/ttyUSB0,baudRate=19200,flowControlIn=none,flowControlOut=none,databits=8,stopbits=1,parity=even,encoding=rtu,echo=false,receiveTimeoutMillis=1500]
2018-12-19 00:00:34.444 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (BasicModbusWriteRegisterRequestBlueprint@4aaa96[slaveId=30,reference=1003,functionCode=WRITE_SINGLE_REGISTER,registers=ModbusRegisterArrayImpl(00 02),maxTries=3]). Aborting. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException CRC Error in received frame: 0 bytes:  [operation ID adec7eb6-1b06-45e4-9d5f-a7f3168910cc]
2018-12-19 00:00:34.462 [ERROR] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:myNilan:controlRegisters:hol1003 'Modbus data' had ModbusSlaveIOExceptionImpl error on write: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame: 0 bytes: ', cause2=null)

I believe I should use the writeMultipleEvenWithSingleRegisterOrCoil, but I have no idea how to use it… And the doc doesn´t give an example either…

Beside that, things are going forward, and I have what seems to be a billion data things now :wink:

No reply the writeMultipleEvenWithSingleRegisterOrCoil. needed anyway… I found an example from another in this thread…

And it works for me as well…

This is my data thing:

 Bridge poller controlRegisters [ start=1001, length=7, refresh=6000, type="holding" ] {
      Thing data hol1001 [ readStart="1001", readValueType="int16", writeStart="1001", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true" ]
      Thing data hol1002 [ readStart="1002", readValueType="int16", writeStart="1002", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true"  ]
      Thing data hol1003 [ readStart="1003", readValueType="int16", writeStart="1003", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true"  ]
      Thing data hol1004 [ readStart="1004", readValueType="int16", writeStart="1004", writeValueType="int16", writeType="holding", writeMultipleEvenWithSingleRegisterOrCoil="true", readTransform="JS(divide100.js)"  ]
      Thing data hol1005 [ readStart="1005", readValueType="int16" ]
      Thing data hol1006 [ readStart="1006", readValueType="int16", readTransform="JS(divide100.js)" ]
      Thing data hol1007 [ readStart="1007", readValueType="int16" ]

   }

But its a bit pain to read the doc about this setting, cause it never actually explain “true” to be an option.

I see you’re getting adventurous with Transforms and all :wink:

The docs for data thing writeMultipleEvenWithSingleRegisterOrCoil does suggest that it is a boolean with value of true, rather than string "true"
I think we’d better summon @ssalonen for confirmation

I tryed both true and “true” and found no difference. Both work.
cheers

Yeah… Actually I was using transforms with the old modbus binding too. They were placed in the items file within the channel section. So this part was a peace of cake :slight_smile:

It takes what seem forever to get through all these registers (adresses) for the Nilan device I have. But I get the picture now, and understand the most of it. So it´s just hard work creating all those data things. (I havn´t counted, but I guess I have something like 40-50 data things now, and still quite a few to go).

About the things file…
I think there may be some timing issues resulting in errors and data things going offline when editing the things file. Sometimes when I edit the file adding data, when I save the file, I suddenly get an error in another data thing, and not the one I´m editing. The data thing will go offline and I cant get it back online, except if I restart openhab. Then it comes back to online and working fine again, without any changes.
This has turned into quite some confusions when it happened and taking abit of a time to realise. I think I recall something simular with the old modbus setup. Each time I changed something, I could end up gettting an error. But after restart it works just fine.
I wonder if this could be due to the huge amount of data things, or is this just a “side effect” of modbus?

My point:
The docs never actually mention ‘true’ as an option. Only ‘false’ is mentioned :wink:

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 :slight_smile:

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 :laughing:)
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 :slight_smile:

Awesome! With the detailed steps (what was changed) it is easier to correlate events with logs, that’s all.

@rossko57 @ssalonen

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.