[Modbus] Testing needed: scaling values to Quantity-aware Numbers and writing individual bits

Just attempted to help with testing but fail on installing the jar (as of Jan ,30) linked to in post #1.
I think it’s because on my test machine I run the latest snapshot and your jar has a version constraint saying maximum is 3.0.0.
The output below is when I drop the transport jar into the addons directory. Same with the modbus jar.
Could you please provide the latest, 3.1 compatible one ? (the one I saw you’ve just requested a review on 2 days ago)

2021-04-14 12:03:01.262 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.core.io.transport.modbus-3.1.0-SNAPSHOT-pr1984.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.core.io.transport.modbus [280]
  Unresolved requirement: Import-Package: org.apache.commons.lang; version="[2.6.0,3.0.0)"

Hi @mstormi

I triggered rebuild in github so that I can offer you fresh jar.

No need to install transport bundle anymore in fact, the changes there have been merged a while back.

@mstormi check out the github now, I uploaded the new jar with latest code (functionality unchanged, minor code cleanups).

1 Like

yes it’s working for me as well, no issues encountered so far. Didn’t put up the transport jar .

1 Like

Thank you all for the testing and feedback! The code has been now merged to main and will be part of next official release.

1 Like

Hi there,

Found a ‘bug’ in the modbus gain scaling. I needed a negative gain (-1), which does not work (gain seems to be an absolute value, it’s always forced to positive of sign is not parsed).
I was needing it for changing power flow direction of some energy meters.

Best regards

Thanks for reporting @tjarco . I need to have a look, there is no intentional absolute value conversions at least…

EDIT: @tjarco I cannot reproduce the issue in a lab setup. Could you enable TRACE level logging for org.openhab.binding.modbus.internal.profiles (log:set TRACE org.openhab.binding.modbus.internal.profiles) and share your config.

Ok thanks, I’ll come back later with a trace log.
I’m currently occupied with other stuff.

Best regards,

1 Like

Hi guys,

Appreciate the work on this.
I’d configured the gain+offset profile using the UI, but I’m wondering what the channel syntax is for the .items file format. I attempted the following along with some variations, but no luck.

{channel="modbus:data:pvinverter:holding1:energyyear:number" [profile="modbus:gainOffset", gain="0.001", pre-gain-offset="0"] }

Any suggestions?
Thanks in advance!

Check out the example in docs Modbus - Bindings | openHAB example

Also find the generic docs for profiles Transformations / Profiles | openHAB

I am not sure if the spaces etc. matter (I can see some differences with your snippet), could be. In general the textual config is very error prone and you need to pay special attention to get it right. You can also try to verify if the config is parsed correctly using MainUI web interface.

Hi @ssalonen ,

Sorry for the late response. I’ve put the trace in for the negative gain on a modbus gain and put inserted the configs and log lines below:

The log line regarding the modbus binding is:

2021-12-01 12:56:46.390 [TRACE] [ernal.handler.ModbusDataThingHandler] - Channel number will be updated to '908.00' (type DecimalType). Input data: number value 908.0 (value type 'float32' taken into account) and bool value true. Transformation: CascadedValueTransformationImpl(SingleValueTransformation [transformation=JS(number2d.js), transformationServiceName=JS, transformationServiceParam=number2d.js])
2021-12-01 12:56:46.393 [DEBUG] [ernal.handler.ModbusDataThingHandler] - Thing modbus:data:Acti9_ID150:Acti9_ID150_Holding:Acti9_ID150_RMS_AC1P channels updated: {modbus:data:Acti9_ID150:Acti9_ID150_Holding:Acti9_ID150_RMS_AC1P:number=908.00}. readValueType=float32, readIndex=Optional[3053], readSubIndex(or 0)=0, extractIndex=54 -> numeric value 908.0 and boolValue=true. Registers ModbusRegisterArray(4081EB85FFC00000FFC0000080008000800080008000800080008000800080008000800080008000FFC00000FFC00000FFC000008000800043658000FFC00000FFC000008000800080008000800080008000800080008000800080008000800080008000800080008000800044630000FFC00000FFC0000044630000800080008000800080008000FFC00000800080008000800080008000FFC00000800080008000800080008000) for request ModbusReadRequestBlueprint [slaveId=150, functionCode=READ_MULTIPLE_REGISTERS, start=2999, length=84, maxTries=3]

The log line regarding the modbus profile is:

2021-12-01 12:56:46.390 [TRACE] [nal.profiles.ModbusGainOffsetProfile] - State update '908.00' from handler, sending converted '-1816 W' state towards item.
2021-12-01 12:56:46.391 [TRACE] [nal.profiles.ModbusGainOffsetProfile] - State update '908.00' from handler, sending converted '908 W' state towards item.
2021-12-01 12:56:46.392 [TRACE] [nal.profiles.ModbusGainOffsetProfile] - State update '908.00' from handler, sending converted '2724 W' state towards item.

Items file:

Number:Power   ID150_AC1_Power   "Heatpump Power consumption   [%.3f kW]" (electric_consumer)  	{ channel="modbus:data:Acti9_ID150:Acti9_ID150_Holding:Acti9_ID150_RMS_AC1P:number"	[ profile="modbus:gainOffset", gain="-1.0 W", pre-gain-offset="0" ]}

Things file:

Thing data Acti9_ID150_RMS_AC1P "Acti9_ID150_AC1_P"@"Techniek" 	[ readStart="3053", readValueType="float32", readTransform="JS(number2d.js)"]

transformation file number2d.js

// Wrap everything in a function
(function(i) {
	var FloatValue = parseFloat(i, 10);
  //  FloatValue = FloatValue * 0.010;
	return FloatValue.toFixed(2);
// input variable contains data passed by openhab

Best regards,


Given the timestamps, that looks like three different Items (potentially with different profile parameters) linked to the same data Thing channel.

There was a bug in OH3.0 where link profiles were “sticky” - you could not edit or remove in flight, it would only change on reboot. Not sure if you ended up with multiple profiles on one link, or multiple links; thought it fixed at OH3.1

1 Like

@rossko57 is probably right. Would be easier to see what is happening by having only one channel configured with the profile. In the startup logs you will also see the parameters as seen by the profile.

Hi @rossko57 ,

Thank you for your reply. And what I notice is that it DOES work :scream:
Ah men I feel stupid now. :zipper_mouth_face:

In the meantime (since the report of the profile not working) I’ve made some changes in items and things configurations and restarted openhab several times.

Probably something was not reloaded at the time or configured incorrect.

Nice that profiles work this way!
(And I learned now how to create custom loggers! )

Best regards

1 Like