How to create templates (of whatever is called) for things and components pages?

Setup, Configuration and Use Beginners
1

I have several devices that work in the same way (EQ3 radiator valves).

I have several of them that are equal.

Creating the things is time consuming, as I need to create channels, give them a name, stablishn properties, create JSONPATH expressions to extract data…
All is the same but for the name of the channels and thing.

So It would be great to have something like a template, which you can reuse serveral times but for the name of the thing (channel names would be derived from thing name).

But I have not found how to do that.

The same for components of pages: each data from a valve is presented in rows with cells (setpoint temperature, opening, etc).
It would be great to create one row with a generic name and associated items name and then make copies of it changing the thing names.

I have seen there are programmatic tools for creating components from scratch, with a designed UI different to what system provides.
But it seems quite and advance developer task and oversized for just packaging a group of off the self UI elements and create copies of it changing the underlying things.

Is there a simple way to automate this kind of tasks?

2

There is no template ability. However there is copy/paste/edit. In .things files that’s obvious. In the UI click on the Code tab for the Thing, copy that YAML definition, create a new Thing and paste that YAML to the Code tab, editing the name as necessary. Alternatively you can query for the Thing’s definition in the REST API Docs, copy and edit that JSON and then submit it back through the REST API Docs to create a new one.

Create a Custom Widget (under Developer Tools). You can define parameters where you can define the Item names to be used. Then you can put that custom widget on your layout or make it the default stand alone widget or default list widget for an Item in the Item’s metadata. All you have to do is provide the parameters.

You can install widgets made by someone else from the Marketplace.

3

Similar to Rich’s comment above about Things in the UI, you an also use the code tab in when building pages. Add one instance of the widget you want using the page builder then move over to the code tab and copy/paste that section of the page’s YAML as many times as you need changing the relevant parameters. Just be careful when you are copying and pasting subsections of the YAML to keep the indentation consistent.

4

Thank you both.
I have been playing around with openhab.

I see that is difficult to automate creation of things, items or components, when they are based on the same patron.

At least when you do all from the UI in openHAB3.

In pages you have de code tabs, and thus you can copy and paste text.
In things you have code page too.

But in other places like in the semantic model tab or items, you have no access to the code page.
You have no option to copy and paste either.

And it seems that openHAB3 does not use external text files and it saves it in database.
So you don’t have an easy access to items, or semantic model definitions.

5

OH3 certainly can use external text files. The same format that has worked for previous versions still works and many users continue to use text files with OH3 to great success. The primary downside to using text files is that you cannot then edit those items from the UI; all editing has to be done with those files. The semantic model is just a particular way of grouping and tagging your items so you can even use text files (and all the copy/paste quick creation that allows) and still have the advantages of the semantic model (but, again, you can’t edit the model piece from the UI).

There’s an additional option. When you click on the blue + to add an item in the UI you see there is an option labeled Add Items from Textual Definition. You can create a text file with all the item definitions you want and then instead of running OH from that file you can import all those items into the OH UI item space. The UI will use that file to create UI editable items from all the definitions it finds. You will no longer be able to edit the items from that initial file but now they exist just as if you had point and click added them with the UI.

As for the database, yes, the UI saves all its item definitions in a special json formatted text file that can technically be edited (but ONLY while OH is NOT running). So you could theoretically, create a single item in the UI. STOP OH and open up that json text file and then copy/paste clones of the item making the appropriate changes as required. When you restart OH you would find all the new items created. Let me stress: while feasible, this is not a good idea.

All three of these options come with a significant risk of making a small mistake and winding up with something that OH cannot actually read or worse in the case of the database edit, a large mistake that breaks the system until you find and eliminate it. Unless you are a veteran user very fluent with OH and very careful with your cut and paste each of these will probably result in a longer setup time as you have to chase down errors and tweak things that didn’t get properly modified during the creation step.

6

Thank, but all that options are way too complicated for a beginner.

I cannot use text file without the interface because I don`t know the options, and the interface guides you.

So using just text files and not being able to edit later in UI is not an option for beginners.

In pages at least you can go back and forth from UI and yaml definitions and do copy/paste.

That is not the case for items or semantic model or even rules.

Having a wat to do copy and paste with easy (there is no option to click in a group in semantic model or an item and paste it in other group, pages cannot copy and paste either).

The option of adding items from textual definition is promising, but it would be great to have the same UI to define them and then just add items.

I will test a bit more.
For now I will have to continue to just recreate the same items each time.

7

Not everything that you want to do is going to be easy for a beginner. That’s just how it is. But it’s really not that complicated to use .items files or even the Items files syntax as Justin described. It’s pretty thoroughly documented. Frankly, if copy and paste is that important to the way you work then you should be using text config files in the first place.

Items are the semantic model. They are not separate. Everything you see in the semantic model is implemented as Items. A location is a Group Item with a location tag. An equipment is a Group Item with an equipment tag. An equipment is put into a location by making it a member of that Group.

And indeed Items do not have a YAML representation in the code tab largely for technical limitations that make doing so impossible with the current way that OH is built. If we could provide a code tab for Items we would have.

You are completely incorrect about rules.

image
image1854×986 56.7 KB

image
image1842×1382 285 KB

I assume you are using the semantic model, yes? And these Items you are creating are linked to Things’ Channels, right? So why are you not using “Create Equipment from Thing” or “Create Points from Thing”? That will let you define and configure all the Items for a given Thing in one go. It will do so consistently across all similar Things (unless you choose to configure them differently).

It’s not copy and paste but it is the next best Thing. Just about everything will be done for you, the Item type, Item name, label, default tags, Group membership to place it in the model, etc. All you have to do is modify each one as desired (i.e. the edit step after the copy).

If you are using the UI and the semantic model to manage your Items, it should only be the rare case that you are creating individual Items.

8

OK, thank you again. You are right, of course: rules DO have a code tab.

The model is separate from things in the interface.

In the model you just create the groups and the items (that appear in items tab too).

Create Equipment from thing does part of the job: create the things asociated and a group as equipment.

But then you have other tasks to do, like changing that to indicate if the equipment is an hvac, or a thermostat or whatever. Assign an icon, and the kind of measuremet for each thing. If I understood semantic model well, equipment is just a generic name, there are several kinds of equipment.
The same for “point” and their icons or kind of measure (power, intentsity, etc).

That would be the same for all the radiators, for example. It does not take all that much to do it, but it is error prone: I always forget to assign something, and liked to have all of them with the same attributes.

It is not that important, you always can correct the errors.
But I had beleived that there should be a better and more “automatic” way of doing it, less error prone.

I had beleive you could create a generic object, something like a template, and then apply it.

In the desing of pages is about the same: it would be great to design a single page to interact with a radiator, and then open to operate over the radiator you want to modify, and not having to create a page for each one.

It seems possible to do that but only creating a new component as developer, if I understood it well, which is a much more advance task.

But it works as it does, so lets take it as it is.

I am too new for developing my own component right now. I will learn more with time and will see if I can take the challenge.