But that’s exactly what we have now. If you have a new install you’ll have the opportunity to select your bindings, set up your location and such.
That’s right. What that selection step could use, though, is some way to search by manufacturer and/or product name. Same applies to the web site: the addon page allows searching, but e.g. entering ‘Roborock’ yields no results, even though Roborock vacuums are supported by the miio binding.
1 Like
This is a brilliant suggestion!
Hi Maniac, in this thread
we are looking for volunteers who have good ideas and contribute for a „marketing“ plan as well as executing the plan.
You are more than welcome to join with your idea(s).
1 Like
I think that would be a great first step
done once when?
Quite often when a very first time user is very first trying to use openHAB for the very first time.
And what if that first time user, someone who read or saw something about openHAB and decided to give it a try successfully installs the program, gets to the main UI and spends the next hour trying to figure out how to make their smart light bulb turn on and off
don’t believe me? just check the forum. example
Uhm…
you know what may make OH easier to use over time is to implement OH as a Matter controller in the core of OH. Then the scope of writing a tutorial is much smaller,
Binding discovery and non-Matter devices would be not that important as they would be an “advanced use case”.
The effort for users to be able to promote OH would then be easier for grass roots marketing.
OH could highlight it’s independence and freedom from platforms that are controlled by companies
looking to monetize the platform. “Free, always been free, always will be free, free from companies looking for money from you”
To me, that sounds like an awesome marketing message!
ps… I’m looking for an easy way to get a Java implementation of a Matter controller
Completely disagree as there are still so many devices/protocols on the market, that cannot be left behind.
We all know that you are so keen into matter, but there is much more beyond that.
Yes - but there the user is already selecting bindings.
I’m suggesting to search by manufacturer or device name, see the example of @maniac103.
The binding setup is done typically once at first start (for a new user).
My argument is that if there is a smart dialogue that installs the bindings based on manufacturer, device name or technology then it’s not worth the extra effort to implement auto discovery of bindings.
1 Like
Please be aware that openHAB itself is another, well… standard (at least from an outsider perspective) so even openHAB added another standard to the competition by trying to implement a more generic way to control most (if not all) smart devices.
The only “real” solution would be to force all manufacturers to use one protocol, one wireless net, one wired net and so on. But this would prevent progress and new inventions (and its not realistic anyway…)
Where did I suggest that?
Over time, Matter will come to be the defacto standard Home Automation platform, and others will offer specialized products not covered in the Matter standard.
OH Binding architecture is not going away!
I’m NOT advocating for ONE standard, I’m recognizing that the market is moving in a direction and OH needs an easy, good, and compelling story to keep the community engaged and the rest of the world interested in looking at OH.
TCP/IP took over the world and SNA(IBM’s networking standard) died
Sure, but that’S a complete other story.
There are hundreds of “standards” out there, as every manufacturer built its own shit (there are some exceptions, for example knx)
And there are good reasons sometimes for another standard. Matter is not.
I think my suggestion is being misconstrued.
I’m NOT suggesting that OH be MADE INTO JUST a Matter Controller.
I’m suggesting that OH incorporate a matter controller in the Core package.
Then a new user would not have to install and configure bindings for basic use cases for the time when Matter has established itself as the defacto standard for Home Automation. The OH Matter controller would interact with the rest of the OH platform just like the Zigbee, Zwave, and other bindings do.
OH would continue to offer first class support for the “much more beyond that”
Well, if (not when) Matter will some day be the “de facto standard” (I highly doubt that) there will be a matter binding, and that’s it.
There will be a matter binding sooner or later anyway, and sure enough it will have autodiscovery, but you will have to install it like other bindings too.
1 Like
WHEN Matter becomes the defacto standard (reasonable people can disagree with this) and 90% of the market and use cases are covered, making a Matter controller part of core OH makes good sense.
OH would be easy for all of those basic use cases that non-technical users want WITHOUT sacraficing OH support of other platforms, devices, and advanced use cases
No.
IF Matter becomes defacto standard, write a matter controller but don’t try to force openHAB developers to do your will. It’s nonsense to set Matter as a core preference as openHAB itself has a bus, that’s the core, Matter won’t.
and when? 2 years, 3 years from now? Will it really become the de facto standard? Even if it will become the de facto standard, the market share in the beginning will be extremely low compared to all legacy products.
1 Like
Just to respond to this specifically about wizards, and sorry for the delay:
Features like “Add Equipment to Model” and “Create Equipment from Thing” are wizards of sorts, because they deal with multiple entities at once (fill out a form, have items and links created for you).
There’s a first-time user wizard, but it’s deliberately kept to the bare bones because it might annoy if you stretch it too much.
What I very much had in mind, though, is a wizard that could bootstrap your initial skeleton of a semantic model (at least the hierarchy of locations and such).
This could be offered when you go to Settings > Model and there’s nothing to show - you would have a button to start the wizard.
As for wizards that could go from discovering a Thing to using it (items, rules and all), I had this in mind too - we could import “packages” from the Marketplace which could define things, items, rule templates, main UI widgets, block libraries, etc., and then have wizards so a single form would create instances of all of these at once.
But it’s kind of off-topic from the title of this thread IMO, the discussion has shifted from “OH needs more marketing” (like, bi-weekly blog posts?) to “OH is too complex to use”.
3 Likes
excellent, then this part should go in a “Configuration Guide”, not in a “Gestting Started Tutorial”
or another option would be to choose the simplest rule language as an example in the Getting Started Guide and then leave other languages ffor the complete Configuration Guide.
IMHO this is questionable: step-by-step guides are great but for very beginners and for limited parts of the documentation, never seen a software (perhapes just those with billions of users like WhatsApp or Gmail) with step-by-step guide that cover EVERYTHING.
agree, what is there is there, it can be just moved/renamed to a more comprehensive “Step by Step Guides” section.
Still most easy and immediate rewards parts could be moved to a short Getting Strarted Guide.
Well, if one sees an easy Getting Started Guide using a Hue device “from zero to hero”, most users should be able do do the same but with the binding/device they have at home…
if not well, probably theiy are not a OH target user, and they should go better to Alexa/Google Home ecosystems…
you do not need questions at all.
With binding auto discovery, you can directly present a list of technologies found in the house (eg. Sonos, Hue, Google, etc.) and then let the user select which one they want to be integrated by OH.
Then in the some onboaring wizard, one can tell the users he has many other binding that can be discovered by country or brand that he can always add them later even if a specific technology does not get auto discovered (maybe asking some quick question like you suggest here)
A first version of binding auto discovery is in fact fast to implement, and can be incrementally extended to other bindings/services in later releases.
Also consider the fact that one can always add new tehcnologies in their house: with auto-discovery you will discovery immediately a new hardware, while if you stick to questions in the onboarding wizard, you should have to re-run it manually to find new useful binding to integrate your new hw
1 Like