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)"
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.
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.
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.
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.
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.
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)
// input variable contains data passed by openhab
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
@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.
Thank you for your reply. And what I notice is that it DOES work
Ah men I feel stupid now.
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! )
As @rossko57 have commented in the other thread, rules are the way to go here.
In openHAB it is not possible to feed in multiple items to a transformation. Nor it is possible to feed in parameters for a profile (gain) using an item - parameters are static, inputted manually.
In the Modbus Binding doku i found following snippet: “The profile also works the other way round, scaling the commands sent to the item to bare-numbers suitable for Modbus.”
I tried the modbus:gainOffset profile on an Item to scale values written to Modbus. Unfortunately the modbus server receives the unscaled value.
Here is my Config:
// .rules
rule "Send aggregated temperature Production1 to Modbus server"
when
Member of gTemperaturesP1 changed
then
val aggregatedTemperatureP1 = TemperaturesP1.state as Number
P1Temperature.sendCommand(aggregatedTemperatureP1)
end
// .items
Number P1Temperature "Temperatur Produktion 1 [%.1f °C]" { channel="modbus:data:localhostTCP:AggregatedPoller:P1Temperature:number"[profile="modbus:gainOffset", gain="0.1", pre-gain-offset="0"]}
// .things
Bridge modbus:tcp:localhostTCP [ host="127.0.0.1", port=8502, id=0, reconnectAfterMillis=15000 ] {
Bridge poller AggregatedPoller [ start=1111, length=1, refresh=5000, type="holding" ] {
Thing data P1Temperature [readStart="1111", readValueType="int16", writeStart="1111", writeValueType="int16", writeType="holding" ]
}
}
It is not a big deal, because i need a rule anyways (temperature source is a aggregated Group: Group:Number:AVG gTemperaturesP1 "⌀ Temperatur Produktion 1 [%.1f °C]" <temperature> (Temperatures)) and i can scale the temperature value inside the rule.
But i am curious: is this a bug in the modbus binding or do i have some faulty config or did i misunderstood the feature?