Yes, sorry. I was trying to make a point. It wasn’t directed at you personally!
That doesn’t look easy to understand.
For instance, a Channel is not actually either of the things you describe it to be but is a conduit or pipe through which pieces of information of one particular type can be sent.
For example (and I love examples), a channel may send and receive information about the colour of a lamp.
Sending the colour information to the lamp will change the colour of the lamp.
Receiving colour information from the the lamp will tell openHAB what colour the lamp currently is.
(That’s a bit verbose but it’s the idea I’m trying to get across).
I think that’s clear. But the point of the original post was to try and attract new users - who may not have much knowledge, but may one day become the programmers etc of the future.
That’s not exactly what I meant, obviously. If a tech guru says something it easy, that doesn’t help new users who are having trouble understanding it in the slightest.
As I wrote before, I’m finding much of the documentation difficult to comprehend (it’s much better than it used to be).
I’m learning by trial and error and so probably am not much help in that respect but I have proof read many technical manuals authored by someone else to ensure that both the instructions within can be followed, and are safe from a electrical-safety legal point of view.
I’d be happy, in the first instance, to volunteer to point out what I think is missing and what could be added or changed.
People telling me that it’s easy and I should just “get it” is neither constructive or helpful.
Looking at those brands you mention, they all started with very easy to setup, but very little “smart home”. And from there they expand. (more or less).
By doing so, they get hold of the “basic interested user”, very easy.
Thats one thing openHAB cant do, unless openHAB make a very easy way to set up the system, and at least get the very same “very little smart home” result.
The keyword is easy.
But openHAB is not easy to setup. And everytime I see debates like this, its always explained with, (by the knowledged users), thats because smart home isnt easy.
Thats makes it a rather serious paradox and dilemma. And I believe the cause of openHAB status speaks for itself here.
Some day someone may spot at least one solution in this, which could make a big difference, simply by focusing on the keyword, “easy”, and “how to get started”.
But as long as there are people in here continuing telling users, “all you have to do is read the doc”, knowing the docs are not easy to read/understand, because “smart home isnt easy”. Then there is yet another serious paradox.
So to open the Raspberry Pi Imager, select the openHABian Image, flash to a Micro-SD-Card, put the card in a Raspberry Pi and get the power on is too complex?
(That’s all what you need to get openHAB up and running)
That is the missing link, I was looking for. Thanks Rich. Will do this tomorrow.
No, it is not. Unfortunately, we are not precise in our wording. Setup for one means installation and for others it means installation and customisation (adding bindings, things, items, create rules). The second part is where new users struggle with.
Discussion is good, but please let me shift the focus back on our actions. If readers or posters wish to contribute for a plan to attract new users and want to coordinate your work with other volunteers, this is what this thread is for.
Please drop us here a line, and I‘ll add you to our list of volunteers. There are already 5 volunteers. You’ll find them in post number 2:
Even though discussion is still ongoing, I want to move forward with our actions.
In post number 2 I will add all actions which are currently ongoing.
As mentioned in the first post I will start creating a New Users Guide this week for our home page which covers in an easy way and less technical language the whole „onboarding process“ from installation, to adding bindings/things/items and finally end with GUI rule. This guide will by intention not cover various possibilites (that is already done by our existing doc). It will cover just one, which is the easiest one.
By intention I want to create this for our home page and NOT for our documentation.
Margaret Mark and Carol S Pearson in The Hero and the Outlaw talk about the best brands using archetypes or personalities.
openHAB has 3 possibilities
Ruler - take control of your life
Hero - Make it easy and take away the pain
Magician - Wave a wand and your problems go away.
The bindings and integrations make Hero and Magician possibilities but the docs need be better. Often they are actually too specific and make it difficult to generalise.
The archetype gives you the ‘hook’ for the messaging
Sorry but it’s not Philip Kotler’s 4Ps it was McCarthy in the 60s. The 4Ps have been 7Ps for 30 years when People, Process and Physical Evidence were added.
The Product is Great - it does the job very well
The Price is Great - it’s free
Place is fine - download from internet
Promotion - needs work
People - great support and development infrastructure
Process - Ooops
Physical evidence - Great configurable in the way you want (provided you understand the Process)
Bear with me with this story.
The main ‘competition’ is Home Assistant. I have a Wallbox Pulsar EV charger. It’s supported in HA (but not in OH). I downloaded HA onto a Pi (but downloaded wrong version - too many options without explanation of what they are). Finally got it to work added the Wallbox integration - spent 2 days trying to get a rule to work. Send the Wallbox data via MQTT and created a rule in under a minute in OH.
We constantly beat ourselves up about what’s not good about OH and ignore the really good stuff. One of my gripes is that I wish we could grasp ladder logic - home automation often time isn’t sequential but all the programming systems are. For instance setting a time window for heating and only turning on the boiler if a sensor requires it is easy in ladder logic but a real pain in OH.
To fix ‘our’ marketing we need to talk to customers. Find out what their experiences (and pain points) are. Then use Pareto analysis to fix them.
Ask yourself, if that procedure is better or worse, than what it takes to add Philips Hue or even Homey.
Alot of people dont even know what a Raspberry Pi is. A term/expression such as an “image” is something they´re watching on a screen.
You´re asking the wrong person.
For me its NOT too complex. But is it people like me, with several decades of experience, which a marketing of openHAB should adress?
Unfortunatly, this is only a small part, before openHAB is actually given any results at all. You and I know this. A new user dont, at least not without having to deal with the documentation first.
Again, try look at some of the references mentioned.
A not knowledged person can install and setup Philips Hue and even Homey Bridge within a very few minutes.
After setup, Philips Hue app will have found whatever Philips Hue compatible devices by itself. All the user have to do, is to add it to a room. Rooms are even predefined. And the user is good to go.
The same goes for Homey Bridge, but Homey goes even futher and find almost whatever is on the WiFi network, all by itself.
In openHAB, the user has to deal with bindings, things and items, after havning openHAB up running. And even by then, there is still no results, as a kind of UI is required as well.
Why would anyone go through the hassle with openHAB for adding lights in a kind of smart home manner?
The question is:
Which kind of users do openHAB wants?
That is what the marketing should be focusing on. Without this definition, the marketing will become wrong from start, and it will change nothing.
I (personally) do not complaint about openHAB being too complicated.
I just state, that the way openHAB is build, it requires more knowledged (and/or alot of patience and reading) to get openHAB up running, even with simple “smart home” devices, such as Philips Hue/WiFi/network devices.
To change this, developers of openHAB needs to focus on, how to make the startup/setup easier. Without doing so, openHAB will be adressing a limited amount of people. And it would probably not need anykind of marketing at all, as those with interest will find openHAB by themselves.
That my opinion. I dont ask you to totally agree, but at least think about it.
That‘s all correct and that professional approach applies to corporate companies, who have their own staff and where you simply create or change the roadmap and your development team starts developing against the new roadmap.
That is not our environment. Even if you succeed in getting the customers‘ requirements or pain points, then what happens next? Who will develop?
I encourage you to create another thread for this, where new requirements can be discussed.
This thread already has applied the pareto principle: Let’s focus on the most urgent 80% of the things we can change easily, and leave the 20% (openhab changes) for later. Let‘s put a joint effort into bringing openHAB as is today closer to non-technical people.
I think openHAB should focus primarily on people who have some level of technical “competence”, or at the very least, interest. a.k.a “Geeks”. Someone who likes tinkering with technology, therefore would have heard of “image” / raspberry pi, etc. There’s still some more work to be done to make openHAB easier, and therefore more appealing to use even for this target market.
Targetting completely non technical people, IMO is going to be very hard on many fronts, but may be do-able once we’ve smoothed the “product” out for the technically minded target audience first.
A valid point. We need to define a certain level of knowledge required for new users. We cannot start from scratch explaining new potential users what wifi is, an IP-address or raspberry Pi or an image.
Specific and actionable issues are the best way to do this. “This section isn’t clear, make it better” really isn’t actionable though so be prepared to come with concrete suggestions.
We’ve done the best that we can with the docs and tutorials. “Do better” without details on how is kind of an FU to those who have contributed up to this point.
Just to be clear. OH could be made very easy for some smallish subset of users. But if your requirements fall outside that subset
OH as an organization cannot sell preconfigured hardware like that. I imagine some third party could do so if they wanted but care would have to be taken with the trademarks.
openHABian is our answer to a “preconfigured” system.
I’ve on my long list of todos to create a rule template to implement a generic state machine. I’m not yet convinced it will make it simpler though.
As for the time window part, in UI rules the “But only if…” section of the rule was made for this. You can define a time range there fairly easily now:
The reason Hue can be that simple is because they only have to worry about Hue as a technology. Homey is that simple because it is limited to only a hand full of technologies, all of which can be auto discovered.
OH has no such limitations.
And there is an issue to figure out how to have OH discover what can be discovered during the first run wizard too.
This is why the semantic model exists. Could it be better? Yes, but when you add semantic tags to your Items you get a UI for free.
Because they want support for a technology that Hue and Homey doesn’t support or they want to do things that Hue and Homey can’t do.
I keep seeing this stated as if that isn’t what the developers are already doing.
Yes, sure, but my point is: Smart home is not and will not be easy.
If even a plug’n’play solution (of course with a dedicated platform) is MUCH too much, smart home may not be the right thing to starrt with (and to be fair, it’s not easier to do it with one of the other Open Source solutions as well)
If someone wants to dive into smart home, he/she has to dive (and get wet).
A single HUE lamp is NOT smart home.
Some bindings may need to be changed to improve new user experience. For example, I have TP-Link plugs, Kasa and Tapo, for the Kasa devices the binding discover their name (as specified in the Kasa App), whereas for Tapo devices the binding discovers the device type but not the name (already reported the issue in the Tapo binding thread).
Which is why its important to state, which kind of users any sort of marketing will focus on.
During setup, OH does have limitations. Even getting as far as to auto discover, the user has to go through a lot of hassle. Remeber, a Rpi is a hassle for those who do not know what an Rpi is.
We know what Rpi is. But we´re (hopefully) not in focus for a marketing of openHAB.
As I said, Hue has the advantage of focusing on a limited “smart home” and its specific devices. Same goes for Homey Bridgde, however Homey has a few more interfaces. Thats why its easy and all can/will be done from a simple smartphone. There is not Rpi, no SD-card, no “Image”. Its simply plug&play, with it limitations ofcouse.
Then the marketing has to be concentrated on those potential users. It has to lift the users requirements/requests.
Thats not what I said, or at least not what I meant.
I meant that, if openHAB is suppose to marketing towards those “not knowleged” users, then the developers has to make the installation & and startup procedure alot easier. Not doing so, cant be rescued by a marketing. And marketing wont be able to change the potential user segement itself.
I dont critizise anyone. I just say what the reality is.
If marketing is suppose to change anything. It has to define what kind of users to focus on.
Atm openHAB itself has defined this. Its purely for already knowleged people, mostly.
