Modbus support for transformations, roller shutter items, read-only items, write-only items, and others

Hi @ssalonen,

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.

bundle:list now says:

openhab> bundle:list |grep -i modbus
218 | Active   |  80 | 1.10.0.201704100111   | openHAB ModbusTCP Master Binding

and before the re-installation:

openhab> bundle:list |grep -i modbus
210 | Active   |  80 | 1.10.0.201702140757   | openHAB ModbusTCP Master Binding

Thanks a lot!

1 Like

Hi @ssalonen,

I want to thank you for the great work with the transformation integration.
If you have a paypal account I would like to offer you a beer!

2 Likes

This is perhaps one for @ssalonen to ponder

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!

Any thoughts on how to do this?

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?

Best
Sami

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.

Best,
Sami

I had a chance to play, my first grown-up transform :smile:

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.

1 Like

Modbus transformation is not working for me.

Item

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

@KJan, are you sure you have the correct version of the binding?

Best,
Sami

I installed binding from Paper UI. Is there any other way?

Hi,

The feature is not available in 1.9.0. Already commented here, I believe: Modbus transformation not working

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.

Best,
Sami

Hi,

Where can i find version 1.10?

Thanks for your help :slight_smile:

Hi

Since 1.10.0 is not released yet, it is generally recommended to use the latest development version. You can find these “snapshot” versions here: https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastSuccessfulBuild/artifact/bundles/binding/org.openhab.binding.modbus/target/

Best,
Sami

Everything is working and SetPoint in sitemap is now also working just fine :slight_smile:

Thank you again!

Hi,

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);

Switch DO_01_1 “Kitchenlight”
{modbus="<[wago750:0],
>[wago750:11776:trigger=ON,transformation=1],
>[wago750:11777:trigger=OFF,transformation=1]"}

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:

  1. PLC output off (status openhab: off => correct)
  2. PLC output on due to “PRIO high” trigger in PLC program (status openhab: on => correct)
  3. OFF command send by openhab
  4. 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

Thank you!

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.

1 Like

This indeed resolved my issue, thank you for your answer!