Where/how to store configuration parameters

Setup, Configuration and Use Scripts & Rules
1

Good evening,

What would be the best place/method to store configuration parameters for my Javascript scripts?

Like for example, I am writing a script that brings up our shutters when a certain wind speed is passed and I do not want to hard-code the threshold in the script but put it in a UI-accessible configuration parameter.

One idea was a non-semantic Item with Metadata, but maybe there is a better way? What I’d find neater is a Point, but it seems there is no way on the UI to alter a Point’s current state value?

2

Items and/or Item Metadata. It can be in the semantic model or not, that part doesn’t matter. All that does is change how the Item appears and where it appears in MainUI.

If this is something that is going to be adjusted frequently, an Item is better than metadata. Metadata is better for set-it-and-forget-it.

I don’t know what this sentence means. A “Point” (assuming you are referring to Point in the semantic model) is an Item. It’s an Item like any other. The only difference is it has a specific well known tag. And you can edit any Item’s state through the UI. But the widget chosen to display the Item by default may not be editable but that’s what the “default stand alone widget” and “default list item widget” Item metadata are for. You can make that Item appear how ever you want, editable or not.

Were I to put this into the semantic model, I’d use “Setpoint” for the Point tag and “Wind” for the Property tag. Note, if you use “Setpoint” for the Point tag, by default you’ll get a slider to control the Item’s state.

You can also quickly send an update to an Item using the ~Scratchpad~ Script. Press alt-shift-d, choose the third tab and click “Open Stratchpad”. You can then select a language and it will create a “Script” where you can write some arbitrary code (e.g. update an Item with an initial state), orchestrate a temporary test, experiment with something, etc.).

3

Good morning, thanks for your reply and help!

OK, understand. So if I understand it correctly, I need an input card, link it to the item and also show the sendButton, so I can update the item state with the new value, correct?

value: oh-input-card
config:
  outline: false
  item: Weather_Station_Wind_Speed_Shutter_Threshold
  inputmode: numeric
  useDisplayState: false
  name: Wind_Speed_Threshold
  type: number
  title: Wind Speed Threshold (km/h)
  required: true
  sendButton: true
  validate: true

This seems to work in principle, but I have two issues:

First, sometimes after pressing the send button, the value jumps back to its previous value and I have to reload the page for it to show the correct new value. This is in the Model section when I select the point.

Second, it works only if the Point type is “Number”. I tried “Number:Speed” but then it does not work, it does not save the new value. Not sure why …

What is the difference between “Setpoint” and “Point”?

4

It’s probably worth revisiting the docs.

In short:

2 Likes
5

Yes, I understand that difference. But when choosing the semantic class for the openHAB item Point, I can choose the semantic class “Point” and “Setpoint”. My question was what is the difference between these two semantic classes.

8

It depends. If this is going to be displayed on the Overview tab cards, you need a list item widget, not a card widget. And a slider or setpoint would probably be more intuitive

That might be limitation of the Model View. I don’t know if it feeds off the event stream to keep everything updated the same as the Overview page or Items pages and the like do.

Error logs?

See the link @hafniumzinc posted and then A Deep Dive into the Semantic Model for more detailed explanations.

Ultimately nothing. They are just tags to tell MainUI what sort of control/sensor the Item represents. “Point” is the tag you’d use when none of the other tags make sense to use. It’s a default of last resort and ultimately provides no information to MainUI on how that Item would be interacted with. In this case, you are setting a threshold above/below which an action should occur. It’s no different from setting a threshold for when to turn on/off your heater or AC. This threshold is usually called a “Setpoint” so that’s the tag I’d use. The Property tag indicates what the Point is representing/controlling. For the heater/AC example, you’d use “Temperature”. In your case, you’d use “Wind”.

The more specific you can be in your tag choices, the more MainUI can infer about the intended use of that Item and choose a reasonable default widget for you.

1 Like
9

Yes, you are right, after playing a bit around with the settings of the slider, it works pretty well and is intuitive:

Screenshot - 11_01_2023 , 19_22_38
Screenshot - 11_01_2023 , 19_22_38990×204 6.14 KB

With the slider that works fine as well, I can use Number:Speed and the value gets saved. I guess there was something wrong/not compatible with my input widget settings that did not work with Number:Speed.

10

I’ve also had the same question as OP. I’ve only dipped my toe into jsscripting, but can already see that having a much more fully featured development language available to you for Scripts and Rules will open the doors to many opportunities.

This is held back a little with the inability to easily store some of these configurations or credentials that might have traditionally stored in a Binding Thing.

Has there been any consideration made to adding a ‘Generic Thing’ Binding? It could work similar to the MQTT Binding that allows a lot of flexibility and customisation for adding Channels. If in addition, you added the ability to enter arbitrary key/value settings to the Thing (with scripting API methods) this would provide a pretty flexible basis for creating script based “Bindings”.

11

There is Magic Binding [3.2.0.0;4.0.0.0) but this whole paragraph seems to show a complete misunderstanding of the entire purpose of Things, Channels and Items in the first place. A Thing is not a place to store configuration info that might be used by a Rule.

A Channel is a way for a Thing to push commands and states to an Item and receive commands back. Items don’t pull information from a Thing. And a Thing is supposed to represent a device. It’s not a database for rules to look to for configuration information.

That’s what Item metadata is for and JS Scripting has OK access to the metadata in 3.4 and excellent access in 4.0.

12

There is one special case where I use a different method for storing rule config parameters. I have several rules that access 3rd party APIs and therefore use API credentials. Given how often rule examples are shared in posts on these forums, and how forgetful I occasionally can be, I make sure that the credential information is not hard coded into the rule so I don’t post copies of my credentials.

Obviously, I am also not going to store the credentials in an item on OH because every OH user on my system could potential have access to that. Fortunately there’s an easy answer here. You can import json objects from files directly into the JSScripting rules with require. For example, if I have a file, ApiCred.json stored in my oh configuration folder with the content:

{
  user: myusername
  pwd: lamepassword
}

Then calling

var authInfo = require('/openhab/conf/ApiCred.json');

gives me access to those configs via authInfo.user and authInfo.pwd.

8 Likes