could you post an example configuration (.things + .items) for serial devices?
Sure!
Here’s some examples
modbus.things
Reads from from a serial device, configures serial parameters. Holding registers are polled every 500ms. Values are extracted from the holding registers to things read1 and read2. Furthermore, write1 thing is defined in order to tell how commands to readwriteCollector should be handled. In this case the are written as int16 register (first register)
Bridge modbus:serial:endpoint [ port="/dev/ttyS0", baud=9600, id=1, stopBits="1.0", parity="none",dataBits=8, echo=false, encoding="rtu", flowControlIn="none", flowControlOut="none", receiveTimeoutMillis=1500 ] {
Bridge poller poller1 [ start=0, length=3, refresh=500, type="holding" ] {
Bridge readwrite readwriteCollector {
Thing read read1 [ start=0, transform="default", trigger="*", valueType="int16" ]
Thing read read2 [ start=1, transform="default", trigger="*", valueType="int16" ]
Thing write write1 [ start=0, transform="default", trigger="*", valueType="int16", type="holding" ]
}
}
}
modbus.items
Number NumberItemTest "Number readwrite [%f]" { channel="modbus:readwrite:endpoint:poller1:readwriteCollector:number" }
modbus.sitemap
sitemap modbus label="Modbus"
{
Frame {
Text item=NumberItemTest
}
}
###To install the modbus binding
- Install serial transport:
feature:install openhab-transport-serial - install modbus transport bundle (copy it to addons folder, see this thread if you are unsure)
- install modbus binding bundle (same way as the transport bundle)
- List modbus bundles
bundle:list | grep -i modbus. If necessary, start them withbundle:start BUNDLENUMER
The bundles are not visible via Eclipse IOT openhab addon (reason unknown, discussed here). However, you can download the jar files manually for installation.
Best,
Sami
UPDATE: corrected NumberItemTest channel reference.
Thx Sami.
I’ve tried your example configuration.
First off, the value of the Item NumberItemTest is always NULL - it never changes. There are no error message in the log:
https://pastebin.com/raw/UpemGDib
Just for fun I’ve changed the value of “refresh” in the .things file to a lower value WHILE openhab was running. It seems to work (activity leds are blinking faster now) but in the log I got these errors: https://pastebin.com/raw/VQc2WpEZ
Best,
Max
Thanks @mbs38!
I think I had the wrong item configuration (channel id was incomplete). I have now updated the above configuration, please check if it works for you now.
The ERRORs you got – I need to check those more carefully, might be a bug which shows up when poller parameters are changed.
UPDATE: Figured out likely reason for the ERRORs, actually it was something on my backlog already 
Jenkins is now building fixed version. Should be out latest tomorrow!
Best
Sami
Unfortunately it doesn’t work either. -.-
Hmm, something’s wrong. I have to try reproduce using locally…
In the meanwhile, could you enable verbose logging:
log:set TRACE net.wimpi.modbus
log:set TRACE org.openhab.binding.modbus
log:set TRACE org.openhab.io.transport.modbus
and paste here what comes out. Thanks!
Thanks, I will let you know once I know more.
At least there is the NullPointerException, perhaps that causes bad things later on. Know how to fix that – let’s see if there is something else as well.
Thanks for the help!!
OK, I know the reason for not having a value. With this version, you have to link the read thing’s channel to an item
modbus_dummy_bug_workaround.items
Number DummyFix "Number read1 [%f]" { channel="modbus:readwrite:endpoint:poller1:read1:number" }
Number DummyFix2 "Number read2 [%f]" { channel="modbus:readwrite:endpoint:poller1:read2:number" }
update: these dummy items are not needed anymore with the fixed version
The modbus_dummy_bug_workaround.items should not be needed anymore, new version fixes this
I have also fixed the NullPointerException.
Update (July 30): The jenkins seems have some issues which means that the IOT marketplace is not updated yet.
Update (July 31): build issues are now solved and IOT marketplace is updated
Seems to work. However, changing the the poller parameter “refresh” has no effect.
EDIT: There may also be a design issue concerning the thing definitions: If I have understood the idea behind “things” correctly, things should represent an actual physical device - like a Modbus capable sensor for example. We should not confuse users by mixing the concept of things with the concept of objects in object oriented programming…
What do you think about that?
Best,
Max
Cannot reproduce the issue with refresh. At least modifying the *.things file seems to have an effect. It seems that you cannot modify the parameters with paper UI if things file is defined – is this an feature of openhab2?
Updated the binding with some NullPointer fixes when poller has been set to not to poll (refresh=0)
Regarding things and physical objects: indeed, I have the same concern. In fact, it has been discussed quite much in this thread as well. I’m not sure that the analogy of physical object applies really well to modbus, which is basically just bunch of bits and registers – there is no concept of a sensor really.
As commented earlier here, it feels like other low level protocols have not yet received openhab2 translation (KNX, MQTT, HTTP) although some work is ongoing there (e.g. KNX seems to have similar “generic” channels for different item types). I think we could use these as inspiration.
Would love to hear your thoughts on alternative ways to structure the things.
Btw, can’t work on this for the next month due to travels but let me know if there’s something broken there.
Well there are two issues around the refresh parameter:
- If the refresh parameter in the .things file is changed several times in a short time frame the polling stops / crashes
- once openhab has been restarted, the default refresh rate (sth. linke 1.5 seconds) is used again and the refresh parameter in the .things file is ignored.
1 Like
Thanks @mbs38!
Can you please try with the latest, version, available here (there are some issues with build once again, and IOT market place is not updated). I think that some crashes might have fixed with the recent changes.
If you find any crashes or weird behaviour, can you please attach the verbose logs and I will have a look once I have the time, thanks!
Sure.
In Modbus we have a physical device (a PLC, IO-Module, sensor… you name it). Of course we do not know what the meaning of a certain coil or register is…
In my imagination openhab should work like this:
One should be able to define a new Modbus capable device (as a thing) with channels that point to certain registers/coils/… Sth like:
Thing mySensor {
connection=/dev/tty…
device address = 1
channel1:someInt [read: holding register 123 refresh = 5, write: holding register 456 refresh = 0]
channel1:someInt2 [read: holding register 124 refresh = 5, write: holding register 457 refresh = 0]
channel3:someBool [coil 5, refresh=10]
channel4:someOtherInt [read: holding register 4522 refresh = 0, write: holding register 6432]
}
In my opinion the binding should then be able to figure out how to poll the registers as efficiently as possible and also consider the limitations (it is not possible to poll holding registers 123 to 4522 in a singe request for example, neither is it efficient), meaning that register 123 and 124 should be polled within a single request and 4522 in a separate request. Of course all parameters, channels etc. should be editable within the Paper UI.
The user should then be able to bind items to the channels and use these items just like any other.
Best,
Max
It cannot do that, due to the vagaries of device implementations.
Some devices allow you read regs 1 to 10 when only regs 1,2,5,8,9 are defined. Some don’t.
There’s no right way to go about this, but the track Sami has taken is based on the experiences of real users trying to work with a range of quirky devices. The needed flexibility comes at the cost of complex manual configuring.
That is indeed a valid point.
It surely does. The manual configuration should be as easy as possible and once completed should not get into the way anymore. The current implementation creates no less than 6 different things that show up in the Paper UI (screenshot) - and thats just for a single device AND reading/writing to a single register.
For users this is very confusing, especially considering that they have been told beforehand that each thing represents an actual physical device. I suggest that only a single thing should be created for each device.
yeh. Back at the beginning of the thread we established a logical hierarchy to represent Modbus devices ; but it has more layers than OpenHAB provides names for, hence the apparent repetition.
The “simple to use” desire might perhaps be addressed by some kind of templating or add-on - some kind of device specific layer sitting on top of the generic Modbus binding.
1 Like
Hi @ssalonen,
I’m having an issue with the binding while using it for a serial connection
It looks like the binding isn’t able to open the serial port because I see this message in the log files:
Error getting a new connection for endpoint null. Error was: null
I’ve enable trace logging for the binding (and transport).
You can find the log here:
https://pastebin.com/wJ9h3wNB
Let me know if you need more information!
Thanks
Greetings,
Frederic
Thanks @FredericMa !
Let’s try to debug this a bit further
- Can you double check you have the latest version of the modbus binding and transport (should be from Aug 2)
- If you have things text file configuration, can you paste it here
- are all the things online? If not, can check the status messages (in paper ui)
Best