Genuine question: auto linking + paperui => sitemap

Setup, Configuration and Use Items & Sitemaps
1

Hi,
this is just genuine question how that supposed to be working really.
As I do have fully working OH2.5 on other machine where I do have everything defined and controled in files (so I think am not full beginner :slight_smile: ), I’ve decided to give it a try on test machine and configure everything possible in GUI as somebody pointed out as preffered way.

I know it is work in progress and there are some great ideas about paperui out there, but how paperui things definition supposed to be reflected in sitemap or habpanel?

Autodiscovery, or adding manually works fine, auto linking works fine as well, but from there? In paperui (when auto linking enabled) there is no way how to show linked items therefore seems to be no way how to know the name which needed to be reflected in the sitemap file.
Or is it?

when autolinking is disabled, indeed I can see item name, but then I kind of missing point of not using files directly.

What’s your general approach to this? files and paperui or files only or?
I do think that files only works for me better, but as I want to be as modern as possible :stuck_out_tongue: I wanted to try gui as well.

2

I believe the GUI way to build a sitemap is Home Builder UI
If you need t install it, it’s under “User Interfaces” in Addons…

3

I know it, but it feels like it’s doing just a demo sitemap, as I can’t select already linked items in there only default items without any connection to anything.
So it’s generating items file, but from paperui there are already linked channels to items when autolink is enabled.

1 Like
4

Paperui is just for Admin. BasicUI is for using the system. The PaperUI will be deprecated soon because it is undocumented & unmaintainable.
It will likely be replaced in OH 3.

5

basicui is not usable without sitemap/items/things … so circle is closing again

is conclusion to not to use paperui at all as we don’t know what will be in OH3 and use files fully till then?

6

No, paper ui is for administering the system. It is mostly useful for installing binding and add-ons and discovering device. Personally I use it for this and create items in files.
Paper UI was created as an all encompassing user interface but was never finished and abandoned by the original author (a volunteer). None of the current developers like using the programming language it is written in and have starting creating new interfaces for OH3 using other tools and paper ui will eventually be depreciated

7

ok, then I’m using it in my production instalation exactly the same.
Basically I’m asking because in other discussion somebody said files are going to be depreciated soon, so I was wondering what is really an option here :wink:

8

The REST API will be staying. That is what PaperUI, BasicUI & HABmin use anyway.
Scripts calling the REST API would be one way of having a text file backup of the configuration.
The REST API can also be accessed via GUI using the builtin Documentation, if it is installed.

9

Someone saying files are going to be depreciated was not outright wrong but advanced users will probably be able to use files to configure OH for the foreseeable future

10

None of this going to happen soon, OH3 is a way off.

Meantime, the user facing UIs are controlled by sitemaps, which are used to display Items only, never things or channels which aren’t of any interest to end users. To get the best from a UI, you’ll need to edit sitemap. Or use Habpanel, which has its own configuration.

11

I personally only use PaperUI for items/things if not forced by some legacy or non implemented things (like WOL for example).

I don’t use the simple mode with autolinking because I want to have full control on what’s get created.

So my approach is: PaperUI for everything I can do with it and then a text file for sitemap transformations mappings persistence and rules.

If you expand the channel in the PaperUI thing definition you can see the linked item.

12

only in non auto mode, when auto links are enabled you cant

using gui and files together is for me bit strange so I went to only files on my production

1 Like
13

Things are not reflected in the sitemap or HABPanel. Only Items are. And in both cases, it’s no different to display an Item defined in a .items file or one created through PaperUI.

Ah, you have Simple mode turned on. Go now and turn it off. Remove all the Items it created. And manually define all your Items. Simple mode is worse than useless.

The Item name is the Channel ID with the : replaced with _.

For now, I think the majority recommendation is to use PaperUI for Things and .items files for Items. There are features with Items that PaperUI doesn’t yet support.

And I really really don’t like Simple mode. Items are where you model your home automation. This is where you map from some random meaningless string (the Channel ID) to something meaningful (e.g. Livingroom_Lamp).

Files for all Items. PaperUI for all Things. Be consistent. As soon as the replacement for PaperUI comes along, I will migrate my Items out of the .items files as well. As the alternatives to the text configs become feature complete I will move out of my text configs.

Don’t pay any mind to the Items created during Simple mode. Get rid of them and then you can link your Channels to the Items created by Home Builder.

You can keep using PaperUI. Just be aware of it’s limitations and don’t expect too much from it (lots of users want to make PaperUI their only UI.

When that happens, a feature complete replacement for PaperUI will exist. And even then, I believe the consensus is that text based configs will not go away completely, but they will likely change format and they will likely not be loaded automatically upon a change like happens now.

The big thing is if you use .things files:

  • you cannot take advantage of auto-discovery
  • often the proper format for the .things files are not well documented
  • when you manually define a Thing through PaperUI, you are guaranteed to get a syntactically correct thing definition, when using .things files it’s easy to define a Thing incorrectly and the error messages, when there are error messages, are often not helpful
  • it takes significantly longer (mostly noticeable on RPis) to load and parse .things files

If PaperUI were feature complete for Items (no way to define tags or metadata right now) I’d recommend using it for Items as well. For now I’d recommend waiting for the replacement for PaperUI.

I recommend never, under any circumstances, recommend using Simple Mode.

14

Unfortunately, the official OH Tutorial recommends turning it on :frowning:

15

this is interesting, why is that? they should be very same or?

rest of the reasons are maybe for beginners something to consider, I do like files because they are easily visible with all infos needed, which paperui is not kind of

16

I think it re-imports the files into the JSONDB database. Things defined through the UIs or REST API reside in the database.

17

and items,sitemap,rules etc are not?

btw when simple mode is evil, why is even there and why it is recommended in the guide? :smiley:

1 Like
18

Actually people are saying rules DSL is evil. I know some are moving to Jython, for example.

19

to add more schizophrenism into the equation … damn son

20

No no, keep it simple
Be consistent like Rich advises
Use paper ui to create things then use item text files to create your items
Sometimes things aren’t correct or use dated info in the docs because the docs are written and maintained by… volunteers