Really appreciate the testing effort!
I am not sure what that error means… What if you just skip the installation of the serial?
Does the modbus bundle install and start?
Since you already have sunspec installed, you must have some version of modbus binding installed. You might need to call bundle:update Xx to make sure the jar from the addons folder is used.
It is working. I only use Modbus TCP.
The first testing results are very positive. I was able to read and write data with following thing configuration:
Thing data EG_Bad [ readStart="0.0", readValueType="bit", writeStart="0.0", writeValueType="bit", writeType="holding" ]
The part to write at the end is new:
writeStart=“0.0”, writeValueType=“bit”, writeType=“holding”
For this part, I am now using a separate thing configuration which looks like this:
Thing data EG_Bad [ writeStart="0", writeValueType="bit", writeType="coil" ]
This I now don’t need any more… awesome! The item is only linked to one channel.
Thank you very much!
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).
yes it’s working for me as well, no issues encountered so far. Didn’t put up the transport jar .
Thank you all for the testing and feedback! The code has been now merged to main and will be part of next official release.
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,
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)
// input variable contains data passed by openhab
Best regards,
Tjarco
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.
Hi @rossko57 ,
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! )
Best regards
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.
OK, thanks.
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?
Cheers,
Stif