Volume control works on its own?

Neuer_User · February 8, 2022, 6:38pm

Hi

I have a strange issue with the Frontier Silicon binding. I have a (pretty old) Dual radio that I connected to via the binding. In general, everything works. However, the volume control somehow changes the volume on its own.

Specifically, if I set a certain volume, e.g. 40%, the volume briefly rises to this value, but then gradually goes back to a value of about 20%. First, I thought, that can’t be. But it is very reproducible. It only happens, when using the binding in openhab. There is no such effect, when using the UNDOK app and neither when directly calling the API via webbrowser.

I did a short tcpdump to see, if there are indeed commands been send to the radio, and yes, they are!

19:26:33.500536 IP swarm-worker1.mbhome.41158 > 172.17.4.26.http: Flags [P.], seq 1:166, ack 1, win 502, length 165: HTTP: GET /fsapi/SET/netRemote.sys.audio.volume?pin=1234&sid=2038482803&value=10 HTTP/1.1
19:26:34.652128 IP swarm-worker1.mbhome.41164 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:34.666767 IP swarm-worker1.mbhome.41166 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:35.703727 IP swarm-worker1.mbhome.41174 > 172.17.4.26.http: Flags [P.], seq 1:165, ack 1, win 502, length 164: HTTP: GET /fsapi/SET/netRemote.sys.audio.volume?pin=1234&sid=2038482803&value=9 HTTP/1.1
19:26:36.744984 IP swarm-worker1.mbhome.41184 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:36.758551 IP swarm-worker1.mbhome.41186 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:37.905588 IP swarm-worker1.mbhome.41194 > 172.17.4.26.http: Flags [P.], seq 1:165, ack 1, win 502, length 164: HTTP: GET /fsapi/SET/netRemote.sys.audio.volume?pin=1234&sid=2038482803&value=8 HTTP/1.1
19:26:38.945726 IP swarm-worker1.mbhome.41206 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:38.959792 IP swarm-worker1.mbhome.41208 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:40.114890 IP swarm-worker1.mbhome.41220 > 172.17.4.26.http: Flags [P.], seq 1:165, ack 1, win 502, length 164: HTTP: GET /fsapi/SET/netRemote.sys.audio.volume?pin=1234&sid=2038482803&value=7 HTTP/1.1
19:26:41.159703 IP swarm-worker1.mbhome.41230 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1
19:26:41.173256 IP swarm-worker1.mbhome.41232 > 172.17.4.26.http: Flags [P.], seq 1:157, ack 1, win 502, length 156: HTTP: GET /fsapi/GET/netRemote.sys.audio.volume?pin=1234&sid=2038482803 HTTP/1.1

This dump show that the initial command raises the volume to 10 (out of 32, I believe), but then there are following commands that slowly reduce the volume back to 7 (first 9, then 8, then 7).

I have no idea, why that is happening. Can anyone enlighten me?

Thanks

Michael

rossko57 · February 8, 2022, 9:30pm

Does your events.log show any activity on the linked Item?

There’s probably some underlying rounding effect like commanding 32% in openHAB side, sends 10/32 to device, new status 10/32 translates to 31.125% back in openHAB, rounds to 31%, etc.
But why should a new command be sent, even if new status does not match last command?

There is a bug in MainUI stepper widget causing it to respond to state changes with new commands

github.com/openhab/openhab-webui

OH3 3.1 stable - Stepper widget sends commands spontaneously

opened 03:37PM - 22 Oct 21 UTC

xsherlockpl

bug main ui

## The problem A wigget is sending spnatagnus commands to the items, rounding …them up to the stepper step ![image](https://user-images.githubusercontent.com/23699880/138481735-d241fb99-469a-4cd9-ac21-82dba7593c42.png) ## Expected behavior Should not happen. ## Steps to reproduce Create item modified by some external controler. On loading the UI layout page. observe the log it will show a number of the commands issued to the items in the steppers on the page code for the stepper ```yaml component: oh-stepper-item config: item: Archive_01_Postriscaldo_valve min: 0 max: 100 scale: true unit: "%" releaseOnly: true commandInterval: 1000 step: 5 title: Archive 01 ``` ## Your environment ```yaml runtimeInfo: version: 3.1.0 buildString: Release Build locale: en-IT systemInfo: configFolder: /etc/openhab userdataFolder: /var/lib/openhab logFolder: /var/log/openhab javaVersion: 11.0.11 javaVendor: Azul Systems, Inc. javaVendorVersion: Zulu11.48+21-CA osName: Linux osVersion: 5.4.0-88-generic osArchitecture: i386 availableProcessors: 2 freeMemory: 26034576 totalMemory: 166723584 bindings: - astro - co7io-bacnet - mqtt - telegram - weatherunderground clientInfo: device: ios: false android: false androidChrome: false desktop: true iphone: false ipod: false ipad: false edge: false ie: false firefox: false macos: false windows: true cordova: false phonegap: false electron: false nwjs: false webView: false webview: false standalone: false os: windows pixelRatio: 1.25 prefersColorScheme: light isSecureContext: false locationbarVisible: true menubarVisible: true navigator: cookieEnabled: true deviceMemory: N/A hardwareConcurrency: 24 language: en-US languages: - en-US - en onLine: true platform: Win32 screen: width: 4096 height: 1728 colorDepth: 24 support: touch: false pointerEvents: true observer: true passiveListener: true gestures: false intersectionObserver: true themeOptions: dark: light filled: true pageTransitionAnimation: default bars: filled homeNavbar: default homeBackground: default expandableCardAnimation: default userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36 timestamp: 2021-10-22T15:30:23.423Z ``` ## Browser console  No erros in console but wisible commands send ```Update iconUseState to true 16.app.js:1 {"item":"Archive_01_Postriscaldo_valve","min":0,"max":100,"scale":true,"unit":"%","releaseOnly":true,"commandInterval":1000,"step":5,"title":"Archive 01","iconUseState":true} app.js:38 Sending command to postriscaldo_valve_reset_switch: ON app.js:38 Sending command to Archive_03_Postriscaldo_valve: 50 app.js:38 Sending command to Archive_07_Postriscaldo_valve: 30 app.js:38 Sending command to Archive_04_Postriscaldo_valve: 35 app.js:38 Sending command to Archive_02_Postriscaldo_valve: 35 app.js:38 Sending command to postriscaldo_valve_reset_switch: ON app.js:38 Sending command to Archive_07_Postriscaldo_valve: 35 app.js:38 Sending command to Archive_06_Postriscaldo_valve: 50 app.js:38 Sending command to Archive_06_Postriscaldo_valve: 45 app.js:38 Sending command to Archive_05_Postriscaldo_valve: 65 app.js:38 Sending command to Archive_04_Postriscaldo_valve: 30 app.js:38 Sending command to Archive_06_Postriscaldo_valve: 50 ``` ## Browser network traffic  ## Additional information

Older OH3 versions have the same bug with knob widget, and slider too I think.

Neuer_User · February 9, 2022, 6:54am

Thanks for your reply, @rossko57

Now comes the very strange thing: While it was a 100% reproducible yesterday (over several hours), I doesn’t do it anymore today I have no idea, what happened.

Anyway, I will see, if that strange “self-control” starts coming back again. If not, then we can move this episode to the category “strange, unexplained events”

Neuer_User · February 9, 2022, 7:07am

Addendum: It has come back, indeed. I just needed to reload the widget page in the browser and it started to appear again. So maybe it is really related to the issue you mentioned. When I close this browser tab and control the volume via the android app, there is no ghost movement. As soon as a browser tab shows the volume widget, this “self-control” starts again.

rossko57 · February 9, 2022, 10:33am

I did say to look in your events.log, where you will see unexpected activity.

Identifying your OH version and the type of widget involved - stepper, slider, knob? - will help too.

Neuer_User · February 10, 2022, 6:52am

openhab 3.2 (stable), the widget is a default widget for a dimmer item (slider). I happens on all screens of the new openhab 3 interface. The old classic interface does not show this issue.

Here is a events.log (on level INFO). The slider was moved from 21 to 30. It then gradually moved back to 21:

2022-02-10 07:48:01.220 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 27
2022-02-10 07:48:01.221 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 27
2022-02-10 07:48:01.224 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 21 to 27
2022-02-10 07:48:01.422 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 30
2022-02-10 07:48:01.432 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 30
2022-02-10 07:48:01.437 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 27 to 30
2022-02-10 07:48:02.317 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 30 to 28
2022-02-10 07:48:03.624 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 27
2022-02-10 07:48:03.627 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 27
2022-02-10 07:48:03.634 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 28 to 27
2022-02-10 07:48:04.727 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 27 to 25
2022-02-10 07:48:05.830 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 24
2022-02-10 07:48:05.839 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 24
2022-02-10 07:48:05.844 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 25 to 24
2022-02-10 07:48:06.923 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 24 to 21

Neuer_User · February 10, 2022, 6:55am

Here another log on level DEBUG:

2022-02-10 07:53:21.687 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 42
2022-02-10 07:53:21.698 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 42
2022-02-10 07:53:21.702 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 18 to 42
2022-02-10 07:53:22.799 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 42 to 40
2022-02-10 07:53:23.891 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 39
2022-02-10 07:53:23.894 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 39
2022-02-10 07:53:23.903 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 40 to 39
2022-02-10 07:53:24.980 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 39 to 37
2022-02-10 07:53:26.096 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 36
2022-02-10 07:53:26.097 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 36
2022-02-10 07:53:26.098 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 37 to 36
2022-02-10 07:53:27.186 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 36 to 34
2022-02-10 07:53:28.294 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 33
2022-02-10 07:53:28.299 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 33
2022-02-10 07:53:28.300 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 34 to 33
2022-02-10 07:53:29.367 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 33 to 31
2022-02-10 07:53:30.497 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 30
2022-02-10 07:53:30.499 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 30
2022-02-10 07:53:30.501 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 31 to 30
2022-02-10 07:53:31.588 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 30 to 28
2022-02-10 07:53:32.701 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 27
2022-02-10 07:53:32.704 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 27
2022-02-10 07:53:32.708 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 28 to 27
2022-02-10 07:53:33.786 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 27 to 25
2022-02-10 07:53:34.903 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'RadioBuro_Volumepercent' received command 24
2022-02-10 07:53:34.906 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RadioBuro_Volumepercent' predicted to become 24
2022-02-10 07:53:34.910 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 25 to 24
2022-02-10 07:53:36.003 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RadioBuro_Volumepercent' changed from 24 to 21

git-boris · June 21, 2022, 5:35pm

I created the same issue at the Add-on some time ago by mistake, because I hadn‘t found this.

github.com/openhab/openhab-addons

[fsinternetradio] percentage volume decreases with paper ui

opened 09:40PM - 21 Feb 22 UTC

git-boris

bug

I’ve found that the percentage volume control for the FS Internetradio behaves o…ddly 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](https://community.openhab.org/u/halloween) [volume_decrease_log.txt](https://github.com/openhab/openhab-addons/files/8112205/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 <state min="0" max="100" step="3"/> 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.

I described the reasons there. I also have a working solution locally, but it does not address the UI but the binding. There would also be possibilities to fix this on UI side, e.g. by not changing the sliders to multiples of the step size for incoming values or not sending the adjusted values in these cases. I‘m new to openHAB and really don‘t know the „correct“ way to solve this. If someone would give me a hint if my approach is correct, I could provide a pull request.