[fsinternetradio] percentage volume decreases with paper ui

[git-boris]

I’ve found that the percentage volume control for the FS Internetradio behaves oddly with the Paper UI. The Percentage Volume is decreasing after it is set via a slider For details, see the below paragraphs. I’m using a Teufel 3Sixty radio, but would expect the same behavior for other radios after reviewing the source code.

Scope: This is not related to my absolute volume range. The radio uses the 0-32 range that the binding expects. So especially I don’t have this issue:
https://community.openhab.org/t/frontiersilicon-radio-binding-not-working-on-my-new-internetradio/5460/3
volume_decrease_log.txt

Expected Behavior

When I change the Volume of the volume-percent channel using a slider control in the UI the volume should stay on the level that has been chosen.

Current Behavior

When I change the volume-percent channel using a slider from the GUI, the Volume keeps dropping with delays of 1 second until it finally settles at some low value.
The same happens with a larger initial delay if the slider is shown and I change the volume at the radio.

You can find the relevant part of the log attached

Possible Solution

I checked the binding source code and found the following root cause:

1. When writing and reading the volume percentage, the value is rounded down to/from the absolute value in both cases. So setting a percentage value, reading it and setting the read value again often changes the value.
2. Even if (1.) was not the case, writing a percentage value and reading it again would only yield the same value in about 1/3 of the percentage values, because the 0-100% range is mapped to the 0-32 absolute value range and the binding doesn’t remember the latest set percentage value
3. In thing-types.xml of the binding, the volume-percent channel is described with 
This seems to lead the UI to adjust an incoming value to a multiple of 3 and send it again. This creates the loop.
4. The one second delay comes from an update scheduled 1 second after writing a volume to the radio.

I tried the following solution and tested it:

• Real rounding in both directions
• Instead of caching the absolute value, cache the percentage value. When a value is read from the radio, only update the cached percentage value if it resolves to a different absolute value than the one just read.
  This makes the values stable and the volume isn’t dropping anymore. It returns the expected values.
  I could tidy up the code and provide a pull request if the issue is accepted.

Alternative Solutions:
Another solution that I haven’t tried would be to make the channel only return multiples of three and the „100“ and therefore prevent the adjustment by the UI.

Alternative solution:
Maybe even removing the „step 3“ in thing-types.xml would suffice as a minimal effort fix. It would return a different value than the one set, but the UI maybe would’t send it again. This could also be done additionally to the solution I tested, to prevent the UI from sending unnecessary updates.

As I’m new to OpenHAB, I don’t know the "correct" solution, though. I feel like there should be some standard solution for this kind of rounding issues, but I haven’t found it in the documentation yet.

Steps to Reproduce (for Bugs)

1. Turn on the radio
2. Set the volume to 30 using a slider

Context

I tried out OpenHAB for the first time and checked out devices that I could control with it. I used the volume slider and discovered the described odd behavior.

Your Environment

• Version used: openHAB 3.2.0, fsinternetradio 3.2.0
• Environment name and version: Tested with Safari 15.3 and Chrome 98, OpenJDK 64-Bit Server VM version 11.0.13+8-LTS
• Operating System and version: macOS Big Sur, 11.6.4
  I’m Using the fsinternetradio binding to steer a Teufel 3sixty radio.

[git-boris]

Log excerpt:
volume_decrease_log.txt

[Rossko57]

Sounds like this GUI widget bug
https://community.openhab.org/t/volume-control-works-on-its-own/133073

[git-boris]

Yes, sorry, I had not seen that one. I'm not sure if it's solely a GUI issue, though. If it is clear that the UI must not adjust the value to the 3 step value range or that it must not send the adjusted value back to the binding, then it is at least also a GUI issue. But I'm wondering if the behavior of the binding is "correct". I haven't found a spec that makes this clear yet.

[openhab-bot]

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

https://community.openhab.org/t/volume-control-works-on-its-own/133073/8

[lsiepel]

Related to openhab/openhab-webui#1186

[lsiepel]

As the issue is likely to be caused by the mentioned bug in the ui and should be fixed by the linked PR, i close this issue. Please re-open if this still happens with the latest openHAB version.