OH 3 Tips and Tricks

[rlkoshak (Rich Koshak)]

EDIT: Added more content to the editing the JSONDB section
EDIT: Added the “Don’t Wait, Try it Out” section
EDIT: Added autoupdate and persistence sections

This is going to be a relatively sparse set of notes, tips and tricks, and other advice for setting up openHAB 3 through the UI. It will eventually be turned into a full tutorial and perhaps added as an addendum to the Getting Started Tutorial. But I don’t want to wait before getting some of these out in the open. It’s mostly just notes right now but I hope to flesh them out with screen shots and such as time passes.

NOTE: This is not an opportunity to discuss the merits and deficiencies of UI based verses text based configs. If you prefer text based configs, this tutorial is not for you and you probably don’t need one like this anyway. This tutorial is intended to be a resource for UI users who encounter weirdness or are looking for more efficient ways to do things through the UI.

Also, I do not intend this thread to be a place to discuss opinions about whether or not it should be this way. I’ll happily discuss that in other threads or even better issues on GitHub.

I want this thread to focus on OH 3.0 release as it is and how to work with it through MainUI as it is.

If you’ve any tips and tricks please respond in the comments and I’ll add them to the top post.

Don’t Wait, Try it Out!

This one is a pet peeve of mine which I do my best not to drive my replies. But I encounter so many questions here on the forum that could be so easily answered if the users will just try it out. Don’t be afraid to click on stuff. Don’t be afraid to experiment. You will learn way more that way than by coming to the forum and asking a question you can answer just by trying it out.

Buying in Bulk (Items Part 1)

There are times, particularly when migrating to OH 3 when one wants to create or update a whole bunch Items all at once. That’s what the “add Items from textual config” is for. You can define or copy .items file Items definitions into the form and submit and it will add all those Items and Links and Metadata defined therein.

However, you can’t change the name of an Item so if you want to do that, delete the old Item prior to submitting the new one.

Buying in Bulk (Items Part 2)

I imported roughly half of my Items using the above. However, as I started to really work with and understand the model I discovered that it’s actually less work not to try to import my old Items this way. Instead what I do is:

• discover the Things
• from the Model choose “Create Equipment from Thing” and recreate all my Items that way

I’ve found this is faster and easier even than importing all my Items from .items files. And I end up with all the Items properly situated in the Model right out of the gate.

Buying in Bulk (everything else)

One of the big complaints about the UI is all the repetitious clicking around to produce a lot of similar things. For example, creating a lot of similar MQTT Things, applying Expire to a bunch of Items, creating a bunch of similar rules, etc. But you don’t have to do that.

1. Create an exemplar using the UI
2. Open the API Explorer from the Developer Tools
3. Query for your exemplar and copy the JSON
4. Navigate to the “create” end point and paste in the JSON
5. Edit the JSON for your new instance
6. Click submit to create the new instance
7. Repeat steps 5 and 6 for all the other similar stuff.

I’ve created a dozen similar MQTT Things in about five minutes with this approach.

You may have to search around a bit. For example, the metadata end points are buried in the Item section of the API.

A Script Error Occurred but the Rule doesn’t tell me what Rule!

The error will include the line of code that caused the problem. Navigate to /var/lib/openhab/jsondb and view the automation_rules.json file. Search for your line of code and you should find the JSON entry for that Rule. From there you can get the UID and Label for the rule which will tell you where to find it in the UI.

Fix the problem in the UI.

[WARN ] [e.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: <item name>

This seems to occur mostly when you have a Widget on your Pages that references an Item that doesn’t exist. It might also occur if there is stuff left over after a delete (e.g. an orphaned Link).

Again, navigate to the JSONDB folder. This time run grep <item name> and it will tell you what files that missing Item occurs in. If the line that is returned isn’t enough to tell you what entity references it, open the file and search. Once you identify the entity, navigate in the UI to find it and correct it.

Orphaned Links

If deletion operations are not done in the right order Links might become orphaned. If you have some sort of error related to a Link that should not be there any more (see previous section), go to the REST API docs Links section and you can delete the Link from there. You will need both the Item name and the Thing ID. If you don’t have them, grep for the Item name in org.openhab.core.thing.link.ItemChannelLink.json and the line that is returned will include both.

How did I do that last week?

We all end up spending a bit of time figuring out how to do something in a Scripting language, finally get it working, and then a few months later we need to do it again. Only enough time has passed now that we have no idea how we did it nor do we even remember which Rule we did it in.

When you figure something out like that (e.g. creating a Timer, importing a library, calling another rule, etc.), create a Script and paste the example into that. Name the Script something meaningful (e.g. “calling another rule with arguments example”). Then if you need to remember later, you have this nice library of examples built in that you can browse, copy and paste from.

I find it very useful to have these references right there in the UI.

How do I give an Item it’s first value?

Sometimes we have Items whose main job is to hold a constant, or at least a rarely changing value. There needs to be a way to boot strap that state. The approaches are as follows:

• Open the Developer Sidebar (alt-shift-d) and bring up the -Scratchpad- script (you can also go straight to it from the Scripts section of settings. Type in (JavaScript) events.sendCommand("MyItem", "NewState") or (Rules DSL) MyItem.sendCommand("NewState"). I think you can even use Blockly but once you type in text Blockly is unavailable. This is a good approach if you have restoreOnStartup and don’t expect to need to change the value again.

• Create a System started triggered Rule that updates the Item to it’s first state. Manually run the rule once it’s created to set the Item for the current instance. This is a good approach for when you want to reset the Item’s state on every reload of OH.

• Often an Item’s default widgets will allow it to be modified based on it’s type. Open the Developer Sidebar and search for and pin the Item. Click on the Item and if it’s editable with the default widgets you can modify it there.

• If the default widgets don’t work, you can create your own default widget that allows it to be edited in the Item’s metadata. The stand alone card is what is shown on the Item’s page itself. The list widget is often how it appears in the automatically generated pages widgets. The cell widget is what appears in the Developer Sidebar. The Input card can be customized to accept date times and free text. See OH 3 Examples: How to boot strap the state of an Item. This is a great approach if this is a value you may want to update again from the UI.

Equipment Widgets

Often it makes sense to represent a given piece of Equipment with a single unified widget. For example a garage door opener that shows the current state of the door and triggers the opener when clicked.

If you are using the model (you really should be) create the unified widget as the default in the Equipment Group Item. Then you can select the widget using “add from model” to your pages and it will drop in the unified widget.

If you’ve more than one of the same type of Equipment, save the widget as a custom personal widget (under the developers tools). Be sure to make use of properties. You can select the custom personal widget when setting the metadata on the Group Item.

Customizing the automatically generated pages

You can change how Items appear on the automatically generate pages by setting their custom widgets. Most of the time it’s the list widget that is used in the cards on the automatically generated pages.

Question: What happens when I set a custom list widget for an Equipment? Need to try that.

Developing Rules Workflow

I’ve developed the following workflow as I have been developing (porting really from OH 2.5 Python to JavaScript UI Rules ).

The setup

• open the Developer Sidebar and pin all the relevant Items the the Rule will deal with
• in another tab bring up the -Scratchpad- Script
• in a third tab bring up my Scripts list for reference
• start a tail on openhab.log (some may use Frontail in another tab, I use a terminal and multitail)
• when necessary, instead of pinning the Items I’ll start streaming the events after having set filters so I only see those events I care about; sometimes I’ll bring up the stream on the -Scratchpad- tab

Note that this is not fixed. It depends on the nature of the Items and the rule to be developed. I may not need the Scripts reference. I may want a Page open of a specific Item’s page open.

Development

Using my reference scripts where I need a refresher on how to do something, I’ll start development of the script. It often becomes apparent pretty quickly when something I’m developing should be in a library at which point I’ll switch over to the -Scratchpad- and develop the library as a function there. Once it works, I’ll move it to a file under conf/automation/lib/javascript/personal/filename.js. See OH 3 Examples: Writing and using JavaScript Libraries in MainUI created Rules.

As I build the logic of the rule I’ll switch over to the -Scratchpad- when I need to experiment or figure something out. When I figure something out, I’ll copy it to a new Script for later reference.

Make liberal use of logging.

Testing

If the rule doesn’t depend on event (JavaScript/Python/Groovy?) or triggeringItem or triggeringItemName (Rules DSL), test the rule by clicking on the play button. If you do need the Item that triggered the rule do one of the following:

• create a test Item to trigger the rule with
• from the developer sidebar, Item page, or -Scratchpad- update or command one of the “real” Items that triggers the rule

Always watch the openhab.log for errors and the output from your own log statements.

After I’m satisfied, I’ll check back with openhab.log over time and verify that it’s still working long term and there isn’t some sort of time based error or the like. It’s also a good idea to restart openHAB and verify the rule works correctly after coming back online.

How do I find everywhere X is used?

A typical config will have dozens of Things and hundreds of Items. And these may be referenced from Widgets, UI created Sitemaps, Rules, Links, Metadata, etc. When you delete something that doesn’t go through everything in OH and remove all references to it. So how does one tell where it’s used? Hopefully you remember most of the places it’s used already, but how do you tell it’s really gone?

As with the above, you can grep through all the JSONDB files for the UID of the entity (e.g. the Item name) and find all the files it appears in. From there you may need to open the file and search to figure out more about which specific entity it’s referenced in (e.g. rule UID/Label). But often just seeing which file it exists in is enough to remind you where it’s used. If it’s an orphaned link, see above.

Item Naming

Frankly, unless you are looking to do something like Design Pattern: Associated Items, the names don’t matter. It’s the label that really matters. The label is what will be used to sort alphabetically, it’s the first thing searched for, and it’s going to be more human rememberable anyway. So do focus on coming up with good labels for all your Items and do make sure all your labels are unique and descriptive. But do not worry much about the names beyond that. You hardly ever have to deal with the Item names themselves when working through the UI.

Deleting In Bulk

On any page that shows a list there is a Select option in the upper right. Click on that and then start searching for the ones you want to delete. Check them as you find them. When done the “Remove” option will be at the bottom. It will show you how many of whatever it is you have selected.

However, be careful with deleting Things. You may want to do those individually and to first open the Thing and opening the Channels tab and selecting “unlink all Items” or “unlink and delete all Items” first before deleting the Thing. This gives you the opportunity to delete the Items and Link. Theoretically the Links should be removed when deleting the Things but I’ve found that doesn’t always happen.

Editing the JSONDB, a last resort

You may encounter a situation where the only way to get around it is to edit the JSONDB manually. This should be only considered as a last resort. I just recently had to do this myself.

Scenario

I have a few “dumb” humidifiers around the house, mostly there to protect my wife’s musical instruments (woodwinds don’t like 15% humidity). So I make them “smart” with a smart plug. Each humidifier is represented by three Items: switch, setpoint, and sensor reading. The Items are named following Design Pattern: Associated Items. But it was not until I had everything set up that I discovered I had a typo in the names for the sensor and the setpoint which made my rule not work.

At this point these Items all have a rule, metadata, links, and UI widgets built around them with the misspellings. Correcting the problem through the UI would not only be a lot of work, but error prone work. My first thought would be to use the REST API (see above) to make these changes but the REST API endpoints for the Metadata makes duplicating the Item with all it’s metadata challenging. Therefore I opted to edit the JSONDB by hand to rename the Item in place.

Preparation

• stop openHAB
• open a terminal where you can search through the JSONDB files
• I found it works best if you can open the JSONDB files in a tabbed editor where the find and replace dialog can be reused for multiple files. This helps to avoid introducing typos from one file to the next. I used VSCode.

Steps

0. Backup
1. Search for one of the misnamed Items in the org.openhab.core.items.Item.json file. Adjust your search string to include the full Item name.
2. On the terminal search through the other .json files for that Item name to see everywhere it’s referenced. Open all of those files. In my case I had to open the Metadata, automation, Links, and ui_components_widgets files.
3. Open every file where the Item is referenced in a separate tab in the editor.
4. Now open the editor’s find and replace and put in the Items full current name in the find and what you want to change it to in the replace field. Execute the replace in the Items file. You should do the replace one at a time instead of “Replace all” to make sure you are not accidentally changing Item names that may just happen to include your find string.
5. Move to one of the other tabs and repeate the find and replace. In VSCode I just change tab and click the replace icon again and it will start doing the find and replace with the stuff I already entered on the new tab. This helps avoid introducing typos.
6. When done, start openHAB and watch the logs and test everywhere the Item was used to verify it all works as expected.

It’s really easy to mess this up so it should only be used as a last resort. Also, don’t try to do too much at once without testing and save incremental backups after each test so when (not if) you make a mistake you won’t have to start all over again.

Also note that you will lose all your historic data that had been saved on the renamed Items. For rrd4j it might be possible to rename the file in $OH_USERDATA/persistence/rrdj4 to recover the persisted data for rrd4j at least. I didn’t try it though as it didn’t really matter for these Items.

Autoupdate

This is a tip from @Spaceman_Spiff .

First a couple of facts. First, when a command is sent to an Item, that command often will go out to a device through a binding. This round trip can take some time. Usually the device will change it’s state and report that changed state back to openHAB where the Item is updated. Second, often a command bears little resemblance to the Item’s state. For example, you can send a command INCREASE to a Dimmer, but the Dimmer carries a PercentType as it’s state so the INCREASE will presumably add something to the current Dimmer’s state.

Given the above openHAB has a feature called autoupdate that helps deal with both of these facts. Autoupdate - a primer is a great resource to learn more about Autoupdate. The tl;dr is that when autoupdate is enabled, it will attempt to guess what state an Item will become in response to a command.

Why would someone want to guess like that? Some technologies never report back that it changed state in response to the command. Others might take an extended amount of time before reporting back. The Item might not be linked to a Thing so there is no device to change state. In all of these cases, leaving autoupdate in the default configuration or set to true will be desired or else the UI and the Item state may never change state in response to the command, or do so too late to be useful (e.g. the UI will look like you never sent the command and users might reclick on the control).

But, if you have a technology and device that does report back changes in state in a timely manner, autoupdate should be set to false. This will keep the Item from changing state in response to a command until the device/binding reports that the device has reacted to the command.

You can set the autoupdate metadata by navigating to the Item and adding it as metadata.

But a question arises, how does one tell if the technology supports timely reporting when the device changes state? If you can’t tell based on the docs for the binding and doing a little bit of reading about the technology, perform an experiment! Turn off autoupdate, command the Item and watch the event stream or events.log to see when/if the Item changes in response to the command. If it does leave autoupdate off. If it doesn’t, turn autoupdate back on.

Persistence

Persistence can be used for a number of things and the best Persistence configuration is different depending on how you want to use it.

restoreOnStartup

This is a profile that will set an Item’s state at openHAB startup to the most recent state saved in the database. This can be great to preserve the state of parameter Items (e.g. setpoints). By default, openHAB ships with rrd4j with a profile to restoreOnStartup for all supported Items.

One problem with a blind restoreOnStartup like that is that it can hide potential problems. For example, if you’ve a temperature sensor with restoreOnStartup and your house loses power and the temp sensor doesn’t come back online when power is restored. openHAB will restore the last temp reading and that restore will not trigger the Expire config. So opemnHAB will chug along with an old and stale reading without knowing there is a problem. Without restoreOnStartup that Item will remain NULL which can be tested for to report problems.

Therefore, instead of blindly using restoreOnStartup on all Items, pick and choose which Items get restored deliberately.

Another problem is rrd54j doesn’t support all Item types. So if you need to restoreOnStartup String Items and other notn-supported Item types, you should use MapDB for restoreOnStartup instead.

Lastupdate

Sometimes in a rule it is important to find out when an Item was last updated. Ideally the lastUpdate should be the time when the Item became it’s current state, or when it was most recently updated to it’s current state. But, calling the lastUpdate method will return the timestamp of the most recently saved value in the database. I emphasized that last bit because the lastUpdate may or may not return the timestamp of the actual last update because it depends on when values are configured to be saved to the database. For example, with rrd4j it saves every minute. This is required by the database. But that means you will never get a value returned from lastUpdate older than a minute. If you have the Item configured to be saved on every change instead of every update, you will get the time when the Item changed to it’s current state, even if it has been updated to the same state since then.

So when calling the Persistence methods in a rule, you must have a basic understanding of under what circumstances the Item is saved.

rrd4j is generally a bad choice in cases where you need to call lastUpdate. MapDB using an everyUpdate strategy would be more appropriate. Or if you want to use lastUpdate as lastChange, use an everyChange strategy.

changedSince

This method will search through the entries starting from the time passed in to present and return true if an Item state was saved in a different state from the current state at any point during that time period. Knowing that MapDB only saves one value per Item should tell you that changedSince will always return true when using MapDB. There are no other entries in the database to show that the Item was different at some point in the past.

HistoricState

Sometimes you may want to get the state of an Item at a given point in time and knowing when it changed to that state is important. In that case you may not want to use a periodic strategy (e.g. everyMinute) because the timestamp will be the most recent record before the time you passed in, not the timestamp for when the Item changed to that given state.

And again, MapDB is not going to be useful for this use case.

Charting

Unlike with lastupdate and historic state, with charting you may want to save a value periodically. This is because depending on the graphing package and the time period chosen, if an Item doesn’t have a state saved during the time period shown, or the first value saved is near the end of the time period shown, that Item may not appear on the chart at all or it may sppear half way through the chart time from nowhere. To have a nice line graphed no matter the time period and how often the Item changes state, use a periodic strategy (e.g. everyMinute).

More Control

Sometimes one wants even more control over when a state gets saved to the database. In this case you can omit the Item from the .persist file and create a rule. You can then call the persist method to cause the Item’s current state to be saved to persistence.

Multiple Persistence Engines

Depending on what you want to achieve, you may need to run more than one persistence add-on with a different strategy for each. For example, one might use rrd4j with a custom .persist file (so it doesn’t do restoreOnStartup which it does by default) for charting and MapDB for lastUpdate and restoreOnStartup.

See Design Pattern: Group Based Persistence for one way to make setting this up easier.

[rlkoshak (Rich Koshak)]

Continuation:

Default Widgets

This was already covered a little bit above under Equipment Widgets but I want to cover it in a more generic way.

All of us will have many Items that are essentially the same thing only in a different location. For example, lights, doors, windows, temp/humidity sensors, etc. As you should already know, if these are all semantically tagged they will be automatically added to the appropriate cards in the overview pages. And if you want to change how those Items appear, you can override the default by setting a “default list widget” on the Item. But you’ll be doing a lot of copy/paste/edit of default list widgets to make all your similar Items look and behave the same.

The way to avoid that is to create a custom widget and reuse it as the default widget for all your similar Items. And if you later decide you want to change how it looks or works, you can modify the custom widget and it will automatically update everywhere it’s used.

See [Wiki] Building Pages in OH 3 - Custom User Defined Widgets for details. As an example:

Here is my custom list widget for all of my humidity Items:

uid: humidity_list
tags:
  - list
  - humidity
props:
  parameters:
    - description: Widget title
      label: Title
      name: title
      required: false
      type: TEXT
    - context: item
      description: Item to display
      label: Item
      name: item
      required: false
      type: TEXT
  parameterGroups: []
timestamp: Feb 2, 2021, 5:08:00 PM
component: oh-label-item
config:
  icon: f7:drop
  iconColor: '=(Number.parseInt(items[props.item].state) > 45) ? "purple" :(Number.parseInt(items[props.item].state) > 30) ? "blue" : "orange"'
  title: =props.title
  item: =props.item
  action: analyzer
  actionAnalyzerCoordSystem: time
  actionAnalyzerItems: =[props.item]

To apply it:

Note that often the preview of the widget doesn’t refresh properly so after you save come back and you should see the correct rendering. Notice how all I had to enter was the properties I defined in the custom widget. Everything else is defined by the custom widget.

DRY - Don’t Repeat Yourself is always the goal.

When widgets don’t work

When ever something that looks like it should work is not working, open the JavaScript console. Any errors will appear there and seeing them can save you a ton of time. for example, I’m creating a list widget for my garage door openers. I’ve defined props for a sensor_item and a control_item but nothing happened when I click on it. I opened up the JavaScript console (it’ll be under Developer Tools in your browser menus) and immediately see the following error:

That immediately tells me I messed up one of my uses of the control_item, and sure enough I forgot the leading =.

What are your tips and tricks?

[konfetti (Stefan F.)]

Take the time before you start and think about the modelling, it will help a lot at the end. I don’t do and have done the job several times now
I finally derive a model in textual form (per location / room) and insert it with “Add Items from Textual Definition”. I like doing it in this way because you can easily modify (not delete, but modify) a bunch of items at once later (and I do it several times now). Also thinking on a restart from scratch at some time in future will be much easier then (hopefully).

Looking into your tips my first idea is to derive (later) some useful adaptations. Searching for things in the jsondb is a hard job e.g. if you search something in a rule (because the format is not very helpful). So a search in the rules via UI would help

Br,
Stefan

[Christopher_Hemmings]

Im also doing the same as you, where you add the thing, then add the eqipment/point to the model.
This creates items, even if you have already linked another item to the thing.

Therefore you will double up on items.

[Christopher_Hemmings]

One thing im struggling with.
I have hundreds of rules. that work off fake items, such as a keypad item. then on my sitemap i have mappings 0-9 to make it look like a keypad. Then a rule that when buttons are pressed, adds the number to a string to get a passcode.
If this passcode is correct, then when i press ARM or DISARM it will change the status of my alarm.
How can i do the same thing in the new setup?

rule "keypad"
when
	Item AlarmKeypad received command
then


if (alarmTimer.state = ON)
	{
	alarmTimer.sendCommand(OFF)
	Unlocked.postUpdate(OFF)
	}
	
if (receivedCommand == "11")
	{
	code.postUpdate("")
	keypadTimer.sendCommand(OFF)
	AlarmKeypad.postUpdate("")
	KeypadString.postUpdate("")
	}



	




	
if (receivedCommand != "" || receivedCommand != "11")
{	
		code.postUpdate(code.state.toString + AlarmKeypad.state.toString)
		KeypadString.postUpdate(code.state)	
		keypadTimer.sendCommand(ON)
		
		if (code.state == "XXXX")
			{
			Unlocked.postUpdate(ON)
			alarmTimer.sendCommand(ON)	
			}
}





end

[rlkoshak (Rich Koshak)]

@Christopher_Hemmings

This creates items, even if you have already linked another item to the thing.

You can pick and choose which Channels get linked. It should be rare that you have the same Channel linked to more than one Item. So why add the equipment from Thing if the Items already exist and are linked?

@Christopher_Hemmings

How can i do the same thing in the new setup?

Keypad

This widget will allow users to enter a numerical (plus * and #) PIN code and send a command with the result to a predefined item when pressing the Send button. [image] How to Use You can show it inline in a page if you want but the preferred way to integrate it is with a “Open Popup” action in one of the widgets that support them, like the Label Card in a layout page, or a floor plan marker: [image] [image] In YAML definition this translates to: component: oh-label-card config: label: …

[Christopher_Hemmings]

@rlkoshak

You can pick and choose which Channels get linked. It should be rare that you have the same Channel linked to more than one Item. So why add the equipment from Thing if the Items already exist and are linked?

because lets say i do it in this order

1. create item from old 2.5 version using text files

2. install yamaha binding

3. link yamaha_volume item to yamaha binding volume channel.

4. add the yamaha volume channel to model.

This then creates another item.

[ysc (Yannick Schaus)]

@rlkoshak

Also, I do not intend this thread to be a place to discuss opinions

Ah, another “let’s run a tight ship here” thread. We both know they don’t work
Sacrasm aside, good initiative!

[rlkoshak (Rich Koshak)]

@Christopher_Hemmings

This then creates another item.

Well yes, it is called “Create Equipment from Thing”. That’s why I wrote that whole "Buying in Bulk (Items Part 2). You would never want to do it the way you describe.

If you imported them from your old .items files or some other text file, it is your responsibility to set the tags and Group membership on those Items so they fit into the model. That’s acutally a quite tedious job which is why I don’t do that any more. I only ever create the Items using “Create Equipment from Thing”. I never import from my old .items files any more.

So the steps are either:

1. create item from old 2.5 version using text files
2. install yamaha binding
3. link yahama_volume item to yahama binding volume channel
4. Create a Group Item called Yahama with the proper Equipment Tag.
5. Add the Yahama Group to the proper Location Group
6. Add the yahama_volume Item to the Yahama Group
7. Set the Point and Property tags on the yahama_volume Item
8. repeat 6-7 for all the remaining yahama Items.

Or the steps are:

1. Install the Yahama Item
2. click on the location in the Model where the Yahama equipment belongs
3. click on “Create Equipment from Thing”
4. Set the Equipment name and category and semsantic tag
5. Select the Channels to create Items for and set the Item names, categories, and Point tags and Properties

You would never do both.

@ysc

Ah, another “let’s run a tight ship here” thread. We both know they don’t work
Sacrasm aside, good initiative!

Yep, but at least I have an excuse to say “sorry, please post another thread.” But I’ve no expectation it’ll work either.

[Christopher_Hemmings]

Yep, thats what i was getting at.
ive since learnt the same. best to create items when adding them to the model. Instead of before hand. As you have mentioned already.

Ive since gone through and removed about 370 items and am starting again.

Thanks for the tips in this thread. Surely they will come in handy

[Spaceman_Spiff (Sebastian)]

If the item is able to report its state (e.g. a zwave device) always use autoupdate=off.
It makes the rules work much more consistently and leads to way less errors.

[ip-ua (Igor)]

I am trying to update properties of existing items using JSON, like you suggest:

@rlkoshak

• Create an exemplar using the UI
• Open the API Explorer from the Developer Tools
• Query for your exemplar and copy the JSON

This working great with one item, but when I try update many items at once using “PUT /items” from API I am getting error:

`Expected BEGIN_ARRAY but was BEGIN_OBJECT at line 1 column 2

Can some one provide an example of correct JSON formatted text for 2 items?
Thanks!

[rlkoshak (Rich Koshak)]

@Spaceman_Spiff

If the item is able to report its state

Unfortunately it’s not always obvious which bindings and devices support that. I’ll want to add some advice on how to tell. But that’s a good one.

It also also reminds me of some tips about persistence I should include.

Thanks!

@ip-ua

but when I try update many items at once using “

The internet was to do it one Item at a time. So paste the one example, edit it, submit it, edit for the next one, submit, and repeat.

That’s more straight forward and less pronevtob error.

You can submit more than one at a time, but you’ll need to format the entries as a JSON array, as the error indicates. I think an array starts with [ and each entry is separated by a comma, ending with ].

Pay attention to the schema down in the docs. it tells you what the JSON needs to be format wise.

[DanielMalmgren]

@Spaceman_Spiff

If the item is able to report its state (e.g. a zwave device) always use autoupdate=off.

Isn’t that the default? I haven’t set autoupdate at all on any of my Items, I thought that was the same thing as manually setting it to off?

[hafniumzinc (T)]

@DanielMalmgren

Isn’t that the default?

Not quite

Autoupdate - a primer

I’ve found myself having to investigate and/or explain some of the features of autoupdate over time, and thought an in-depth view would be helpful. These notes apply to openHAB version 2.5 Overview Autoupdate is primarily a “speed up” feature for openHAB Items. Mostly we can ignore it, but sometimes you may get an unwanted or unexpected effect, or you may wish to exercise more control. To fully understand autoupdate, we must understand the difference between command and state of Items. If w…

[rossko57]

I would advise understanding what autoupdate is for before blanket disabling it. It’s default enabled for a reason.
The explanation in Rich’s original post is a good starting point.

[robmac (R Macdonald)]

When working with a few items from the semantic model, use the Pinned Objects in the developer sidebar so it is easy to access them without navigating the tree.

[Fritz (Fritz P)]

Thanks to Rich for these tips and JustinG for this post Solved: Mass change for multiple items possible?

Here’s how I copy things (including channels) and copy items (including metadata) via OH3 UI. This works well for e.g. the KNX binding, which does not support discovery, yet. It is not as fast as copying and modifying text files, but works well for me.

Copy things

• Create all things via UI (only basic settings, no channels)
• Create all channels for one specific type (e.g. HVAC, lighting, blinds) of thing
• Go to Code of thing
• Copy channel configuration to editor of your choice
  
  
• Do a search and replace in the channel configuration
• Paste channel configuration to the other things

Copy items (including metadata)

Copy items

• Go to API Explorer Administration → Developer Tools
• Do a GET items with itemname
• If you want to copy multiple items, it is easier to create a group (item) first. Then enter group name as itemname
• Supply the relevant metadata when GETTING, if you want to copy it. (e.g. stateDescripton, widget, listWidget, widgetOrder, …)
  
  
• Copy JSON response to editor of your choice
• Do a search and replace in the editor (keep editor open for copying metadata)
• Do a PUT items with the JSON (metadata will not be copied in this step)
• Check the response, if all items have been created successfully

Copy metadata of items

• Do a PUT items/itemname/metadata/namespace
• Copy itemname
• Copy namespace
• Copy metadata
  
  
• Verify response code to be 201

Link channels

• Copy part of the item name to the clipboard (to be faster)
• Link channel to items and do a paste of the item name
  
  

Best regards
Fritz

[rmhoutz (Ryan Houtz)]

@Spaceman_Spiff

autoupdate=off

Can you provide an example of how you add the autoupdate=off to a item?
I know how it’s done using the UI but the items in the UI won’t allow you to view the code.

[rlkoshak (Rich Koshak)]

It’s Item Metadata.

Navigate to the Item. Click on “ADD METADATA” and choose “Auto-update” from the list of well-known namespaces.