OpenHab Marketing is Lacking

41

No but all examples given here, while true, apply to economic battles and wins. While there’s overlap, that doesn’t apply too much here.
Open Source software is about enthusiasts doing this for free, for fun, with and in itself.

Then again yes, popularity will affect developer “availability” and user base figures in the long run.
And yes, the thread title is about right. But don’t expect devs or volunteers to take on that.
Maybe the foundation could take a little on getting more and more directed PR out? Maybe there’s some € left to pay some clickworker or agency to do it for us ?
Have them get in touch with some popular “comparison” alike websites and YTers. Ensure they propagate at least non-biased statements based on current not outdated information (see bad examples somewhere up still talking about ESH. Those to write that stuff have never even looked at OH).
Note new developers not necessarily stem from an enlarged consumer-minded user base but can be professionals, too. Yes ESH was a debacle but I’m not talking about companies to sponsor OH but skilled and open-minded individuals that work for companies in the home automation area.
Address Industry interest groups, too. Like tell KNX installers how much more they can get out of bundling their system with an OH server to provide stuff they cannot. Tell the electrician and HVAC guilds how you can benefit from hooking your solar plant or heat pump to an OH server.
In short, go out and do some active marketing.

42

We do compete about people’s time, attention and commitment. We fight for people who want to publish their stuff and receive some positive vibe from somebody on the other end of globe.
If we refuse to participate in such contest, because we may, we have to accept that this forum will be a shrinking community. We need also to acknowledge that over time them, not us will be a first pick of hardware suppliers to publish integrations of their equipment forcing even larger set of people to re-evalute their use of openHAB.
Can you imagine i.e. control4 getting into partnership with HA to serve certain markets? I can’t currently think of such thing, but it doesn’t mean that it is impossible in some future.
Use and adoption of open source projects by commercial entities is based on facts and numbers, not on beliefs and assumptions.
As a developer I am entirely happy with technology excellence, however as an user I want to have a winning solution which will last as long as my house.

Correct, nothing stops you from having both and having benefits of each as well as troubles. This discussion however, is not about who runs what, but about whether people consider OH at all. Whether they have a chance to find OH and give it a try.

I don’t think we are on sinking titanic yet, however descent of great empires and amazing technologies starts unattended. If you look at history of countries which are gone in certain form (“The empire on which the sun never sets”), the hardest part is noticing when it starts to loose power. Its a historians argument to find which decision began it.

We see some evidence of openHAB having lower numbers, fewer active community members, less fresh addons over releases (I suppose), fewer active contributors on github compared to competition. Adding all these things together we see that the best time is over, probably by couple of years. Its questionable if we can regain popularity as it is not clear if OH project wants to be a mainstream or not. Whether publishing a set of nice YT movies is going to help - I don’t know. I guess it may not, because it will be lost within information storm we experience every day. Driver of people attention are social media, who steer our emotions and guide us where their algorithms find most of the hate or “like” clicks. This is a fight which happens every day, not every release. :confused:
A playing orchestra on titanic was helpful but did not prevent catastrophe.

7 Likes
43

@splatch - excellent write up. I couldn’t agree more.

It seems that first of all, we need to agree whether having more popularity and userbase is what we want. It seems that people are divided on this. However, to my mind, not focusing on having a large userbase is detrimental to openHAB’s future, as has been explained by several people above.

About marketing.
The question is whether those articles and youtube videos about Home Assistant were paid contents. If they weren’t paid contents, then going out and paying for content is fighting the wrong and hopeless battle. We should ask first, why those people wrote articles and created videos favouring HA. What can we do, as a community, and as a product (openHAB) to make people want to prefer openHAB? Because content creators will create contents that are mainstream and their ultimate goal is exposure / clicks / views. It’s a bit of a snowball effect.

It may be that we’ve already “lost” the critical mass and the only way forward is downhill, like Windows Mobile vs iPhone. But if we look at Android vs Apple, what did Android do to catch up?

I don’t know the answer. My only idea is to look through the current complaints about openHAB, especially from those existing videos / articles, and address them by “improving” openHAB without us being defensive.

So they say that openHAB is hard to understand? Instead of arguing, take them at face value and self-evaluate. I’m sure there’s some validity to their points and there is always room for improvement.

So they say openhab’s documentation is lacking or bad? Perhaps that’s true, despite what we may currently believe.

Maybe once we’ve addressed the “issues”, marketing will sort itself out, because content creators will create contents for their own benefit without anyone asking them to do so.

2 Likes
44

After reading a lot of folks comments, I think it is important to consider that prior to V3 when the new Main UI got rolled out, openHAB wasn’t really non-technical enough for mainstream uptake. It was something only a technical person would pursue because they could see the potential.

I think the help document are great. For an open source project, the help docs are comprehensive. Folks just don’t want to read help docs, they wanna play. (learn by doing?)

Do we want to appeal to a mainstream user base?
Do we want non-technical people to use openHAB?

As I’ve read this thread, I keep popping over and looking at the docs.
Should we just omit the stuff about file configuration? Try to make the starting out and intro less… wordy?

I think a first time wizard would help wider adoption, I think a lot of people check it out then get frustrated.

1 Like
45

Fair enough, that’s good advice in any situation. The number 1 complaint I hear from everybody I’ve nudged into going to openhab, and who later went home assistant, wasn’t about not abouthow complex it was, but how manual and specific everything is.

In one situation that stood out to me, we were discussing about Shelly devices, and the conversation went like this:
“So in openHAB I add the binding, look for the device, add the thing, then I check the channels, need to create the items, and if I want them in the semantic model I have to add the tags or location to them? “

Me:” yes, sounds about right.”

“In home assistant after adding the addon everything was already there, all of the field names already there of my devices, directly in my dashboard.”

All of the conversations always revolve about how home assistant has pre made dashboards or views or when you setup something the fields are auto populated.

Edit: sorry for the interruption, baby cried. :no_mouth:
As I was saying:
while I don’t really agree on “copying” simply for the sake of the copy, we might stand to benefit from reading those “complaints “ and turning them into improvements. Make the semantic mode semi automatic by auto placing stuff there. If the location is missing, add a pop up that says “oh want this to appear in the semantic model? Don’t forget to add a location!”. We can “unlink and delete” all items in channels, but why can’t I create them all together? And if I can create them all, then ask me “would you like all of the items created? Will they be in the same location?” Yes - “office” boom items in the semantic model, in the office, created.
This is just a rushed example which I think would put new people looking at a dashboard much faster than currently. It just might be what users want.

But of course, any changes or improvements need devs :slight_smile:

1 Like
46

I haven’t ever really tried HA
Can folks who have briefly discuss differences?
So it sets everything up for you and you can create automations but you are limited in what ways?

47

There are plenty of users here in the forum that chose openHAB specifically for the file configuration and having chattet with quite a few openHAB users (I’ve convinced quite a few colleagues to try it out and use it) the issue was never with how the configuration was done. I think the overview sums it up quite fine although imho it’s a bit biased towards GUI configuration.

Most of the time the users (I talked to) face issues it’s because of the confusion around Things, Bindings, Bridges, Channels, Items and the semantic model. Having spent quite some time with openHAB for me it’s clear what is what and how they interact but apparently this is a huge issue.
I think what would help tremendously is a small image in the overview section which than could be expanded to show the flow of an item update and an item command (another huge source of confusion).

I’m not very good a graphics design but if someone would like to do the graphics part (i.e. the heavy lifting :wink: ) I’ll gladly contribute the ideas and create the PRs and text so it can be added to the docs.
So if someone wants to work together please send me a PM and maybe we can contribute and improve the docs for newcomers.

For me it’s like
“So in openHAB I add the binding, look for the device, add the thing, then I check the channels and then see the rollershutter channel is missing because the thing initialization has been completed but somehow faulty and the binding does add the channel dynamically. Then I restart openHAB and the rollershutter channel is finally there but now the Flood sensor channel is missing because it’s a battery powered device and thing initialization can take up to multiple weeks because it’s also flaky.”
Adding thing channels dynamically is the worst!
If you are a binding developer who is reading this please don’t create the thing channels dynamically based on the thing initialization, rather make it possible to configure the channels (i.e. like in the MQTT binding) and automatically create this channels configuration (once).

For clarification:
I’m in no way intending to throw shade at the Shelly binding developer(s) who is/are doing are great job and try to be and are helpful, but depending on how things are implemented in the binding it’s impossible for a newcomer to debug issues and it provides an inconsistent user experience.

I’ve tried switching to HA when OpenHAB2 came out and even did a short write up of the differences (which I can’t seem to find). This was some time ago so things might have changed but I found HA much harder and the docs more lacking than the OH docs.
It does auto generate lot’s of stuff which makes it very easy to get started but doing “advanced” stuff is exceptionally harder.

If the goal is to make OH more appealing then that’s the way to go (imho):
Automatically generate stuff that “just works” which can be edited later on when the user is more advanced and has better knowledge.

1 Like
48

Don‘t get me wrong, but this can only work up to a certain point. How should (would) openHAB or HA know what a certain Shelly device, to stick with your example, is controlling ? Is it s light ? Is it a socket ? Is it a rollershutter ?
The answer seems quite simple, both can‘t, expect the rollershuter, but that‘s a different story.
So yes, it could be achieved for some „specific“ hardware, but not for all this generic things.

1 Like
49

You are absolutely correct and I’m not saying that that’s the way for “everything”.
But What I see is that on the “other side” people/devs work more at a device level, so each device has its own “widget” pre configured, and not per binding. If you configure a Shelly 2.5 (oh god I might have made a mistake in referring the Shelly. I’m in no way complaining about the Shelly binding, I just used that example because it was the topic of my personal conversation for comparing both applications of the dev is reading this please forgive me! You’re doing gods work!.), then there would be a “widget “ or “template” made for that specific device.

I think that the best way to describe (without being too wordy, otherwise we might as well hop on discord) is, imagine that once you add the thing to OH, that inside the thing you have next to the “channels” tab, a “dashboard” where all of the channels/items are already there. You don’t have to create anything, all of the functions are listed, created and ready for use. Eventually you’d even be able to drag and drop it to a dashboard, but, for a new user they would immediately jump from “configure binding, find thing” to → “open created Thing and see exposed items ready for use”
That simplicity is, I believe, what some users are looking for.
Now I’m not saying that channels and items are not needed, what I’m describing is that they might just as well be automatically created. If they aren’t needed, we can delete them. The widget could be tweaked by the users. But for that first interaction with a new user, things would seem quite simple.

Doing this at a binding level would not work as you said @hmerk , or at least it would require an ungodly amount of work. I think that all of the pieces are already available. We have the templates from the marketplace. We have a community providing templates for different aspects of the system. What we would need is a place to connect those with a thing, automatically. (I’m also in no way saying that it’s easy :slight_smile: but I do thing it makes sense if explained like this.)

hmerk
How should (would) openHAB or HA know what a certain Shelly device, to stick with your example, is controlling ? Is it s light ? Is it a socket ? Is it a rollershutter ?

All of those are relays, so just an on / off switch. But I agree with you, I’m over simplifying. I can continue using the Shelly 2.5 as an example, and from what I can think, it doesn’t matter if I hook it to a light, a rollershutter etc. I could always go to the item and change the icon, or the type. But the core basic functions would already be controllable. I really think that that’s there we may have a gap in functionality.

50

All good, I know Shelly was just an example, but it describes the difficulties very well.

What just went through my mind, and this is just an unfinished idea and sorry for going off topic now…

What about having several wizards, first one to setup the semantic model for your home, generating floors and rooms, like we had with Kuba‘s homebuilder in the past.
Second a wizard that can be opened from inbox for autodiscovered devices, asking some questions about what to put where and create everything needed…

How does this sound?

3 Likes
51

Tie them together with a wizard that launches the model wizard then the inbox wizard, so they just keep clicking Next

1 Like
52

As said, just an finished idea, we should continue this on a separate topic….

1 Like
53

This was exactly my experience with HA. I found OH1 when I was first starting (I think I had just two Nest thermostats and a couple of wemo outlets and a sonos or two, something like that). I took one look at the textual channel configuration at the time and decided that was more effort than what my meager goals were worth. I tried HA and it found my outlets immediately, found my Nests and sonos immediately and added them all to a (PITA) dashboard and stopped there. Everything else I wanted to do to customize my system to my and my family’s usage was next to impossible. Despite have some skill at understanding technical material, I could barely make and advanced headway with the what information was available.

I came back to OH around 2.1 and found that yes, the initial effort was 3x greater, but the possibilities were 30x greater. That’s one reason why I don’t really see this as a competition with HA. In my experience, the two systems are just intended for different user bases. HA => I want to achieve simple easy out of the box things and not really have to think about it ever again because I have other primary interests : OH => I have some fairly custom goals in mind that are unique to my situation and I don’t mind/enjoy opening of the hood and tinkering. I’ve always been in the later camp with just about all of my computing endeavors, so it was a no-brainer for me once I understood.

This is a very good statement of the other reason I just don’t see this as a “competition”. If OH’s continued existence depended solely on market forces then it would be important to convince users that OH was a better fit for all their home automation needs regardless of whether it is true or not (that’s marketing). Then the devs would be so flooded with complaints about this thing or the other thing from users who couldn’t understand why OH doesn’t fit their needs that they would quit left and right or simply begin ignoring 99.99% of user input. The forums would be so flooded with questions from users who simply want a solution with no effort on their part that forum volunteers would have an impossible task actually connecting with the small minority of users who they really could help. It’s been so long, I can’t say with any personal certainty, but the reports from users who have recently switched over from HA somewhat line up with this scenario.

So again, I think what we do have to do a better job of is helping people understand 1) which user base they have a stronger affinity for and 2) which system may fit that personal affinity. I agree entirely that we can’t do that if we don’t make the very first impression of OH slightly more inviting and easier for the potential user who is shopping around all the options for the first time. Many of the ideas presented here do fit that goal. However, it would, IMO, be an equally bad mistake to give a false impression during that early use of how OH truly works and what its philosophy is. Then we loose more in the end when a multitude of users rage quit and spread negative publicity.

Despite being a quarter of a century old at this point, there’s a lot in Neal Stephenson’s essay on the philosophy of operating systems that’s still relevant today and in particular to this conversation (not to mention it just being a fun read).

1 Like
54

This is a thread posted by a guy who joined the openHAB community August 12 this year. I really think his first post is the journey of a first time users perspective. Give a read if you like, it’s interesting

This is obviously a bright techie guy.

Now we’re talking :+1:

ok… so anyhow

The nomenclature can’t be expected to be universally understood
To use openHAB, you must understand these Things…
are a metaphor
for a thing, maybe a lightbulb, maybe a web service, maybe the sun in the sky
And items rather Items… only live in openhab land, and there are only a few, and they all act the same. A switch turns on and off
Channels are the glue
And none of this matters if you need a binding first
Why do I need a binding? I don’t know
So… I have a light bulb, I have an internet browser, I find openHAB
go from there.

1 Like
55

Thank you for your compliment @Andrew_Rowe

Yes, this was the hardest hurdle to understand as a beginner: where to really start.

I read for about 30-40 minutes of the help section, trying to understand the architecture before giving up and just ‘trying something’.
I took about 3 hours to make a custom http thing to talk with my Tesla charging system (no authentication required).
The same process took about 5 minutes after I found out about bindings, etc for my Tesla Gateway (which is far harder, due to the authentication requirements).

In my very humble opinion:
A visual workflow showing where to start to get to automating something like a light bulb would be really helpful.
For me, ideally, it would walk through the process of creating, connecting, controlling and then coordinating (with other things), step–by-step. The final step being able to see the state and status of the thing and access is from any device.

3 Likes
56

No but the docs need a huge edit to emphasize, and in some cases cover at all the UI way of doing things. We don’t want to eliminate the text config docs though.

I started a complete rework of the rules docs (and if I’m honest I just came up with an outline and @florian-h05 did most of the writing thus far). That work has stalled as my time has been taken up elsewhere. Volunteers are most welcome!

And I want to emphasize what’s been said over and over on this thread. It’s not enough to recognize the problem exists. It’s not enough to come up with a solution to the problem. After all that if we still come to “someone should do something!” and that someone isn’t you, this is all a lot of discussion that will go nowhere.

This whole discussion was had before a few years ago. A couple people, including myself, stepped up to try to do something about it. I think neither one of us have the chops for this type of work and I certainly didn’t enjoy it and it kind of died. But at least I can say I tried.

Please use Draw.io so we can check in the original non-proprierary XML and future maintainers can update any such diagram in the future.

Concepts or Getting Started? Concepts should be agnostic and not really emphasize either and Getting Started is deliberately UI focused. It’s already too long and it would expand by at least 2/3s to cover both at the same level. Drive the audience for Getting Started should be new and non-technical users, focusing on the UI makes sense.

Almost all the bindings create the channels dynamically, unless I’m not understanding something. Do we really want to force end users to manually create and configure every channel for something like Astro or OWM? Wouldn’t that be a step backwards?

2 Likes
57

A+. Unfinished idea it may be, but a good direction. This would bridge a lot of the knowledge gaps.

Man we could really use a discord server to discuss some of these “off topic but relevant “ themes :slight_smile:

As for the rest of the conversation, I think that it’s going on a healthy route, keep it up gang!

58

I am talking about adding the linkable thing channels not during thing creation but about adding them during the thing initialization. I’ll try to make an example to make my point clear. Feel free to ask if it’s still unclear.
If you add an astral thing “sun” it always has all the linkable channels for a “sun” thing and this is fine (e.g. azimuth and elevation).
If you add an mqtt thing and configure the channels the linkable channels on the thing they are always there. Even after a restart as soon as the thing is created you can link items to the channels because they are immediately created based on the configuration. That’s also fine.
The shelly binding starts the thing without channels and then tries to communicate with the device and only then creates the linkable channels depending on the communication with the device.
That’s bad because

  • for battery powered devices it can take days to weeks until the initialization is complete and the linkable channels are created. If you have an item properly configured with a link to the channel it will not work because the channel points to nowhere. The only alternative is wo manually wake all devices after an openHAB restart (which is not feasible tbh).
  • If something during the initialization phase does not work you might have a thing with incomplete linkable channels. For example I had a roller shutter thing that doesn’t have a roller shutter position channel but the thing was online as expected. I only realized when some of my shutters didn’t move in the evening.
    Or I had a smoke alarm which properly reported the battery level but not the smoke alarm because the smoke alarm channel was missing (thank god no real fire). The channel just wasn’t there but the thing was online.
  • It results in non-deterministic behavior. If we both configure a thing exactly the same it will result in different linkable channels and thus in different behavior for the same device depending on how the device responded. So if your device responds with A and mine with B we can still configure the same from an openHAB perspective but the available channels will be different.
    This makes trouble shooting a nightmare
  • The whole initialisation procedure repeats with every openHAB restart
  • It’s inconsistent with other bindings (e.g. astral, mqtt) which provide different behavior
2 Likes
59

I wasn’t aware that was possible and I tend to agree this seems suboptimal. It’s not likely the Thing is going to change once it’s fully discovered and interrogated so why doesn’t it cache that information and need to redo it on every restart.

However, if the devices/channels can be discovered, the binding should support that I think. Anyway, this is getting off topic and I now understand what you mean.

2 Likes
60

@odinhab I think your forum post would be a good script for a YouTube video :slight_smile:

2 Likes