[transform.math] Allow to use an alternative Item State as value for the transformation

[cweitkamp]

• Convert source value and operand to QuantityType to allow proper unit calculations
• Allow to use an alternative Item State as value for the transformation

Special use case: AVM FRITZ! outlets expose power and voltage. I have a rule to calculate the current based on the formula "E = U * I <=> I = E / U" read from two Items. This enhancement allows me to define a profile to do the math.

Currently a remaining issue is the target unit.

Signed-off-by: Christoph Weitkamp github@christophweitkamp.de

[J-N-K]

Regarding the units: would it be possible to add a new method performUnitCalculation with an implementation like

    @Override
    Unit performUnitCalculation(Unit unit1, Unit unit2) {
        return unit1.multiply(unit2);
    }

The AbstractMathTransformationService could then check if at least one of the values has a unit (creating a Unit from the string after the number part). If that is the case, the method could be called and the new unit added to the value. If only one value has a unit, it the other unit should be Unit.ONE, that way even dividing 5 by 2 s would result in 2.5 1/s.

WDYT?

[cweitkamp]

Good idea. But if we think about doing so we might want to cast the source and value strings for the transformation to a QuantityType directly and use the existing arithmetic methods.

[cweitkamp]

Do you think these "inside string" transformations are mandatory? Parsing the source string with text and invalid units won't work with both proposals.

https://github.com/smarthomej/addons/blob/2d81a05d5147e7e16fdda757ebd17c98efdb7389/bundles/org.smarthomej.transform.math/src/test/java/org/smarthomej/transform/math/internal/MultiplyTransformationServiceTest.java#L39-L44

[J-N-K]

No, I don't think that's mandatory. A clean solution that works with units is IMO better.