Javascript support of Widgets not up to par with Javascript Scripting Automation

[ThaDaVos]

The problem

It seems that when working on the widgets, they do not support the .numericState and .quantityState options of the items (maybe many more new properties) - I thought they did as it could remedy the old ugly check .displayState and then check .state code - but .numericState always returns undefined

Checking the item returned from items gives only the state and type values (see second screenshot below

Expected behavior

Or full Javascript support - or at least access to these new properties to ease the creation of Widgets now we have UoM

Steps to reproduce

1. Just try to acccess the .numericState inside the Widgets Expression Tester for a UoM used item

Your environment

runtimeInfo:
  version: 4.1.0
  buildString: "Build #3662"
locale: en-NL
systemInfo:
  configFolder: /openhab/conf
  userdataFolder: /openhab/userdata
  logFolder: /openhab/userdata/logs
  javaVersion: 17.0.7
  javaVendor: Debian
  osName: Linux
  osVersion: 6.2.0-33-generic
  osArchitecture: amd64
  availableProcessors: 6
  freeMemory: 419641488
  totalMemory: 832569344
  uptime: 258197
  startLevel: 100
addons:
  - automation-jsscripting
  - binding-avmfritz
  - binding-dsmr
  - binding-gpstracker
  - binding-kostalinverter
  - binding-lgwebos
  - binding-remoteopenhab
  - binding-rfxcom
  - binding-shelly
  - binding-solaredge
  - binding-sonos
  - persistence-influxdb
  - persistence-mapdb
  - transformation-bin2json
  - transformation-exec
  - transformation-jinja
  - transformation-jsonpath
  - transformation-map
  - transformation-regex
  - transformation-rollershutterposition
  - transformation-scale
  - transformation-vat
  - transformation-xpath
  - transformation-xslt
  - voice-mimictts
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: true
    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: N/A
    hardwareConcurrency: 16
    language: nl
    languages:
      - nl
      - 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; rv:109.0) Gecko/20100101
    Firefox/119.0
timestamp: 2023-10-09T09:39:21.502Z

Browser console

N/A

Browser network traffic

Additional information

[ThaDaVos]

Maybe this should be moved to a feature request - as it's apparently by design: https://www.openhab.org/docs/ui/building-pages.html#dynamically-configuring-components-with-expressions

[JustinGeorgi]

It is by design. The devs have put a lot of work in to minimize the amount of information that has to be passed back and forth between the server and the UI in order to maintain UI responsiveness.

The widgets really shouldn't need to be able to run a full javascript engine. If you're doing something that computationally intensive, offload the work to a rule that stores the result in an item, and just use the item the UI.

As for quantity types, just handle them with a simple string -> number conversion and then perform whatever unit manipulation you want manually, that's a far lower impact on the widget resources.

[rkoshak]

The only thing I want to add is that the JS environment that runs in OH rules/transformations is completely and wholly separate and independent from the JS environment that executes in your web browser to execute the widgets.

In this case, the Item class in the JS Scripting add-on's helper library has direct access to the Java Item class provided by openHAB. It can have that access because it runs on the server. All that is available in the UI is what gets to it through the REST API.

[ThaDaVos]

What I meant more was, instead of the whole api - you could include the two properties numericState and quantityState just as displayState is added already - why? Simply to not have to parse the string to a number for example - doing that a lot can also cause a slow down

[rkoshak]

Simply to not have to parse the string to a number for example - doing that a lot can also cause a slow down

Based on experience and experiments, even adding displayState was a stretch. In fact, even if you have a State Description Pattern, displayState will only be there if it's different from state. Even just adding displayState every time adds too much load. Adding two new fields would be beyond what can be supported I would think.

[ThaDaVos]

I don't get why it's such a load? I build Vue based apps for work - loading JSON with thousands of properties and nested objects and the page experience still smooth - so how could adding two properties increase the UI load so much? Or is it the Server side you're talking about?

[rkoshak]

I don't which side but as I understand it is the load in handling and process the event stream.

[florian-h05]

I don't get why it's such a load? I build Vue based apps for work - loading JSON with thousands of properties and nested objects and the page experience still smooth - so how could adding two properties increase the UI load so much?

Item states are sent from the server to the UI over an SSE stream, which has to be processed by the UI. Every new property adds some weight to the processing of that event stream and also requires some more bandwidth — the question is how much.

Let me comment on the two requested properties:

quantityState: Impossible to add, because the Quantity class is part of the JS Scripting helper library and is wrapping openHAB‘s Java QuantityType. Both are not available in the browser.

numericState: Could be added by modifying the processing of the event stream inside the UI, however trying to parse a number from every new pushed state may create some load (you could attempt it only for some types to improve that behaviour).

@ghys WDYT?

[florian-h05]

Closing as numericState has been added meanwhile and quantityState cannot be added, see my explanation above. Please use a state description pattern to convert the displayState to the required unit you want to show.