New User documentation

Tags: #<Tag:0x00007f01461a3710>

(Andrew Rowe) #41

Doesn’t the demo just show example sitemap which actually does not do anything right? I can no longer view it I guess, it is not one of the install-able UIs once you have a running openHAB?
I’m curious, after observing ‘demo’, how did you begin setting up your own openHAB?

(Alex) #42

I used “demo” as a starting point. Then I added/changed the “config” files to see what happens…
After I knew my way around, I installed OH new, with the “standard” package. The files from the folder “config” I have then copied into the new installation.

That remained so today!

(Andrew Rowe) #43

very interesting. So using this method, openHAB in a way gave you a running version of the application which you could then learn through experimentation

How did you learn the various methods? I’m guessing it was all text file based configuration? Where did you learn? Documentation or forum?

How has the documentation changed since you started?

Thank you for your input!

(Alex) #44

How did you learn the various methods? --> By adopting the syntax inside the config files.

–> And reading the documentation, if there was one… :wink:

I’m guessing it was all text file based configuration? --> Yes, it still is.

Where did you learn? Documentation or forum? --> Both!

How has the documentation changed since you started? --> When I started, it was very poor. But now it is great, but not perfect!

(Andrew Rowe) #45

Bravo @Celaeno1 Excellent post much useful information
Thank you
This gives great insight into how people learn a new application and a very interesting point of view with regard to improving the documentaion

(SiHui) #46

Change the package option in your addons.cfg to demo:

# Valid options:
#   - minimal  : Installation only with dashboard, but no UIs or other add-ons. Use this for custom setups.
#   - simple   : Setup for using openHAB purely through UIs - you need to expect MANY constraints in functionality!
#   - standard : Default setup for normal users, best for textual setup
#   - expert   : Setup for expert users, especially for people migrating from openHAB 1.x
#   - demo     : A demo setup which includes UIs, a few bindings, config files etc.
# See for a detailed explanation of these packages.
package = demo

(Andrew Rowe) #47

Relevant recent pull request for Linux installation document

(marcel_erkel) #48

I’m a long time openHAB 1.x user and am in the process of migrating my system to openHAB 2.x. Now that openHAB 2.4 includes the new Z-Wave binding and writing rules in Jython is now possible in openHAB 2.x as well, I feel that now the time for me has come to make the jump.

So I know my way around in openHAB but I’m always interested to learn from other people. This morning I was reading the forum and got triggered to read the documentation when I ran into a kind of ‘you’ve lost me here’.

  • “Of course, this is the correct.” I don’t know what the writer is trying to say here, ‘Of course, this is not correct.’ or ‘Of course, this is the correct representation.’, or may be something else, so “you’ve lost me here”. I have no clue.
  • The italic part can (IMHO) be completely removed since it seems a little far fetched to me. Does anyone seriously do this? I mean, it’s certainly a creative solution, but also a solution triggers so many questions (how does this work with direct sunlight on the sensor, multiple lights on dimmers which could cause false positives, etc.) that this seems to be more a topic for a forum post where it can be discussed than that it should be part of the documentation. Or may be something for an ‘advanced solutions’ section of the documentation.

I hope I didn’t step on anyone’s toes here because that is absolutely not my intention. I appreciate how much time and effort everyone puts in this.

(Rich Koshak) #49

Just to be clear, OH 1.8 supported Jython and OH 2 had supported it since at least 2.1. I don’t want anyone to have the mistaken impression that this is something new.

One thing to note is this section of the docs is not describing anything new. OH has always worked this way since at least 1.6.

The writer is saying that the UI is behaving correctly given the scenario presented. A command was sent to an Item to turn ON. The Item’s state charged to ON. The device didn’t turn on because of some problem. So the UI and the physical device are out of sync.

If you want the UI to accurately reflect the state of the device, you need feedback from the device or some other sensor to tell you the light turned on or not.

The short answer is yes, people do this. Usually it is something more critical than lights like irrigation or heating.

(marcel_erkel) #50

That’s why I wrote 2.x and not 2.4. I was just providing a little context why it has taken me so long to jump on the 2.x wagon.

I know, not sure if I used 1.6, but 1.7 for sure and I’m still running in production with a 1.8/1.9ish version. I was mainly referring to the text which I made bold. The sentence “Of course, this is the correct.” simply isn’t correct English. So that’s where I came to the point that Andrew asked for to point out:

Then may be it would be better to use irrigation or heating as an example here. Still, I think it takes away the focus from what is being explained and hence should be a topic for an advanced section in the documentation.

I’m just providing some feedback on how I perceive the documentation.

(Andrew Rowe) #51

much appreciated as well.
If I’m not mistaken, you are quoting me from the ‘concepts’ post above. That page is part of the eclipse smart home documentation. The concepts page is a target for improving the portion of the documentation considered important for new users. Thank you