OpenHab Marketing is Lacking

My opinion is based on my years of experience helping new users get up and running on this forum (and the Google forums that came before that).

I think you’ll find that even your reduced set is not going to be too large to handle, not only to create in the first place but to maintain.

But, as above, you’ve identified a problem and think you have a solution. Hurray! Go get busy! No one here is going to stop you.

I will note that the Getting Started Tutorial was intended to walk someone through all the major concepts of OH needed to build a working system.

I’d add also subscribe to the more general home automation stuff as well and participate there. That’s really how we are going to get the word out. Just interacting with OH stuff is only going to be seen by people already interested in OH.

:face_with_symbols_over_mouth:

This is what we do (or at least try to do) now!

Has anyone on this thread actually gone through the Getting Started Tutorial? Looked at the discussion threads that lead up to Getting Started and the concepts, concerns, et al that went into it? Has any attention at all been paid to the work that has been done thus far? I can provide links on request, though you all should have already read the Getting Started Tutorial.

All these new ideas aren’t new. We’ve hashed them over and over again in different guises and different ways.

I’m more than willing to admit we need help with Getting Started. The docs are not perfect and need major attention. There is always more we can do and we can do it better.

But it is getting annoying that all that work I and many others have put in to solve exactly this problem is being completely ignored. And then in the end, after rejecting all that prior work and going around and around, you come to the exact same conclusion.

I think I need to bow out of this thread.

If anyone needs anything from me, tag me. Good luck!

5 Likes

@rlkoshak I have gone through the Getting Started Tutorial.
Great work indeed, and it looks like huge amout of time was spent on it.

Unfortunately, in my opinion, it’s way too long to read: it’s 18 full sections (!!) that will probably take several afternoons to read and to follow.
Plus there is plenty of advanced stuff: if it’s a “getting started” why should I bother with topics like “advanced things”, “custom widgets”, and several type of creating rules (even advanced ones)?

I really think that OH is missing:

  • a 1h- max 2h Getting Started Tutorial from “zero to hero” to be able to configure at least 1 widget in 1 page and 1 graph to represent some data
  • (much more complicated to do, I know) an onboarding wizard /discovery mechanism FOR BEGINNERS that brings the user from zero to having an item configured, possibily with auto-discovery of bindings (this is WIP, I know) and auto-creation/connection of items (like it was in PaperUI in OH2)

I think this could help new users to have an idea of how OH works and - very important aspect - have some immediate reward after downloading it.
Later on they can cover more advanced/manual configurations using the other guides/manuals.

(I am already contributing as binding developer/code owner: so -sorry- I cannot invest more time on OH other than that)

2 Likes

Imagine how much longer it would have been if I had included text based configs like many wanted.

Because, as of right now, that is the only place the overall process for doing those things are documented at all. Nowhere else in the docs is the overall step-by-step process covered. For example, nowhere else is the overall process of working with an add-on like MQTT/HTTP/Exec where you have to create the Bridge and the Things and the Channels is captured in a step-by-step manner. You get a couple of sentences in the add-on docs and that’s it.

As for the rules, in addition to the above, it’s because not everything is possible with simple UI rules. At the time Getting Started was written Blockly was not capable of doing everything either. So it was important to show users who bump up against limitations how to get past those limitations. Otherwise there was too great of a chasm between Getting Started and actually accomplishing what the users need to. Also, if there is one takeaway from the advanced rules page, it’s RTFM. If that whole page were reduced to a sentence or two saying “RTFM for the language of choice” I’d be happy. But then we still need to capture how to write Script Actions/Script Conditions in the UI somewhere and that’s not anywhere else in the docs.

Now that Blockly is basically feature complete coupled with the addition of the Rules page under Concepts and the Building Pages and Creating Personal Widgets pages under UIs I can definitely see the argument for many of those pages mentioned being removed or reduced, on the contingency that no actual content is lost because still, there is a lot in those pages that is not captured anywhere else.

Overall, the challenge is the rest of the OH docs are reference docs. They are places where you go to look stuff up. They are not How-To Tutorials. Getting Started is, for now, the only place in the official docs where there is any step-by-step how to do X documentation at all. That’s why it’s so long. It has to cover the step-by-step for almost everything.

Could it be broken up? Sure! I’d support a PR that does that, maybe even be able to help a bit.

However, if we just cut stuff out without making sure that content is moved somewhere else, the docs IMO become worse, not better.

And, I’ll mention it again, I’ve an open PR (link above) to completely rework the rules documentation. And once again I’ll request volunteers. All contributions, no matter how small, are welcome!

1 Like

@rlkoshak Your work and time spend is highly appreciated and I really look up to someone like you being so much into such a complex system. Most answers I got here over the years came from you, and I know that I can always count on you. The least I want, is making you angry.

Talking about marketing does not mean not to value what has been done already and it does not mean starting from scratch leaving excelent things behind, ignoring great technical experts, deleting things from existing documents that cannot be found somewhere else, …

But it is a well known and often seen fact, that people with a great technical background think in technical details and complexity and explain things on a complexity level that has prerequisites only few, new to a subject and interested in something from a “what can I do with it?” approach has or is willing to build up before knowing what this will be good for and if it is really worth spending time for, unless it is clear, that it will fulfill personal needs.

And therefore - in my eyes - we need more material on a low level to make people interested in OH, let them have a first success very fast, let them take quick wins, and then they will see, that OH is worth spending more time on the technical backgroud. I went through the getting Started Tutorial several times and it helped me a lot. It is great if you are already infected by the OH virus. But I am with @massi It is much to much to overcome the first hurdle on the way to become a new OH user, when we think about the time to spend for it, before a new user will see a first payoff.

Therefore I support the idea of showcases or whatever it will be named not as “making it better”, but adding one step below to what is already there as a marketing instrument. A guided tour to score the first goal leaving everything out that is not necessary to get there but constanty naming possible further steps, alternatives and where to find more backgroud information. And when I write “support” I mean also spending time and brain on it. Not because I am a big OH hero (I am absolutely not), but because I know and experienced that you can get great payoffs out of OH even with a limited background and which hurdles you have to overcome to get there (and learn more and more on the way). Years ago I tried to support in the docs, but had to realise that my knowledge was too limited to really help there. But on a marketing level this seems possible and I just can offer to become part of it when some people find together to start with it.

4 Likes

OK, fine. So whose going to do it?

Everyone with all these ideas on how to make the Getting Started Tutorial better are too busy or too concerned about not being good enough to do it.

You already don’t like the way I did it (note, I wasn’t trying to defend what I did in Getting Started, just trying to explain how it got to where it is) and if I were to do it now you’re going to get more of the same likely. You’ll have to wait too as I’m focusing my time not spent here on the forum on the Rules docs, a problem I’m trying to solve in openhab-js, documenting my experiences with willow and little ESP-box, and maintaining and supporting my own rule templates and openhab_rules_tools.

I intended to rework Getting Started before OH 4 release. I didn’t even manage to create the Issue.

So who’s going to do it?

I see tons of great concrete ideas here. I also see lots of “not it!” (including me). We have great, concrete, actionable ideas here.

Where I’m frustrated though is all this focus on “if only there were just one tutorial to get someone up and running.” which then becomes “oh, we’ll just point them to some other tutorial for anything that doesn’t fit.”

That’s exactly what we do now and it’s the overall philosophy of the OH docs in the first place. I’m not convinced this is going to lead us anywhere else than to where we are now.

If you look back at the discussion that happened in writing the Getting Started Tutorial, I was against using Hue as the first example in Things. Not everyone will have Hue and I wanted to choose only bindings, Things, etc. that do not have external requirements. That way anyone could follow the tutorial, follow exactly those steps with nothing but what they have installed, and have a working OH configuration.

The problem is you can’t actually do anything with that configuration. There’s no “home” in that automation.

4 Likes

It seems auto discovery of bindings/things is one of the major differences with the other popular home automation system. The idea of automatic discovery has already been considered. Is this something that is a breaking change that would require waiting for a major release? Would individual binding developers need to do anything for their bindings to work? I realize it can’t work with all bindings. Could this at least be used for some of the more popular bindings?

Here is a link to the github (still open) issue started in 2021 (by Kai) discussing the idea (that Rich already linked)
https://github.com/openhab/openhab-core/issues/2645

Edit: I like the idea of a Addon Suggestion Service

2 Likes

Tbh I don’t see the alleged benefit of auto discovery and installation of bindings.
Why not just make an additional step in the startup assistant with a simple question
“What manufacturer of devices are you using?”. And some kind of searchable drop down selection thing.
Even if I am absolutely new I know that I am e.g. using shelly devices.
Or “What kind of wireless technology do you use?”.
The startup assistant would then install the bindings.
This would bring complexity down and auto discovery of things already works for some/most of the bindings.
With two or three questions it should be possible to “discover” most of the needed bindings.
And even if not - if there already is an installed binding the new user will know where to look for more bindings because the existing ones can be used as an example.

I am aware that it’s not as elegant as real auto discovery, but it should be very easy to implement and typically binding installation is only done once so I don’t think it’s worth all the extra effort.

But that’s exactly what we have now. If you have a new install you’ll have the opportunity to select your bindings, set up your location and such.

That’s right. What that selection step could use, though, is some way to search by manufacturer and/or product name. Same applies to the web site: the addon page allows searching, but e.g. entering ‘Roborock’ yields no results, even though Roborock vacuums are supported by the miio binding.

1 Like

This is a brilliant suggestion!

Hi Maniac, in this thread

we are looking for volunteers who have good ideas and contribute for a „marketing“ plan as well as executing the plan.
You are more than welcome to join with your idea(s).

1 Like

I think that would be a great first step

done once when?
Quite often when a very first time user is very first trying to use openHAB for the very first time.

And what if that first time user, someone who read or saw something about openHAB and decided to give it a try successfully installs the program, gets to the main UI and spends the next hour trying to figure out how to make their smart light bulb turn on and off
don’t believe me? just check the forum. example

Uhm…
you know what may make OH easier to use over time is to implement OH as a Matter controller in the core of OH. Then the scope of writing a tutorial is much smaller,

Binding discovery and non-Matter devices would be not that important as they would be an “advanced use case”.

The effort for users to be able to promote OH would then be easier for grass roots marketing.

OH could highlight it’s independence and freedom from platforms that are controlled by companies
looking to monetize the platform. “Free, always been free, always will be free, free from companies looking for money from you”

To me, that sounds like an awesome marketing message!

ps… I’m looking for an easy way to get a Java implementation of a Matter controller

Completely disagree as there are still so many devices/protocols on the market, that cannot be left behind.
We all know that you are so keen into matter, but there is much more beyond that.

Yes - but there the user is already selecting bindings.
I’m suggesting to search by manufacturer or device name, see the example of @maniac103.

The binding setup is done typically once at first start (for a new user).
My argument is that if there is a smart dialogue that installs the bindings based on manufacturer, device name or technology then it’s not worth the extra effort to implement auto discovery of bindings.

1 Like

https://xkcd.com/927/

Please be aware that openHAB itself is another, well… standard (at least from an outsider perspective) so even openHAB added another standard to the competition by trying to implement a more generic way to control most (if not all) smart devices.

The only “real” solution would be to force all manufacturers to use one protocol, one wireless net, one wired net and so on. But this would prevent progress and new inventions (and its not realistic anyway…)

Where did I suggest that?
Over time, Matter will come to be the defacto standard Home Automation platform, and others will offer specialized products not covered in the Matter standard.

OH Binding architecture is not going away!

I’m NOT advocating for ONE standard, I’m recognizing that the market is moving in a direction and OH needs an easy, good, and compelling story to keep the community engaged and the rest of the world interested in looking at OH.

TCP/IP took over the world and SNA(IBM’s networking standard) died

Sure, but that’S a complete other story.
There are hundreds of “standards” out there, as every manufacturer built its own shit (there are some exceptions, for example knx)
And there are good reasons sometimes for another standard. Matter is not.

I think my suggestion is being misconstrued.
I’m NOT suggesting that OH be MADE INTO JUST a Matter Controller.

I’m suggesting that OH incorporate a matter controller in the Core package.

Then a new user would not have to install and configure bindings for basic use cases for the time when Matter has established itself as the defacto standard for Home Automation. The OH Matter controller would interact with the rest of the OH platform just like the Zigbee, Zwave, and other bindings do.

OH would continue to offer first class support for the “much more beyond that”