Feedback from a new openHAB(ian) user

It is most definitely a goal.

But like I said above, there are over 300! (a three with 641 zeros after it) possible combinations of bindings which can run on five very different platforms (Windows, Mac, Linux, QNAP, and Synology).

It is a great goal and the maintainers are working very diligently towards that goal, but, I simply do not see it as being remotely feasible to ever achieve and maintain those aspects of OH that make it powerful and attractive:

  • an unprecedented collection of supported technologies and APIs that are of varying degrees of maturity and complexity
  • seamlessly bridges between ALL of these through a standardized abstraction layer (i.e. Items)
  • runs on five very different operating systems

The only way to achieve a truly intuitive UI based system like OH is to massively reduce what OH can do. For example, drop the supported APIs and technologies to something more manageable, say maybe the top 20, though we should exclude lower level bindings like Exec, serial, and TCP/UDP. Then we would need to support only one operating system.

Once we’ve done that then we can probably achieve this. However, once we’ve done this we’ve eliminated just about everything that distinguishes OH from commercial home automation hubs like Wink and Vera.

1 Like

@rlkoshak, yes, I fully agree that there is a balance between being completely open and versatile, which is in my opinion one of the main differentiators of OH, and remaining user friendly, intuitive, and properly documented.

If you ask my which direction I would choose, I would prefer openness and compromise a bit on the user friendliness and docs.

However, let me try to pull the conversation back into my initial post if I may: I would like to suggest that it should be a priority to avoid that users of any technical level should have to dive into config files and UUID and secret files in order to allow access from the web or a mobile device. And the same for access from voice assistants like Siri/Homekit, or Alexa or Google Assistant.

I feel pretty confident that the number of users who don’t want to set up web and mobile access in 2018 are in the low percentage digits. I do accept that this may not yet be entirely true for voice assistants, even though we’re in the end all tech enthusiasts at different levels of technicality, and there is hence probably a good percentage of users out there who use or want to use voice assistants.

I take the point, of course, that progress has been made since 2.0 to 2.2. And I’m sure this progress will continue in 2.3 and beyond. I’m hugely thankful for what the community and contributors have already managed to offer the HA enthousiast space.

I checked the 2.3 change list, and bar me missing it, I did not see a lot of UI level improvements, like for example elevating access from config files to the UI level.

Could I make the suggestion to launch a poll here or on another polling platform asking for the key features the current and prospective user community would be most in need of?

As always,
Your thoughts are welcome.

Completely removing features and platforms would be a pitty. What could work is to have an inner set of platforms and integrations that are known to work well. So people could have a simple life by using this inner set or be more versatile and have more possible issues.


Indeed and that is what is being furiously being worked on. Some of them are easy enough to do and some require a good deal of planning and changes to the core. The whole reason there was a break between OH 1.x and 2.x is to enable just this. In OH 1.x all we had were text-based configs. What has been implemented:

  • automatic discovery and configuration of devices
  • creation of Items through the UI
  • HABPanel which can be built entirely within the browser
  • binding management and configuration through the browser
  • Experimental Rules Engine which, although experimental, let’s one create Rules in the browser and it is approaching parity of the Rules DSL
  • Home Builder which lets one generate some of those files that do not yet have UI support in PaperUI or elsewhere

There is still a ton to do and it is all being worked on including:

  • complet the Experimental Rules Engine
  • add support for tags to PaperUI
  • sitemap creation through the UI
  • migration of very important bindings to 2.x so they can be configured in the UIs (MQTT, HTTP etc)

All of these are actively being worked and there are many more.

That being said, there was much complaining and fears expressed about the loss of config files. A number of users are refusing to upgrade BECAUSE of the UI changes in OH 2. For the power users out there, the config files will ALWAYS be preferable to a UI based system and OH will likely always continue to support them.

So here is the problem with doing something like a poll like this. OH is an open source project. We can’t make anyone work on anything they don’t want to work on. We can run as many polls as we want and open as many issues as you want but unless you find one or more developers who are able and willing to actually code it the poll is meaningless.

Honestly, I don’t really see a poll telling us anything that we don’t already know. Nothing mentioned thus far is a revelation that hasn’t been discussed before and that the developers don’t know.

So I think it would be better to spend efforts recruting developers to work on the things you want worked on.

That is only going to show those things that are done and merged in. There has been a ton of infrastructure work that is required to support the UI changes that need to be made. The Experimental Rules Engine continues to progress. There were changes made so one can define preferred units (e.g. F verses C temperatures) and OH will handle the conversion, there has been a ton of work going on with tags, which are much bigger than just telling Google Assitant which Items are switchable. And these are just the ones that I’ve seen come up here on the forum. I’ve not watched the issues and PRs that closely.

Most of the issues people encouter come from specific bindings or the combinations of bindings they want to use. In my experience almost no two systems will have the same set of bindings. So we would be right back to where we are now. Especially for those new users who want to use a low level binding like TCP or Exec to talk to their alarm system or stereo receiver. So coming up with the core set will be very difficult and even if we were to do so it doesn’t really solve the problem because each user has their set of technologies they want to use, whether or not they are “known to work well”.


I am quite sure, whenever you are a bit more familiar with openHAB, you will absolutely love the opportunity to use config files instead of clicking your stuff together in any UI.

I have about 150 devices and stopped using things which are unable to be configured via files. Don’t have any Z-Wave, so i do not know these.

UIs are great for a handful of devices and for starters, but handling of many devices comfortably require special UIs for mass changes.

I started with PaperUI, but with a large number of devices you need to set the location, a reorganization takes some time. This is a breeze with search and replace in a text editor like VS Code. (You can rename an item in all your files with a single operation.)

Most but not all OH 2.x binding support configuration of Things through .things files. Zwave is one of the few exceptions to this, and even there if you are using the Development branch of the Zwave binding (see OH2 Z-Wave refactoring and testing... and SECURITY).

You do not have to forego OH 2.x bindings and Things entirely even if you don’t want to use automatic discovery.

Also, you don’t have to use one of the UIs to perform automatic discovery and manage the inbox. You can do all of those actions through the REST API or the Karaf console as well.

Not really. The Location only changes where they show up in the Control tab of PaperUI. I do not believe it currently has any other purpose yet. You can leave out the location and just leave the Thing as the default that it comes up as.

VSCode has full support for creating and editing .things files.

Exactly. Just to separate the control page. If you had ever tried to open the control page with that many devices without setting the location, you would agree. You need to, to make any use of the control page! Which is, at least for me, a first check if new devices are working properly.

Sure it has. I do not understand your point. My point is, a reorganization of items is easy with a text editor, just using search and replace. Changing Names and/or Descriptions/locations may be ok using a GUI with a handful of devices, but the OP wants to handle 200. Handling that number of devices either needs a detailed documentation (:rofl:) or a strict naming structure. And sometimes this structure needs to be changed.

The whole point of my post, was to inform the user, some of the things he dislikes currently with openHAB will turn into big positives later on. Positives, he will not find in any streamlined commercial product.

You can do the exact same thing with Things as you can with Items. You’re original post implied you abandoned all Things because you don’t like the UI. My point is you don’t have to use the UI. There are multiple ways to do just about anything the UIs do.

So reorganizing Things can also be done in a text editor.

Hi Job,

OK, I see your point.

Could I ask you a favour? Before I start adding all those devices, could you share (probably best in a different post) the logical structure that you have come to use based on your experience? I think it could be useful for users with many devices.

Thank you,

Arnold, I went trough the same way, but over a longer timeframe.
I found that I needed to learn very much about each thing I want to implement.
Without searching the forum, I never would have made it only with the docs.

Things which are confusing are the different UIs. Normaly use Paper UI to configure and add things, items, but for zWAVE need to use Habmin… Why not fix the zWAVE functionality in PaperUI and throw away Habmin? This would already reduce the confusion level one step.

Just my 2ct,


Because this is an open source project. There’s no boss to tell others what to do. There’s no overall task prioritization list.
Because there’s no volunteer available right now because all those capable of doing it are buried in lots of requests ? This is not a commercial product, btw.
Because PaperUI authors are not the same as is the habmin author. You should rather thank @chris instead for creating habmin in the first place rather than ask for dropping his work (the zwave binding too ?).
Because there’s many things left to be done so clearly noone will focus on re-creating functionality that already is available.
Because PaperUI DOES the job, too.
Since you claim it’s broken you certainly have put up a Github issue, haven’t you ? If you haven’t, no developer can know about a “need” to fix.
Because there is no single, all-compelling UI to configure all the stuff people love OH for.
Are you volunteering to write a PaperUI module to configure KNX, ZigBee or any of the proprietary HA systems to match what you can do in ZWave today ?

“Just MY 2ct”

Sorry, I did not want to drop anybodys work here!
And from several discussion threads I learnded that handling of zWAVE items like inclusion/exclusion only works propperly in Habmin, and it does not in PaperUI.
So still I think to focus on ONE management interface would be a good idea to reduce users confusion. Or at least claim one as the primary one, and leave others as optional.

I am very sorry, I am not capable of doing this.

Hi @ACobb,

it’s far simpler than you would think. Most important is, you have a structure, which one is more or less irrelevant. I’ll put mine here to give some overview. If interest exists i could polish it a bit and put it in the tutorials section.

Here are some hints. My primary concern is to keep all the devices manageable, i don’t care about a fancy UI at first, so i use BasicUI (It’s not ugly, just functional, but you can for sure create a nicer one with HABpanel. You’re limited with BasicUI). It’s easy to setup and less work than a fine tuned HABpanel (my opinion, no fact).

  • Each room has a unique 2 letter abbrevation (one letter wasn’t enough, two is enough for me. Maybe you need thre). LR=Living Room, C1=Corridor 1st floor, B1=Bathroom 1st floor, BG=Bathrom Ground floor

  • Each device type has a 2 letter abbrevation (i need sometimes extend to three letters, the last is a number/or point of compass). I wish i had structured it better. :frowning: CL=Ceiling light, WT=Wall thermostat, MD=Motion detector, WL= Wall light)

  • combined you have the device name (all uppercase to distinguish small ‘l’ and a large ‘I’): LRCL= Living Room ceiling light, KICL=Kitchen ceiling light, C1MD = Corridor 1st floor mtion detector

  • the item names are constructed by device name + underscore + channel name: C1MD_MOTION, KICL_colortemperature

  • I strongly suggest to use at least item files with a large number of devices. Thing files are not that important, because the benefit later on is not that much. (For my thing files i use the exact id the autodiscovery uses. Then you don’t need to hide all autodiscovered things, openHAB doesn’t show them.)

  • the default item description is exactly like the item name(* for PaperUI neccessary), device name or just the channel. This differs by the channel type. For example, the battery state description is just the device name, because its sole usage is a simple overview of all states. Other items are not used in overviews, only in a detail view of a device, so i omit the device name, using just the channel. With BasicUI you can change the label per usage, so it is no showstopper. If you use PaperUI you have to use the full description, because that’s what you see in any dropdown list.

So, what’s the benefit of all these guidelines i set for myself?
Whenever i want do setup another device in a room, i just copy a block of this device type and exchange just the room name. (Search & replace for selection, with VS Code.) Same for a motion detector or a radiator thermostat (did this for 15 pieces, now i am done, unless i built another room with a radiator.)
For starters (with a large number of devices) this means, you need to do configure a device type once with a config file, then it is copy, paste, search & replace. Compare that to click, type, click, wait, type, click, select, click …


No - that’s no correct. The ZWave binding uses the standard functions, so can include/exclude through PaperUI. Inclusion works EXACTLY the same as any other binding (using the inbox). For exclusion (for which there is no ESH concept) HABmin simply provides a nicer interface for things like exclusion, which in PaperUI is a configuration slider, and in HABmin is a button.

HABmin just provides a more ZWave centric interface - produced with knowledge of ZWave, where PaperUI has to present things in a more generic way.

The problem is not really with ZWave - it’s more that PaperUI, and ESH/OH implement generic interfaces, and HABmin uses these interfaces in a way that works better for ZWave (basically as mentioned above for exclusion).

That’s also fine, but please remember that HABmin actually came first :wink: .HABmin was written for OH1, and then rewritten for OH2 at the same time as PaperUI. PaperUI is now starting to improve, but it’s not so simple working with ESH as it’s not possible to implement features in a binding specific way. Maybe one day there will be a system to add binding specific features into PaperUI, but for now, it’s not possible.

Ultimately I will likely try to phase out HABmin once PaperUI improves as it takes a LOT of time to maintain such a system and I’m busy as well with ZWave and ZigBee bindings…


I’m also new with openhab and smarthome. my little experiences are as follow (currently I only have zwave devices running) :

  • inclusion of things does work in paperui and habmin without any problems
  • I never added things in text file…
  • 95% of my items are configured in text file, because amazon alexa does find them only in text file
  • I love the REST API like almost always, when I find projects using swagger
  • I still run into problems regarding association groups (after reboot groups are not saved). but this could be because of running zwave development snapshot on oh2.2… will check this on oh2.3
  • habpanel is really a nice tool, to create a nice dashboard in really low time consumption. only problem are different resolution and a rough grid. I dont use any other UI
  • thanks to java my windows 10 installation runs like openhabian installation with one exception: when I setup OH as a service on Win10, it couldnt find any configuration I did (seems that some pathes are not correct in service). I workaround this with an auto start setuped as task scheduler.

Openhab has a very big functionality but you can create small to big smart homes with very low time consumption! the REST API helps for every external applications you are writing. the only thing I would whish is, that in habpanel javascript would be allowed. I know that there are some ways with angular lazyloading but at that moment, I’m not much firm with angular.

1 Like

There have been many posts (you should search and read some, it is good to see what everyone comes up with) and there is a discussion on an open issue (I think it is still open) to add a naming convention recommendation to the docs themselves. At a high level the advice is:

  • Use meaningful names for the data or functionality the Item represents. Items are the functional view of your Home Automation so the names should reflect what that Item represents functionally, not what device it happens to be linked to.

  • There is debate on this but some people, myself included, use some sort of convention to distinguish between different types of Items. For example, I start my actuators with “a” (e.g. aGarageDoorOpener1 to open/close the garage door), by values with a “v” (e.g. vGarageDoorOpener1 to represent the open/closed state of the door), and “g” for Groups (e.g. gGarageDoorOpeners). The consensus on the open issue was that Groups should be plural rather than prepending the “g”.

  • If you plan to use Design Pattern: Associated Items (I highly recommend it) be sure to name Items that are closely related in such a way that you can construct the name of one Item given the name of the other Item with some simply String manipulation. (e.g. vGarageDoorOpener1 and vGarageDoorOpener1_Timer (Expire based timer Item) so I can send the on command to the Timer from a rule using sendCommand("_Timer", ON) from a Rule that lets me write generic Rules).

  • Be prepared to change your convention. Over time you will find that what works for you may not be what works for others and as you grow you will come up with alternatives. My recommendation would be not to over define your naming convention. Let it be pretty loose to start and over time you will find whether or not you need to add more structure.

Finally, I’ll recommend structuring your files (you will want to use more than one file) based on function rather than location. For example, I have a lights.items, lights.rules, lights.things set of files where all the lighting stuff goes rather than a kitchen.items, et al.

Inclusion works just fine in PaperUI. Configuration of devices also works in PaperUI. I don’t think PaperUI supports exclusion yet. But most people recommend Habmin for administering zwave because it provides more information, has more capability, and it is written by the same author as the zwave binding itself.

But Markus’ point is key. To a large extent, an opensource project is strictly an additive process. Capabilities like Habmin rarely if ever get removed. And while not all areas of Habmin are at the same maturity or up to date (e.g. the Rules creator in Habmin still generates OH 1.x rules) I don’t think there is much of anything that PaperUI can do that Habmin cannot do. Lots of people prefer Habmin to PaperUI.

And I’ll also point out that this is a good thing. If OH tried to be more exclusive we would never have received HABPanel, VSCode, and any number of bindings.

@job, it occurred to me last night that you could edit the location of autodiscovered Things in the JSONDB directly. I’m not certain of the exact format but it looks like it is a first level entry under the Thing ID.

  "zigbee:coordinator_ember:a38f078d": {
    "class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
    "value": {
      "label": "Zigbee Coordinator",
      "location": "Office"

This is my own experience using OH… Im glad to know about OH… I read the document start from A to Z. It’s really useful and more than enough for me to make it running in Raspberry Pi. Just read and follow the instructions in the document i able to run OH and control My Devices at home using OH. Any complex rules and program i’m using provided Node-Red.

1 Like

A lot of feedback already has been given, but let me just give my two cents.
I struggled a lot too in the beginning and I guess everyone has a preferred way of learning, but what helped me a lot was to just install the demo file (sitemap and items) and look at what it does and what the structure is.
I felt that with creating items etc directly in the config files that I had more grip on things than creating everything in the PaperUI and the demo file really got me going on that, but that’s just me.
I personally found it easier to start from the demo files than to just start creating everything from a blank file, though now I would have no trouble with that anymore.
Definitely in the beginning things may seem overwhelming but if you persist you too are going to have a ‘Eureka’ moment when it suddenly all comes together and starts to make sense.I can genuinely say now that after my earlier struggles I love OpenHab and what I can do with it


Hi @Job,

Thank you so much for the time you spent in writing this up. It makes a lot of sense and I’ll for sure follow your suggested approach.



I do agree with you, that would greatly simplify things.

I also understand @chris when he explains it’s not so obvious to merge everything into one UI. Like you said Chris, maybe one day. And until we get to that point: thank you for Habmin.