I would love to support and see my limited technical background an advantage to describe things to new users with an even more limited background.
And directly some ideas:
The homepage does not really show that OH has a vivid community and what are people do and achive with OH. I love the weekly newsletter with some featured postings from the forum. But to get this newsletter you have to subscribe to it first. How about featuring the postings from the newsletter on the homepage, too and write some testimonials, short overviews on already implemented solutions, have some pictures of dashboard users created with a short description what they are used for and rotate them, so that a new visitor sees, that OH is widely used and covers all aspects of home automation you can think of?
We could also feature and link to already existing tutorials (after checking that they work with OH4)
More complex would be âshowcasesâ, like already discussed in the other thread, based on a little set of often used bindings and addons that fulfill some typical basic needs, described and accompanies by a step-by-step guide leaving out everything not necessary to score the goal but always recalling that e.g. instead of a z-wave device a Homematic or Zigbee device could be used, too, and that the concept of OH has the advantage that, as we are talking about items in the end, the goals from this guide could also be achived when using another technology following it from the point where the necessary items are defined.
A first example was already in the other thread and I would just add some quite general things with a big impact on automation like a weather binding, the astro binding and perhaps google calendar.
Thatâs not whatâs being proposed here. Eliminating them or at least hiding them is whatâs being proposed. The first âPâ in @timo12357âs four Ps is âProductâ: i.e. changing the product, not the documentation.
Weâve asked for volunteers to create graphics for quite some time. If someone volunteers, please use Draw.io which saves in a non-propretary XML format that can be edited later but other developers as needed.
One thing we Finns get a lot of criticism for, is falling too much in love with the products we create. Then we aggressively wait for the customer to call and order the product. And this is understood as marketing ;-). This is quite typical for us engineers, we create the best possible product for our selves, but forget about the customer. This may or may not apply to OpenHAB, too.
I am a friend of free speech. But out of a lot of ideas there must be some consensus found if you want/propose something you cannot do on your own. We are now at the stage where ideas are developed and that is a good thing. The next thing is, to find some consensus. And this means, that a lot of ideas will not survive in their original form.
For my part I can say, that I do not want to change OH in general, leave well thought concepts that have a meaning and that can be communicated as a big advantage of OH over other solutions, ⊠And at least I want to hide/delete deep drilling documentation. The only thing I want and would support besides updating existing docs is adding a new level of documentation/marketing documentation that allows a new user to generate quick wins, without the need to go too much into technical background and details to get him or her infected by the OH virus, so that he/she sees value in investing more time to get into the technical backgroud, concepts, details, not so often used bindings, âŠ
I am more on the writing instead of the pictures and I never uses Draw.io. But I will have a look at it.
Hi Rich, let me assure you, despite the fact that changes to openHAB are discussed in the other thread (and I have also mentioned this in my first post here), it is not my intention in this call of action to discuss changes to openHAB. From a strategic point of view, the more a technology develops further and enters the mainstream market the more you need to keep your product in balance for your new target users. From a general point of view I understand Timo but this is what I do not want to do here in THIS thread.
Letâs focus what we can do for openHAB as it is today.
I tried to give an answer which really sounds impressive, but I canât
To me, it is simply everyone who has a reasonable amount of things installed in his house/flat
Home automation solution that can work with, and combine the system from multiple vendors, such as Philips Hue, Alexa, Google, Homekit, Ring, Nest, Tuya, Tesla, BMW, Mercedes, Fronius, LG, and more, and connect them into one integrated system. (OK this needs to be shortened perhaps)
Runs on Windows, MacOS, Linux, Raspberry Pi, Docker, Synology, etc.
Additional points:
100% Free, no monthly fees. â this is a USP against Home Assistant.
Free Android and iPhone / iPad Apps
Fully respects your privacy. GDPR compliant. No telemetry or data collection, no ads, no hidden backdoors. No hidden agendas. Completely open source. It is built by home automation enthusiasts for the love of home automation. Not for profit. â This is one of the things that set us apart from Home Assistant!
Integrates with over 2000 brands and systems.
Note one of the things they have out there on comparison sites is that HA integrates with over 2500 or some such numbers, basically saying that openHAB supports fewer things than HA. This may be true, but we need to clarify this because this ânumberâ is probably somewhat important in making a good impression to uninformed people.
Need to throw more things in there.
Support UI Based Rule creations for creating simple rules (when X happens, do Y) as well as using scripting languages for more advanced automation: Blockly, JavaScript, Ruby, Groovy, Python, Java, Node-Red. â also a USP against HA
TWO main things about HA that people prefer over openHAB:
Ease of adding things - they just auto discover most common things and appear on the first install.
Sorry if I am being a bit unrelated here. My works require architects engineer supervisors etc sobthere is a structure also we have a plan and also deadline for each part of the project. So who will be the architect that designs in ruff the main concepts, who is the engineer that will will do the plans based on the architect, and who is the supervisor that will take the plans and divide them and makes sure they are implemented by the volunteers?
Sorry for the rude description.
?
If yes, please letâs exclude tasks about what to change in openHAB. This will be too much for this call to action (and there is already a lot to do).
If it is just a set of new and nice widgets, thatâs something different though.
Exactly what I hought about their 2500 integrations: Type in MQTT. It appears 32 times. But it does its job.
And have a look at their âSwitchâ category. They have listed every interface . Even AVM, camera vendors and vacuum cleaners are listed.
âThe Othersâ (probably?) donât mention this ânumber of protocolsâ, so itâs not comparable anyway.
Donât need to overcomplicate the point. Itâs already jargon-dense enough. Some jargons are beneficial if not just to impress without scaring people, but some arenât.
@rlkoshak Rich,
who is/are the maintainer(s) for the website and documentation? Before we start providing suggestions I think it makes sense to get consense with the responsible people prior to the work.
Exactly. The goal of this thread is to do a better job marketing openHAB exactly how it is today.
The openHAB nomenclature, Things. Items, channels et. are there for a reason, they are actually there to simplify and have benefit. My idea is to do a better job of explaining the nomenclature. In fact, I think the nomenclature should be made so obvious that even a first time user encounters it immediately and it is explain. Your brand new Hue light bulb is a âTHINGâ. Your motion sensor is a THING. To do anything with your new THING you need a ITEM. To hook you ITEM to your THING you need a CHANNEL
