Thanks Max!
Yeah I would like to get rid of it exactly because of that issue.
Ok I did not know that you have beefy cpu, I think the test would require raspberry pi or similar as you mentioned.
Best
Sami
Thanks Max!
Yeah I would like to get rid of it exactly because of that issue.
Ok I did not know that you have beefy cpu, I think the test would require raspberry pi or similar as you mentioned.
Best
Sami
Testing on “high power” hosts (I run on a Windows dual P4) is valid and does show up different issues. I had lots of “new” race conditions to sort out when migrating from an elderly laptop. It is of course equally important to test on slower platforms.
Not really ready to go with OH2 yet myself, the lack of basic login password is off-putting. Yes I know, reverse proxy etc., but I want to avoid more subsystems to maintain.
Can’t see a problem with enforced updateunchangeditems=true. Out of interest, how does that interact with ‘expire’ binding - ‘invisible’ updates restart expiry or no?
Thanks for the reply!
According to expire binding documentation
If another binding is repeatedly updating the state of the item to be the same state it already was, the expiration timer will continue to be reset into the future. Dedicating an item to the expiration function (so it doesn't receive repeated updates from another binding) would avoid unwanted behavior, should it apply in your case.
I think the warning above would apply, correct?
Best
Sami
That is the behaviour that would be taken away. I can imagine someone currently using expire to detect e.g. a failed modbus device.
There should be alternative ways to do that, if the Modbus binding updates Items to UNDEF (or whatever it is in OH2!) upon failure.
Or by looking at status of Things.
So I do not think that should be a stopper for removing this option, and reducing overheads.
EDIT - the standard ‘Undefined’ Item value in OH2 is in fact NULL (distinct from null meaning no value).
I presume the Modbus binding should set read Items to NULL when retries all fail. We do not want some special UNDEF value or something instead, right?
What about write failure - any change in Item, or rely on Thing status for those who want to check? Most write Items would in reality be read/write so the next read poll would usually pick it up.
There should be alternative ways to do that, if the Modbus binding updates Items to UNDEF (or whatever it is in OH2!) upon failure.
Agree on this. Good point about Thing status, that sounds like the right way to handle the situation (although there is no
support in scripts as trigger, yet)… Also we could have additional channels for diagnosing issues, similar to exec binding provides exit code, time of last execution etc.
Best,
Sami
Info only - Thing status can now be used to trigger rules, which for Modbus users allows for creating error management rules.
I’m trying to post up first version of the binding to the IOT marketplace. I have tested it very superficially but would like to start gathering first feedback already.
At this stage only TCP connections are supported, will implement serial support later.
UPDATE : the binding is now in the eclipse market place :
Both the transport and binding should be installed for a working installation
Best,
Sami
The binding follows the thing hierachy described in here (Alternative proposal (better?) version).
So you have to define the following things
It’s most convenient to use readwrite channels to read the data; values from all read are aggregated from all the read things. This is similar how old binding item state reflected all the “read definitions” in the config string.
Please comment!
Best,
Sami
Serial slaves should be now supported as well, jenkins is building so tonight there should be a test version available in the IOT store.
Any feedback or testing would be much appreciated!
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
feature:install openhab-transport-serial
bundle:list | grep -i modbus
. If necessary, start them with bundle: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