That is the missing link, I was looking for. Thanks Rich. Will do this tomorrow.
No, it is not. Unfortunately, we are not precise in our wording. Setup for one means installation and for others it means installation and customisation (adding bindings, things, items, create rules). The second part is where new users struggle with.
Discussion is good, but please let me shift the focus back on our actions. If readers or posters wish to contribute for a plan to attract new users and want to coordinate your work with other volunteers, this is what this thread is for.
Please drop us here a line, and Iāll add you to our list of volunteers. There are already 5 volunteers.
Youāll find them in post number 2:
Even though discussion is still ongoing, I want to move forward with our actions.
In post number 2 I will add all actions which are currently ongoing.
As mentioned in the first post I will start creating a New Users Guide this week for our home page which covers in an easy way and less technical language the whole āonboarding processā from installation, to adding bindings/things/items and finally end with GUI rule. This guide will by intention not cover various possibilites (that is already done by our existing doc). It will cover just one, which is the easiest one.
By intention I want to create this for our home page and NOT for our documentation.
Margaret Mark and Carol S Pearson in The Hero and the Outlaw talk about the best brands using archetypes or personalities.
openHAB has 3 possibilities
Ruler - take control of your life
Hero - Make it easy and take away the pain
Magician - Wave a wand and your problems go away.
The bindings and integrations make Hero and Magician possibilities but the docs need be better. Often they are actually too specific and make it difficult to generalise.
The archetype gives you the āhookā for the messaging
Sorry but itās not Philip Kotlerās 4Ps it was McCarthy in the 60s. The 4Ps have been 7Ps for 30 years when People, Process and Physical Evidence were added.
The Product is Great - it does the job very well
The Price is Great - itās free
Place is fine - download from internet
Promotion - needs work
People - great support and development infrastructure
Process - Ooops
Physical evidence - Great configurable in the way you want (provided you understand the Process)
Bear with me with this story.
The main ācompetitionā is Home Assistant. I have a Wallbox Pulsar EV charger. Itās supported in HA (but not in OH). I downloaded HA onto a Pi (but downloaded wrong version - too many options without explanation of what they are). Finally got it to work added the Wallbox integration - spent 2 days trying to get a rule to work. Send the Wallbox data via MQTT and created a rule in under a minute in OH.
We constantly beat ourselves up about whatās not good about OH and ignore the really good stuff. One of my gripes is that I wish we could grasp ladder logic - home automation often time isnāt sequential but all the programming systems are. For instance setting a time window for heating and only turning on the boiler if a sensor requires it is easy in ladder logic but a real pain in OH.
To fix āourā marketing we need to talk to customers. Find out what their experiences (and pain points) are. Then use Pareto analysis to fix them.
Ask yourself, if that procedure is better or worse, than what it takes to add Philips Hue or even Homey.
Alot of people dont even know what a Raspberry Pi is. A term/expression such as an āimageā is something theyĀ“re watching on a screen.
YouĀ“re asking the wrong person.
For me its NOT too complex. But is it people like me, with several decades of experience, which a marketing of openHAB should adress?
Unfortunatly, this is only a small part, before openHAB is actually given any results at all. You and I know this. A new user dont, at least not without having to deal with the documentation first.
Again, try look at some of the references mentioned.
A not knowledged person can install and setup Philips Hue and even Homey Bridge within a very few minutes.
After setup, Philips Hue app will have found whatever Philips Hue compatible devices by itself. All the user have to do, is to add it to a room. Rooms are even predefined. And the user is good to go.
The same goes for Homey Bridge, but Homey goes even futher and find almost whatever is on the WiFi network, all by itself.
In openHAB, the user has to deal with bindings, things and items, after havning openHAB up running. And even by then, there is still no results, as a kind of UI is required as well.
Why would anyone go through the hassle with openHAB for adding lights in a kind of smart home manner?
The question is:
Which kind of users do openHAB wants?
That is what the marketing should be focusing on. Without this definition, the marketing will become wrong from start, and it will change nothing.
I (personally) do not complaint about openHAB being too complicated.
I just state, that the way openHAB is build, it requires more knowledged (and/or alot of patience and reading) to get openHAB up running, even with simple āsmart homeā devices, such as Philips Hue/WiFi/network devices.
To change this, developers of openHAB needs to focus on, how to make the startup/setup easier. Without doing so, openHAB will be adressing a limited amount of people. And it would probably not need anykind of marketing at all, as those with interest will find openHAB by themselves.
That my opinion. I dont ask you to totally agree, but at least think about it.
Thatās all correct and that professional approach applies to corporate companies, who have their own staff and where you simply create or change the roadmap and your development team starts developing against the new roadmap.
That is not our environment. Even if you succeed in getting the customersā requirements or pain points, then what happens next? Who will develop?
I encourage you to create another thread for this, where new requirements can be discussed.
This thread already has applied the pareto principle: Letās focus on the most urgent 80% of the things we can change easily, and leave the 20% (openhab changes) for later. Letās put a joint effort into bringing openHAB as is today closer to non-technical people.
YES!
I think openHAB should focus primarily on people who have some level of technical ācompetenceā, or at the very least, interest. a.k.a āGeeksā. Someone who likes tinkering with technology, therefore would have heard of āimageā / raspberry pi, etc. Thereās still some more work to be done to make openHAB easier, and therefore more appealing to use even for this target market.
Targetting completely non technical people, IMO is going to be very hard on many fronts, but may be do-able once weāve smoothed the āproductā out for the technically minded target audience first.
A valid point. We need to define a certain level of knowledge required for new users. We cannot start from scratch explaining new potential users what wifi is, an IP-address or raspberry Pi or an image.
Exactly!
I have a draft, started to write it last year, but never finished. Iāll send it to you
Thatās the Link which @Udo_Hartmann didnāt list.
Specific and actionable issues are the best way to do this. āThis section isnāt clear, make it betterā really isnāt actionable though so be prepared to come with concrete suggestions.
Weāve done the best that we can with the docs and tutorials. āDo betterā without details on how is kind of an FU to those who have contributed up to this point.
Just to be clear. OH could be made very easy for some smallish subset of users. But if your requirements fall outside that subset 
OH as an organization cannot sell preconfigured hardware like that. I imagine some third party could do so if they wanted but care would have to be taken with the trademarks.
openHABian is our answer to a āpreconfiguredā system.
Expect some pushback on this.
Please elaborate.
There have been some examples of using a state machine in OH rules. A State Machine Primer with HABlladin, the openHAB Genie is old but still shows the overall approach.
Iāve on my long list of todos to create a rule template to implement a generic state machine. Iām not yet convinced it will make it simpler though.
As for the time window part, in UI rules the āBut only ifā¦ā section of the rule was made for this. You can define a time range there fairly easily now:
In just text based rules or in a Script Action both JS Scripting and jRuby make time comparisons somewhat easier. For example:
if(time.toZDT().isBetweenTimes("08:00", "22:00")) {
The reason Hue can be that simple is because they only have to worry about Hue as a technology. Homey is that simple because it is limited to only a hand full of technologies, all of which can be auto discovered.
OH has no such limitations.
And there is an issue to figure out how to have OH discover what can be discovered during the first run wizard too.
This is why the semantic model exists. Could it be better? Yes, but when you add semantic tags to your Items you get a UI for free.
Because they want support for a technology that Hue and Homey doesnāt support or they want to do things that Hue and Homey canāt do.
I keep seeing this stated as if that isnāt what the developers are already doing.
Yes, sure, but my point is: Smart home is not and will not be easy.
If even a plugānāplay solution (of course with a dedicated platform) is MUCH too much, smart home may not be the right thing to starrt with (and to be fair, itās not easier to do it with one of the other Open Source solutions as well)
If someone wants to dive into smart home, he/she has to dive (and get wet).
A single HUE lamp is NOT smart home.
Some bindings may need to be changed to improve new user experience. For example, I have TP-Link plugs, Kasa and Tapo, for the Kasa devices the binding discover their name (as specified in the Kasa App), whereas for Tapo devices the binding discovers the device type but not the name (already reported the issue in the Tapo binding thread).
The same may happen with other bindings.
Which is why its important to state, which kind of users any sort of marketing will focus on.
During setup, OH does have limitations. Even getting as far as to auto discover, the user has to go through a lot of hassle. Remeber, a Rpi is a hassle for those who do not know what an Rpi is.
We know what Rpi is. But weĀ“re (hopefully) not in focus for a marketing of openHAB.
As I said, Hue has the advantage of focusing on a limited āsmart homeā and its specific devices. Same goes for Homey Bridgde, however Homey has a few more interfaces. Thats why its easy and all can/will be done from a simple smartphone. There is not Rpi, no SD-card, no āImageā. Its simply plug&play, with it limitations ofcouse.
Then the marketing has to be concentrated on those potential users. It has to lift the users requirements/requests.
Thats not what I said, or at least not what I meant.
I meant that, if openHAB is suppose to marketing towards those ānot knowlegedā users, then the developers has to make the installation & and startup procedure alot easier. Not doing so, cant be rescued by a marketing. And marketing wont be able to change the potential user segement itself.
I dont critizise anyone. I just say what the reality is.
If marketing is suppose to change anything. It has to define what kind of users to focus on.
Atm openHAB itself has defined this. Its purely for already knowleged people, mostly.
You and I can agree on that.
But the user segment of Philips Hue and even Homey Bridge do not agree. For them, a single light (or alot, even capable switching on/off by a motion detector, by speech/whatever, change colors etc) is āsmart homeā for them.
Most of this kind of users dont even know better. Thats why Phillips got the massive success with Hue.
You and I know better.
But if we want those users to use openHAB, things got to change alot, specially regarding the installation/setup. If we dont want them to use oenHAB, maybe there is no need to change anything/do any marketing. And we should just accept the way things are today.
Iām pretty confident in my use of the English language. Perhaps then the word āchannelā is incorrect?
Either way, itās confusing, especially to describe it as:
Channel ā a piece of information and/or the option to control some part of a Thing
I thought my lamp example was pretty clear but apparently itās not.
Iām not saying that, or even suggesting that. However, a new user may look at the existing documentation and say FU, Iām not bothering. People are trying to be constructive and thereās no need to become all defensive when people are trying to help. Read my original post and you can see where I am coming from.
Why not? āMarketingā is not about explaining you home automation.
āMarketingā is about creation of a preferences for openHAB for people who are looking for a home automation solution - regardless if they are experts, semi-professionals or novices.
Itās not an English problem, itās a problem that the terms Thing, Item, Channel, Link are terms of art in OH. They have a specific technical meaning when it comes to OH that is separate from the regular English meaning.
If it were me, I would have chosen different terms. But I didnāt develop them so I didnāt get to name them. (Iād probably call them Attributes).
In the context of openHAB, as a term of art, a Channel represents a sensor (a value that could be reported to OH) or actuator (something that OH can cause to do something). A Channel is something that can potentially be used in OH. But itās not until you Link it to an Item that you actually have something that looks like a āchannelā in the normal English meaning of the word.
This is why Iām diligent in making sure to capitalize the word when Iām referring to the OH concept instead of the generic English meaning.
If I were to make a poor comparison, a Channel is like a TV channel. Itās there in the background as something you could potentially watch. However, itās not until you turn the TV to that channel that you actually see whatās being broadcast. Similarly, a Channel on a Thing is there in the background and itās not until you Link that Channel to an Item that you can actually use it in OH.
Iāve always been uncomfortable with the way that Links are given short thrift. Iāve seen it cause confusion and mistaken assumptions. But everyone is looking to remove concepts here, not make them more clear somehow so :shrug. Maybe it doesnāt matter.
That wasnāt directed directly at you. But I have had years of people saying āthis sucks, do betterā with nothing concrete. I and everyone else who has contributed to the docs have done their best already. So without something concrete and actionable, we canāt do anything. Itās just complaining. āI donāt like this rock, bring me another rock!ā
I see some complaining in this thread but by not means is it only that. There have been a lot of actionable suggestions and ideas.
Just to clarify because you wrote sensor which could also be misunderstood as device:
In openHAB a device is a Thing. These thing can provide or receive values. These values are provided through channels. To get the values from a Thing into an item (or vice versa) you have to create a Link between the item and the corresponding Channel.
I think the most unexpected part is that a link can exist without an item or a thing.
Imho it would help tremendously if the link would actually be item bound because thatās how seen from a user perspective.
Because itās easier to remove something that is (somewhat) hard to understand than to try to explain it better.
This is my biggest fear of all this marketing and letās-do-something threads.
Good ideas are always easy, actually implementing and/or doing things is always hard.
I just hope that this time we actually see change at the proper places and not only frustrated users.
If we see some fancy marketing things and docs improvements that would already exceed my expectations.
For users who use text files, yes.
From the UI though the Link can be accessed equally from the Item or the Thing. Whatās missing in some cases is that the Link was created at all. When you use āadd equipmentā you never see the Links at all.
And donāt even get me started on Profiles. 
If I were king, I never would have let Profiles become a thing in the first place.
Note that it also used to be the case (donāt know if it is any longer) and was distressingly common for users to create the Links through the UI even while using .items files.