Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong value of Slider for (e.g. MQTT) dimmer items #832

Closed
CSchlipp opened this issue Jan 21, 2021 · 2 comments
Closed

Wrong value of Slider for (e.g. MQTT) dimmer items #832

CSchlipp opened this issue Jan 21, 2021 · 2 comments
Labels
bug Something isn't working main ui Main UI

Comments

@CSchlipp
Copy link

CSchlipp commented Jan 21, 2021

The problem

Preface: This issue may not be specifically related to MQTT items, but that's where I've noticed it and what's probably the easiest way to reproduce..

I have several MQTT things with channels of type "dimmer", annotated with min, max, and step values, usually ranging from 0-254. These channels are linked to OH items of type Dimmer.

Main UI shows a slider for these dimmer items, but mixes up the display of raw min/max values and calculated dimmer percentages. The following Dimmer is e.g. set to 100%:
image
(Channel: min=0, max=254, step=1; Item: state=100%)

  • The slider in the UI is set to be between min and max of the channel
  • The position of the slider is however the percentage value.
  • Setting the slider to a value outside of 0-100 will not update the item state at all

This especially gets worse when the min-value is not equal to 0, then the slider dot may even appear outside of the slider bar:
image
(Channel: min=137, max=370, step=1 ; Item: state=11%)

Expected behavior

The MQTT documentation states in Section “Channel Type “dimmer””, that:
Defining a channel of type dimmer with min/max/step definition leads to an automatic calculation of a percentage value, that should be linked to to an item of type Rollershutter or Dimmer.

Dimmer items are defined to be in the range of 0-100.

Therefore:
For all dimmer items, the UI should by default (=without having to change the state representation every time) display a slider ranging from 0 to 100, with the dot representing the current percentage value.

Steps to reproduce

  1. Create a MQTT Thing with a channel of type dimmer, e.g.:
Thing topic ledpanel "LED Panel"
{
  Type dimmer : brightness  "brightness"  [ stateTopic = "<anyStateTopic>", commandTopic = "<anyCommandTopic>", min = 0, max = 254, step = 1 ]
  Type dimmer : colortemp  "colortemp"  [ stateTopic = "<anotherStateTopic>", commandTopic = "<anotherCommandTopic>", min = 153, max = 370, step = 1 ]
}
  1. Map this dimmer channel to a dimmer item, e.g.
Dimmer  LedPanel_Dimmer  "Dimmer"  ["Control", "Light"]  {channel="mqtt:topic:server_retain:ledpanel:brightness"}
Dimmer  LedPanel_ColorTemp  "Colortemp"  ["Control", "ColorTemperature"] {channel="mqtt:topic:server_retain:ledpanel:colortemp"}
  1. Update the channel state, e.g. via Developer Tools to a percentage value, e.g. 100 for the first example, or 11 for the second one.
  2. Observe the wrong slider position
  3. Update the item state with the slider, e.g. to the very right
  4. Observe that there is no change to the item state (in the logs)

Your environment

runtimeInfo:
  version: 3.0.0
  buildString: Release Build
locale: de_DE
systemInfo:
  configFolder: /openhab/conf
  userdataFolder: /openhab/userdata
  logFolder: /openhab/userdata/logs
  javaVersion: 11.0.9
  javaVendor: Azul Systems, Inc.
  javaVendorVersion: Zulu11.43+21-CA
  osName: Linux
  osVersion: 5.4.0-48-generic
  osArchitecture: amd64
  availableProcessors: 8
  freeMemory: 49627896
  totalMemory: 132120576
bindings:
  (...)
  - mqtt
  (...)
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
    prefersColorScheme: dark
  isSecureContext: true
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: 8
    hardwareConcurrency: 12
    language: de-DE
    languages:
      - de-DE
      - de
      - en-US
      - en
    onLine: true
    platform: Win32
  screen:
    width: 2560
    height: 1440
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: dark
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
  userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
    like Gecko) Chrome/87.0.4280.141 Safari/537.36
timestamp: 2021-01-21T17:31:57.670Z

Browser console

e.g. for the second example with the colortemp channel, when setting the slider to a value of 333:
image

Browser network traffic

e.g. for the second example with the colortemp channel, when setting the slider to a value of 333:
image

Additional information

  • If the channel and item would have been of type number, the current behavior would most likely be correct.
  • I know that you can currently work around this, by setting the state representation for every item manually to min=0, max=100, but this should already be the default for all items of type dimmer, as other values cannot be represented in such an item anyways.
  • This topic is being discussed in the forums: https://community.openhab.org/t/slider-scaling-on-oh3/110727
@CSchlipp CSchlipp added bug Something isn't working main ui Main UI labels Jan 21, 2021
@hubsif
Copy link
Contributor

hubsif commented Mar 20, 2021

Since I also want to use MQTT with OH3, I've had a closer look at this. As it seems to me, the fault is not within the UI, but more in the core/binding. The core (REST API) returns the stateDescription of that item with the minimum and maximum values set in the channel. Perhaps that's also what the channel reports to OH. I don't know if it's possible, but I think the channel should keep those min and max values to its own and always report 0-100 to OH, because these are the values the channel actually accepts.
So, I'd suggest to open an issue in the binding/addons repository.

@kaikreuzer
Copy link
Member

This should hopefully be fixed by openhab/openhab-addons#10587.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working main ui Main UI
Projects
None yet
Development

No branches or pull requests

3 participants