Problems with Items/Things in Habmin/PaperUI

Setup, Configuration and Use Runtime
1

Hiya,

Still struggling.

I’ve got an items file which I copied from OH1, but I’ve been trying to add some new features, such as battery.

I had PaperUI in simple mode, and for this reason (I guess) it autocreated a bunch of items. I’ve now disabled Simple mode and have been trying to go through and remove them, and/or link the Thing to the correct item.

This isn’t going so well. Can PaperUI/Habmin not edit the .items file? If so, this is a bit confusing.

Concrete example of my confusion: I have a Siren for which I never created a battery item in OH1. Looking at the Thing in Habmin I see an autogenerated item linked to the channel. Deleting this, I see the following in the log:
2016-10-03 14:23:18.377 [INFO ] [thome.io.rest.core.item.ItemResource] - Received HTTP DELETE request at ‘items/zwave_device_fb6ff0c0_node31_battery_level’ for the unknown item ‘zwave_device_fb6ff0c0_node31_battery_level’.

Why unknown?

Anyway, now I want to create a new item, so I click on the + in the blue box next to the channel. This gives me a popup for a new(?) item called “zwave_device_fb6ff0c0_node31_battery_level” (again). I renamed this “Siren Battery” and then clicked on Save. I get a pop up saying “Error saving item Battery Level. HTTP 404 Not Found”. So it looks like it maybe got the name wrong?

If I try this in PaperUI, then I get a “405 Method not allowed error”

Hopefully this isn’t permissions related? I’m currently running OpenHab2 from my Openhab account installed under /Users/XXX/openhab (I’m running macOS Sierra)

2

Another example: I’ve added the Yahoo weather in PaperUI.

I go to the Temperature Channel, click on “Linked items +”, go to “Create new Item” and call it “WeatherTemperature”… and I get a 405. I don’t see anything in logs.

Edit: but this part at least seems to work okay in Habmin (I’ve moved the .items file to Desktop, which possibly helped)

3

PaperUI for sure saves everything to a database, not .items files. If you tried to create Items in Habmin and don’t see an .items file I guess the same is true for it as well.

I don’t know. I, kai, and others recommend users who are coming to OH 2 from OH 1 not use PaperUI to create and manage their Items.

You cannot have a space in an Item name.

4

Okay, thanks.

Out of interest, why is this? It’s a non-trivial amount of work to do all the zwave → channel changes (unless there’s a better way than I found, which seems very likely!)

Doh! Thanks again!

5

PaperUI was written for Eclipse SmartHome by a third party company. Therefore it is not tailored for openHAB 2 in specific. It is nice that it comes for free, but it’s continued development is not ensured and in a lot of ways it breaks the overall paradigm in OH where everything gets saved to easily backed up, configuration controlled, and human readable text files. By putting all the configs in a database it makes all of this opaque and not easily changeable nor is it particularly friendly with other tools (e.g. Habmin, Designer, etc.).

While PaperUI works OK as is, it does put users in a position where they have to maintain configuration in two different places and in two different ways. For example, you can create Items and bind them to Things in PaperUI, which gets saved in a hidden DB somewhere, but if you are using a 1.9 version binding you MUST put that config in a .items file. If you want Groups I think you need to put those in a Text file.

At this point in time, I don’t think it is feasible to do EVERYTHING through one of these GUIs (though Habmin may be pretty close) so you will always be stuck needing to learn two skill sets, remember two different places to look and update things, and maintain an overall more complex configuration.

Finally, editing .items files, .rules files, et al is more familiar to OH 1.x users than PaperUI. Because PaperUI hides so much in DBs and simplified GUIs OH 1.x users are often left with “This feature used to work in OH 1, where do I configure it in PaperUI?” This sort of question is probably the #1 most frequently asked on this forum right now.

Therefore I recommend, at least for Items, Rules, Sitemaps, and Persistence sticking purely with text files and forego PaperUI. Things are a bit trickier to handle because those that get automatically discovered never hit your .things files, but manually configured Things do. And since you bring up zwave, which is an auto discovery binding, I’m fine with managing the Things in PaperUI, since they are already there anyway and configuring zwave Channels is not well documented and very complex (every device has its own config if I understand correctly). However, for Items I simply replace the old zwave binding config with the channel ID.

To me that seems pretty trivial. Not sure what you are doing that makes it more complicated.

PaperUI is also pretty convenient to use for installation of bindings. Though, for a lot of the same reasons I already sited, I’d stick with using the services/*.cfg files rather than the configuration widgets in PaperUI.

From where I sit, it appears that PaperUI causes more problems than it solves.

4 Likes
6

I think this should be pretty much plastered all over OH’s website. I’d even go so far to say (at this point) Paper UI should be a UI that the user installs instead of coming self installed. Many people (including myself at first) assume that Paper UI is the “official” OH2 administrative console and run into many problems as you stated.

9 Likes
7

I definitly agree with the statement of @RHINESEL. When I started watching around and read about OH2 I found PaperUI promoted everywhere as the new “intuitive” UI. But looking at the fact that it is not so simply and even implies a fixed own sitemap which one even can’t rename is horrable from my point of view.

3 Likes
8

Only my second post so I’m not really in a position to say but I’ll say anyway.

I tried OH a few months ago and found that in comparison to OH2 it was harder to find an easy to follow setup guide for a Pi install.

However configuration does seem a bit hit and miss now I have OH2 running. None of the folder structure for the config files appear on my system so everything I am playing with at the moment is via paperUI.

I will say I’m a complete noob so have alot to learn and I wouldn’t be bothered about using the UI and config files to do things but there needs to be a consistency to it, if you can use both but they do not update one another (if you create .cfg files they should be read into the database and vice versa) it will be very confusing.

Also is there a database editor or instructions on viewing the databases other than with paperUI?

9

Thanks rlkoshak - that was very informative, and I see your point. I think I’ll revert my changes - in fact, probably it’s best just to wipe the OH2 install and start again.

Well, if I have ~25 things and each have ~4 channels, that’s 100 channel ids that I have to edit by hand. There’s a decent chance I’ll make a mistake, whereas doing it through the GUI (especially if you turn off Simple mode, which IMO is a massive annoyance) then it’s pretty quick.

I think I now agree, and in which case I definitely agree with smhaller and Lloyd that it would be helpful if this was explained in the documentation (I’m not complaining by the way - this is open source software in beta, so I really don’t mind having to do a bit more work).

Okay. Time to start again! :confounded:

10

I’m also not complaining, just an observation.

Its great that this works at all to be honest.

11

I will open an Issue on the docs github and see what the powers that be think.

12

Check out the OH1 to OH2 migration tutorial thread:
Migration Tutorial

Basically, in Paper UI you add the item from the Inbox. When you go to Configure>Things you’ll see the auto generated name for the channel (even though it is not automatically linked as you’ve turned off simple mode). Just highlight the generated channel name and paste it into your .items text file. Works really well and significantly (can never eliminate) the chances for error.

13

This is more or less what I did (though I found Karaf a bit easier to use). It took me the best part of an hour though, and I still made mistakes, so either I’m slower and clumsier than most, or it’s a bit painful.

14

Yes, slow and painful. Working on OH is a lot like waiting for your significant other to get ready for a party that started 45 minutes ago.

3 Likes
15

Personally, I recommend using the UI - especially for ZWave. Definition of things will not work well using text files (eg you will not be able to configure the device), so these will need to be managed through the UI anyway if you want to interact with the device. Management of items is subject to error if using the item files, although this is probably acheivable.

Personally I don’t see the drive to use the text files - I think the push to use them for migration from OH1 to OH2 may allow some reuse of OH1 files, although that’s really only true if you use the OH1 bindings as well.

To me the big benefit of text files is that they allow easier backup and editing, and this is a big drawcard. In this respect there is an alternative to the mapdb database which uses a text file format and can be easily edited, but it’s not currently part of OH2 - when this is added it should provide the best of both worlds as you can use the UI, and edit a text file if you wish.

Just my personal thoughts on a popular topic ;).

16

Don’t you have to use text files to create site maps to use in other UI’s (Basic, Classic)? Is there a way to reference an item configured in PaperUI in these site maps?

Wondering because I’m just starting moving things to text files.

17

Yes - at the moment this is correct - there is no way to edit sitemaps through the UI (in HABmin-1 for OH1, this was possible, but I never ported this editor to OH2 as it is planned that there will be a new sitemap REST API and therefore this shouldn’t be needed (one day!).

18

This is the json addon you wrote that I saw you discussing in another thread? This sounds perfect!

19

Yes - it’s this PR -:

20

For me the big push is that the UIs at this point in time can’t do it all. Your Habmin comes the closest but, as far as I can tell and I could be wrong (I seem to usually be wrong on this stuff these days) I can’t create a sitemap that will work with Classic/Basic UI. PaperUI is even more limited. As a result we are stuck in a bifurcated paradigm where some stuff we have to do in the UI and other stuff we have to do in text files. then we are left with a precedence problem. For example, if I configure the Nest binding in PaperUI and I have a nest.cfg, which takes precedence?

Over all it is confusing and based on the numerous threads on this forum, the current UI/text files approach violates user expectations for how it should work and it is causing lots of people lots of problems. As it stands right now, the most consistent approach is through text based. And that is why I recommend it for most things (not zwave of course for the reasons you have already mentioned). Actually I recommend more of a hybrid approach where you manage bindings and Things from the GUIs and everything else from text files. It provides some sense of consistency while allowing full use of autodiscovered Things.

From a personal perspective I like the ability to use change control (i.e. easily see how a file has changed over time) which is difficult to do with a DB based config. I’m also more comfortable editing rules in Designer than through a browser page, but I’m more than willing to give all that up once we have at least one admin UI that does it all. But my main concerns are based on the problems others are having understanding how the UIs and text files interact with each other to create a full config.

And I’ve said it before, I think a lot of people’s problems would be mitigated if the default UI for OH2 were Habmin rather than PaperUI. It is more complex, but it is more complete and has fewer areas where user expectations are violated.

So the tl;dr is: I’m not against the UIs, I’m not even agains the DB configs. But the UIs as they exist right now are causing users more problems than they solve.