[aWATTar] include fees in calculation

[tl-photography]

The current calculations are a bit off and the config is not able to compensate for this.

This MR would include the correct fees for the service directly in the calculation.

There seems to be a little diverge:
In DE the 3% fee seems to be calculated directly from the net price, while in AT the absolute value of the net prices is used to calculate the fee.

Maybe there is another way of reflecting that in config, I'm open for suggestions.

[tl-photography]

Con someone confirm the calculation for Germany? I'm not sure anymore if the absolute value is used or not.

[lsiepel]

AT and DE both add 3%, why are you using two different ways of doing the same? Only in a negative case it would be different. For example:
if nettotal is 105, both will be 108,15
if nettotal is -105, AT will be 101.85 and DE will be -108,15 (i guess this is wrong, as the fee that you have to pay to awattar, gives you extra in return?)

[Herschdorfer]

It was not clear ro me if they are really doing the same.
I mentioned this in the description and added a commet if someone can confirm.

I would find it strange if they would not use the absolute value to calculate the 3% fees, but i wasn't sure.

The current caculations are like this

DE:

 20 * 1.03 =  20.6
-20 * 1.03 = -20.6

AT:

 20 + |20|  * 0.03 =  20
-20 + |-20| * 0.03 = -19.4

[lsiepel]

We share the same view on this. Hopefully somebody from DE can confirm.

[Wolfgang1966]

I am no longer an aWATTar customer, so I can't tell finally, sorry. But however the logic looks like, I recommend to make the percentage configurable for the binding, similar to the VAT. Otherwise, if aWATTar changes the factor from 3% to 4% a new version of the binding would be necessary.

[jlaur]

Is there any reason to add it at all then, rather than using a transformation? For VAT, there is VAT Transformation Service. This seems like a simple case of multiplying a value?

I'm not sure what is the best fit, but could even be done inline. Otherwise there is https://docs.smarthomej.org/4.2.0/org.smarthomej.transform.math.html

[tl-photography]

Probably it can be made this way.
The only thing that's missing would be to get an absolute value.

[tl-photography]

i now changed it that way that there is an addtional parameter that can be used as a service fee. this will be cacluated from the absolute value.

[tl-photography]

Typo "bridge".

[lsiepel]

No need to wait for fixing this ypo. :-)

[tl-photography]

I just put that there to remember.. I'm case ther might be more changes needed... :)

[tl-photography]

Hi,

Any progress on this? :)

[lsiepel]

As it defaults to the current behavior (serviceFee = 0), it can be merged as is. There is also a trasnformation possible that the user can use to calculate the same and or adjust accordingly to their specific situation. I don't have a specific preference. But as @jlaur brought this up, he might have more to say about it.

[jlaur]

There is also a trasnformation possible that the user can use to calculate the same and or adjust accordingly to their specific situation. I don't have a specific preference. But as @jlaur brought this up, he might have more to say about it.

IMHO adding configuration parameters to add VAT, fees, etc. is bloat when there are more elegant ways to do it:

• Transformation: This is equivalent, since the fee is added directly to the item and time series is automatically supported.
• Group: One could create another item containing the fee and create a Group with SUM aggregate for calculating the total price. This will however not support time series. See Time series support for Group items openhab-core#3869. There is also a work-around for cases such as this: https://www.openhab.org/addons/bindings/energidataservice/#time-series

There is also some related context here: https://www.openhab.org/addons/bindings/energidataservice/#total-price

In any case, I'm not binding maintainer, and this is a small thing, so maybe having a "built-in" calculation outweights the inconvenience of having to configure something additional outside of the binding for this case. So please go ahead if @Wolfgang1966 approves - and @J-N-K also did some recent work on this binding, and might have an opinion as well.

[tl-photography]

There is also a trasnformation possible that the user can use to calculate the same and or adjust accordingly to their specific situation. I don't have a specific preference. But as @jlaur brought this up, he might have more to say about it.

IMHO adding configuration parameters to add VAT, fees, etc. is bloat when there are more elegant ways to do it:

• Transformation: This is equivalent, since the fee is added directly to the item and time series is automatically supported.
• Group: One could create another item containing the fee and create a Group with SUM aggregate for calculating the total price. This will however not support time series. See Time series support for Group items openhab-core#3869. There is also a work-around for cases such as this: https://www.openhab.org/addons/bindings/energidataservice/#time-series

There is also some related context here: https://www.openhab.org/addons/bindings/energidataservice/#total-price

In any case, I'm not binding maintainer, and this is a small thing, so maybe having a "built-in" calculation outweights the inconvenience of having to configure something additional outside of the binding for this case. So please go ahead if @Wolfgang1966 approves - and @J-N-K also did some recent work on this binding, and might have an opinion as well.

Well ok, then there might be a way of adding this tax in config. But to be honest, this is not very convenient, looking at the example configuration (I haven't checked in detail now).

I wanted to add a easy way of having this specific tax to the price, without having to configure a lot.

But I'll not insist on this, so if it's not desirable, I'll just close the PR and try to add it with time series.

[tl-photography]

@jlaur could you maybe give an example of the usage of transformation service?
I checked and i do not see a way of adding the percentage of the absolut value...

[jlaur]

could you maybe give an example of the usage of transformation service?

TBH, I've struggled at lot with this because I never used script transformations before. First success was using JavaScript and UI configuration. In $OPENHAB_CONF/transform/test.js:

(function(data) {
  return Quantity(input).multiply('1.03').toString()
})(input)

Linked item:

Compared to "raw" item with no transformation:

I also tried the SmartHome/J MULTIPLY transformation from the Math transformation package, but it doesn't support time series.

[tl-photography]

Ah thanks, I'll give it a shot and try to use it. If you don't mind I would, if I succeed, change the MR to only change documentation adding this.

[Wolfgang1966]

Also here sorry for the delay. Changes look good to me, just please correct the typo.

Sorry, I am no longer customer of aWATTar, so I don't know whether a service fee is now part of the price in Germany.

General thought:

Originally I thought it would be a good idea to do all the calculations to make the binding easy to use for the aWATTar customers. I am no longer sure if this decision was correct (or more specifically: I tend to think that it was not the best idea in the first place at all). I was not aware of transformations, but I was aware of Rules which could be used to achieve the same results. But computing the gross price in the binding means now, that everytime aWATTar changes the pricing model the binding needs to be adapted too, as we see here.

Strictly speaking my price calculation was not complete from the very beginning, as it did not respect the pricing limits that existed at that time (+/-20ct at the beginning, +/-40ct later). Also, the price calculation is not needed to determine the cheapest hours, which requires more complex calculations and therefore is in my opinion the more relevant part of the binding.

So how about declaring the net and gross price calculation as deprecated and open the door to remove them sometimes in the future or at least no longer adapt them if the pricing model changes again?

[Wolfgang1966]

LGTM after correcting the typo :-)

Thanks

Wolfgang

[tl-photography]

LGTM after correcting the typo :-)

Thanks

Wolfgang

Thanks :)

[tl-photography]

@jlaur

i have tested the transformation services without any success.

I added awattar.js

(function(data) {
    return data
  })(input)

but i only get as error in the logs:

2025-01-09 20:32:23.975 [ERROR] [.module.script.profile.ScriptProfile] - Failed to process script 'awattar.js': (function(data) {
    return data
})(input)

Either the transformation service docu (https://www.openhab.org/docs/configuration/transformations.html#js) is wrong or somthing is broken...

EDIT:

Sorry had forgotten to add JS again in my new installation.

Anyway, after 3h of fiddeling I was not able to get this to work...

[SKLD-OH3]

the update is on the next day not working. only the action to save (again) the binding is starting receive.

[tl-photography]

@SKLD-OH3 I don't think this is the correct place here.

Did you build this branch or do you have an issue with the current version?