OH3 3.1 stable - Stepper widget sends commands spontaneously

[xsherlockpl]

The problem

A wigget is sending spnatagnus commands to the items, rounding them up to the stepper step

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

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

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

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

[Rossko57]

This feels deja-vu of #789
Maybe stepper got overlooked in the fix for that.

[NeuerUser]

I have a similar (probably the same) problem, described here:
https://community.openhab.org/t/volume-control-works-on-its-own/133073/4

In short:

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 found out that this only happens when a browser tab showing the volume widget is open. The item is a dimmer item with its default widget. As soon as I close this window and instead use the openhab android app to control the volume, the issue is gone.

[WTKodi]

This issue might be general and not only for oh-stepper. I had the same e.g on switches in groups.

• Equipment
  • Group of Light A and B (Dimmer / Average)
  • Light A (Switch)
  • Light B (Switch)

The Group had widgetOrder equal to 0 in order to be promoted as the main Point item of an Equipment. I am not sure if this is important for the error, but it was the reason I had this configuration. I wanted the Group to be the representation of the equipment in the UI.

When switching one light, I got a disco. The lights were not set to ON simultaneously - there was a lag - and therefor I assume the average of the two switches (50%) was sent back to the switches resulting in a loop.