OpenHab Marketing is Lacking

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

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.

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?


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

1 Like

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

1 Like

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

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

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.


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 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?


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!

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

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.


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


I read here in multiple places that attracting more users could override developpers capabilities to handle requests, issues, flood the forum. I see it differently : this could help onboard new developpers. The graph showing the decline of OH results in Google search is a real concern. Maintainers have always struggled in PR reviewing capacity this can lead users to quit because bug solving is too slow. I’m more concerned by the low number of developpers (and especially core maintainers).


Can you please point me to where things are at (relevant PRs and issues/discussions) with this?

Funny, how this thread turned in to the what OH is really good at: problem-solving. :slight_smile:

While improvements here and there are always great… the core issue is public visibility for “the product (OH) exists”, and “it’s easy to use”. Many users a lazy, new generation, point and click, no tolerance for a challenge; maybe I am pushing a stereotype, but my kids and grand kids have a short attention span (if any at all).

I guess, many new users simply want to set-up something, really quickly. And ‘this’ we (IMHO) should aim for.

Users who want to play more, will (eventually) realise, what has been said on this forum many times “home-automation is hard”, and are then prepared to dig deeper into the technology/automation system.

I don’t want to kill the discussion… I find it very useful. I also don’t expect developers to do the marketing.

And marketing (not advertisements), more so social marketing, is required. Maybe donations to OH can be made more visible. E.g., ask “like what you are seeing, please (or feel free) support the project”. I have not much of an idea of Patreon, may this would work for OH as well. These funds could then be used to sponsor OH on social media?!

As some said WRT developer attraction; how can OH attract developers if most don’t know it exists.

Also, as much as ‘fun’ may be the driver to people to develop, I am sure the inclination to develop for a cause is more rewarding when more people use the fruits of their labour. Browse on GitHub, and look for stale and abandoned projects; the less activity (in dev and download) the quicker they die — this is simply a fact.

1 Like

There’s also this WEIRD phenomena I’ve observed in my local community. If you charge for something, e.g. a regular activity, people would value it more, more would attend, and they would attend consistently, than when you do it for free. When it was free, nobody would turn up, and if they did, only once or twice. Once we started charging money for the exact same activity, we’d have to have a waiting list! It’s soooo bizarre!

I love the fact that myopenhab is free, but I wonder if the same thing applies here.

I think every update for Thunderbird, AdBlock, and whatever browser plugin comes up with a donate page.
And I have donated to quite a few application I use on a regular basis; which I wouldn’t if that donate page would not have come up.

IMO, no amount of sponsored articles / ads will change anything if when people come and check out openhab they get repelled because it’s too hard to use / understand.

Only the very technically minded people would stick around, and that’s probably only after trying out the others and getting frustrated with their limitations.

We see openhab from a different perspective because we already understand how it works.

As you know if you put a free fridge out the front of the house it will still be there. If you put $50 on it then someone steals it! Bizarre!

I still don’t know how it works and I have been using it for years.
HA was a pain I didn’t like the yaml and have to check the config and then have to restart it all the time. What was good was it did fire up and find stuff first time but after that it wasn’t that great.
I like Openhab because I can write sloppy code and have it indented all over the place and maybe it would work. :grinning:
My system is not fancy by any means and I just want to add “features” that I need and then forget about it.
I have used Mister house (perl) and Domotiga in the past and they were ok for what I wanted as well.
At the end of the day I don’t really care what is controlling the place just so long as it works and i am happy with it.
Openhab widgets are great.