OpenHab Marketing is Lacking

Hey all, I’ve just finished reading the thread. There are a lot of good ideas here covering different topics and areas. What @rlkoshak said about needing people to actually do these things hit a chord with me. I’ve been in IT almost my entire career, mostly in data and currently as a BI developer. I don’t think I have any skills that are directly applicable to anything that needs to be done. Right? If I wanted to know if my skills could be applied to something, how would I find out? Where does the OH community go to manage the volunteers needed to accomplish some of the great ideas presented here? Obviously a skilled Java developer has a hundred different things he could do, but I don’t know if my particular skills are of any use. I’ve been a user since 2.x and I feel like maybe I should do something to give back and help keep OH going. I know I can join the foundation and provide support financially, and maybe that’s the best way I can help. It would be interesting though to see a list of ‘soft’ projects that I might be able to contribute time to as well.

It’s a very interesting discussion to be sure. For what it’s worth, I ended up on YouTube when I moved to 3.x and found the videos on the official OH channel to be very helpful.

Thanks,

~Mark

2 Likes

A complementary approach to raise the profile of OH to new users could be to detail the available bindings or integration potential for OH on the various product manufacturers websites.
As an example, the Weatherflow weather system has the OpenHAB logo, but no mention of HA.
https://weatherflow.com/tempest-integrations/
The Hue website has a section on integrations, but with no mention of OH.
https://www.philips-hue.com/en-au/explore-hue/works-with#smart-home
As a binding is developed, a short ‘blub’ on the value of the interface with OpenHAB, along with a copy of the logo sent to the manufacturer for consideration could be another way to increase visibility. Whist many manufacturers may be reluctant to include something that had not been through their QC systems, there could be many products where the usability with a home automation product could be of mutual benefit to both the manufacturer and OH. This could be a consideration during the development or updating of a binding.

5 Likes

I know it sounds tedious but you can always improve the documentation. Writing and maintaining a good documentation is very hard and every so little help is always appreciated.
E.g. if you read something in the docs that doesn’t have an easy reading flow why not just rephrase it. Or if you use textual config just add some working examples to the binding you are using.
Just click on the bottom of the doc page “Edit this page on GitHub” and you are good to go.

Docs are one of the most important parts but they often receive little love, yet they are the first things a newcomer sees/reads (hopefully).

Unfortunately, it is not as easy as this. You need a Github account, fork the documentation, make comits, make pull requests and maybe some more stuff. I gave up on this when there is no feedback for PRs

2 Likes

I had a quick look on this thread an red some of the postings. So i am not fully involved. Anyway:

My feeling is, that we don’t talk much about how to do “marketing”, more “marketing” or even better “marketing”. Most of the time we talk about product improvements.

I always had exactly this impression in my working life when technicians talked about marketing. Technicans can do quite everything like software, documentation and (as lots of people here are german natives) rules on how to contribute - but no good advertisement or even marketing.

There is a German saying: “Confident behavior when completely clueless” (“sicheres Auftreten bei völliger Ahnungslosigkeit”). This is not our strengh nor is it part of many open technical projects. We even think of this to be wrong.

So partly, a much-needed type of people is missing. This thought comes to me when I skim through the posts here.

I don’t know a solution, but I would like to reflect that.

3 Likes

Anyone can write docs though. By making this post you’ve proven you’ve the skills for that. :wink:

Depends on how you want to contribute. If you want to write code, look through the issues and pick one that seems easy, or create an issue to change something that’s been troublesome for you that you think you can fix. Some of the repos mark issues as good candidates for first time contributors.

The same goes for the docs with the addition that if you see something minor like a typo, there’s a link at the bottom of the page that takes you straight to where you can suggest a fix.

Or you can help users here on the forum by posting tutorials, answering questions, posting rule templates or widgets or blockly libraries. The barrier to entry here is very low.

Or, as discussed above, get into marketing and show off what you’ve accomplished, participate on other forums, create videos, etc.

But one very important thing to understand is you don’t need to be an expert in any of this to get started. You can learn as you go. We’ll help where we can. Many add-on developers had their add-on be the first Java anything they ever worked on.

There are two sides to this. We don’t have any way to manage a group of back benchers. We can’t say “Hey, Mark, X needs to be done and you have X skills. Get to it!” It’s up to you as the volunteer and the expert on what your skills are and what you are willing to work on to speak up and dive in. You need to find something you want to contribute.

Once you identify it, create a forum posting and an issue on GitHub where it can be discussed, especially if it’s going to be a lot of work. If it’s controversial, there might be discussion, compromises might need to be made, or it might be rejected because of some impact on something else.

Except for the creation of the GitHub account, all the rest of that gets handled when you click on that link at the bottom of the page.

Which PRs have received no feedback? In openhab-docs there are only ten open PRs, the oldest of which is from July 27th of this year. You will find few repos with a better response to PRs than that.

1 Like

That was not my experience when I clicked on the edit button. I‘ll open a seperate thread for this.

After reading the whole thread, I would like to start with an answer to the innitian question: Yes, it would be very nice if someone would produce more and up to date video content. And from a marketing perspective it is not optimal to have a version 4 on the market and a selection of videos featured at https://www.youtube.com/@_openHAB without even one video for this version. And as a new install after an unwanted upgrade gave me the chance to update my openHAB-appliance setup, which is now written down in detail, I really think about making a video tutorial for it.

But the bad numbers for openHAB shocked me, too and I question myself, if it is still worth investing more time in openHAB. This question has nothing to do with the technical quality of openHAB but simply with the future perspective. And this leads me to some aspects that have not been addressed yet it this thread.

I am not a developer and although I can understand some code, feeling comfortable with making some changes in examples I found on the internet and have a quite broad list of software I can use on a quite high level, openHAB always gives me the feeling of loosing more then learning more. The initial learning curve is not only steep but the number of things you have to learn (and then just use once for years) is so huge that I often have the feeling of loosing more than learning more. And new versions with new features and now obsolete things come faster than I have time to keep up.

And this means not only openHAB itself, but also the ecosystem arround when trying to find information/help in a concrete situation and the ease of use. The already discussed wizzard for a 1st start would be great for the beginners experience. But there is more:

I really appreciate the work that is done on documentation, but I miss tool tips for the fields of a mask like, what is the purpose of a field, examples (with explanation) of common inputs, … And I miss a more structured approach to find an item, … when I want to use it, like a grid with several searchable and sortable columns for more information than just the label (e.g. the thing it belongs to, the binding as already implemented in the overview, the location, the parent groups, …), more list boxes instead of free text for data known to the system already to avoid typo. E.G. when adding a new thing, item, … it would be so nice to have a chance to refer to the already existing items, … for naming conventions used. I so often find myself in a situation going back/opening an additional tab to look up things like this or getting wrong names by simply not remembering my own naming convention right (and yes renaming would be great!).

And as much as I seen how much time of some members of the forum they invest here (and I often needed and found great help here), the forum is a horror for me with threads of hundreds of postings starting back with a problem/new feature years ago over two versions with more outdated information then still usable content. And I do think that this is also a hurdle for beginners. Imagine someone wants to use the IP camera binding and sees this thread with 2860 postings, … And then there is Github, Reddit, we have the documentation, but with all the outdated information and hard to find “truth” for the actual version this can be quite frustrating.

And yes, I really would like to contribute in any way possible for me, but it starts with the complexity of the eco system. E.G. I made a widget for the Hanover AHA trash binding (no big thing) and wanted to offer it to the comunity, but for me it looked harder to do so than coding the widget, and so I kept it for myself. And whenever I read the documentation I would love to add a sentence here or there when I found a solution for my problem somewhere else, but the process is to complex for me. In Wikipedia there is this nice “Discussion” page behind every article. Would that be something for the openHAB-docs, too? Or links from the docs to special forum pages where such contributions could be made without any additional needed tools (and the knowledge how to use them) and accounts?

I see the need to broaden the user basis to keep openHAB alive and find new developers and advanced users to help these developers. Therefore we should make the start and also the “active life” with openHAB as comfortable as possible for those who are not already native Github-users, JAVA-developers, …

1 Like

The Developer Sidebar is made for this.alt-shift-d to open it and you can search by name, label, metadata, etc. It searches inside rules and widgets. You can pin stuff, interact with the pinned Items (e.g. flip switches), and easily navigate to their pages.

What would you recommend to streamline the process? Ultimately, adding a widget to the marketplace involves creating a new post in the marketplace and filling out the template post that tries to document what you need to do.

I’m always open for new ideas but if creating a forum post and filling out the template is too hard I’m not sure what we can do to make it easier.

OH 1.x was based on a wiki. It really didn’t work well and we abandoned it. Given the way that the docs are built from sources from multiple different repos and versioning is kept so that you can go back and see the docs for a specific version of OH, not just the latest docs (which was only one of the major problems with the wiki based docs) that just isn’t feasible.

Something is not right here. There’s a difference between complexity and ignorance (not the negative connotation, just, not knowing something.)

Just yesterday I did my first contribution to the documentation. Scroll down to the page, click in “edit in GitHub”, login to GitHub, and follow the instructions (commit with your real email instead of the anonymous one for example.)
It was easy (even when I did something wrong, the maintainers were kind enough to correct me.)

So really, if you found it too complex, please take the time to check it out again. It’s simple.

2 Likes

Hello,

I follow the topic with interest because I also fear that at some point openHAB will end up dying. I will give you my feedback. I am an electronics engineer by training, I do quite well in IT (Linux, C programming) but I do not know the languages used for OH programming (I am not capable of developing a binding for example.)
I started with OH1 and quickly realized that it was a reliable, robust and powerful solution. I grew my installation then moved to OH2 with a mixed textual and UI configuration. There things got a little complicated with the introduction of the concepts of Things, Channels, Profiles, Tags… However, I was able to develop a reliable installation with rules developed thanks to the help of the documentation and the forum.
Then came OH3. At that time I saw that there were breaking changes and also the stopping of support for 1.x bindings. I decided not to migrate to OH3 for these reasons.
After a while, I began to fear for the sustainability of my system. Many of my colleagues were telling me about HomeAssistant. So I tried HomeAssistant. I was amazed by the ease of implementation. In less than 2 hours, I had connected all my devices and I had nice dashboards, particularly for energy management, with graphs. Doing the same thing with OH would have required days of work. I was then thinking of migrating to HA. But I didn’t do it because I realized that advanced automation required a lot of learning.
Finally, I saw that OH4 was released and wanted to give it a chance. I did a new installation on a raspberry 4.
What progress! I can finally define all items from the UI. I can also write advanced rules in script. Now it’s decided, I’m going to stay at OH4. However, I am aware that I can easily adapt to OH4 because I have a significant background in OH since OH1. But I also realize that for a novice, the concepts of OH are complicated and the learning process takes a long time. And I also ask myself a lot of questions. What will be the future of OH? What approach should I adopt to guarantee the sustainability of my installation? Just one example: there are several possible languages for rules. I use DSL. Is a language that will be supported over time, or will it disappear in a future version?

Jetblack

2 Likes

Your example shows much of what people know and think of OH (and HA in comparison) is… well, outdated. Wrong in fact. And in part result of OHs long history.
The GUI stuff you discovered in OH4 had been there since OH3 about 2,5 years that is.

If you were to start today you maybe wouldn’t be using files or DSL to do the config and programming. But you still can. It’s there and what’s even more important it keeps being maintained, there’s even smallish new features.
Docs were very much improved telling you how you can do in DSL and JS or marketplace templates.
Feature parity UI or text config for automated deployments or just because you like it. Binding or 3rd party component for e.g. ZigBee.
Semantic model, custom widgets or from the marketplace or ancient(v1!) text config of sitemaps.

This is what beginners, reviewers and even to some extent long termers often do not understand: there is not THE one way of doing things. There’s choices, and they’re ALL up to date.
Most people just don’t know about more than one of these options and quite some have a history like you do or they read/watched some information snippet so they believe this is how OH is.
That has a downside, of course. Freedom of choice means being forced to choose and spend efforts to evaluate options and educate yourself upfront to be able to make an educated choice that’ll stay, turning the effort into a beneficial invest mid to long term.
OH will never become a no-brainer but real home automation is hard and will remain to be so any home automation system that’s comparable in capabilities will be more or less as hard and costly to learn and use.
We try to make it easier to apply to less complex use cases but we won’t be sacrifying flexibility.

HA in comparison is simple. It just provides a single method to do things. Interactive only, essentially.
That’s a lot more appealing to users as it matches the Zeitgeist of getting things effortless (no thinking, no preparations required) done quick.
But there’s limits and downsides to that, too.
OH has overcome these limitations, initially at the cost of apparent user unfriendlyness and now at the cost of being complex, still confusing at times and somewhat unappealing as it is giving users a feeling of inferiorness maybe.
But we’re improving faster than users and reviewers notice - granted it’s still somewhat confusing due to complexity and the sheer amount of options.
And we’re getting there, we’re already way further in than noticed outside our community.
There’s the semantic model, there’s UI files feature parity and greatly improved alike documentation, the marketplace, Getting Started tutorials and more.

Getting back to the title which is all to the point: all of this is incredibly hard to document and to communicate, and that’s where we currently fail for the most part.

This thread should not be about OH and your experience with OH but on how to improve on communications.

4 Likes

I’ve been following OH for years. So if am outdated and wrong, that means that OH communication and marketing miss its point!

So: communication issue.

Such a point is acceptable for a professional or an engineer, not for a standard user who wants the home automation software.

I agree.

Sorry for that. But community forum are also the place to exchange views and ideas.

But in a separate topic please. This one is about marketing.

Imho this is one of the greatest strengths of openHAB but also what is too much if you first try openHAB.
The unmatched flexibility and that’s really something where there should be more emphasis on.

Configuration:

  • You like GUIs, you can configure openHAB through the GUI,
  • You like files, you can configure openHAB through files

Rules

  • You like javascript, you can write rules in javascript.
  • You like ruby, you can write rules in ruby.
  • You like python, you can write rules in python
  • You like graphical rules, you can do blockly or NodeRed

It’s a little bit shown here but I think there should be more emphasis on this flexibility. Especially old forum posts (not in this forum) still complain about RulesDSL when now there really is a rule engine for everyone.

1 Like

I know the developer sidebar and use it sometimes although this is something I constantly forget about. Perhaps at it is not so prominent/has to be activated manually, not so self explaining? It helps in some situations when looking up an item, … but as it needs the correct spelling to search it does not help if you got lost in your own naming conventions, like: Did I use Outdoor, or Porch or Terrace, or maybe Patio, or an Abbreviation of one of these words in the name or label? Sorting items, … in a grid with a colum location sorted from A-Z would bring me quite fast to the result. Or I know that the item belongs to a thing that uses a special binding and I sort by binding first and then by location in a second column. And I could see in following columns parameters I want to check out to make a new item identical to existing items, find the cause of an error in deviating parameters, … And, one wish more: Perhaps could even do mass changes without editing every single item in the selection I made.

And for the widgets: The first “problem” is, that from within openHAB, where I work on a new widget there is no functio/link to publish the new widget. The same, when you open the marketplace from within openHAB searching for a widget. So without searching out of openHAB you will not see, that you have the chance to publish a widget to the marketplace and that this is wanted. Instead you feel like “There must be a secret team somewhere that is able to develop and publish widgets to the marketplace and you are not part of it, your contribution may be unwanted”.

If you find the right place, the first impression is: There is a lot of text. Then the mask does not look like a mask for offering a new widget, but to post a text article in a forum (as it is). Furthermore you see that some of the text already in the mask has to be edited and that there are obvioulsy parts you should not change/that are necessary for functionality, but it is not easy to see, what has to be changed an what not. Is the [ and the ] necessary for each position? What about these ## and ###? Should I add my input instead of the text in the brackets, or instead of the red pen or both?

The title field above the text seem to be the field for the name of the widget, but is this correct? Are there naming conventions? Where can/should I make clear that my widget belongs to a certain binding or certain things/items? Then there is this tag field. For what? In the text I see that there should be tags used for maturity, and that I am obviously free to decide, OK. They should go in this tag field? But are other tags needed or recommended, like the binding or type of devices the widget can be used with?

As my widget is dead simple, working for months and will not have any additional features in the future I could call it stable, but below I see a version history starting with 0.1. Is this correct then? Or am I free to decide for a version number?

Then there are several ways mentioned to publish the widget itself. Code-fences with YAML are what for? Yes, I know that I obviously could use them to copy and paste the code from the openHAB editor within these fences, but would everybody understand it that way?

To be honest I made myself here more stupid that I am, but I wanted to point out that for a beginner or someone who does not work with openHAB on a daily basis it is often really hard and timeconsuming to find through the different systems needed as they are often not linked to each other that well and the level on which you find explanations is often quite high/not very detailed.

1 Like

Well, you found exactly the point: You need a second tool/system with an account and you have to learn how this tool works. I know that a in the developer comunity a GitHub account and the knowledge how to use it is a nobrainer. But not everybody is a developer. And just for the sake of “After hours of searching I found a solution to a special problem for which I could leave a little hint in the docs”, who will start by opening a GitHub account and first making himself comfortable with GitHub? I have a GitHub account, use it quite seldom and normally have forgotten everything about how to use ist, when I need it again. Therefor I also do not make PRs when I face some problem within openHAB. I use the forum, and leave the PR to people who are native GitHub users.

And GitHub is just one of many tools in the eco system you have to make yourself familiar with.

I agree that there is this “Zeitgeist” but there are also other aspects. OH has a great basis of IT professionals and people with no other hobby. They are all familiar with 1001 tools, programing and scripting languages, … and they keep up there knowledge as they use it on a everyday basis. If they find some lines of code somewhere they know which language it is and how to handle it. They do not mind rewriting code in a different language and having an installation that uses all the choices you wrote about.

But besides “Zeitgeist” and an existing wish to learn more, get more into it, … there is a majority of people out there that has a special need or a wish for some automation but no big IT background and limited time and limited needs and therefor often get frustrated when they see how much knowledge is needed and has to be kept up to make use of OH. I really would love to do more with OH but often it takes weeks or even months to find time for it again, and I think a lot of people have such a situation. And then the complexity of OH strikes again. You forgot a lot of thinks you first have to find again and with every addiditonal component and tool, scripting language, … this situation ist getting worse.

2 Likes

I’m no developer. I don’t use GitHub. This is my heatmap:

If you don’t know how to read it let me just say that my heatmap is very cold.
The best I can do is fumble on GitHub.
But the key part in my statement is:
What you’re saying is “I don’t want to do it.”
And you didn’t do it.
What I’m saying is “I’m going to try to do it.”
And I did it.

Don’t know what else to tell you. You have to make an effort, otherwise it comes out as whining, I’m terribly sorry to say. And I whine a lot, trust me. But when the openHAB team makes an effort to have a process where everyone can give feedback and improve on the documentation, code, application etc, in a transparent and standard way, you saying “I forget how to use it, I don’t use it often, it’s a different tool” I’m sorry to say, you’re whining. And you’re not really helping either because you’re not sharing your knowledge. So… if you want to improve your condition, why not create a best practice, step by step on how to login to GitHub and update openhab documentation. That way you know exactly what to do, you aren’t limited by your memory, and you can even go one step further: share the best practice in the community to allow other members who don’t know how to use GitHub to collaborate also.
That would actually be awesome, because I’d probably refer to it myself.

3 Likes

Well, we are talking about marketing here and potential hurdles for people not to use OH or not become part of the active community. Writing about myself as someone who uses OH since 1.8, has no technical background by education but a good technical understanding and is interested in such things and willing to spend some time (but also has more than e fulltime job, a quite big old house and a familiy) was just to show how high the hurdles are and must be for people being even more on the user/consumer side as OH requires really a lot knowledge around itself to become more involved.

GitHub is a great tool and is a great tool to help working on the docs for someone who is already familiar with it, or sees a use/potential that is worth learning it, far beyond correcting some typo in an OH doc. But for everybody else it is just an additional hurdle. And as easy it may be to really use it, when you overcame the first hurdle of getting a GitHub account, I bet there are lots of people who will - just emotionally as they expect things to be complicated - not even try.

But GitHub is just one example of many things within the eco system. For a lot of things you have to leave OH and make yourself familiar with quite a lot of stuff of the underlaying OS, and as much as I love openHABian, and though I have several LINUX devices in the house I am more or less able to manage, even after several years I still have to follow tutorials (often outdated or not really correct), search for hours on the internet when things are necessary like installing a MQTT server, connecting to a external database for persistence, and solve problems following advice I found on the forum. My LINUX knowhow is getting better in small steps as I do need it to manage not only my OH server (that is the difference compared to GitHub for me), but again: From a marketing perspective I can understand that people are afraid of the complexity and the necessary learning curve not only for OH but also for a lot of things around it and that they feel frustrated when they never feel real progress as they forget faster than they learn as there is so much to learn.

1 Like