Modbus bindings with offset, work or not?

I am totally new to OH, found out about it a week ago or so.

Now, I am representing a system, Smart-House by Carlo Gavazzi, where much automation is done in the controller, functions similar to knx, if you know it better.

A good feature of Smart-House controller is that it is also have modbus TCP or modbus RTU. All functions and I/Os added to the Smart-House system, automatically generates modbusadresses, so from a modbus-master I can access all functions, it’s parameters and physical I/O’s by individual modbus registers.

Why use OpenHab?
Well to have Smart-house talk with other gadgets in the house, like TV, Sonos, weatherservices etc.

I started out to control just one function, a light-function, defined as:

HR 1 0 H0000 UInt16

meaning

Holding Register
ID 1
Adress(dec) 0
Adress(Hex) H0000
Type UInt16

my openhab.cfg:

modbus:tcp.slave1.connection=192.168.100.156:502
modbus:tcp.slave1.type=holding
modbus:tcp.slave1.id=1
modbus:tcp.slave1.start=0
modbus:tcp.slave1.length=1
modbus:tcp.slave1.valuetype=uint16

item:

Switch Ljus_pers_desk		"Pers test1"		{ modbus="slave1:0" }

It works well.

But if I add an item:

Switch Ljus2 		"Pers test2"		{ modbus="slave1:36" }

I’d expect to have info from

HR 1 36 H0024 UInt16

But I get error from the second call:

2016-09-07 16:03:59.458 [INFO ] [runtime.busevents             ] - Ljus_pers_desk state updated to ON
2016-09-07 16:03:59.462 [INFO ] [.b.modbus.internal.ModbusSlave] - ModbusSlave error getting responce from slave

However if I change the .cfg to:
modbus:tcp.slave1.start=36

item Ljus_pers_desk is now reflecting status from register 36

So, back to my question:

Isn’t it supposed to make one connection (base adress like 0), per type and function code, and then use offsets in the .item file to retrieve all objects?

I might have 50-100 objects I want to bring in from modbus to populate the home-page, and if I have to make all of them with absolute references in the .openhab.cfg file it seems very heavy. I also think i have to restart the server every time i make a change in openhab.cfg, while .items files will be parsed during runtime am I right?

Hope my questions are clear, thank for reading!

I can’t help with the Mobus stuff. You will have to delve into the code and/or hope someone who knows this binding to respond. But you are indeed correct on the config files. Changes to openhab.cfg and logback.xml require a restart of OH for changes to be seen. Changes to everything else in configurations and changes to the addons folder get picked up automatically.

Thanks for confirming that. That makes it even more interesting to add new modbus-items via .itemfile and not by adding new connections to the .cfg, as I have seen as solution in other discussions. Because dealing with modbus often make use of the trial end error-method…

Seems like @ssalonen is one who knows how the modbus bindings work, I was hoping he could pick this up :slight_smile:

It seems that you are using 1.8.3 version of the modbus binding? That has several major bugs, and I would suggest trying out the 1.9.0-SNAPSHOT version available from here. More importantly, it logs proper error messages telling what is the real problem. Can you try with this version and report back please?

Isn’t it supposed to make one connection (base adress like 0), per type and function code, and then use offsets in the .item file to retrieve all objects?

Yes, this is how the binding works. Each “slave” in modbus.cfg corresponds to a single modbus query. See wiki for more details.

EDIT: In your case the issue is that are not reading enough registers, just adjust the length accordingly. See wiki for examples.

Think of it as the binding reading blocks of registers. OH fetches the whole block of data in one transfer.

You don’t have to configure OH items for all of the registers you read. So to read 1 and 36 you could define a single ‘slave’ in the openhab.cfg with a length of 36. The block has to be all the same datatype, like uint16.
And then define just the items you.want from the block by offset,
Number XX “testX” { modbus=“slave1:0” }
Number YY “testY” { modbus=“slave1:35” }

You do have to try it out with any given device, which might reject block reads that include registers that don’t actually exist in that slave device.

If you need to leave gaps, or change datatypes, then you must break the blocks up by configuring separate “virtual” slaves in openhab.cfg which map onto the same physical device.

1 Like

Thanks @rossko57, I think your explanation saves the day. That makes total sense, since thats how modbus requests are built. (id, FC, start, length) and then pick the pieces out of the answer
I just didn’t see the structure like this from the documentation I have read. Think you should add this explanation to the wiki :slight_smile:

This explains why I get good answers on my first adress but not offsets, because this modbus slave(SH2WEB24) does not have all information in consecutive registers. I have to add all my requests in the openhab.cfg.

How will it affect the performance if I add for example 50 or 100 or more “modbus-slaves” in .cfg?
And do I need to consider other settings like pollingtime, turnaround-times? (you name it with other terminology, i know but I haven’t picked that up yet). I don’t think this is as important in modbus TCP as it is in serial communication. I think TCP handles it?

How will it affect the performance if I add for example 50 or 100 or more “modbus-slaves” in .cfg?
And do I need to consider other settings like pollingtime, turnaround-times?

The openhab “slaves” will be polled one after another. Only single connection is established at a time. Certainly more slaves will mean more protocol traffic but there’s really no way around it. Try it first with default settings and determine if the performance is good enough for you. For performance optimization, I suggest you consult this wiki section.

Btw, tried to improve the docs based on your feedback, thanks a lot! I think the word “slave” might be causing quite a lot of confusion…

I will try to make a test with a full project with lot of “slaves”. I post the feedback here later.

I finally made the connections without problems with 1.8.3 version, but also used 1.9.0-SNAPSHOT.
I suspect the bugs you mention are mostly related to serial devices. The difference I noticed was more info on console, wich is always good.

One thing struck me.
The error i got when first trying was

When in fact the problem was in the .item file, where I used “slave1:36” but I did not read 36 words in the bindings-request.

This error should display “Offset in *.item out-of-range” or similar, because now I thought it was a problem of the binding or my modbus-device.

Hi

Are you sure that error message is with 1.9.0? I believe the grammar has been fixed for 1.9.0.

Would be interested to hear if the new error message was self explanatory in this case…

Best
Sami

Hi @ssalonen,

no, that was from the “original” 1.8.3.

with 1.9.0 i see this message:

2016-09-10 12:14:17.166 [ERROR] [.b.modbus.internal.ModbusSlave] - ModbusSlave (slave3) error getting response from slave
java.lang.ArrayIndexOutOfBoundsException: 1514

This refers to this item:

 Switch GF_Ute 	"Belysning ute entre"	 {modbus="slave3:1514"}

I understand that now, but didn’t see it that way when i debugged my configurations.
But that was because i did not understand how the request was built from .cfg and items togehter.