[Solved] OH3 - Modbus Command Options

Add-ons Bindings
1

Have a dedicated/fresh test environment preparing to migrate to OH 3.

As for my 2.5 operational environment, I manage successfully to get the Slave and Poller bridges Online. However, I struggle to convert from Selection Item in 2.5 to Command Option in 3.0 (metadata).

From my 2.5 setup, I have a Data thing against a write register (without transformation) with a Number item which I use as a Selection Item, as shown below, which enables me to select the desired mode, which again sends/confirms the correct number input to the Modbus unit (working as intended).

Selection item=ChangeUserMode icon=settings mappings=[0="None", 1="Auto", 2="Manual", 3="Crowded", 4="Refresh", 5="Fireplace", 6="Away", 7="Holiday"]

For my OH3 setup, I try to achieve the same for a similar Number item, but then using metadata and oh-label-item. Metadata is set up with action Command Options with following options:

0=None, 1=Auto, 2=Manual, 3=Crowded, 4=Refresh, 5=Fireplace, 6=Away, 7=Holiday

Selection for item appears as expected, however, when selecting different modes, I receive a warning without an actual change of the user mode:

[ernal.handler.ModbusDataThingHandler] - Cannot process command 2 (of type QuantityType) with channel modbus:data:fanControl:changeUserMode:number since transformation was unsuccessful

Any hints/help would be appreciated.

2

Just double check in your events.log that the expected numeric commands are sent to your Item.

That’s a bit suspicious.
Have you inadvertantly selected a non-default profile when linking channel to Item?
Or applied a transform at the modbus data Thing?

3

events.log confirms correct number updates for the item: Received command → Predicted to become → Changed.

The Modbus Data thing is set up without transformation:

UID: modbus:data:fanControl:changeUserMode
label: Villavent Change User Mode
thingTypeUID: modbus:data
configuration:
  writeType: holding
  updateUnchangedValuesEveryMillis: 1000
  writeValueType: int16
  writeMultipleEvenWithSingleRegisterOrCoil: false
  writeMaxTries: 3
  writeStart: "1161"
bridgeUID: modbus:poller:villavent:fanControl

Profile is set as No profile

Skjermbilde 2021-01-27 kl. 08.13.47
Skjermbilde 2021-01-27 kl. 08.13.47732×129 9.5 KB

4

Realised, after having tried different channel types, that traces for different channel types were contained in the jsondb files (even though deleted from main UI). Stopped OH and cleaned up, and recreated the Data thing and Channel / item: Value as Number.

Using writeTransform: default, I now get an error stating:

[ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.modbus.internal.handler.ModbusDataThingHandler@64564fbf': Command '2' of class 'org.openhab.core.library.types.QuantityType' cannot be converted to registers. Please use OnOffType, OpenClosedType, or DecimalType commands.
5

It seems to be complaining about being fed a Quantity but expecting plain numeric.
What OH version are you running?

I know you said you had a Number Item, but are you sure? Sometimes people get mixed up with Number:Dimensionless - which is not what it appears, it’s actually a Quantity usually in % units but unique among Quantity types it is happy with no units (meaning ratio).

6

My test environment is running under: 3.0.0.RC2 - Milestone Build.

Channel/item is created within Main UI as shown below, choosing default Value as Number, item/point set up as basic type Number (not choosing from Numbers with dimensions):

Skjermbilde 2021-01-27 kl. 12.25.49
Skjermbilde 2021-01-27 kl. 12.25.49721×121 12.6 KB

7

I think you should move up to a stable release, though I don’t expect that to affect this issue.

Can you use a rule or REST API to command a simple number to this Item?
I’m looking to eliminate the UI feeding us a Quantity.

Apart from that I’m stumped.

8

Appreciate your feedback.

Switched to latest stable release, 3.0.0 - Release Build, but as you expected, this did not change the issue.

Also tested using a rule, and then the number command is sent successfully:

triggers:
  - id: "1"
    configuration:
      cronExpression: 0 15 13 * * ? *
    type: timer.GenericCronTrigger
conditions: []
actions:
  - id: "2"
    configuration:
      itemName: VillaventChangeUserMode_ValueasNumber
      command: "3"
    type: core.ItemCommandAction

I see that the command is sent with " ", and tried to change to same for Command Options with no luck.

9

You can still use sitemaps and BasicUI under OH3 - I’ll bet that works fine too.

I wonder if you would repeat your rule test using a Quantity command - “22 km” say - and see if it provokes the same message. To confirm my theory.

hmm, deduction then that UI is sending Quantity value to plain Number type.

Finger pointing is complicated here.

Really,the UI is being naughty - there is no good reason to post a Quantity to a Number Item.
The sneaky part is it looks like a Quantity with blank units, which appears the same as, but is not the same as, just-a-number.
But the framework lets you do it - you can command “22 km” to a plain Number without error. It will not behave like a Number:Length though, it’s a bit difficult to understand what use it is.
I’m pretty sure there has been work to UI setpoint widget since OH3.0 which may or may not affect this.

Meantime, if Quantity commands appear to be viable even if unexpected, maybe the binding should handle them more gracefully. I’d call that an enhancement, not a bug.
As it happens, the Modbus binding has been enhanced to deal with “proper” Quantity types, units and all, since OH3.0
It’s possible this is already dealt with - I will try to conjure up author @ssalonen for an opinion here?

10

Seems somehow to be related to an already filed issue on GitHub, although in this specific case for a general Number item set up with metadata for list item widget in Main UI: oh-label-item.

11

Yes indeed. In OH3.1 modbus binding will also support dimensionless quantitype units, e.g. % numbers or quantitypes with unit of one, like here. You might be able to patch your existing installation by updating the modbus transport bundle… Would fix this specific issue I believe.

With the upcoming gain-offset profile the modbus binding can be used with number items having dimensions, e.g. Number:Temperature, with units converted as you would expect. Funnily enough, I rely on the fact that QuantityType_can_ be posted to Number (without dimension!) channel. Naturally the Item type would be having a dimension (e.g. Number:Temperature), otherwise it would not make sense.

Please try to update transport bundle from the gainOffset profile thread.

12

With the new version of the binding, Gain-offset Profile, the issue is solved.

Thanks for the help @ssalonen and @rossko57.

1 Like