You were right, sorry, my fault.
It wasn’t enough to just move the jar to ./userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.modbus/1.10.0-SNAPSHOT/org.openhab.binding.modbus-1.10.0-SNAPSHOT.jar and to restart.
Re-installing the binding via the gui worked, after downloading the new snapshot .jar.
Background: I have a number of motion/presence detectors, which I represent in OpenHAB as Contact items. Due to being hooked up in different ways to different devices they are not all acting the same way, i.e. CLOSED can be the inactive (rest) state for some, and the active (detection) state for others. Obviously, it would be good to rationalise for consistency.
So, I have some Contact items read from Modbus discrete inputs I would like to “invert”, and the new Transformation feature looked promising.
Contact Standard "sensor [%s]" {modbus="slave1:0"}
Contact Inverted "sensor [%s]" {modbus="<[slave1:1:trigger=OPEN,transformation=CLOSED],<[slave1:0:trigger=CLOSED,transformation=OPEN]"}
That seems to work - but it generates a stream of Item updates for each poll. I guess because we are working outside the scope of the updateunchangeditems=false slave setting. Given a dozen Items it generates lots of unnecessary bus activity and logs.
Using the trigger=CHANGED would work around that … but then I would not be able to achieve the inversion effect by acting differently on different inputs. Aargh!
Yeah you are correct, it’s not possible with the current syntax.
Perhaps it was not sensible to copy the trigger logic from the other bindings as is… If there would be separate item configuration parameter for updateunchanged, would that make sense?
I suppose, but it seems to be yet more clutter and complexity.
Thinks; I have not played with script transforms because I’m not very confident. But would a script triggered off CHANGE achieve the desired result, i.e. update Item on change only? That would be a good enough workaround for oddball cases like mine.
Else, is it possible to extend the scope of the existing slave-defined updateunchanged to apply after transforms? Or rather, avoid triggering tranforms when unchanged.
It seems unlikely anyone would want different behaviour across a modbus slave but the workaround for that would be splitting virtual slaves.
CHANGED in rules should work. The original reason for the updateunchangeditems was to resolve high CPU usage issue with lot of updates – at least on openhab 1.
I had a chance to play, my first grown-up transform
To invert the sense of a Modbus discrete input:
Create the following javascript, call it mbinvert.js
(placed in /configurations/transform in OH1)
// function to invert Modbus binary states
// input variable i contains data passed by OpenHAB binding
(function(i) {
var t = i ; // allow Undefined to pass through
if (i == 'OPEN') {
t = 'CLOSED' ;
} else if (i == 'CLOSED') {
t = 'OPEN' ;
}
return t ; // return a string
})(input)
Note the ‘input’ to the script is pre-processed by the Modus binding into OPEN or CLOSED, suitable for the Contact Item it is bound to. The ‘input’ is not the raw 0 or 1 from the Modbus read.
Item defintion
// This default Contact shows OPEN for Modbus discrete=1
Contact Standard "sensor [%s]" {modbus="slave1:0"}
// This inverted Contact shows CLOSED for Modbus discrete=1
Contact Inverted "sensor [%s]" {modbus="<[slave1:1:trigger=CHANGED,transformation=JS(mbinvert.js)]"}
This generates logs and bus events only when the state changes.
Number zelena_temperatura_modbus "Number [%.1f]" <temperature> {modbus=">[slave1:0:transformation=JS(multiply10.js)],<[slave1:0:transformation=JS(divide10.js)]"}
In console i get error:
2017-06-20 11:16:34.637 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type 'modbus' of item 'zelena_temperatura_modbus' could not be parsed correctly.
org.eclipse.smarthome.model.item.BindingConfigParseException: Invalid number of registers in item configuration
You need to install 1.10.0 (I have now higlighted this better in the opening post), please refer to this thread for the instructions how to install the binding and how to avoid possible pitfalls.
I’ve been playing around with these modbus bindings and have ran in to a problem.
First some context: There’s a program in my PLC which uses certain register to switch an output on or off (there’s an on and off register). In addition I’ve programmed in the PLC the possibility to configure a “PRIO high” and “PRIO low” input to switch the output on or off with priority ignoring any other inputs (including the registers). This allows the possiblity to wire an alarm system into the PLC (high reliability) and when the alarm goes of the “PRIO high” comes high and all lights switch on…
To switch the PLC from openhab using the registers i’m using the item configuration below. Note that i’m using polling on the ouput to update the item state (in case the output is switched from the logic in the PLC);
Don’t look to much at the addresses, the item has been tested and is working; meaning I can switch the output on and off.
Now here comes my problem: when the output is low and the “PRIO high” becomes high the output is made high and as long “PRIO high” is high all other inputs are ignored (including the registers used by Openhab as in the item example above). At this moment the output is high and correctly displayed as high in Openhab. However when I push switch the item to off using the habpanel the item gets the off state while the PLC output is actually high/on… It seems that the polling doesn’t update the item after the modbus command triggered by “trigger” in the item configuration.
I’ll go trough the scenario one more time step by step to make sure everything is clear:
PLC output off (status openhab: off => correct)
PLC output on due to “PRIO high” trigger in PLC program (status openhab: on => correct)
OFF command send by openhab
PLC output stays high as “PRIO high” trigger in PLC program is still high (status openhab: off => wrong)
I’m currently looking for a solution to correct this behaviour, would anyone have some input?
EDIT: forgot to mention; I’m using modbus binding 1.10.0
Not sure I follow exactly, but you probably want autoupdate=false in the Item configuration?
OH ‘helpfully’ updates Items in response to UI/rules commands - useful if you have devices with no response or a response in minutes - but it is not always helpful if you want the Item state to reflect actual device.
