OH3 Modbus things

Setup, Configuration and Use Beginners
,
1

Hi all,

For an unsupported modbus slave I created a thing ‘duco.things’ in the things directory of openhab.
It’s a copy of the solution in topic 2 or more modbus slaves

Thing is, I cant find the thing anywhere. I cant add it as thing, I cant find it as thing, I cant use it as thing.

What am I doing wrong?
I’ m new to openhab and really have no clue.

‘’’
Bridge modbus:serial:endpointDUCO [port=“COM7”,baud=9600,id=1,dataBits=8,parity=“none”,stopBits=“1.0”,encoding=“rtu”] {
Bridge poller DUCOBOX_HOLD[ start=11, length=9, refresh=10000, type=“holding”] {
Thing data teplota1 [ readStart=“0”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota2 [ readStart=“1”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota3 [ readStart=“2”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota4 [ readStart=“3”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota5 [ readStart=“4”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data teplota6 [ readStart=“5”, readValueType=“int16”, readTransform=“JS(divide10.js)” ]
Thing data tlakBMP [ readStart=“6”, readValueType=“int16” ]
Thing data teplotaBMP[ readStart=“7”, readValueType=“int16”, readTransform=“JS(divide10.js)”]
}
‘’’

Best regards,

2

First, look in your openhab.log for evidence that your duco.things file loads without error.

Then make sure the Modbus binding is installed.

3

Ho @rossko57 ,

Thank you for your reply
The modbus binding is installed. When i search the openhab.log for the duco string it’s never found.

Do I have to add it somwhow to a list?
Or is it automatically picked up?
I placed the thing file in /conf/things/
And I rebooted the complete pc (windows)…

Best regards,

4

Yes.
It does have to go in the correct folder.

That seems correct.
There should be a readme.txt already in that folder, for confirmation.

You also have to get the filename extension correct, as xxxx.things format
Common mistake is xxxx.thing or another is xxxx.things.txt, as saved by some editors.

5

Hi @rossko57,

Hidden file extension… yea I should have known that.
It’s a new preinstalled win10 system (I hate it), all my other systems are setup to show file extensions and hidden files. Argh, stupid.

I get an error in the openhab logfile. Perfect :slight_smile:

Thanks.

6

I think your error will be that that data Thing readStart 0 is not included in the poller’s read block 11-20
The readStarts are ‘absolute’ addresses, not offsets within the ppolled range,

7

Hi @rossko57 ,

Thank you for your input.

I’m having some doubts on my things file to be valid.
I’ve got a ventilation system with the ventilator box as the master unit.
Connected to the master box there are RH ad CO2 controlled slave devices (valves, sensors, manual switches, etc).
Every device in the system as a modbus page of 10 addresses, the master unit starting on address 10d.
Every device has a page in holding registers and a page in input registers.
I would like to have them all defined in one things file, including channels. Is this possible?

I was thinking about the following:

Bridge modbus:serial:endpointDUCO [port="COM7",baud=9600,id=1,dataBits=8,parity="none",stopBits="1.0",encoding="rtu",echo=true,receiveTimeoutMillis=2000,timeBetweenTransactionsMillis=500,connectMaxTries=100] {
	 Bridge poller DUCOBOX_NODES[ start=10, length=100, refresh=10000, type="input"] {
		Thing data DUCO_NODE1 [ ]{
			Channels:
			Type number : DevType	   [readStart="10", readValueType="uint16"]
			Type number : Status	   [readStart="11", readValueType="uint16"]
			Type number : Flow	  	[readStart="12", readValueType="int16"]
			Type number : Power	   		[readStart="13", readValueType="uint16"]
			Type number : PowerAvg	   [readStart="14", readValueType="uint16"]
			Type number : PowerMax	   [readStart="15", readValueType="uint16"]
			
			Type number : DevGroup	   [readStart="19", readValueType="uint16"]
		}
	 	Thing data DUCO_NODE2 [ ]{
			Channels:
			Type number : DevType	   [readStart="20", readValueType="uint16"]
			Type number : Status	   [readStart="21", readValueType="uint16"]
			Type number : Flow	   [readStart="22", readValueType="uint16"]
			Type number : Temperature  [readStart="23", readValueType="uint16"]
			Type number : CO2	   [readStart="24", readValueType="uint16"]
			Type number : Humidity	   [readStart="25", readValueType="uint16"]

			Type number : DevGroup	   [readStart="29", readValueType="uint16"]
		}
	 	Thing data DUCO_NODE3 [ ]{
			Channels:
			Type number : DevType	   [readStart="30", readValueType="uint16"]
			Type number : Status	   [readStart="31", readValueType="uint16"]
			Type number : Flow	   [readStart="32", readValueType="uint16"]
			Type number : Temperature  [readStart="33", readValueType="uint16"]
			Type number : CO2	   [readStart="34", readValueType="uint16"]
			Type number : Humidity	   [readStart="35", readValueType="uint16"]

			Type number : DevGroup	   [readStart="39", readValueType="uint16"]
		}
	}	
 	Bridge poller DUCOBOX_NODEScfg[ start=10, length=100, refresh=10000, type="holding"] {
		Thing data DUCO_NODE1 [ ]{
			Channels:
			Type number : ForceFlow    [readStart="10", readValueType="uint16", writeStart="10", writeType="holding" , writeValueType="uint16"]
			Type number : AutoMin	   [readStart="15", readValueType="uint16"]
			Type number : AutoMax	   [readStart="16", readValueType="int16"]
			
			Type number : Action	   [readStart="19", readValueType="uint16"]
		}
	 	Thing data DUCO_NODE2 [ ]{
			Channels:
			Type number : ForceFlow    [readStart="20", readValueType="uint16", writeStart="20",  writeType="holding" , writeValueType="uint16"]
			Type number : AutoMin	   [readStart="25", readValueType="uint16"]
			Type number : AutoMax	   [readStart="26", readValueType="int16"]
			
			Type number : Action	   [readStart="29", readValueType="uint16"]
		}
	 	Thing data DUCO_NODE3 [ ]{
			Channels:
			Type number : ForceFlow    [readStart="30", readValueType="uint16", writeStart="30",  writeType="holding" , writeValueType="uint16"]
			Type number : AutoMin	   [readStart="35", readValueType="uint16"]
			Type number : AutoMax	   [readStart="36", readValueType="int16"]
			
			Type number : Action	   [readStart="39", readValueType="uint16"]
		}
	}

}
8

Yes.
All openHAB cares about - port, ID? Set that in serial bridge.
Register address range, type, poll period? Set that in poller. There may be many pollers belonging to a serial bridge.
Individual register address, interpretation? Set that in data Thing. There may be many data Things belonging to a poller.

9

Hi tjarco,
login via ssh to the console:
ssh -p 8101 openhab@IP_ADDRESS_WERE_OH3_RUNS

Password: habopen

then use
log:tail

Good luck

10

Hi All,

Well the syntax etc seems to be fine and the Bridge is online.
The things are in error state and the log reports:

“Channel type modbus:number could not be resolved.”

While the doc says that Channel type number is a valid type for Data-type Things.

What am I missing?

11

Nope. Can’t be a (data) Thing and a (number) channel at the same time, different entities.

Looking more closely at the docs I think.

You don’t define channels with Modbus binding. You define Things of type data. Every data Thing comes with a selection of channels including number type, which you link to your Items.

Example Thing from the docs

Thing data input1500 [ readStart="1500", readValueType="float32" ]

Example linkage to Item from the docs (though of course you can do it via GUI instead)

Number Input1500Float32 "Input registers 1500 [%.1f]"    { channel="modbus:data:localhostTCP:inputRegisters:input1500:number" }

This is where you choose to use the number, dimmer, or switch channels etc.

1 Like
12

Hi @rossko57,

Yes, oke… that’s what I was afraid of. That was my question earlier.

My problem is that I define my master box as “hub” for my ventilation system. Every room in the house has a (CO2, Temperature, flow controlled) ventilation valve (on the air-valve) and some rooms have an additional room unit sensor with a humidity sensor and manual override.

Duco modbus sheet

l define these sub components as sub-devices (just like an zwave or zigbee sensor) having upto 20 endpoints (status: dev-type, airflow, temperature, humidity, override, parent-node, and setpoints: airflow, temperature, humidity, overrides, limits, etc).

I have 12 devices which would mean that I would get upto 240 things exposed in openhab, whats really would make a mess and sound unlogical. that’s what I would like to prevent by defining the “components” as devices, ans the devices having their endpoints. So, structuring and layering like the zwave/zigbee.

Is grouping of things a solution here? Or must I start a development for an own modbus thing?

Beat regards,

13

What’s your problem? Nobody looks at Things in UI etc. Why are 200 Things more problem than ten Things with twenty channels each? You’re going to have 200 Items, the real stuff of interest, however you go at it.

That’s about Items and Groups. The organisation of the Things and channels they link to is unrelated.

14

Well, perhaps i’m not really into openhab yet. But I’m very charmed about the way of structuring.

Especially, for example, how zwave and zigbee sevices are published as things and contain the properties of that device (thing).

For example the xiaomi sensor (device) has multiple properties like temperature, humidity, light, and has some setpoints for alarm levels.
And it is connected through a bridge (hub/controller). And the thing can have a location (kitchen , etc).

That was wat I, as programmer, was trying to achieve (the easy way).

So, there is no real problem here. It’s just what I preferred.

Best regards

15

Modbus is an ancient protocol, pre-dating PCs, and intended to run factory production lines. There is just a bunch of binary bits and 16-bit registers. There isn’t even an agreed standard to represent a 32-bit integer.

That makes it flexible, of course. We can impose a limitless number of different conventions on what a particular register or group of registers “means”. But there is no way to signal that convention through the protocol. You can’t even signal which of many thousand possible registers are implemented. Just about every manufacturer has their own ideas, and has changed those ideas across the decades. Any meaning you assign to a chunk of data and any clue about where to find it is really just an understanding between the user and the target device designer.

In practice there are many thousands of unique Modbus devices. The openHAB binding has been developed from experience gained on OH version 1, which revealed some people using some really quirky devices. The end result of that is a binding that deliberately exposes the bare bones of the protocol, allowing users to jump through whatever odd hoops their device requires. You can, for an example, read a bit of data from one place and write to a different place.

Within openHAB, that is all hidden because we use the data at the abstract Item level. It’s a one-off configuration task.

This stands in contrast to e.g. zwave, based on extensive published standards. This code means ‘switch’, that code means ‘temperature’. This bit of data represents a decimal number, that bit of data represents a unit of measurement. It’s all codified and structured.

16

I understand your point of view, but do not fully agree.

For exame Sunspec on modbus protocol which holds all Channels for sunspec compatible devices.
Same for standardized energy meters,
and the E3DC thing.

Ofcourse it’s less flexible because the strict description of registers. But in my opinion I think it should be possible to definethe things properties in an abstracted way on lower level instead of doing all the work on higher level.

The zwave is indeed more standardized, but i would like to present my devices to be presented “standardized” (abstracted) into the system on the lowest layer as possible.

With Duco modbus protoc it would in fact be possible to “auto detect” node types because the registers are standardized.
Pages with fixed size (10 words)

Address as x:y = node:function.
y=0 for device type
y=9 for it’s parent

Modbus is ancient, yes, but TCP is older. We can use modbus over (TCP) fiberchannels these days. That’s the beauty of it!

17

There’s no way to find out if some random device uses Sunspec convention. There is no way for a slave device to advertise itself.
If you do know in advance - generally the case - there is an existing Sunpec extension (amongst others) to take care of tedious Thing creation.
Again, the relationships amongst those auto-created Things are of little meaning, it’s the Items you’d be interested in. The predefined convention here does allow the extension to suggest suitable Item attributes, like units.

If you would like to create a Duco extension, please do.

18

Hi @rossko57 ,

For simplicity sake I’ll stick to what you suggested. Modbusbridge ->things->items.

Thank you for sharing your time and your thoughts.

Best regards,