Help, I'm ready to give up

I must say I feel for the OP.
His issues are real. He’s not a computer illiterate. And still…

Several answers are in the form of “You need to do this also …” and the classical " you must understand it is a beta"

The big risk is that threads like this doesn’t escalate into problem records or issue to address the underlying causes for his frustration.

If this is not handled it will be the death of OH. Or it will never leave Beta phase.

When I’ve been looking for solutions to issues in my installations , I’ve seen plenty of answers like “Try this” or “Try that” but many of the underlying causes never gets addressed or escalated.

This year only, several people (including me) have reported issues where OH doesn’t start.
No real help on the issue, no roadmap/tips for fault analysis, nothing.
What I’ve seen is “I did a fresh install and now it works”. (And I’ll try the same)

( I still don’t know how to debug if karaf doesn’t start)

In my view , these issues are extremely dangerous for OH.


I understand your frustration and struggles. the community is working furiously to try to address the deficiencies in the documentation but it is slow going and OH itself is growing and changing so quickly that it is hard to keep up. That coupled with the sheer complexity of home automation in general presents a huge barrier that newcomers need to overcome.

I will admit I only scanned the rest of the replies in this thread and reading them more closely as I write this so this posting may be a bit disjoint.

It takes one change. Open services/addons.cfg from your config folder and change package to demo.

Wait a bit and all the bindings and configs that work with the demo will be downloaded and installed.

Now when you open your URL you should see a BasicUI, in addition to PaperUI. when you click on BasicUI you will see the demo sitemap. The file that defines that sitemap is located in sitemaps/demo.sitemap.

The rest of the config that makes that sitemap work are in the other config folders.

SmartThings does have a REST API that can be used to integrate OH with the SmartThings Hub. But there is no SmartThings binding at this time. Also, Zigbee support will be added to OH soon which should allow OH to control those other bulbs.

That is generally true. It is much easier to answer more specific questions than generic questions. Particularly when asking for help with something we generally need to know:

  • versions of OH and addons used
  • detailed description of the problem
  • Items, Rules, and other relevant config files
  • logs
  • what has already been tried to solve the problem.

“Help it doesn’t work” type questions often do not get much of a response because we don’t have enough information to help and it is no fun playing 20 questions trying to extract all the needed information to even begin to help.

However, in @tdsheppard77’s case, this is one of those generic questions that should be answered and I see several attempts at answers here. The fact the answers were not satisfying is a different thing entirely.

Its a pain and I think there is an issue for this. As @Udo_Hartmann described, click on the type on the tree in the left and press <crtl>n and the new dialog file will come up.

If you created a new file outside of Designer, click on the folder and select your config file again and everything will be reloaded.

It is a pain. It shouldn’t be this way.

So here is one problem you will face that is partially caused by the fact that OH is in transition from version 1 to version 2 right now. Version 2 has a new architecture and a whole new way to write add-ons. But Version 2 has backwards compatibility with 1.x version add-ons. This results in two different ways that Things and Items need to be created and managed.

Version 2 stuff can all be created and managed within PaperUI. For those addons that have not yet been rewritten for OH 2 everything must be managed in the old OH 1.x way in the text files. Hue happens to be one such add-on.

For all 1.x verison addons you need to look at the OH 1.x wiki for documentation on how to configure and create Items bound to that Item.

Now that I have that out of the way, you will only see something in the Control Link on PaperUI for Things that come from 2.0 version bindings.

What is the name of this sitemap file and where is it located? When you start openHAB do you see anything in openhab.log? If you installed using apt-get (preferred) that is located in /var/log/openhab2/openhab.log I think.

Are there Items and Groups defined for all of the Items that appear in that Sitemap?

The fact that nothing came up in BasicUI indicates there is an error somewhere.


@tdsheppard77, @Daniel_Hermann1, @erland_lestander, being relatively new to OH, can you post here or PM me privately what you would have like to have seen in a New User Getting Started Tutorial?

The documentation team knows full well such a tutorial is sorely needed and some recommendations about what such a tutorial should contain and how it should be presented would be useful.

Has an Issue been filed on github yet?

As for debugging, the best I can offer is to look at what systemctl status openhab2 returns. The bottom will contain the last few lines that OH printed out before it died.

You can also look in /var/log/syslog (grep for lines that contain “openhab”) and see what it is printing out when it tries to come up.

Have you tried to start it by hand using the script?

I don’t want to kidnap the thread ( to much :slight_smile: )
this thread contains a similar issue to what I’ve seen; ( and it holds my systemctl response)

Yes, tried, sometimes the processes was there forever, sometimes they went away immediately, sometimes they was there for a few minutes. A few times some GUI showed up. But OH never worked.

I’ve seen atleast two threads with the same issue.

syslog says nothing:

pi@homeauto /var/log $ grep openhab syslog*
pi@homeauto /var/log $ grep -i openhab syslog*
pi@homeauto /var/log $

A fault that is so severe that you have to resort to reinstalling is pretty serious. And as we do that, all information needed to do an RCA goes out the window.
Reporting issues here is twofolded for me, yes I want them resolved. But first and foremost I want to make the product better. And I think that the process of moving from cases in this forum to code improvements could be strengthened.

As for your specific question on documentation:
I come from OH1 and I would like to throw the Paper UI as far as I can. Or provide an import utility to move all files into the database.
For instance, being a novice in the tools and trying to edit stuff when the UI doesn’t reflect the updates is a nightmare: Did I do something wrong or is the tool at fault, Should I try again? or something else?

If OH should make an impact on the IoT stage, the installation and admin must be rock solid, coherent and hazzle free. Not a lot of jumping between PaperUI, habmin and good old vi combined with guessing.

The documentation should provide one solid way for doing this.
And if needed, the GUI’s should adapt to that one seemless way of working.

my 2 cents.

FTR, I just started an openHAB2-setup-from-scratch tutorial here: Setting up openHAB2 from scratch
I’m not finished yet, but I hope it can help people to get started!


1 Like

I agree and sadly this is a case where PaperUI (nor is Habmin) fully capable. And it is a double problem as PaperUI can’t work with OH 1.9 bindings at all except to install them.

Massive changes are being made to PaperUI even as I type this and it is getting better and better. But for now, especially for people migrating from OH 1, I can’t recommend it as your primary tool. It is just too soon. Personally I currently only use PaperUI for auto-discovered Things and as a place to quickly find the ID of a Channel. I use text files for everything else.

As PaperUI matures I will likely move more over to it but probably not until all of the bindings I currently use have a 2.0 version.

I pretty much wrote the Migration tutorial with this approach in mind.

Great effort. Lousy timing :smiley:


(As I understand it, cloudbee is being phased out)

I think most would prefer appl maintenance by apt-get or similar.
I also think that all doc should rely on one installation method.
Then doc can be clear on directories and file locations etc.
For a beginner is is a tremendeous difference between
place your rules in /etc/openhab2/rules/ compared to
place your rules in your rules directory.

But in all a greatly appreciated documentation.

1 Like

The single distro started with the snapshot I used in the tutorial, so no problem there :slight_smile:
I agree on your apt approach, but on CentOS that’s not possible (because of yum instead of apt :wink: ). But the setup is almost the same after the first installation

That is a challenge because a significant portion of OH users are running on a non-apt based OS (CentOS, Windows, OSX, even some FreeBSD) or containerized (e.g. Docker, Synology). We would be cutting off a third at least of all users if we restricted the docs to just the apt-get Linux installation in the instructions.

Ideas have been floated to make the docs a little dynamic where you check a box at the top with your install type and the paths and some instructions get tailored to that type of install but I think pretty much everyone would agree we should focus more on the content right now than cool features like that.

I think you are absolutely right… I had a similar experience; endless frustration…almost 40 years in IT… e.g. wrote a complete and secure online store software package (ASP), do PHP, C++, a bit of Python, but this openHAB thing has frustrated the hell out of me… arriving at the same point (multiple times) of simply ditching this bloody thing.
… if it weren’t for the help of a few individuals (rlkoshak, Udo, shui, and others) I would have dumped this thing quick smart.
It has always puzzled me (and still does), that I could do so many things in other languages, but could not in OH.

However, I am still here; have overcome my frustrations; like what OH can do (it is brilliant compared to any other HA system), but not the way it needs to be ‘programmed’. I would say, it is like learning other languages; some pick-up a language in months, while others may study them for years and never reach a satisfactory level of proficiency.

When I started out with H(ome) A(utomation) I was in the process of owner-building a house, exploring the option of automating it, ending up with an architecture, where I am building hardware (based on Arduino), messaging (with MQTT), and control and display with OH. I am doing things in concert, which no other current system can do.

When I look at the money side, despite having wasted time ‘en mass’, I am looking at 2,000 AUD (~`1,300 EUR) for something that could have cost me 10s of thousands.

What I suggest to you is:

  • make sure you have installed OH properly (I started over after discovering that I used a ZIP method rather than apt-get). This solved quite a few issues right there.
  • start with the demo set-up; play with it, make changes and see what falls over --> learning
  • add one thing of yours to the demo, and see what happens
  • once you get an idea, remove things form the demo (sitemap, items, rules,) and see what happens
  • then build your system, one ting at the time – always observe what happens

What also needs to be remembered and understood: this is a free, open source run by a bunch of volunteers, not a commercial off the shelf product… enthusiasts with a shared goal of producing a wonderful system. If you hate it, just walk away…

There are only two options:

  1. overcome your frustrations and learn, and end up with a system that can do basically anything (look at the number of bindings, and what rules can do)
  2. or ditch the bloody thing and never look back.

All yours… best of luck.


I couldn’t find the name yum in my head so I wrote “and similar” instead. :wink:
But honestly I don’t know if both installs have the same directory structure.

For a beginner I think wget, curl, mkdir and unzips etc should be avoided.
Basically anything that hinders clear documentation.
I think that anyone that writes doc for an addon or binding or such is also greatly
helped if we can nail some things on the wall, like folder structures.
( But also other small things like calling the default sitemap default.sitemap for instance )

Here is an example of less than perfect doc that I see in many places:

If you don't have a Tellstick Duo or the number of device events is less
than 1 every 10 minutes you should increate the max_idle: 

All I’m left with is: “In which file???”

Yes I can see that One methods was oversimplified. And I don’t know if yum packages uses the same physical directory structure.

2nd best (or desperate last) option could be to set env variables so doc could refer to $OH_CONF/rules or something like that.
Even if the env variables wasn’t used by the package itself.
Heck, they could probably just be defined in the doc.

I know what you are trying to say, all the more funny I had to google for the quoted sentence. :slight_smile: As you can see, writing a text others can follow is not as easy as it seems.

Let me state a few things:

  • openHAB is best run on a Linux system. Linux systems are great as dedicated servers. That’s why most instructions expect a Linux system. It is possible to run openHAB on Windows! It’s just not as common…

  • When using a Linux system, you need to know the Linux 101. As a Windows user you know how to do things the Windows way - As a Linux user you need to know about wget, mkdir, ls and find. It’s not pleasant but everyone can do it. Please check the very first paragraph after the table of content here:

  • Now, does that mean it’s pointless to look into openHAB if you do not want to bother with Linux? Not necessarily. That’s where things like openHABian come into play.

  • Another big issue seems to be the documentation question. “The documentation is incomplete”, “Following a tutorial didn’t work”, “I read somewhere that I have to set max_idle, now my cat is ill”. Yes of course, the situation on the documentation front is far from perfect. However, most of the time I see questions like these, the answers are repeating and repeating. Often it would just have been a matter of one search. All useful information - including thorough documentation, answered questions, binding usage hints and even hands-on tutorials - can be found en masse under docs and here in the community forum.

  • Lastly I want to say something without wanting to offend anybody. It’s easy and quick to ask questions but hard and time consuming to give answers. Often this is a one-sided deal and I very seldomly see anybody giving anything back. If the one before you would have improved the Tellstick article, we wouldn’t have this problem. If you were to invest a few minutes to help others here in the forum, the next one could already spend time improving the documentation. That’s what I would be doing right now, if I had not seen this discussion…

openHAB is not an iPhone. It’s a complex diverse framework for home automation covering hundreds of technologies and devices. Dig into it, get to love it, grow on it.


@rlkoshak as for documentation for a beginner: Create a step-by-step guide to setting it up and getting it running. Things like the pressing ctrl+n in the designer, don’t assume the user knows where the config file is, Give a real example of a sitemap and then explain it.

Speaking of which, would anyone be willing to share their sitemap with me so I can learn from it?

I’m working on getting one light working the way I want and learning from that. I have basicui controlling it. with the following:

sitemap home label="Main Menu" {
	Frame label="Hall" {
		Switch item=hall_light label="On/Off"
		Slider item=hall_light label="Dim/Brighten" switchSupport

I’m trying to add the dynamic icon support so that if I switch the light off the slider goes to zero and the lightbulb icon turns to and “off” state.
I tried this:

sitemap home label="Main Menu" {
	Frame label="Hall" {
		Switch item=hall_light label="On/Off"
		Slider item=hall_light label="Dim/Brighten" "MAP(" <dimmablelight> {channel="hue:0100:0017882eb162:2:brightness"} switchSupport
1 Like

I think the biggest issue with the current documentation is that it assumes too much. It assumes that a user knows that the default sitemap should be named default.sitemap or that you have to go into the config and tell it to load whatever.sitemap by default. It’s little details like that which cause the most frustration for me. Once, someone answered that for me I was able to get things going. Now i’m just working out proper syntax for controlling things the way I want.

1 Like

But there is a problem right there. The “default sitemap” does not really matter. You can call your sitemap whatever you want and even create multiple. BasicUI or your smartphone client will prompt you to select the one you want to open. Setting the “default” sitemap in Paper UI is a second step but that’s totally up to you.

Ok, I’ve got it working with 2 lights now. I’m trying to get it to show the percentage the light is at but I can’t get it to do that. I’ve read the docs and tried each one but not sure what i’m doing wrong.

Also, sometimes the icon will update based on the percentage and sometimes it doesn’t.

Here’s my files:


Bridge hue:bridge:1 [ipAddress="", userName="xxxx"] {
	0100 bulb1 [lightId="1"]
	0100 bulb2 [lightId="2"]


// Rooms
Group	WH	"Casa de Tomas"	<house>
Group	HL	"Hall"	<corridor>	(WH)
Group	BR	"Bedroom"	<bedroom_blue>	(WH)

Dimmer	bedroom_lamp	"Bedroom Lamp"	<slider>	(BR, WH)	{channel="hue:0100:1:bulb1:brightness"}
Dimmer	hall_light	"Hall Light"	<slider>	(HL, WH)	{channel="hue:0100:1:bulb2:brightness"}


sitemap home label= "Main Menu" { 
	Frame label= "Hall" icon= corridor { 
		Slider item= hall_light label= "Hall Light is [%d %%]" switchSupport 
	Frame label="Bedroom" icon= bedroom_blue { 
		Slider item= bedroom_lamp label="Bedroom Lamp is [%d %% ]" switchSupport 


Concerning the documentation: I found the installation documentation quite good (could be extended or clarified here and there, but generally it was good). But after the installation I was quite left alone. I would add (in the openhab2 configuration documentation) what can be configured where, the relation between OH1 and OH2 configuration, mix-and-match-ability, and what part of the OH1 configuration can be used, should be used and is not outdated.
Also an Example collection would be very helpful, as many of the “old” examples do not work any more, mainly due to minor issues, but for a beginner that can be a deal-breaker.

I am travelling at the moment, but I will write a more comprehensive suggestion as soon as I am back.

1 Like

Please do so.

These are good points. Waiting for the extended list.

I’ve found the BasicUI to update sometimes, when it feels like it. I’ve tried messing around with it to try and see what the problem is and came to the conclusion that it “just doesn’t work properly”.
I’m not overly concerned, as I only use openhab to interface all my stuff with Alexa. Hopefully one day someone will create a nice interface, then I might use it.

Regards the documentation, I’ve found it to be all over the place, unorganised, and a lot of it is out of date.
I tend to search these forums for answers, and usually find them!

I think the best (only?) use for openhab, is as an interface to Alexa or HomeKit.

My 2p :slight_smile: