OpenHab Marketing is Lacking

141

That’s just implementation detail. If we wanted it done, it will be done.

That’s really the gist of it. I’m not sure if “too little benefit” is necessarily true. The ability to rename things (even if that may cause some loss of data, e.g. persistence) is a huge benefit for usability, in my opinion. Especially for new users who don’t yet have any idea about what naming system to use.

It’s just a very tiny part of the overall user experience though.

This is an example of why it’s so hard to get “non technical people / a.k.a. the average person” for the lack of a better term, to adopt OH and as a result they go with HA: Because OH in general don’t value such “ease of use” factors for noobs and therefore don’t prioritise it. (oh dear I might get in trouble for saying this - I don’t mean to offend anyone)

The fewer users OH has, the less importance it has for third party to build support for it.

1 Like
142

Of course the openHAB devs can do it - they are highly capable and motivated programmers.

But what we can not forget is that everyone is working in their spare time and with their own focus and usage of things. It’s already a lot that people maintain, develop and improve things but in the end all we can do is ask and see if someone is willing to sacrifice their precious spare time.
And don’t forget that auto discovery is not the only feature that improves things, there are other features which have enormous impacts, too. Just look at the open github issues.

And I also think it’s not worth to spend the precious dev time on auto discovery.
It’s something I might only use once. Sure it makes a good first impression but I’d rather have improvements in areas I use more often and that affect openHAB users every day.

Additionally openHAB already became quite complex and more often than not the information all participants have is incomplete and it’s hard to get everyone on board because there is no unifying vision and architectural strategy.
Just look how the improvement of UoM Items went. @J-N-K provided a complete implementation, people who didn’t understand the complete picture made him back off, he provided a second partial implementation (which was inferior to the first implementation) and there were still people who didn’t fully understand the issue made the discussions run in circles. It was exhausting to the point he closed the PR. Only then the consent was “It’s better than nothing - let’s use it”.
And I get why there currently is no central strategy:
Why would I spend my free time implementing something that somebody told me - that sounds a lot like work :wink: .
So most of the time if someone wants to improve something most of the heavy lifting has to be done by said person and that only works to some degree.

I too have many great ideas (who hasn’t :wink: ) how openHAB can be improved, but in the end of the day the only thing I can do is either implement them myself or ask nicely and see if someone will do it for me.

Having the expectation that someone implements something just because I think it is a good idea (even if it is) is imho a little bit out of place.

5 Likes
143

As someone who has used OH since 1.6 I think this is an unfair statement. Usability is a priority and it is worked on and supported. But not every maintainer’s priorities are the same nor should they be.

Why do we have Things at all? Because prior to that configuring a connection between an Item and a device was awful. Bu no one had to implement Things and automatic discovery. It was done to make OH easier to use.

Why do we have MainUI? Because we learned a lot of things not to do from PaperUI. It’s not perfect but it’s getting better every release.

Why implement Blockly, managed rules, the marketplace, and all the rest? To make OH easier to use. To reduce the burden on end users.

But, why are certain things that seem easy in concept hard to accomplish in practice? In large part backwards compatibility with text based configs. But a sizable portion of OH users depend on text based configs and would throw a fit (and rightly so) if we simply drop the support.

I’ve watched OH grow and improve for a long time. I was all over the PRs and Issues that fed into OH 4. To say that OH doesn’t favor ease of use is simply not fair. But it is true that ease of use is not the only concern. There are many competing concerns that all have to be balanced. If ease of use were the only concern, you can bet that anything using Xtext/Xtend (i.e. all those file based configs) would have been ejected long ago.

1 Like
144

Since for some people file based configs are easier this is imho a nice example how the openHAB developers value ease of use and still drag an architectural burden into each new release.

While I agree with most of your post I very much disagree with that statement. It’s not file based configs which are a problem but the technology how they are implemented.
It’s often used interchangeably but no user cares if xtend/xtext is removed. They care if the possibility to textually configure openHAB is removed.

But please let’s not start the GUI vs text discussion again.
The openHAB GUI is awesome and openHAB textual config is also awesome and everyone can use what they like best and be happy. :slight_smile:

To add on: Most if the time the concept is easy yet the actual implementation is hard.
That’s why a concept is a concept: a simplification to make things easier to understand.

1 Like
145

I haven’t chosen my words well.

Your points taken and I agree with what you’ve said. What I meant was the “usability” from the point of view of brand new users, specifically for the purpose of attracting them.

Everything that’s been done especially on the Main UI side has been amazing for us!

However, we are here to discuss and explore what can / should be done to increase OH’s popularity. How hard or easy those ideas can be implemented is probably secondary. We need to at least set the goals and agree with it first.

As a very crude and inaccurate analogy: “If your competitors are going to the Moon and are extracting more resources that we all need, the technical difficulties of going to the moon shouldn’t be a reason not to make the efforts if our goal is to also go to the Moon”.

That’s perhaps the biggest difference here, between a non-profit, non-commercial group of enthusiasts working on building something for themselves, vs a commercially-driven product, with paid developers!

146

They will if the format changes and there is no automated way to translate between them.

But I think you miss a subtlety to my argument and we probably agree more than you realize. My main point is that there are competing interests in all PRs that need to be weighed. One change may be super great for core and the UIs but will require a reworking of most/all add-ons. That’s going to be a non-starter. Replacing Xtext/Xtend is one of those types of things. It could be a huge amount of work which makes it difficult for a volunteer to tackle.

I’m encouraged by the work that has been done so far with YAML and hope that we can get that pushed forward. Imagine the improvements if the code tab you see in MainUI matches the code you’d find in text file configs? The docs are simpler, both sets of users can talk the same language.

A side point I’m also trying and failing to make is “OH is too complicated” leads to “there are too many options” leads to “why do we have these file based configs?”. That seems to be the direction I see the arguments heading here.

147

This topic is moving a bit too fast for me :slight_smile:
Just two thoughts from my side:

  1. I’d rather keep the status quo than see openHAB dumbed down only to appease new users. We should all accept a steeper learning curve for a solution that offers us a more granular control over it. If that means that we must work harder when explaining then so be it.
  2. I was semi wrong about the automatic item creation. When adding points to a model we can already create items in bulk. Here the wizard @hmerk mentioned would help address the gap of knowledge, while also preventing the issues @rlkoshak mentioned of the auto creation of items.

But I’ll reinforce my idea of having an automatically setup dashboard at the thing level would help alleviate some of the “complaints”. And because I’ve enjoyed the idea of adding pictures I’m following suit.
Ps: I’m no artist, you’ve been warned.

move the thing menu content to a new tab called Configuration

IMG_8108
IMG_8108828×1792 189 KB

the tab Thing would be a dashboard, that as users add items, would be automatically populated by the switches, dimmers etc of said items. Users would immediately get a basic “thing dashboard”

IMG_8105
IMG_8105828×1792 194 KB

the “add points to model would benefit from a wizard explaining its function while also being moved to the very top because new users would simply add all points to the model, and have the dashboard mentioned before all populated in one go.

IMG_8102
IMG_8102828×1792 244 KB

IMG_8107
IMG_8107828×1792 235 KB

This would offer a couple of benefits:
We’re discussing mostly the moving of objects around, not the development of entirely new things.
There’s probably more interest in doing this because there’s an immediate positive effect: “add binding → add points to model → select all + add → thing dashboard instantly created and usable” which we can measure.

And for anything more complex we already have the semantic model which is being automatically populated by the points. Maybe there we’d need another wizard though.

That’s all I have now :slight_smile:
Ps please forgive me my horrible artistic skills.

1 Like
148

Hey guys. I read the beginning of the thread but couldn’t go through all of it.

I agree that OpenHAB needs better marketing or companies such as Homey and Home Assistant would get more market share and OH users would migrate thinking those systems are better. At some point, if more support is provided to them, they will become better.

At the beginning of the thread, people suggested to create YouTube videos. My idea is to have a page on the website where videos created by volunteers are showcased by “official” curators under different categories. Volunteers might be motivated to create quality content if they see it showcased on the website and it could be helpful for potential, new, and existing users as well.

I can suggest some videos from a guy who created great content and tutorials about OH

4 Likes
149

I know… and I’m not suggesting that. From an earlier post in this thread I said

my suggestion in that same post was

150

I am realising that this is a complex topic…

  • I don’t think any one here has or is dissing the devs or their work, or OH.
  • Open source is different from proprietary software.
  • HA is different compared to OH.
  • HA may have paid devs (I don’t know HA, but believe to have read here that they do), while OH does not.
  • OH has no strategy.
  • OH has no road map.
  • OH is lacking marketing.
  1. Is there a point of continuing to consolidate a shared view on the actual topic?
  2. Even if a consolidated view would come to existence, would it actually change anything?

I did some research on the nature of open source, it’s advantages and disadvantages, and it triggered my response, by saying, OH is what is based on what open source stands for. It’s like herding cats; if it gets to restrictive, a fork will be created, thus increasing potential solutions, creating more confusion for users, who will even more opt to go with what has been adopted most.

It was said fairly early in this tread: better software or systems do not ensure their survival or superiority. Proven in the real world umpteen times over.

My point is, if change is desired, an action plan is required. While I totally understand that the action plan is useless if no volunteers can be found to take it on; an action plan provides some (hopefully) agreed guidance about the steps forward (potential volunteers maybe include to follow to add the most value).

What I have learned in life, and forms part of my principles: every coin has two sides; or more universal, everything has at least two solutions. Which often forces a decision to adopt the lesser evil.

2 Likes
151

yes

You know why I say that? Because way back in 2018 I started a new user documentation thread which ran 66 posts. That thread started a discussion on improving the documentation and lots of folks had an opinion. Eventually that thread spawned new introduction documentation thread which turned into a github pull request which got merged and is now a part of the documentation.

Don’t get discouraged Max. This community is capable of talking things over and coming to a consensus, I’ve witnessed it. And cool individuals like Marcus L. who wrote most of that PR step up and make a contribution and it gets done.

2 Likes
152

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
154

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
155

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).

156

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
157

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
158

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
159

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

160

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
161

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.

image
image752×2066 142 KB

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.

image
image1472×1790 321 KB

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.