I have an Solaredge MODBUS connection retrieving some values:
1st value is a number
2nd value is a factor (this changes over time)
The combination of both gives the real value
Example:
For “1st Value” = 2071 and “2nd Value” = -2
The real value = 2071*10^-2 = 20.71
How can I solve this with creating rules and a 3rd value?
I thought it might be possible with transformation, but I read that you can not reference to a dynamic value in it
Sample of a javascript transformation, but only with a fixed value 1000:
(function(i) {
if(i < 0) return “UNDEF”;
return parseFloat(i) / 1000;
})(input)
Also, please check out if the sunspec modbus binding would work for you SunSpec - Bindings | openHAB. This is an device specific binding on top of the plain modbus binding, avoiding the error prone configuration by the user.
According to below (binding author @mrbig) you should let the binding auto-discover the device…you should not define the thing manually. Docs have more through guidance how to enable the discovery.
Did it find the device automatically or what was the issue?
The limitation on a transformation is that you can only import one bit of data.
If your two bits of data are in adjacent modbus registers, you would be able to cheat and treat them as a single 32-bit value or whatever.
A JS transform can then analyze the single input to its component parts, do its thing and return a single value.
Not sure how well you feel with Java, since your problem might be solved with an profile. I guess with javascript transformation too, if you play a little bit with bitwise operators.
I experienced same issue with stiebel isg which returns MWh and KWh part of energy as two registers, each taking 16 bits.
Way to solve problem:
Read both registers as single number, if you have uint32+uint32 then read it as uint64, if you have uint16+uint16, read it as uint32.
Within read transformation you can split values back to two numbers.
Return scaled result according to base unit you chose.
(function(val) {
if(val < 0) return “UNDEF”;
reading = val & 0xffff; // first 16 bits
multiplier = (val >> 16) & 0xffff; // last 16 bits
return (reading * multiplier) / 1000; // assuming your unit is kWh or MWh and your base is W
})(input)
Main profit - you can have single item and single read request which moves together. So you never miss a window when you retrieved number but not its scale.