[transform.vat] Initial contribution

[jlaur]

This simple transformation adds VAT (Value-Added Tax) to a given input amount.

Its main purpose is to conveniently let the provided profile add VAT when linking an item to a channel without requiring any configuration. However, it can also be used for display purposes only, although in this case the rate must be configured.

One use-case is to eliminate the need for any built-in VAT logic in bindings providing electricity prices, thereby reducing redundancy.

Advantages:

• Automatic rate according to country in openHAB regional settings (no configuration needed).
• Consolidates VAT calculation in one centralized place.
• Potentially eliminates custom VAT calculations in bindings.
• Not dependent on any online service.

Limitations:

• Only standard rate supported, no specialized types of VAT.
• Only one rate per country supported, no deviations for specific territories .
• Only current rate supported, no validity periods implemented yet.
• Rates are currently built in, thus add-on needs to be distributed when rates are changing.

Alternatives:

• Redundant VAT implementations in bindings.
• Manually applying VAT through rules.
• Using the MULTIPLY math transformation in SmartHome/J having the rate configured multiple times.

See also #14222 (comment)

Resolves #14524

Screenshots

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/vat-transformation-4-0-0-0-4-1-0-0/144942/1

[J-N-K]

I can't find the discussion at the moment, but I remember that a "MULTIPLY" or "DIVIDE" profile was rejected for being to specific and confusing (because of too many transforms/profiles if similar ones would be introduced) and those problems should be solved in rules. This seems to be even more specific.

[jlaur]

I can't find the discussion at the moment, but I remember that a "MULTIPLY" or "DIVIDE" profile was rejected for being to specific and confusing (because of too many transforms/profiles if similar ones would be introduced) and those problems should be solved in rules. This seems to be even more specific.

I was initially looking at the SmartHome/J math transformation, because the MULTIPLY profile would have been a quick solution for me to this problem.

I agree that this profile is very specialized, but personally I think both the math transformation and this one provides value. The math transformation fits right in, where this one is more in a gray area because in contains logic which might be too complex for the intention of transformation/profiles - not sure. I can't find any other types of components that would fill in the gap I'm trying to fill here, though.

I recently merged #13259 which is also very specialized - I was (and am) not aware of any guidelines for the scope of profiles and transformations. Also, no one had commented with any arguments against the PR since August 2022.

@openhab/add-ons-maintainers - any opinions/input? Also @J-N-K - as I read your comment, you are referring to a rejection reason provided by someone other than yourself. What is your own opinion here?

[jlaur]

@openhab/add-ons-maintainers - gentle ping. Which level of specialization for profiles/transformations in the addons repository is acceptable? Examples:

• VAT (this PR).
• Math
• Roller Shutter Position: [rollershutterposition] Initial contribution #13259

IMHO, since this is selection of dedicated tools that users can choose to install (or not), we should try to be as open as possible. I would personally have used the Math transformation before adding VAT calculations into the Energi Data Service binding, but would also prefer this even more specialized version rather than building monolith bindings with duplicated functionality or leaving it entirely to the users to add such functionality in rules, creating even more duplication.

[lolodomo]

IMHO, since this is selection of dedicated tools that users can choose to install (or not), we should try to be as open as possible.

I agree.

[J-N-K]

Since the add-ons list is not searchable (at least for me), you should also think about grouping similar functionality in one bundle. With increasing number of profiles the UI should be changed to a dropdown instead of the selector we have now.

Otherwise I agree that it should be as open as possible, but keeping in mind that "we don't want it to do everything for everybody".

[kaikreuzer]

I agree that we should be open as there can be many helpful specific transformations for different situations.
My only concern is indeed the potential abundance of such transformations/profiles.
While bindings are a fairly complex construct that make sense to have in dedicated bundles, I feel that for a fairly simple feature like this VAT transformation, 660 locs are a lot - making it on the one hand a lot of effort to implement such an add-on and making it on the other hand a potentially large set of additional add-ons a user might want to add.

So I like @J-N-K's proposal of grouping similar things into a single transformation add-on. Like car companies went away from putting every single feature on their pricelists to offering feature bundles, we could also make the choice easier for users here. Especially, if a feature does not require any bigger external libraries, but is rather a piece of simple Java logic, we could ship many such transformations with others "for free" even, if the user might not use them (yet).

The resulting question would now only be: What are reasonable groups?

[jlaur]

So I like @J-N-K's proposal of grouping similar things into a single transformation add-on. Like car companies went away from putting every single feature on their pricelists to offering feature bundles, we could also make the choice easier for users here. Especially, if a feature does not require any bigger external libraries, but is rather a piece of simple Java logic, we could ship many such transformations with others "for free" even, if the user might not use them (yet).

Makes sense. Only thing to consider here - as also pointed out by @J-N-K:

With increasing number of profiles the UI should be changed to a dropdown instead of the selector we have now.

Currently profiles which are not installed will not "pollute" the UI. If we start bundling them, more entries would also show up in the UI, even some specific ones the user may not be interested in (yet). So probably the UI should be improved before bundling too many profiles.

The resulting question would now only be: What are reasonable groups?

In this repository, this is all we currently have:

• org.openhab.transform.bin2json
• org.openhab.transform.exec
• org.openhab.transform.javascript (doesn't exist anymore)
• org.openhab.transform.jinja
• org.openhab.transform.jsonpath
• org.openhab.transform.map
• org.openhab.transform.regex
• org.openhab.transform.rollershutterposition
• org.openhab.transform.scale
• org.openhab.transform.vat (doesn't exist yet)
• org.openhab.transform.xpath
• org.openhab.transform.xslt

Possible candidates:

• JSON: bin2json + jsonpath
• XML: xpath + xslt

Of course, if we welcome new profiles, there will also be more to group. 🙂

Maybe you were already thinking about more abstract groups, i.e. some kind of "themes"?

[J-N-K]

There are also already the system profiles. That aside: profiles are not necessarily coupled to transformations.

[clinique]

LGTM

[kaikreuzer]

That aside: profiles are not necessarily coupled to transformations.

That's right - we even do not have any "profile add-ons", but only "transformation add-ons". But every transformation add-on comes with its own profile. So bundling together transformations will automatically result in a longer list of profiles (which the user might not want).

Maybe it would already be enough to split the profiles into 3 groups in the UI: System profiles, transformation profiles and profiles that come with other add-ons (e.g. the enocean binding). This should already give some better overview.

Still, this does not address the potential proliferation of transformation add-ons itself. I don't really have any good idea how to deal with this yet, since packaging things together is imho not well supported by our architecture (wrt installation, documentation, etc.). So maybe we should take that discussion out of scope of this PR and just consider "vat" to be another fairly specific transformation next to rollershutterposition and we will deal with the matter as soon as we really feel that there's too much uncontrolled growth...

[J-N-K]

My comment was not intended as a request to delay merging, just an information for those not so familiar with profiles 😀

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/dishwasher-price-calculation-automation/139207/5

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/vat-transformation-3-4-0-0-4-0-0-0/145451/1

[jlaur]

@Confectrician - should new transformations appear here automatically, or is some manual action needed:
https://next.openhab.org/addons/

? I'm wondering if I got some kind of metadata wrong.