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.
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.
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.
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:
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).
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.
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.
Ok. What is your opinion of the following:
Adding „Quick Guide“ on top of our documentation tree where I can start writing a new User‘s Quick Guide. This way I could mostly use your existing material and would link to your docs for more detailed information.
Personally, I think, it is „dangerous“ to direct a new and probably unexperienced user to our documentation because of the overwhelming content. But if that Quick Guide would be on top even before „Welcome // Introduction“ that would make it clear that new users should be starting with a Quick Guide first.
Even „Welcome // Introduction“ is too heavy for new users.
The problem is putting something that looks like documentation anywhere but the documentation page.
Also just because there might be some pushback doesn’t mean you can’t ultimately prevail. Most of the maintainers are reasonable and can be convinced to change their minds. But be prepared to make your case and pivot if you fail to convince them.
If it’s too heavy, why not make it less heavy? It seems awkward to have a guide even before the welcome. Note that the welcome page is to level set the users. That’s the first place where we make it clear what OH is and what it’s going to take to get it to work for you.
one step after the other. I really think that a Quick Guide is required which guides a new user from downloading OH to a first rule at ONE place in a very simplified way. I won‘t go into details or offer too many options as this sort of document has already prepared by you.
The guide does not have to be at the top of the menu tree. We‘ll have other options to guide new users there, like changing the „Getting started“ link on our website or have two links on our website or even other options.
The reason for the change is also that it is by far more complex to makes changes to the website than to our docs.
EDIT:
heavy is the wrong word, without explanation. It is not heavy in iteslf. It is a good document and not optimized for new users, because you wrote the doc for existing users desperately needing a detailed description.
It is like with any other software, too, where you have a few docs, each of them aimed at different target people (user guide, admin guide, update guide, …)
If I were king, I never would have let Profiles become a thing in the first place.
one step after the other. I really think that a Quick Guide is required which guides a new user from downloading OH to a first rule at ONE place in a very simplified way. I won‘t go into details or offer too many options as this sort of document has already prepared by you.